How To Implement GDPR Cookie Consent Notification with Google Tag Manager

In less than a week, on May 25th, General Data Protection Regulation (GDPR) will come in effect, meaning that online businesses which get visitors from the European Union, must track visitor/user behavior and collect data more carefully, responsibly, and with consent.

I will not go into details what GDPR is (there are other great blog posts out there like this one, this one or this one). Long story short, a standard This website uses cookies blah blah blah cookie consent becomes irrelevant. From now on, cookies which contain personal data must be activated only when a person gives a consent, in other words, a visit is not a consent a consent by default.

So before you get the actual consent, all the tracking should be put on hold. In this guide, I’ll show you what solution did I choose and how I implemented GDPR cookie consent notification on analyticsmania.com + you’ll get a GTM Recipe.

First things first, GDPR is NO cookie legislation

Before we continue with the GDPR cookie consent notification, I’d like to point out a common misconception. The General Data Protection Regulation only involves personal data. It does not talk about cookies in any way. If a cookie contains personal data, then it GDPR applies to it (because of data), in all other cases, a “cookie law” should be applied.

In fact, the European ComisCommission is currently working on a new ePrivacy Legislation (expected end of 2018) which will be built upon the ePrivacy directive and the GDPR. This legislation is expected to bring more clarity on how companies should handle tracking and advertising online. And that’s good because most of us are still confused and everyone is interpreting GDPR in their own way.

GDPR Cookie Consent Notification: Action plan

OK, now let’s go back to our main topic, cookie notification. I’ve checked several solutions and the one that I’ve chosen is offered by OneTrust. In fact, you’ve probably already seen it here, on Analytics Mania just a couple of minutes ago. If you are a returning visitor, then open analyticsmania.com in Incognito window to check it out.

Here’s the flow:

• A new visitor lands on a page and sees the cookie notification banner at the bottom of the screen.
• Banner offers to accept cookies or decline them by going into cookie settings. Until this moment no tracking tags are fired yet. In other words, a visitor still has the opportunity to act before cookies are stored in his/her browser.
• If a visitor clicks Accept Cookies button, this is a consent.
• If a visitor continues browsing a website, this is considered as a soft opt-in and all the cookies are also stored in the browser.
• If a visitor clicks on Cookie settings he/she can change preferences and opt-out of particular groups of cookies.

Onetrust Cookie Consent Notification: Pros and Cons

I have to admit, I struggled a lot when I was trying to implement OneTrust’s consent for the first time. For the second one, I already had a GTM recipe which made things much faster and easier.

If you’re not sure whether this tool is right for you, here are the advantages and disadvantages:

Pros:

• Free for one website (not limited by pageviews/number of pages, etc.)
• The design is pretty good and clear
• A Preference Center and the ability to opt-out/in to separate categories of tracking cookies
• Pushes consent data and events to the Data Layer
• Scans the website for cookies, automatically assigns them to different cookie categories in the preference center.
• Offers various opt-in/opt-out settings, is pretty customizable.

Cons:

• On workdays, the cookie scan takes pretty long time (if not carefully configured, even several hours). But I’ll show you a workaround.
• Several bugs
• Not all data layer pushes are usable, some require hacking
• Does not store consent data (in the database). At least in a free version. I’ve found a workaround for this as well.
• Requires a lot of configuration on GTM side (but this step is required by pretty much all cookie consent tools, as far as I know).
• Setup flow was annoying sometimes, especially for new users who don’t know all ins and outs, yet.
• Sometimes script caching is too persistent. Once again, I’ll show you a workaround.

I have to admit, it took me way too much time during the first implementation (a day or two) because I had problems almost in every step (and the support was pretty meh with their help).

But when I did succeed, all the other attempts took me about 1-2 hours. Once I knew all the possible obstacles, I avoided them immediately, therefore saved a lot of time.

In this guide, I’ll also give you tips how to avoid possible blunders in order to implement the GDRP cookie consent notification asap.

Create an account

This is a very important part. It’s not that simple to create a OneTrust account. You will need to fill in this form, submit and wait for up to 48 hours because someone will manually create an account for you and then send an email with the confirmation link.

So if there is a slight chance that you will want to try OneTrust, immediately go to this page and submit the form. Go, do it now. I’ll wait.

I had different experiences waiting for the email with a link. Once it took maybe 2-4 hours of waiting, while the other time it indeed took me around 48 hours (2 work days).

After you get an email with a link, finish registration and come back to this blog post and we’ll continue.

OneTrust has published a long but informative and useful guide, you can find it here. Cookie-consent-related stuff starts at page 148.

Scan the website

After you get an email with a signup link and finish the registration, you should be redirected to this page.

Click Cookie Consent & Website Scanning. On the next page, click Scan Website.

Then click Add Website (in the top right corner of the screen) and enter website’s information. Free OneTrust plan allows you to have one domain.

Important! DO NOT ENTER a subdomain (e.g. www.analyticsmania.com). ALWAYS enter just the main domain, e.g. analyticsmania.com. By entering just the main domain you enable this GDPR cookie notification consent to work on all subdomains. 

If I entered just www.analyticsmania.com, then consent cookie settings will be saved only on www.analyticsmania.com. If I also had support.analyticsmania.com, that subdomain wouldn’t be able to access cookie settings stored on www.

It is crucial to enter only the main domain on the first step because you won’t be able to edit it later and OneTrust’s support will also be useless here. The only way to change it is to delete all the content and settings in OneTrust and start from scratch (which is annoying and time-consuming).

Important #2! When you enter your website’s information, click Advanced Settings and set the Scan Limit to 50 or 100 pages. The default is 1000 pages which is A LOT. If you leave it as it is, your initial scan will take way too long. I did this mistake once and my page was being scanned for about 4 hours. Make the scanning process faster by reducing its scope. Without scanning, you won’t be able to proceed, therefore this step is required.

Once you create a website’s profile, its status will be Scan pending. It might take a while for it to start, sometimes 60+ minutes. It depends on how much OneTrust platform is currently loaded with other tasks and traffic.

Another tip. If your scan’s status changes to Error, this means that your website’s protection is too strict against bots (or there is a redirect).

In my case, I’m using Cloudflare and it did not let OneTrust’s scanning bots through. A solution? Temporary disable Cloudflare’s firewall or make its settings a bit lighter. Consult a developer/sysadmin, you has set Cloudflare in the first place. But this is not a common case. Usually, OneTrust’s bots manage to go through just fine and complete the scan.

It’s a good practice to go and drink some coffee while the website is being scanned. People say that time flies faster then 🙂

After the scan is complete, you should see some cookie numbers in this report:

If you see only zeros even though the scanning is complete, once again, that’st the issue that might be caused by your website’s firewall as it’s blocking OneTrust’s scanning bots. Temporarily disable it or make a bit less strict for a while and then re-scan.

Cookie Banner Setup

The next step, a banner which informs the visitor that a website is using cookies and it requires a consent. To set the banner, go to Cookie Banner page.

You will be able to change its layout, colors, content, and behavior. I won’t go into details of all options, just want to mention several:

• Layout and colors for GDPR don’t matter. Choose whatever is beautiful for you.
• In Content, I’ve enabled both Accept Cookies button and Cookie Settings link.
• In Banner Behavior, there are many options that you can play with. Personally, I chose that closing a message and scrolling down should be considered as a consent. Scrolling will be treated as a consent if a person has scrolled for ~25%. So an accidental scroll will NOT be taken for a consent (which is good!).

Yes, I know that this is not an explicit consent, but in this case, I am giving the visitor an opportunity to act before being tracked and doing a soft opt-in. I’ve seen other large companies implementing this similar tactic.

Yes, I know that’s not a good practice because that does not make you fully compliant. But for now, I’m choosing to spectate how the market acts and how GDPR is implemented on a larger scale. I chose this way as a small business owner. This is not a legal advice in any way. If you’re super concerned with GDPR, you should get a legal advice from an attorney.

I really doubt that after May 25th a bloody hunt will start, especially knowing that EU regulators themselves are not GDPR ready! So I chose to be partially compliant regarding the consent (at least, for now) and see what will happen on the market with larger businesses who have implemented the consent mechanism in the same way.

Nevertheless, OneTrust GDPR cookie consent notification banner has many options so you can decide how well compliant to you want to be.

The consent banner can be always viewed in a live preview (there’s no need to have OneTrust’s JavaScript added to your website).

After you’re satisfied with settings and appearance, hit Publish changes.

Configuring a Banner For a True Opt-in

One of the other possible banner configurations goes like this:

• A person lands on a page
• The entire content gets hidden behind the overlay
• This way, a user is forced to interact with the banner: give consent to be tracked or opt-out.

Here’s how this looks in action:

In order to enable such banner configuration, go to your OneTrust account > Cookie Consent > Cookie Banner > Behavior and enable Require Banner Interaction.

Cookie Policy Setup

If the scan was completed successfully, OneTrust will automatically assign the cookies to dedicated cookie categories. By default, there are 5 cookie categories:

1. Strictly necessary cookies
2. Performance cookies (a.k.a. for Analytics)
3. Functional cookies (e.g. for A/B tests, for support chat widgets, etc.)
4. Targeting cookies (for marketing)
5. Sometimes a 5th category appears, Social Media Cookies.

Later in this blog post, I’ll share a GTM recipe for this cookie consent (which contains triggers, variables, etc.). It will work ONLY if you use the first 4 cookies groups as they are in their default state. #1 always must be Strictly necessary cookies, #2 must be Performance cookies, #3 must be Functional cookies, #4 – Targeting (Marketing) cookies.

Now go to Cookie Policy section (of OneTrust interface) and set cookie groups to the following statuses:

1. Strictly Necessary Cookies – Always Active
2. Performance cookies – Inactive LandingPage (consent will not be active just on landing)
3. Functional Cookies – Inactive LandingPage.
4. Target Cookies – Inactive LandingPage.

Inactive LandingPage consent model means that a cookie group toggle will be set to ON but it will come into effect only if a visitor gives consent to be tracked. A visitor will be able to change his/her preferences in the Cookie Preference Center. You can read more about OneTrust consent models here, at page 181.

As you can see in the screenshot above, each cookie groups has its ID. Make sure that they are identical to yours. If you do not change any default settings, they will be just like that.

If you don’t see any or some of these groups, do not fear, that means that a group still does not have any cookies automatically assigned to it.

We’ll be able to do that manually really soon. Go to Cookie Policy > Assign Cookies. You will see a more detailed list of those 4 cookie groups containing actual cookies, like _ga, etc.

OneTrust does a pretty decent job automatically assigning cookies, however, it won’t do the job at 100% precision. You should manually drag all unassigned cookies to the most appropriate cookie groups. Just click (and hold) a cookie block and drag it to, say, a group of Functional Cookies. Repeat the same action with all other unassigned cookies as well.

Keep in mind that a cookie group will be visible to visitors in the Cookie Preference Center only if it contains at least one cookie.

After you’re done, publish all changes.

Cookie Preference Center Setup

Preference center is a popup with more settings, detailed explanation, and relevant links. It is displayed after a visitor clicks Cookie Settings link.

In Cookie Preference Center section, enter all the information you feel is necessary. Personally, I entered a link to the Privacy Policy, edited some texts. All other settings remain default. I chose not to display the detailed list of cookies in the Cookie Preference Center as my plan is to display the list in the Privacy Policy page on analyticsmania.com (but due to lack of time I still did not manage to do that).

In Preference Center Styling section, you’ll be able to change main color scheme and upload your own logo (also included in their free plan).

Script Integration

The next step is to get familiar with OneTrust GDPR cookie consent notification’s script. There are two options you should be aware of. Since my blog is without a staging environment, I used two scripts out of 4 options:

• Production Single Location. It is especially useful if you want to see your cookie banner/preference center changes almost immediately on your website (settings cache is not that persistent). However, cookie banner will load with some delay. I use this option when I’m configuring the consent solution and testing/debugging.
• Product CDN. This option uses multiple servers scattered across the globe. It uses a stronger cache, therefore it might take even several hours for your changes to go live for all visitors. On the other hand, the cookie banner loads faster. I switch to this solution after everything is configured correctly.

We’ll get back to these scripts really soon. But first, let’s prepare the GTM configuration.

GDPR Cookie Consent Notification: GTM Recipe

Configuring OneTrust’s cookie consent solution is just the half of the task. Your tracking scripts (like Google Analytics, Google Adwords, etc.) will still continue working as they always did unless you import my GTM recipe and then reconfigure all of your tracking tags. Yup, there’s a lot of manual work waiting ahead.

Important: After you follow my instructions and configure everything properly, OneTrust’s Cookie Consent will affect only those tracking codes which are implemented via GTM. So if you have Google Analytics hardcoded directly in website’s code, it’s right about time to migrate to GA + GTM.

I will not go into details how everything is set up in the recipe and why did I choose one solution over another but here’s a brief recap of what useful settings will you get. After you import the container, it will automatically create a dedicated Folder called GDPR Cookie Consent Notification containing 24 assets. Here are the most important ones:

Tags

• cHTML – Cookie Consent. This is the tag where you should paste your OneTrust consent script. Without it, GDPR cookie consent notification will not work.
• cHTML – Push To Data Layer – Consent Updated. Pushes an event to the Data Layer when consent settings are updated (a new consent is given or the current consent is updated).
• cHTML – Set Cookie – Actual Cookie Consent Active Groups. Stores consent settings in the cookie that expires in 12 months.
• cHTML – Push To Data Layer – Consent Data For The Record. Pushes full consent information (including user agent) to the Data Layer. That data will be later used to store the consent information (as a proof) in Google Analytics.
• GA Event – Cookie Consent Data For The Record. If a user gives a consent to at least one group of tracking cookies (excl. necessary ones), this event tag will send the consent data to Google Analytics.

Triggers

There are many triggers but the most important are those which control the permissions of tag firing:

• 4 blocking triggers:
  • Blocking – Analytics Tracking is Not Allowed
  • Blocking – Functional Cookies are Not Allowed
  • Blocking – Marketing Cookies are Not Allowed
  • Blocking – Total Opt-Out (if a visitor opts out of all cookies (except for necessary)
• 9 Pageview-related tags which fire only if a visitor has agreed to a particular group of tracking cookies.
  • Pageview – All Pages – Analytics Tracking Allowed
  • Pageview – All Pages – Functional Cookies Allowed
  • Pageview – All Pages – Marketing Cookies Allowed
  • Pageview – DOM Ready – Analytics Tracking Allowed
  • Pageview – DOM Ready – Functional Cookies Allowed
  • Pageview – DOM Ready – Marketing Cookies Allowed
  • Pageview – Window Loaded – Analytics Tracking Allowed
  • Pageview – Window Loaded – Functional Cookies Allowed
  • Pageview – Window Loaded – Marketing Cookies Allowed

Variables

• dlv – consentData for the record. This variable will be used to record the consent and send the data to Google Analytics. In other words, you’ll have a proof of consent which will be stored in GA.
• Cookie – Actual Cookie Consent and dlv – Active Consent Groups. Two variables which store the consent information (a list of groups that a visitor agreed to). Both store the same information but in different places, one is Data-Layer-based, while the other one is cookie-based. Here’s a sample what its value could look like (in your case, some might look different, that’s perfectly fine):
  
  • If its value contains ,1, then a visitor gave consent to Strictly Necessary Cookies. This is a default that cannot be turned off.
  • If the value contains ,2, then a visitor agreed to Performance (analytics) cookies.
  • ,3, means Functional cookies are allowed.
  • ,4, means Targeting (marketing) cookies are allowed.
• For your convenience, I’ve prepared 3 variables which return true if a particular cookie group is allowed by the visitor.
  • Custom JS – Functional Cookies Allowed
  • Custom JS – Marketing Cookies Allowed
  • Custom JS – Performance and Analytics Tracking Allowed
    
  • Personally, for me, Social Media cookies were not needed therefore I did not include them in the recipe. If you need it, let me know and I’ll try to find spare time and update the recipe.

Other triggers and variables (which were not mentioned) are also important but not THAT much I should mention and explain them.

Import The GTM Recipe

After you download the GDPR cookie consent notification GTM recipe, follow this guide how to import it. Just make sure you choose Merge as an Import Option, NOT Overwrite.

Update Your Current Tags with New Triggers

There are several things you need to do (in this exact order!):

#1. Go to cHTML – Cookie Consent tag and replace its code with the script that OneTrust provides you at Cookie Consent > Script Integration. Use Production Single Location while you’re developing and testing. After everything’s done, replace the script with Production CDN option.

If for some reason you stop seeing latest changes with Production Single Location script, do a hack. Add “?v=1.0” to the end of script’s URL. Just like I did in the image below:

Save the tag and refresh the Preview and Debug mode. Updated URL will force the browser to download the latest version of the script. If you face the issue once again, change the v=1.0 to v=1.1, and so on. Everytime an issue reoccurs, change the URL parameter.

#2. Update all your tracking tags (which deal with personal data) in Google Tag Manager by adding one of 3 blocking triggers to them as an exception. This needs to be done with every single tracking tag (which deals with personal information), including Google Analytics Pageview, Google Adwords Conversion Tag, etc. Simo Ahava has another solution but it’s available only for GA360 (premium) users.

If a tag is related to analytics (e.g. Google Analytics Event tag) then assign Blocking – Analytics Tracking is Not Allowed trigger as an exception. In case of Adwords tag, use Blocking – Marketing Cookies are Not Allowed trigger. You get the idea, right?

Here’s how an updated tag triggering could look like of a Universal Analytics tag:

#3. Additionally, update all those tags which fire upon Pageview, DOM ready, or Window Loaded Events. The important part of this new cookie consent is to hold tracking tags until a visitor gives a consent to be tracked. Therefore, GA, FB pixel, and other pageview-based tags must be “on hold” as well. Consequently, standard All Pages trigger becomes irrelevant here.

Firstly, you need to remove all Pageview, DOM Ready, and Window Loaded triggers from your current tags as they do not respect visitor’s consent. Instead, you need to fire Pageview-based tags immediately after the consent was given.

That’s why assign Custom – Optanon Consent Updated trigger to all of them.

The expected result: Universal Analytics pageview, Facebook Pixel main code, and others which fire upon page load must not fire until a visitor gives the consent (by clicking Accept Cookies button, closing the banner, or scrolling down).

But what happens to pageview tags if a visitor has already given the consent and then refreshes the page? That’s why you also need to complete the step #4.

#4. Add pageview-based triggers which respect the consent settings. In the aforementioned GTM recipe, I’ve prepared 9 pageview-related triggers which are based on separate cookie consent groups:

• Pageview – All Pages – Analytics Tracking Allowed
• Pageview – All Pages – Functional Cookies Allowed
• Pageview – All Pages – Marketing Cookies Allowed
• Pageview – DOM Ready – Analytics Tracking Allowed
• Pageview – DOM Ready – Functional Cookies Allowed
• Pageview – DOM Ready – Marketing Cookies Allowed
• Pageview – Window Loaded – Analytics Tracking Allowed
• Pageview – Window Loaded – Functional Cookies Allowed
• Pageview – Window Loaded – Marketing Cookies Allowed

Choose one of them for each tag and assign. For example, Universal Analytics Pageview Tag should get a Pageview – All Pages – Analytics Tracking Allowed trigger while Facebook Pixel should get a Pageview – All Pages – Marketing Cookies Allowed trigger, etc.

Record a proof of consent in Google Analytics

In order to have a proof of the consent, there is a tag called GA Event – Cookie Consent Data For The Record which will send the consent data to Google Analytics (as an event). Its data includes:

• Consent groups (to which groups did a visitor agree)
• Timestamp
• Google Analytics client ID (if the permission was given to analytics/performance cookies).
• User Agent (information about the browser: version, etc.)

If a consent was not given to analytics/performance cookies, then GA Client ID’s value will not be passed. If a visitor does not opt-in to all cookie groups, then no event will be sent to Google Analytics at all.

In order to make this feature work, you need to open GA Event – Cookie Consent Data For The Record and:

• Set GA tracking ID
• Or, preferably, set the Google Analytics Settings Variable:
  

To sum up

1. Go to cHTML – Cookie Consent tag and replace its content with the script that OneTrust provides you at Cookie Consent > Script Integration.
2. Every tag (regardless of whether they are event-based or pageview-based) should get a blocking trigger of a particular consent group. If a tag is for analytics, assign a Blocking – Analytics Tracking is Not Allowed trigger, etc.
   
3. Remove Pageview, DOM Ready, and Window Loaded triggers from your current tags. Instead, choose a trigger which states that a Consent was updated. You must not fire tracking tags before the consent is given. So choose Custom – Optanon Consent Updated trigger. Do that to all tags that used to fire on pageload.
   
4. Additionally, for every pageview-based tag choose one of 9 new pageview-based triggers. For example, in the case of Universal Analytics Pageview tag, choose Pageview – All Pages – Analytics Tracking Allowed trigger.
   
5. Set the GA Settings variable in the GA Event tag which will record the proof of consent in Google Analytics.

In total:

• All event-based tags will get a new blocking trigger.
• All pageview-based tags will get a new blocking trigger, two new triggers and will get the old Pageview (or DOM Ready, or Window Loaded) triggers removed.

But wait, there’s more

Even though you’ve just installed and configured GDPR cookie consent notification with Google Tag Manager, there are other things to do if you’re a user of Google Analytics. I will not go into details and will only give a brief list.

• Anonymize IP. In Google Analytics tags or GA Settings variable go to More Settings > Fields to set  and enter the following settings:
  
• Disable Display Advertising features or configure it to respect consent settings with allowAdFeatures.

Useful Resources

In addition to all of this, here’s a list of other useful resources related to cookie consent and GDPR in general:

• [VIDEO] GDPR and Google Analytics – What do you need to change? by MeasureSchool
• OneTrust documentation (really useful in order to learn more about their GDPR Cookie Notification Consent tool)
• The Definitive GDPR guide for ecommerce by my colleagues at Omnisend
• Configure Google Analytics to be GDPR compliant by Humix
• Did not like OneTrust as a cookie consent solution? Not a problem! Here are other GDPR cookie consent notification solutions:
  • Civic
  • CookieBot

GDPR Cookie Consent Notification: Final Words

In a nutshell: According to GDPR, firing all tracking codes right after a visitor landed on your page is not permitted anymore (since May 25th, 2018). You should first ask for a permission to track and only then fire your marketing tags.

In this blog post, I’ve explained how to implement a GDRP cookie notification consent with Google Tag Manager and how to update your current marketing tags accordingly.

Cookie consent notification is just a tool for getting a consent, it’s not capable of managing your tracking tags because every website and every GTM container is unique, therefore there is no universal solution. As a result, you will have to manually update all your tracking tags with additional firing rules.

OneTrust GDPR cookie consent notification solution was a tool of my choice (you saw it on this blog, already) and in this guide, I’ve explained how to configure it.

It has its pros and cons but with some experience, you can do pretty flexible implementations. Obviously, new users will have no previous knowledge, that’s why my guide should be useful to them as I share my blunders and ways to avoid them. Plus, my GDPR Cookie Consent GTM Recipe should save you lots of time.