_paq you get another (visitor has the same IP, so it’s confirmed that it is the same user). Is it true, then, that you cannot mix different APIs for one visitor? You have to use either the PHP API for everything, or JS for everything? And since we need to use the PHP API for some cases, we have to replace all JS tracking code with PHP API calls?
Don’t be so confident. Many ISPs distribute access to the same iP address across a broad range of consumers. I would venture to say that in the vast majority of cases it takes more than a simple IP address to clearly identify a visitor.
Also, keep in mind that there is a built in lag between the time when data is collected and the time that it is made available for reporting. Before the new update the default was 90 seconds, if I remember correctly. You can make the reporting time immediate, if you like, but I would not advise this, if you have a very large number of visitors. Matomo is by definition a resource-intensive piece of software.
We tested with our own computers as well as with customers, and it followed the same pattern (checked using live visitor log). After replacing our
_paq JS calls with only PHP API calls, the system now works. I can only conclude that Matomo works correctly as long as you use only one API system, so no mixing. The manual should reflect this, IMO.
There’s one big drawback with only using the PHP API, and that is you can’t successfully install a front-end cache like Varnish.
“The manual should reflect this, IMO.”
The manual does reflect this, as I distinctly remember a caution against mixing. But, as with all guidelines, one must be practical in their application.
If everything is sent to the database, before it is reported, then mixing should not be a problem, so long as what is sent to the database is not duplicated or contradictory.
Do you have a link?
Well, if PHP API
getVisitorId always returns another value than JS
getVisitorId, there can’t be a sensible way to mix the two, right?