Since GDPR came into force on 25 May 2018, websites should be providing clear information to their users around what cookies are being dropped on their devices.
Under the GDPR legislation, personal data is defined broadly as information that relates to an individual either directly or indirectly, or by reference to an identifier. It also sets out a legal basis for the collection and processing of personal data where consent plays a big role.
Therefore, if your website has any cookies other than those necessary for its basic functionality, then you must obtain the consent of the user prior to collection and processing of data.
In this example, we will walk through how to set up CookieBot via Google Tag Manager so that only users who have consented to tracking have their data collected.
This methodology will work with other acceptance tools on the market, though the implementation may differ depending on how they handle the acceptance criteria.
We have assumed for this guide that you have already set up CookieBot and applied it to the website. This can be either hardcoded, or by using CookieBot’s tag within Google Tag Manager.
We also assume you have a basic understanding of Google Tag Manager and have segmented your cookies into the various buckets: Necessary, Preferences, Statistics and Marketing, which can be accomplished within your CookieBot login.
Required Variables in GTM
Firstly, in Google Tag Manager, open your workspace and navigate to the variables section using the navigation on the left of the screen.
First-Party Cookie – CookieConsent
Under User-Defined Variables, click ‘new’ to add a new variable, and choose 1st-Party Cookie as the variable configuration. This will allow GTM to read the cookie dropped by CookieBot to denote consent. This cookie is called ‘CookieConsent’, and should be added into the cookie name as part of the variable.
For this example, we have named the variable: cookie – cookie consent.
Marketing, Preferences and Statistics Lookup
Next, we need to add a variable which will allow us to use the cookie value and determine if the user has consented to the various buckets. The step needs to be repeated for each bucket.
Create a new variable under the user-defined variables, and this time, use ‘RegEx Table’, as this allows us to perform partial matches against the cookie value.
Looking at the marketing bucket first, the input variable needs to be our first party cookie variable (cookie – cookie consent).
Then the pattern and output should be set to the below:
Row 1: Pattern: marketing:true
Row 1: Output: true
Row 2: Pattern: marketing:false
Row 2: Output: false
Default Value: false
This works by performing a search on the ‘pattern’ and then returning the output. A user who has consented will output to true, and those who have not will output to false. The default value should be set to false, as this will prevent data from being tracked should something be incorrect.
You should also ensure under the advanced settings, ignore case is ticked and both Full Matches Only and Enable Capture Groups and Replace Functionality are unticked.
The full regex table setup is shown below:
For our marketing consent lookup, we have named it ‘rgx – marketing consent’ in this example. We also need to create the same table but for preferences and statistics, to ensure full coverage of the consent mechanism. Details for each are below:
Variable name: rgx – preferences consent
Row 1: Pattern: preferences:true
Row 1: Output: true
Row 2: Pattern: preferences:false
Row 2: Output: false
Default Value: false
Variable name: rgx – statistics consent
Row 1: Pattern: statistics:true
Row 1: Output: true
Row 2: Pattern: statistics:false
Row 2: Output: false
Default Value: false
Required Triggers in GTM
In this example, we will be using trigger groups as our method for consent on pageview tags. By using trigger groups, this provides an ‘and’ functionality, meaning the group will wait until all triggers within are deemed OK to fire.
For this post, we will focus on the marketing consent triggers, but this process should be repeated for preferences and statistics too.
All Events – Consent = True
Navigate to the triggers section of Google Tag Manager using the navigation at the left-hand side of the interface. Create a new trigger with the type set to Custom Event.
The event name should be ‘.*’ with the ‘Use regex matching’ box ticked. ‘.*’ is a wildcard in RegEx and will match anything.
The key aspect of this trigger is to set ‘This trigger fires on’ to ‘Some Custom Events’. Below in the three boxes that appear, select your marketing consent variable (rgx – marketing consent), then choose ‘equals’ as the criteria, and finally input ‘true’ as the value.
The full trigger configuration is shown in the image below:
This trigger is looking for any event which the browser sends where consent has already been given. We are not trying to hit the pageview event sent by Google Tag Manager (gtm.js as the container loads), but we will still be able to send a pageview to Google Analytics as soon as the user consents to our data collection.
To repeat this for statistics and preferences, duplicate this trigger and then change the variable from ‘rgx – marketing consent’ to ‘rgx – preferences consent’ or ‘rgx – statistics consent’.
Page View Trigger Groups
Trigger groups – as the name implies – allow you to group triggers together to form an ‘and’ logic within your triggers. For this implementation, this means we want to only track people who have set off the ‘All Pages’ default trigger AND our event trigger ‘event – all events – marketing consent true’.
Using trigger groups for page views is ideal because we can make our marketing tags wait until consent is given, and we are sure that it is only being tracking once without the need for blocking triggers or multiple triggers attached to our tags to capture both first and subsequent pageviews.
What you should be taking away from the above, is that there are multiple ways of using Google Tag Manager to perform this governance of your marketing tags. Trigger groups are our preferred way, as we feel it makes the container easier to manage, and quickly assess what a specific tag should be firing on.
So, to generate a trigger group, navigate to the triggers section of Google Tag Manager and then create a new trigger. For the trigger type select ‘Trigger Group’.
Now the configuration allows you to choose your triggers, which will be applied to the group. In our example, that will be ‘All Pages’ and our marketing consent event as shown below:
The trigger should fire on all conditions, and be saved to your workspace. Repeat the process for statistics and preferences, exchanging the consent event to gain full coverage of the assigned buckets in CookieBot.
Do not add all the consent triggers into a single group, because if you do, then you will only track users who have accepted all cookies. Triggers are an AND function, meaning everything in the group must return true for it to fire.
Interaction Event Triggers
Though we have dubbed these triggers ‘interaction events’, they can be non-interactive if you are looking to track scroll depth, for example. However, the phrase best matches the other triggers available in Google Tag Manager that are not page view based – for example, the click triggers or form submission triggers. Both need some form of user interaction to send data to your tracking technologies.
These types of events can be easier to track as you do not have to use trigger groups. Of course, if you wish to use the trigger group methodology, then you can, but an alternative is to filter the trigger within its configuration as unlike pageviews, we will not miss the opportunity to capture if the user has not consented to data collection. In this case, if they have consented, then the event should fire. If they have not, it shouldn’t send data to our marketing platform.
Create your trigger, and add any filters required to make it track what you need. In our example, we have used a click trigger to track buttons on the page using a CSS selector.
You can see in the image below we have also added our consent variable, and we’re looking for it to be ‘true’ before we send data.
If both the primary button on page is clicked and the user has consented to marketing activity, then this trigger will fire.
Using this method, if you need to have multiple buckets available then the trigger should be duplicated, and the consent variable changed to be the preferences or statistics variable created earlier.
Do not add all the consent variables into a single trigger as this would only fire if the user has accepted all cookies. The filter is an AND function and therefore all must return ‘true’ for the trigger to fire.
CookieBot gives the user the power to only accept the level of cookies they want, and if they only accept marketing for example, then the trigger will not fire due to preferences and statistics returning ‘false’.
Putting it all together
The final step is to attach your triggers to your tags based on which buckets they need to fall in. For our example, we’ve shown Google Analytics as requiring marketing consent, but you may bucket your cookies differently.
Once you’ve attached the triggers to the tags, get into preview mode and check the implementation is working as intended before publishing to the live website. As a final tip, if you need to test the integration multiple times, you should install EditThisCookie to your Chrome browser. This extension allows you to managing and delete cookies individually – meaning you don’t have to remove all of your logins by wiping out every cookie stored.
Summary
Let us know your methodology for integrating CookieBot with Google Tag Manager. Do you prefer to using blocking triggers to prevent data being sent are you a user of trigger groups?
If you need help getting to be GDPR compliant with CookieBot and GTM, get in touch with us.
