We are using Matomo without Cookies, Javascript or Pixel tracking. Just sending each tracking event directly by server-side API request.
This is working well, with the exception of logging the device resolution. We have a small piece of Javascript code which sends this info to the server on the first page load of a session, and then it is available to send to Matomo on subsequent page loads.
The problem is that if the resolution is ‘unknown’ (API parameter res not passed) on the first tracking event, then it seems to stick with this value for the whole visit, even though we are subsequently sending the resolution data with every other tracking event.
I understand that some visit data needs to stay static and keep the initial values, but I would expect a value which was missing when the visit was started to be updated if subsequent tracking events provide this data.
I hope this makes sense! Is there a way to get it to work?
Hi @seb303
Your problem is probably that the tracking (done server side as you said) is done before the first page rendering user side (it is done for serving the first page).
One thing you could do is start the tracking only after receiving the user screen resolution from our script. But then it would make the tracking a lot more complex, as for first page of the visit the tracking behavior will be different (you’ll have to identify the first page of a visit). Or else track only with JavaScript (for all trackings)…
Yes, as you say, the problem is that the user screen resolution is not known when the first page impression is tracked.
We are not using the Matomo Javascript at all as it’s overkill just to read the screen resolution, and there are some things which must be done via the HTTP API. We just have 3 lines within our own Javascript which checks if the screen resolution is known (or has changed), and if not then sends an AJAX request back to the server to record this for the user session.
So what we need is a way to update the resolution for the current visit from ‘unknown’ to the actual value. The API seems to just ignore any actual value and prefer to keep the value ‘unknown’, or whatever was first sent.
I can confirm that Custom Dimensions do update the original visit data in the log_visit table each time a new value is sent. So that is a possible solution for our use case.
But it’s a shame that this way we can’t use the standard field, so the data can appear within the Devices and Software/Configurations sections of the UI.
Since it seems the architecture does support updating Visit data from subsequent tracking events. I’m wondering whether it may be possible to make a Plugin which would change the behaviour of how the Resolution value is recorded. But I fear it may take me a lot of time to figure our the internal architecture enough to do this…
I edited plugins/Resolution/Columns/Resolution.php and added:
public function onExistingVisit(Request $request, Visitor $visitor, $action)
{
// Also update value for subsequent tracking events in visit
return $this->onNewVisit($request, $visitor, $action);
}
Now I just have to figure out how to make a plugin which can extend the Resolution class, as obviously it’s not ideal to make edits directly to a core plugin!
Is it possible to make a plugin which extends the class of a core plugin, and would then be used in its place?
Or perhaps it would be nice if the Core plugin itself had an option for this behaviour.
In the end, it seemed cleaner to patch the actual Resolution (and DevicePixelRatio) plugins rather than creating another plugin to override the behaviour.
