Disclaimer: The methods described in this post are to be seen as educational, and should in no way be seen as a legal advice on GDPR compliance.
In times of GDPR and digital marketing privacy scandals, many of us have been motivated to re-think and implement a tougher consent flow on our sites, making sure we don’t track sensitive data about users who have not actively agreed. With this post I wanted to describe how we at Precis have decided to interpret the new legislation and implement our consent flow.
Consent Flows Throwback
In these solutions, it’s common practice that the banner is visible until the user actively has ”accepted”. When a user clicks ”I accept”, a cookie is placed in the browser with some information noting the acceptance. The next time the user visits the site, a check is done for this cookie, and if the correct value is found, the banner is hidden.
Updated Consent Flows
Thanks to Google Tag Manager, we can re-use our old way of thinking and apply a similar method for our tracking consent flow. The method we’ll be using is that “if consent-cookie is not true, then block all marketing tags from firing”.
1. Find the name of the cookie used to store “consents”
2. Create a cookie-variable in Google Tag Manager to pick up the value from the cookie
3. Create “negative” triggers for pageviews or any custom events you are firing marketing tags on today
4. Add the negative triggers as “Exceptions” in your marketing tags
Why negative triggers?
The reason I choose to use a negative block approach is to keep my tags and triggers as modular and reusable as possible, and it makes it easier to add and remove the blockers as needed for individual tags. And similarly to the benefit of using Settings variables, if your consent flow changes, and you need to update the triggers, you only have one to update, rather than repeating the updates for each individual tag.
Obviously, your consent flow may vary from ours, but it is likely that your site has some way to ”know” that a user has accepted cookies or given consent to being tracked. This might be done on the client-side, like in our case, or at the server-side, and in that case it is likely the page gets a notice from the server by either a server variable or perhaps even a push to the dataLayer. Nevertheless, while your mileage may vary, the basic method still applies.