I’ve played around with matomo and it’s API now for couple of days and run into this problem:
With cookie-based tracking, retrieving the visitorId using the Http API is straight forward and works fine:
$tracker = new MatomoTracker();
$visitorId = $tracker->getVisitorId();
→ The MatomoTracker::__constructor inits MatomoTracker::cookieVisitorId with the id found in the cookie and calling $tracker->getVisitorId() returns this very fitting id. So my Tracks send via PHP will be aligned with the other visitors data inside Matomo .
As i understood, cookieless tracking uses other metrics, than a primitive cookie, to determine a consistent visitorId to buildup a visitors profile. Viewing the path taken by a user in Matomo Reports who is not tracked using cookies i can confirm this works quite good! Also the user has obtained a visitorId!
But, and here comes the problem. When Cookieless tracking is enabled and MatomoTracker::__construct is doing it’s thing, no cookie is discovered and MatomoTracker::cookieVisitorId remains uninitiated (false).
Calling $tracker->getVisitorId() now returns MatomoTracker::randomVisitorId (the only MatomoTracker::*VisitorId filled). This is, as the name suggest, always a different one and eventually, every report send with the $tracker can’t be aligend with the existing visitor profile already inside Matomo!
I feel the data contained in the query rendered by MatomoTracker is wrong.
Oh yes, I’ve read all the docs I found carefully. So this is either not (yet) implemented or something goes wrong.
The browser tracking has a number of other factors like resolution, country, browser version and other params to create semi-reliable user ID based on a hash of these things (simplified explanation).
From the PHP API tracker, these need to be provided by some other way from the calling code, as there are no other data points that can be used to mimic what the browser based tracking is doing.
So the back-end can set the visitor ID e.g. based on a logged in user, ecommerce user etc. or any other available information, but needs to calculate/derive that in the code outside of the tracker API call, so it’d be a responsibility of whoever is implementing the API call.
Thanks for the clarification. I somewhat hoped to find a (simple) way to make browser and backend tracking align with the same visitors because some events are much easier to dispatch in the backend.
But of course, the relatively arbitrary/intransparent way visitors are recognized when using cookieless tracking makes this difficult. Even if I code a working solution, it likely will require a ton of maintenance.
Would love to see both APIs - browser and backend - being able to recognize visitors in the future like cookie-based tracking was capable of using the consistent VisitorId stored in the cookie.
Meanwhile, I found a working + solid solution:
Generate an event array in the backend
Supply the array to your frontend (using ajax)
Let the Matomo browser client dispatch it
This way, you get both: backend-generated parameters + visitor recognition!
There is another advantage: If the user’s browser suppresses JS, your “backend” events, delivered via the frontend, are also suppressed! No data distortion
I’m using Drupal for my backend and can tell more details about implementation. Just leave me a note if you’re interested.
For Drupal, there’s a freshly backed module to easily trigger Browser Clients from Backend. I’m successfully using this now for my case. http://drupal.org/project/trigger_api
.
. When Cookieless tracking is enabled and 