Delay loading of matomo.js until consent is given

[psobeich]

I'd love to see a feature (or default behaviour) that delays the loading of the tracking client until consent is given when consent is set to be required for tracking.

The reason is that by by loading the tracking client Matomo already can track the access (like static image tracking) and there will at least be entries in Matomo's access log.

The adblocker shows a blocked request to matomo.js even without a given access.

I think it helps privacy and reduces customer confusion when matomo.js is requested after consent was given.

[AmazingDreams]

I do think this is a good idea to implement, though it is a very strict behaviour which I think goes beyond the GDPR. If implemented and enabled by default it would break compatibility though as matomo queues actions until consent is given and then the whole backlog of events is sent to the server.

However, I can see creating an additional option delayLoading, with appropriate documentation that Matomo will be unavailable entirely until setConsentGiven is called. We could create a simple object with one function and put it in place of $matomo, or maybe better expose it through VueMatomo. When this function is called it would load the matomo script and matomo would be available again.

Pseudo:

// main.js
Vue.use(VueMatomo, { delayLoading: true })

// CookieWall.vue
acceptCookies() {
   VueMatomo.loadAndSetConsent()
}

Obviously, the simplest solution would be for people to remove access logging from matomo.js server side

[unikitty37]

Not sure about going beyond GDPR — as a site visitor, if I deny consent for tracking and then later allow it, I don't expect the stuff I did in between to have been tracked!

That's especially the case where the Matomo instance is hosted by a third party, because I've said that I do not consent to my personal data being sent to them, not that my personal data should be sent to them as long as they ignore it. (One thing so many people implementing consent dialogs forget is that it's consent to processing of data, not consent to cookies 😀 )

It's probably more Matomo's issue to deal with, though; delayLoading would be a useful feature.

As it is, this issue has made me worried about using Matomo at all, as I don't want to have to deal with the issues that will arise if somebody finds out they've been tracked when they shouldn't be…

[AmazingDreams]

You have a clear reason for tracking certain data without explicit consent - access logs are there to help identify server load issues, hacking attempts, etc. The GDPR does not provide people the absolute right to destroy any random piece of information that is gathered about them. Only personally identifiable information, such as IP addresses, names, etc, that has no clear reason to have been gathered. However if there's a clear reason that this data is required for delivering services, the data is not required to be removed (within reason of course, there is no reason to store access logs for 5 years - unless you actually have one). It is advisable to hash or remove parts of the IP addresses though, just in case.

In case of third party hosting. I think that if you do not trust them to responsibly handle access logs, you can't trust them with the full analytics data either.

The GDPR is there to stop companies from gathering every single thing they can get their hands on. To enforce that every piece of information that is gathered, has a clear reason that it is there. If there is no clear reason, consent is required, and consent can be revoked.

Disclaimer: I am not a lawyer and this is not legal advise

[unikitty37]

Thanks for answering — I think the question (which is definitely for the Matomo devs, not for you :) is what does Matomo queue up and send along in those circumstances? If nothing else, that's something that a site developer would need to know in order to make sure the privacy policy is accurate…