In some cases the tracking code implementation for tracking User IDs can be setup incorrectly or the application/tracking code is not able to correctly retrieve a device UID (In the case of apps)
In these situations the User ID may be set to
Since the default setting in Matomo 4 is to overwrite Visitor ID (
idvisit) with User ID this can potentially result in all visits being tracked under a single User ID and Visitor ID.
A perhaps easy solution for this would be to have Matomo ignore the User ID (And
_id from the tracking request if the tracking request contains the same as the User ID) if it is
undefined or some combination of all zeros (This can hopefully catch any combination of zeros and special characters such as
- in the User ID when people are using device IDs for User ID)
We ignore the userId for such visits on the cloud. Also for
nil etc. But for On-Premise we don't do it just yet as it can be hard to debug and find out why something is not working. Eg you get a bug report userId feature not working etc vs you can see it that you have an error when
undefined comes up in the userId report. It may be possible to use the tracking failure feature for this but it's not 100% the same because we wouldn't fail the request in that case but simply unset the userId.
Is there any sort of softfail for tracking? More like a warning than a total tracking failure?
Not really AFAIK. We could maybe in the user report add a footer message at some point and mention it if we notice some of those values that look faulty were detected. Most of the times, when undefined or something similar is used then the majority of visits have such a userId and it could be also seen likely in the report quite clearly anyway (obviously it's not super clear but saying it as it reduces the priority of the issue a bit).
@tsteur Okay, I understand.
Would it maybe be possible to log a warning when a User ID or Visitor ID is ignored if we do implement something like this instead of a tracking failure?
The main reason I'm thinking it might be a bit higher priority is there is no way to correct tracking data that is tracked with the incorrect User ID or Visitor ID(because User ID overwrites Visitor ID by default) which means all the tracking data sent with the incorrect data would basically be useless for a lot of reports.
I guess something like this could be setup as a Custom Alert though, which might be a much easier method.
@Starker3 we don't have any such logging in tracker method just yet unfortunately.
@Starker3 we could probably add this otherwise as a system check and look at eg last X days of data to see if this happens but then it may sometimes show up in the system report and then disappear again and then show up again whenever the bug happens. And once it's been fixed it would be still shown for a while and would only disappear after X days of fixing it. The logs itself wouldn't be too helpful likely as it would still take someone to look at these and that's not always possible/doable especially since file logging is not enabled by default and we also don't log in tracker just yet. If it's a permanent problem then it be likely directly visible in the UserID report (could add a footer message). Optionally, we could also show it in the system report indicating there may be a problem but it can be confusing.
Usually, we just "error" these tracking requests when unexpected data is past as this is the best way to make people aware there is a problem. If this happens to all userId requests then it would be quickly noticed likely but it may be hard to notice this when it only happens for a portion of the users so it might not be the best idea here.
Generally, we wouldn't really want to ignore these values though as someone might be wanting to track these values. For example someone might actually have the userId "undefined" I suppose. It's better making a problem visible rather than ignoring it automatically.
@Starker3 closing this one for now as wontfix. If users click on the userId report in the reporting menu then it's easily visible that there is a problem with the userId tracking.