@ktrhn opened this Issue on November 16th 2016

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.

@tsteur commented on November 16th 2016 Owner

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.

@ktrhn commented on November 17th 2016

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 commented on November 17th 2016 Owner

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 commented on November 18th 2016

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,

@ktrhn commented on November 19th 2016

@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 commented on November 20th 2016 Owner

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 commented on November 20th 2016 Owner

Maybe for Piwik 2 we could restore the old logic,

@tsteur :+1: for a smooth LTS

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

:+1: 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 commented on November 20th 2016 Owner

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 commented on November 21st 2016 Owner

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 commented on November 21st 2016 Owner

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 :+1: 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 commented on November 21st 2016 Owner

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 commented on November 21st 2016 Owner

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 commented on November 21st 2016 Owner

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 commented on November 21st 2016 Owner

👍 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

@ktrhn commented on November 27th 2016

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 commented on November 27th 2016 Owner

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 https://github.com/piwik/piwik/issues/10797

@tsteur commented on November 27th 2016 Owner
@ktrhn commented on December 2nd 2016

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 commented on December 21st 2016

@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 commented on December 26th 2016 Owner

@tsteur What should we do with this issue? is there anything we can / want to do here? besides merging https://github.com/piwik/piwik/pull/10888 ...

@tsteur commented on December 27th 2016 Owner

There would be only https://github.com/piwik/piwik/issues/10951 otherwise

@mattab commented on December 27th 2016 Owner

Ok so closing as #10888 is assigned to 2.17.2

This Issue was closed on December 27th 2016
Powered by GitHub Issue Mirror