When cookie-less tracking is enabled some features don't work for example:
Because the features become very broken after cookie-less is enabled, people tend to get confused, and ask questions, or they may use the data not knowing it's very wrong! So it would be really useful to somehow hide these reports from users, or make it otherwise crystal clear that they shouldn't use this data. What do you think?
Note: we'd leave Visitor profile as it's helpful when user id is used
required for https://github.com/matomo-org/matomo/issues/15507
Hiding this data was also suggested in https://github.com/matomo-org/matomo/issues/13655#issuecomment-616892565 but we didn't do it since it can currently not be enforced and is only done client side. There are few more features like Cohorts, Multi Attribution, Visitor Profile, etc. Hiding this features might only be a good idea though if not also the userId feature is used.
Here's what @mattab and I discussed:
We archive a new metric "nb_profilable". It is the sum of how many people had cookies (or similar technology such as advertising identifier on iOS etc) enabled to identify them over several visits. If 99% or more of the visits were not "profilable" (had cookies disabled), then we assume the site is tracking cookie-less and remove certain features etc see issue description.
It basically means for every requested date range we probably also need to check if there were "profilable" visits or not.
We don't need to expose the new metrics to the UI for now but could do this later. This can be quite useful later to be able to see what percentage basically consented to cookies etc.
@mattab I just looked in the code and
log_visit.profilable=1 also when userId is used. This kind of makes sense because a profile for that visitor is possible. So in the small percentage where users use the userId feature then we would not disable the features mentioned in the issue description. Not sure if this would be an issue or if we would want to workaround it?
just looked in the code and log_visit.profilable=1 also when userId is used. This kind of makes sense because a profile for that visitor is possible. So in the small percentage where users use the userId feature then we would not disable the features mentioned in the issue description. Not sure if this would be an issue or if we would want to workaround it?
Good question... Btw as I'm not sure anymore how the field profilable is used by Matomo. could we document the field in https://developer.matomo.org/guides/persistence-and-the-mysql-backend and maybe add an entry in glossary for Profilable https://glossary.matomo.org/ (or a FAQ if there's enough material but probably not)?
if we were to workaround, what would be the options?
(eg. would it make sense to have a separate column set to 1 when visitors had tracking cookies activated?)
Profilable means you can create a profile of a user. That's either through cookies, userId or a fixed set visitorId.
select sum() where profilable = 1 and user_id is null or something... It wouldn't be 100% accurate maybe since a user maybe has cookies plus
user_id (the user_id feature was implemented wrong from the beginning so it's hard to separate). I guess it might be edge case though as only small percentage of our users use
user_id and technically
user_id would need consent anyway so you can assume in most cases cookies were used.
Let's keep it simple and simply sum how many users had
profilable=0 and when 99% or more of visits were not profilable then we disable all the features.
should metrics be disabled in the API as well? or just the UI?
Since we remove metrics from the UI, we would also ideally remove them from the API (so it's consistent with the UI, and also so that the data shown in API is trusted and it's good to know it doesn't return invalid data).
Also could you keep track of which metrics are affected and compile them in a list, so you can publish the list of API metrics/reports affected in the existing FAQ: https://matomo.org/faq/general/faq_156/
should segments (ie, visitorType) be disabled (ie, removed)?
When a segment is not compatible with the current site, then we could "hide" the segment from the list in the UI (but in the Segment APIs we would still return all segments).
Also we want to make sure data for any segment on any website is not archived if the segment is invalid for this website.
Regarding hiding segments, it would be great to also add a section in https://developer.matomo.org/api-reference/reporting-api-segmentation for example
List of segments that require tracking cookies where we explain some segments are hidden and list the segments that require cookies.
and ideally we also mention in the user guide https://matomo.org/docs/segmentation/ that some segments require tracking cookie and link to the list on the developer page.
@diosmosis do you think we can finish this issue ideally this week so it can make it into the release?