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 (
$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.
This technical question seems very specialized, maybe @innocraft can give you some tips on this?
Hi there @TomSaw,
I would say it works as expected.
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.
Does that make sense?
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.
- Matomo Tag Manager
- GA Tag Manager
- … (whatever you adapt it to)