How to Manage Consent in Google Tag Manager

Cookies, GDPR, CCPA, Cookies & More Cookies..

·

4 min read

How to Manage Consent in Google Tag Manager

Cookiebot in conjunction with Google Tag Manager makes consent management incredibly easy. Instructions to get started with Cookiebot and GTM linked here.

In this article I want to specifically cover nuances with the Cookiebot GTM template and how to control opt-in vs. opt-out strategies.

Opt-in vs. Opt-out

Opt-in indicates consent is not granted by default upfront. That is, until a user opts-in to tracking, they are not being tracked. In a real word opt-in configuration, a user visits a webpage for the first time, their consent settings are not initially granted by default. They are shown a consent banner and refuse to interact with the consent banner as they navigate the site. During this time, they are not tracked given the opt-in configuration.

Opt-out indicates consent is granted by default upfront. That is, until a user opts-out of tracking, they are being tracked. In a real world opt-out configuration, a user visits a webpage for the first time, their consent settings are initially granted by default. They are shown a consent banner and refuse to interact with the consent banner as they navigate the site. During this time, they are being tracked given the opt-out configuration.

TypeDefault ConsentImplication
Opt-inDenied ❌Not tracked until action
Opt-outGranted ✔️Tracked until action

Further Cookie Consent Documentation

Controlling Opt-in vs. Opt-out in GTM

Within the GTM Cookiebot template, there are options to control opt-in vs. opt-out strategies by taking advantage of the Regions parameter. This parameters allow a change in the default consent settings by region. If a region is not listed, all default consent settings are set to Denied.

In the example below, I’ve added US and changed all of the default consent states to Granted. In this instance, US users will be configured to an opt-out policy given they are initially tracked until taking action to opt-out and change their consent settings.

This configuration, or any configuration can be tested and viewed within the GTM debugger. My physical location is the US, in the debugger, the on-page defaults are all granted as modified by the Region parameter.

US IP Example - Initial Site Load:

I connected to a IP via a VPN to a location in Denmark, an EU country. Now, the on-page defaults are Denied and continues to be Denied because I have not taken any action on the consent banner…yet.

Denmark IP Example - Initial Site Load:

Denmark IP Example - NO - Interaction with Consent Banner:

The current state gets populated a few milliseconds after the on-page defaults propagate, specifically for the event below, the gtm.load event. At this stage, the consent banner has been displayed to the user.

Denmark IP Example - Allow All Cookies - Interaction with Consent Banner:

After allowing all cookies via the consent banner, Cookiebot pushes a custom event cookie_consent_update that changes the consent settings all to Granted. This is the dataLayer push event in the above screenshot. Point-forward the consent settings are saved in the user’s browser. This is an important step to understand because this is why all tags that fire would normally fire on page load need to be changed to fire on the custom event of cookie_consent_update

Otherwise in this Denmark scenario, the Gtag or any other tags that fire upon page load/page view would not fire because they would initially be blocked by the default consent settings. Once the user takes action to change settings (via consent banner), the custom event cookie_consent_update is pushed to the dataLayer and appropriate tags can trigger off of that custom event. On subsequent page loads after consent action has been taken, Cookiebot continues to fire a cookie_consent_update which applies the saved settings of the user. This ensures the Gtag continues to fire on subsequent page loads (even when the consent banner ceases to be shown).

More Examples

  • US user visits datatribute.com for the first time -> Piwik Pro, GA4 etc is initially triggered and data captured -> User DENYS tracking via consent banner -> User navigates to another page -> Piwik, GA4 etc is NOT triggered.

  • US user visits datatribute.com for the first time-> Piwik, GA4 etc is initially triggered and data captured -> User ACCEPTS all tracking via consent banner -> User navigates to another page -> Piwik, GA4 etc is triggered.

  • Denmark user visits datatribute.com for the first time -> Piwik, GA4 etc is NOT triggered -> Consent banner is shown -> User ACCEPTS all tracking via banner -> Consent Update event is triggered -> Piwik, GA4 etc is triggered for initial page -> User navigates to another page -> Piwik, GA4 etc is triggered.

These examples behave this way because of the opt-in vs. opt-out policies controlled by the Region parameter.

Other Notes

  • Region codes are ISO-3166 A-2 codes. Full list here.

  • Regions that share the same settings can be combined to a comma separated string like US,CA,UK,IT

  • In the context of regions, Cookiebot checks for the users physical location via IP origination