Piwik multiple domains - tracking on one but not another


#1

Hi guys,

I have two domains I want to track. One hast ID 1 (www.computerhilfe-eppelheim.de) the other one 3 (klanzeiger.de). 1 gets tracked without any issues, but 3 does not get tracked at all. Both times I use the same piwik installation to track.

I have no idea how such a thing can happen.

any suggestions are highly welcomed!


#2

The problem still persists. The code seems to be ok. I can see it in the source of the page on the domain that is not tracked. So the problem must be with Piwik.

Anyone had same problems and solved it?


#3

Up - the problem still persists after update to piwik 1.12

Please if you have any suggestions or need further information I can provide whatever you need. It really bothers me that it is not working. I can see the code in the browser, so it gets loaded.

But somehow the piwik installation does not register it. Piwik works perfectly with another site on the same server.


(Matthieu Aubry) #4

PLease try debugging your tracking code as explained in: http://piwik.org/docs/tracking-api/reference/#toc-debugging-the-tracking-api-requests


#5

I am having the same or similar problems tracking multiple siteids after updating from an earlier release. Synchronous or asynchronous tracking no longer work for multiple siteids. This is a huge problem for my site as I track articles written by different authors in a common siteid and individual authors in their own siteid. This allows me to provide them analytics to only their information through a login with view access to their siteid/website.

I can provide code, but the code on my site was taken from the Piwik documentation on multiple site tracking and nothing changed other than updating the Piwik version. I looked for but did not see documentation on this functionality changing.

Is there an update/fix for this in the works? Or do I need to back out the updates?


(Matthieu Aubry) #6

Sorry, async does not work for multiple site ids. I have clarified the doc at: https://piwik.org/docs/javascript-tracking/#toc-multiple-piwik-trackers

“Note: When using multiple trackers, you must use the synchronous Javascript tracker object (ie. this will not work with the asynchronous tag):”


#7

Thanks for the inputs and update.

Maybe there are caveats I don’t know about, but I have found async tracking to multiple websites to work properly.

However, when I updated from 1.9.2 to 1.12, async tracking stopped working when tracking to 2 websites. Both hits were being tracked in the 2nd website. I changed the code on my website to implement synchronous tracking, but it also failed.

If I use the javascript files (piwik.js and the js directory) from 1.9.2, tracking multiple websites worked properly again.

Here is the tracking code from my website which works on 1.9.2, but doesn’t on 1.12.

I will retest the synchronous code since there may have been some caching issues–the same ones that steered me to trying the old javascript files. Let me know if there are details I can provide to help debug/characterize this.

I would like to understand what is happening and if it is a bug, have it fixed as I’d like to use the official code/scripts.


(Matthieu Aubry) #8

It is “by design” and a design decision I took, to make sure that even if users call setSiteId() “after” trackPageView() then Piwik still knows the site ID: The code is: matomo/piwik.js at master · matomo-org/matomo · GitHub

It is not very good and so, maybe we could fix it so it still works with multiple site ids. For example we could “move up the queue” the setSiteId() only “once” before each call to trackPageView() or so. But it could become complicated. hence my decision to just “not support” it still SYNC code works


(mauser) #9

There is a quick, but dirty workaround. You can push to a function, and then Piwik won’t execute it in the first place, but sequentially:

In other words, the second site tracking should be something like:

_paq.push([function(){
_paq.push([“setSiteId”, “2”]);
_paq.push([“trackPageView”]);
}]);


(Matthieu Aubry) #10

Not too bad a workaround, actually. Thanks for posting it here!