2.17.1 JS-Tracking does not work anymore #10878

sebastianhelbig · 2016-11-16T16:28:25Z

Seems to be related to #10818
Now trackig does not work anymore in my app as the _paq property does not get initialized and just stays an array. I have to manually add

if (!window.Piwik.getAsyncTrackers().length) {
    window.Piwik.addTracker();
}

in my tracking code to activate tracking again.

The text was updated successfully, but these errors were encountered:

tsteur · 2016-11-16T18:26:01Z

How do you embed your tracking code into your website? Feel free to send us a link to hello at piwik.org and leave a comment here afterwards in case it goes into spam folder.

sebastianhelbig · 2016-11-17T10:09:23Z

index.html:

<body>
…
<script src="…piwik/piwik.js" async defer></script>
</body>

After the app has loaded:

if (!window.Piwik.getAsyncTrackers().length) {
    window.Piwik.addTracker();
}
window._paq = window._paq || [];
window._paq.push(['setTrackerUrl', …piwik.php']);
window._paq.push(['setSiteId', 1]);

After every routing event / url change:

window._paq.push(['setCustomUrl', window.location]);
window._paq.push(['trackPageView', window.document.title]);
window._paq.push(['enableHeartBeatTimer', 10]);

In the 1,5 days I had visitors which where tracked, but only around 10 percent of the usual numbers. So either the had an older version of the app loaded or the code was running for some users/browsers (but browser statistics seem to be the same). I tested it in Opera 41, there tracking did not work without

if (!window.Piwik.getAsyncTrackers().length) {
    window.Piwik.addTracker();
}

tsteur · 2016-11-17T18:05:32Z

Maybe sometimes the piwik.js was loaded before your script was executed?

The _paq.push calls are supposed to be placed before Piwik is loaded, then it would work. We could fix this issue, however I'm not sure if we should. When setting _paq.push methods after Piwik has loaded, the tracker methods won't be executed in the right order and therefore random bugs may occur that we have fixed in the past. For example Piwik might set a cookie and only later the "disableCookies" is applied, or set cookies are set on wrong domain etc.

@mattab should we maybe in such a case log an error or so explaining the tracker should be initialized before Piwik is loaded?

@ktrhn if you place just one _paq.push call before the loading of piwik.js it should work for you again as usual as a temporary workaround. If not, I would execute this at the end after calling all _paq.push methods:

// ...paq.push()...
if (!window.Piwik.getAsyncTrackers().length) {
    window.Piwik.addTracker();
}

This makes sure the correct order of tracker calls will be respected

GuilloOme · 2016-11-18T19:40:14Z

Before using this fix, I had the same issue.
I integrated piwik.js in a angular single app and run it in the angular startup sequence (created a custom module with a hook on startup).

I understand that it's a safety feature to keep it this way. But it could be nice to document it and add a error in log for the not standard context like mine.

Thanks,

sebastianhelbig · 2016-11-19T18:52:59Z

@tsteur Thank you for the explanation. As I only load piwik.js and the javascript of the single page application (which is quite large), most of the time Piwik will get loaded first. So I will use your workaround. A note in the documentation (or when showing the tracking code for a website in the piwik app) would be nice, as I don't think single page applications are uncommon these days.

tsteur · 2016-11-20T18:31:45Z

I'm not sure how it is related to a single page application. Wouldn't it be still possible to add least define eg the following in HTML head before loading the files?

_paq=[];
_paq.push(['setTrackerUrl', …piwik.php']);
_paq.push(['setSiteId', 1]);
_paq.push(['enableHeartBeatTimer', 10]);

In theory one of them would be enough but the configuration for the Piwik tracker should be always configured upfront as explained as otherwise random bugs may occur.

Maybe for Piwik 2 we could restore the old logic, for Piwik 3 we could show a warning explaining tracker needs to be initialized upfront. @mattab @sgiehl any thoughts?

mattab · 2016-11-20T22:23:49Z

Maybe for Piwik 2 we could restore the old logic,

@tsteur 👍 for a smooth LTS

for Piwik 3 we could show a warning explaining tracker needs to be initialized upfront.

👍 were you thinking of a warning in the browser console (or even throwing exception in the tracker), or to show warning in the Piwik tracker code generator page, or maybe both?

tsteur · 2016-11-20T23:43:35Z

tracker code generator does not make sense. Would only confuse people etc. Instead we need to show it in the browser console if someone decides to do it differently

tsteur · 2016-11-21T01:16:17Z

for Piwik 3 we could show a warning explaining tracker needs to be initialized upfront.

Just to be clear, I was thinking of not tracking at all in that case. Or is it supposed to still "work" because it wouldn't really "work", or only in some cases when they call all methods in correct order

mattab · 2016-11-21T01:48:51Z

Or is it supposed to still "work" because it wouldn't really "work", or only in some cases when they call all methods in correct order

would be great to track data 👍 Ideally if we can detect the necessary methods were called in the right order, and tracker could initialise properly, then tracking will work and no error displayed in this case. would it be maybe possible to display error and not init tracker only when the JS API was effectively mis-used?

tsteur · 2016-11-21T02:20:28Z

would it be maybe possible to display error and not init tracker only when the JS API was effectively mis-used?

No.

I will update PR to track data then. Even though IMO we should protect users from something like this. Because of such behaviour we track in couple of cases wrong data eg server side when someone tracks data for visits > 4 hours. Users do not expect this and because it still seems to "work" users assume there is no problem. Still tracking data in such cases is not helping users and over times makes certain features unusable. Eg where we ignore time > 4 hours and set it to now, it prevents users from being able to use offline feature which is needed nowadays.

tsteur · 2016-11-21T02:39:28Z

I have updated PR.

FYI: It may also "break" custom tracker plugins. They might call _paq.push to an unconfigured tracker which causes tracking requests being sent to the same URL that is currently viewed instead of the tracker. IMO the Piwik Tracker should actually never work when it is not configured upfront. It will cause over time various issues created in the issue tracker, hard to reproduce issues, support requests, etc.

mattab · 2016-11-21T03:14:48Z

IMO the Piwik Tracker should actually never work when it is not configured upfront. It will cause over time various issues created in the issue tracker, hard to reproduce issues, support requests, etc.

as one of our key goal is to reduce support requests especially around such potentially complicated to debug issues, it is fine to not track at all and just show the error when tracker was manually initialised too early (in Piwik 3 where we can break BC and document changes).

tsteur · 2016-11-21T03:27:40Z

👍 done, changed tracker again. This will definitely reduce bug reports, wrongly tracked data, and make it easier to maintain tracker in the future and to maintain custom tracker plugins

sebastianhelbig · 2016-11-27T15:20:41Z

I'm not sure how it is related to a single page application. Wouldn't it be still possible to add least define eg the following in HTML head before loading the files?

You're right. I changed it like that. I think the problem was/is that there are piwik extensions/addons for ember and angular which do not do it like that for some reason. But of course that is not a problem which should be discussed here.

tsteur · 2016-11-27T18:59:40Z

Interesting. Didn't think of this but does make sense. I presume in such a case you configure the tracker URL and idSite via a config and then ember / angular extension configures itself?

One way to solve this would be to merge/minify piwik.js with all the other files and make sure piwik.js is loaded at the end but this adds problems when Piwik gets updated which means you would need to update the piwik.js in your project and deploy your app/website just because of Piwik.

Maybe we need to rethink the tracker a bit more to allow such things in the future, eg like _paq.push([['setSiteId', '5'], ['setTrackerUrl', 'http://www.example.com'] ['trackPageView']]). When we get an array of push methods for initializing the tracker we can always sort them before executing the trackPageView. Or maybe it would be like recommended to use _paq.push(['addTracker', [['setSiteId', '5'], ['setTrackerUrl', 'http://www.example.com'], ['trackPageView']]]) in such a case

refs #10797

tsteur · 2016-11-27T19:06:07Z

Just added a comment to #10797 (comment)

sebastianhelbig · 2016-12-02T11:17:45Z

I presume in such a case you configure the tracker URL and idSite via a config and then ember / angular extension configures itself?

Exactly. For ember I now modified the ember-cli-piwik addon to use the configuration to setup the index.html where the original piwik tracking code is used (except for trackPageView which is used in the ember app after route changes).

ron23 · 2016-12-21T23:33:50Z

@tsteur Just to add some insights of how we use Piwik in the company I work for. It might be an edge case but definitely something to think about.
We don't do SaaS. We install our app "On-premises" and we have longer release cycles because of it as well.
To make a long story short - we set the site id based on some configuration that are loaded after the app was loaded, and after login. We don't really care about traffic that much, we care more about usage and patterns.
Since we use React, we basically have a component that's responsible for fetching piwik.js and setting the right configuration. We can't set it in the index.html file cause we don't know the configuration at that time. We can't have multiple index.html cause we don't build for each client his own version, and we can't deploy piwik.js ourselves cause maintaining it will be hard like you mentioned.

I think everything worked correctly up until it start breaking (that's how I got to that ticket).
It would be great to have more control on the configuration after loading the page.

mattab · 2016-12-26T03:43:19Z

@tsteur What should we do with this issue? is there anything we can / want to do here? besides merging #10888 ...

tsteur · 2016-12-27T01:15:57Z

There would be only #10951 otherwise

mattab · 2016-12-27T09:36:27Z

Ok so closing as #10888 is assigned to 2.17.2

mattab added the Bug For errors / faults / flaws / inconsistencies etc. label Nov 17, 2016

mattab added this to the 2.17.2 milestone Nov 17, 2016

tsteur mentioned this issue Nov 21, 2016

Added possibility to create tracker automatically via paq after piwik… #10888

Closed

tsteur mentioned this issue Nov 21, 2016

Show warning when paq.push is not initialized correctly #10889

Merged

tsteur mentioned this issue Nov 27, 2016

Change default recommended JavaScript Tracking Code #10797

Closed

tsteur mentioned this issue Dec 3, 2016

Make Tracker work when initialized after piwik was loaded or when using multiple trackers without _paq #10951

Open

mattab closed this as completed Dec 27, 2016

mattab added the answered For when a question was asked and we referred to forum or answered it. label Dec 27, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

2.17.1 JS-Tracking does not work anymore #10878

2.17.1 JS-Tracking does not work anymore #10878

sebastianhelbig commented Nov 16, 2016

tsteur commented Nov 16, 2016

sebastianhelbig commented Nov 17, 2016 •

edited

tsteur commented Nov 17, 2016

GuilloOme commented Nov 18, 2016

sebastianhelbig commented Nov 19, 2016

tsteur commented Nov 20, 2016

mattab commented Nov 20, 2016

tsteur commented Nov 20, 2016

tsteur commented Nov 21, 2016

mattab commented Nov 21, 2016

tsteur commented Nov 21, 2016 •

edited

tsteur commented Nov 21, 2016

mattab commented Nov 21, 2016

tsteur commented Nov 21, 2016

sebastianhelbig commented Nov 27, 2016

tsteur commented Nov 27, 2016 •

edited

tsteur commented Nov 27, 2016

sebastianhelbig commented Dec 2, 2016

ron23 commented Dec 21, 2016

mattab commented Dec 26, 2016

tsteur commented Dec 27, 2016

mattab commented Dec 27, 2016

2.17.1 JS-Tracking does not work anymore #10878

2.17.1 JS-Tracking does not work anymore #10878

Comments

sebastianhelbig commented Nov 16, 2016

tsteur commented Nov 16, 2016

sebastianhelbig commented Nov 17, 2016 • edited

tsteur commented Nov 17, 2016

GuilloOme commented Nov 18, 2016

sebastianhelbig commented Nov 19, 2016

tsteur commented Nov 20, 2016

mattab commented Nov 20, 2016

tsteur commented Nov 20, 2016

tsteur commented Nov 21, 2016

mattab commented Nov 21, 2016

tsteur commented Nov 21, 2016 • edited

tsteur commented Nov 21, 2016

mattab commented Nov 21, 2016

tsteur commented Nov 21, 2016

sebastianhelbig commented Nov 27, 2016

tsteur commented Nov 27, 2016 • edited

tsteur commented Nov 27, 2016

sebastianhelbig commented Dec 2, 2016

ron23 commented Dec 21, 2016

mattab commented Dec 26, 2016

tsteur commented Dec 27, 2016

mattab commented Dec 27, 2016

sebastianhelbig commented Nov 17, 2016 •

edited

tsteur commented Nov 21, 2016 •

edited

tsteur commented Nov 27, 2016 •

edited