Consent Mode Overview
top of page
Search

Consent Mode Overview

  • Mar 24
  • 6 min read

The GDPR was introduced on May of 2018. Since then, in the UK, the ICO has been responsible for enforcing it. For years now there has been a regulation in place stating  how to collect, withdraw, and document data in regards to user consent. Google Consent Mode was launched in 2020, with v2 available from 2023. To this day though, a lot of businesses still risk non-compliance with the GDPR, and a lot have either not yet implemented Google Consent Mode, or have not done it to a good standard.


There are a lot of resources out there that explain the impact of GDPR, the Data Protection Act 2018, and PECR - like this Ultimate Guide by Didomi. I’m not a lawyer or a DPO (and this is not legal advice!) so I won’t comment on these. I have, though, seen my fair share of misconfigured Consent solutions (including, but not limited to Google’s), and I’ll share what you should be looking for to ensure best practices are being followed.


Google Consent Mode

Google Consent Mode is a technology that updates the behaviour of your Google Tags according to the user consent preferences. There are two versions available right now: Basic and Advanced. For all intents and purposes I’m using a full GTM solution.


Basic Consent Mode

This is the simplest version to grasp. If Basic Consent Mode is implemented, and the user has either not made a consent selection, or has denied all consent, no Google Tags will be run. It’s as simple as that. No consent, the tag doesn’t fire, Google doesn’t get any data. This is how most other non-Google platforms have to be configured as well.


Weirdly enough, Basic Consent Mode is more laborious to implement than Advanced. This is because you have to ensure that the tags fire after consent has been provided (whereas in Advanced you don’t have to do that). Let me show you.


The first thing that needs to happen on a page is the setting of consent. First, the consent tag fires, then it sets the consent Default:


Google’s documentation states that Google Tags should be set to fire on Initialisation, and other tags that track page view or similar events, should be on All Pages. Here, because they’re configured for Basic Consent Mode, the tags are blocked by consent, which mean no data is sent to these platforms:

 


Then, if the user grants consent, we need to update the gtag with the Update command:


Great! Now Google consent status for all the signals have been granted. The problem is that none of those tags that were previously blocked have fired, so if your implementation stopped here, you’d not be sending data to the platforms after consent was granted. The solution: add an event after the Consent Update, so that tags can fire after the signals have changed:

Now, after every consent update, you can set tags to fire in case they haven’t before.


Another important situation is when consent is already known. In this case, when the user lands on the page, the Consent Update needs to happen immediately after the Consent Default. This way all tags that subsequently fire will have the correct consent flags. And just like before, we add an event after that happens, to ensure that the tags only fire after this update:


 There are still a few more things to configure correctly here, like tag firing order, what consent each individual tag requires, and more, but this is the expected output of a simple implementation.


Advanced Consent Mode

With a Google Advanced Consent Mode implementation, Google tags are now allowed to fire even before the user grants consent, and if they deny consent. Google tags will update their behaviour based on the consent settings, so if consent is denied, but a Google tag fires, a few things will happen:

  • No cookies from these platforms will be set.

  • The tags will send cookieless pings to the platforms. 

  • The tags will wait for an update on the consent settings and send the full measurement data if consent is granted.


That third point makes implementing Advanced Consent Mode is simpler because the Google tags don’t need to re-fire. On to the setup! As before, The first thing to do is to set the Default Consent:


With Advanced Consent Mode, Google tags are allowed to fire. Other tags that require consent are still blocked:


On the GA tab, we can see that in the hit sent to GA the Cookie consent state (gcs) has the value of G100, which translate to Google Consent Mode being active, and both ad_storage and analytics_storage being denied:

This means that this is a cookieless ping, so it won’t set cookies, and the data will not be surfaced in GA without modelling.


When the user grants consent, we need to update the consent signals:


You’ll also have noticed that now we also see a user_engagement event. This is created by GA and, among other functions, is responsible for communicating the consent state to GA without the need to re-fire tags. On the GA tab we see the event, and we see that the gcs value is now updated to G111, which translates to both ad_storage and analytics_storage now being granted:


And there you go. This is how to set and update consent statuses for Google Advanced Consent Mode. As with Basic Consent Mode, more configuration still needs to be done to ensure defaults and updates follow from page to page, and if you’re using pixels from other platforms that require consent, they also have to be correctly configured.


Consent Mode V2

Since March 2024 Google has enforced the use of Consent Mode V2 in the EEA. This needs to be adopted if you’re engaging in personalized advertising, independent of Basic or Advanced Consent Mode. Implementing it means that, in addition to the aforementioned ad_storage and analytics_storage signals, we also send the ad_personalization and ad_user_data signals. Unlike ad_storage and analytics_storage signals, these two newer ones don’t affect how the Google tags behave. They are additional parameters responsible for communicating to Google the user’s consent for personalised advertising and user’s consent for sending user data related to advertising to Google. Julius Fedorovicius wrote a great article explaining what they do, and exemplifying their effect. Below is a simplified version of what happens when consent is granted or denied given these four signals.


Other Consent Modes

This is where things get confusing. So far we have been talking about Google Consent Mode. These signals modify the behaviour of tags from Google platforms. Consent Mode though is an industry-generic term for a mechanism by which tags adjust their behaviour based on user consent signals. Microsoft Ads, for instance, has its own version of Consent Mode, which they have recently started to enforce. Microsoft Clarity, as well, has its own version of Consent Mode. Although named differently, Meta also has custom flags to ensure consistent data protection within the GDPR. I could go on.


The complicated part here is that every system has its own implementation, and you have to have the knowledge and expertise to implement and check them all if you want to follow regulations and use the platform's best practices. That can be a lot. Some GTM Tag template’s like Simo Ahava’s Consent Mode Tag Template, have an option to incorporate Microsoft Clarity and Ads signals with the click of a button. Others, like Didomi, offer TCF integration, seamless Microsoft Ads Consent Mode integration, Amazon Consent Signal compliance, and more.


All Together Now

Let’s now say you have a global enterprise, with websites for different markets, using different marketing and analytics tools, and have hundreds of thousands of users on a weekly basis. Or let’s say have a small business running ads on a couple of different platforms. What should you do to ensure you’re compliant and that you’re using up to date technology? The answer is the same: Look for professional assistance. There is a lot of value to be gained by ensuring correct implementation. The cost will repay itself again and again in ensuring you’re not breaking regulations, that you're gathering and using the best data available for your campaigns, for training optimization models that will adjust your bidding and spend, and will ensure that your data driven decisions are made with the best data available.


If you want to start your journey for better data, give us a shout at Duga and we’ll take it from there.

 
 
 

Recent Posts

See All
H1 Google Analytics Roadmap inside track

Last week we attended the Google Analytics H1 roadmap webinar and came away with a clear picture of where things are heading. We cannot share the specifics (NDA firmly in place) but we can tell you wh

 
 
 
Google_GMP_Certified_Badge_Final_Med (1).png
  • Facebook
  • LinkedIn

CONTACT US

Lime Tree Work Shop, Lime Tree Walk, Sevenoaks, Kent, TN13 1YH

info@dugadigital.com

Registered in England and Wales no. 13177452.
VAT Registration no. 397 6168 39.

bottom of page