Over the past few months Google has been tightening up its policing of consent management and has offered a new deadline of March 2024 to be compliant in order to continue using its products and features. They’ve called it Google Consent Mode v2.
In the past week users of Google products will likely have received an email with the subject line: Important: Product changes are coming to existing implementations of consent mode in 2024. But what does this mean for you?
Fairly quietly, in my opinion, back in November, Google released two new additional consent mode parameters into its consent mode API. These were ad_user_data and ad_personalisation.
The reason?
As a part of Google’s ongoing commitment to a privacy-centric digital advertising ecosystem, we are strengthening the enforcement of our EU user consent policy
*For information on Google's EU user consent policy
The impact of Google's Consent Mode announcement?
Well, it seems like if you’re not using Consent Mode (and you didn’t have to as long as you were controlling your tags by consent preferences in your own way) you are going to start having to in order to use products like Google Ads and Google Analytics together.
"To keep using measurement, ad personalization, and remarketing features, you must collect consent for use of personal data from end users based in the EEA and share consent signals with Google. The requirements also apply if you are using Google Analytics data with a Google service.”
This instruction is a little wooly because if you’re not using Google Ads, and only work with Google Analytics you could be exempt (as you’re not using GA4 data with another Google service), but if you are connecting GA4 with GAds or Google Cloud / Biq Query you will be. So probably better to be safe and get it done!
What is Consent Mode?
A quick recap for those who may have chosen to ignore this topic for the past few years (I don’t blame you), sadly the time has come to make sure you ‘get it.’
"Consent mode allows you to adjust how your Google tags behave based on the consent status of your users and enables Google to model for gaps in conversions. You can indicate whether consent has been granted for Google Analytics and Google Ads cookies. Google's tags will dynamically adapt, only utilising cookies for the specified purposes when consent has been given by the user. Using consent signals, we apply conversion modelling to recover lost conversions due to consent changes."
More information from Google's support centre
It became most noticeable last year when GA4 was pushed to the foreground and its powers in behavioural modelling were preached as a big step up against GA, especially in our privacy-centric world where consent management should be adopted. The legal and ethical obligations and questions surrounding consent management are not going to be discussed here, but obviously you know what the stance is for your own business. Once you’ve learned more about Consent Mode perhaps that viewpoint will change?
Anyway, Consent Mode introduced us to four consent types:
- ad_storage – connected to advertising
- analytics_storage – connected to analytics
- personalisation_storage – connected to personalization (e.g. recommendations)
- functionality_storage – connected to website functionality (e.g. language settings)
Based on a user’s preferences and interaction with your cookie banner some or all of these consent types could be communicated to Google to help recover lost data from unconsented users. Consent Mode is only applicable to Google products but is really handy in platforms like Google Ads where missing conversion tracking could affect campaign performance and optimization.
It’s application can also be used to conditionally fire other 3rd party tags within Google Tag Manager.
Read all about Consent Mode from Google
So how do you know if you’re using Consent Mode already?
There are three good places to check:
1) In your Google Tag Manager account – GTM tag preview
When you preview your tags in the tag assistant, do you see consent state on an event level?
You don’t want to see this….
...you want to see this…
A dataLayer push should exist which provides the default status of all consent tags.
Before any consent is offered, the default status should be denied (for end users in the European Economic Area (EEA)).
So, if you don’t see this in your tag preview, then it’s likely you’ll need to set-up Consent Mode.
2) In your Google Tag Manager account – GAds or GA4 Gtag tag preview
In the tag assistant you can toggle between the GTM tag and other Google tags. If you select a G tag you can then view what data it sees. The difference between when consent status is available or not is there is an extra field with a ‘gcs’ parameter (Google Consent Status).
These are the meanings behind the codes:
So, if you don’t see this in your tags, then Google isn’t seeing it either, so you need to set-up Consent Mode.
3) If you don’t use (or can’t see) Google Tag Manager, you can also check for the presence of ‘gcs’ in your page source
Visit website. Right click & inspect. In the control panel, navigate to ‘Network’ tab. Search for ‘collect’ and when you find your GTM tag ID, view the ‘payload’ in the second window.
Here you will find the gcs code, if it exists.
If you can’t see it, neither can Google. So, you’ll need to sort out Consent Mode.
4) GA4 might be able to tell you
As of mid February, Google Analytics appear to be rolling out a consent settings panel in GA4. Don't worry if you don't see it yet, this will be a gradual rollout no doubt.
In the web stream details area (in Admin panel), if you're lucky you'll see a new section below stream details with an overview of the consent settings GA4 is receiving. Note, this is for GA4 and not other Google properties.
Credit goes to Tamás Geiger on LinkedIn for spotting and sharing this!
How do you set up Consent Mode?
If you need to set up Consent Mode, the two most comprehensive guides we’ve found are from Simo Ahava, who has created a Google Tag Manager template and Measure School who have a video and article based how to guide. There’s no point in us re-inventing this excellent resources, but they’re very technical!
What about Google Consent Mode V2?
If you have tackled the implementation of Google Consent Mode so that you can retrieve the consent status in GTM, via Gtag calls or via network inspection, for the four main consent types, then you need to review whether your current set-up also enables for the two new consent types to be read. This is specifically for Google Ads customers.
- ad_user_data – this sends user data to Google Ads (for enhanced conversions for example). It is also needed for any links between GA4 and Google Ads for conversions and audiences (for example).
- ad_personalisation – this sets consent for personalized advertising (e.g. remarketing)
These two tags are based on the same trigger as ad_storage and currently they can inherit the same consent preferences as this type rather than be set independently (and thus chosen by the user).
Ad_user_data and ad_personalization are downstream flags – they don't impact what happens on the site per se, they impact how Google is given permission to utilize data. Ad_storage is mostly ePrivacy Directive-related, whereas ad_user_data and ad_personalization fall squarely under GDPR as they need to process user data.
If you’ve used Simo’s GTM template, then he has a V2 update available – refreshing your template in GTM might be sufficient, but it all depends on the consent management tool you’re working with.
If you’re doing it independently, then the requirement is to ensure that these two consent types are added into your dataLayers in the same way that you added the original four.
What you should see, if you’re using GTM, are some extra fields in the event consent status table for these additional types.
As per the example below, the next thing to tackle is ensuring the statuses are correct across all types and align with user preferences on your site. This example shows there are some odd signals occurring.
Ultimately, Google doesn’t care what the Consent Management Platform (CMP) does, it only cares about getting a value for ad_user_data and ad_personalization. As long as it receives these status codes, it's happy (I think!)
For a full round up (as some advice is still a little hazy) - this is the recommend source.
Basic vs. advanced set-ups
There are also some queries floating around about basic and advanced implementation.
- A basic set-up is when requests are only sent to Google servers when consent is granted. This could be if you only fire a GTM container on acceptance of a cookie banner, or tags are only fired if consent explicity granted. In this instance, Google can't use modelling or machine learning to plug the gaps of unconsented data.
- An advanced set-up means that requests are sent to Google servers for both granted and denied consent types. The denied consent requests are
What happens if you don't implement Consent Mode V2 by the March 2024 deadline?
Without Consent Mode, data for new EEA users isn't going to be captured by your Google platforms (Google Ads or Google Analytics) which will affect your audience lists and conversion counts.
This in turn will mean your remarketing campaigns are affected, and any conversion driven bidding strategies will be impacted.
We have also (potential scaremongering) been told by Google account managers that failure to comply could also result in account suspension, so for any Google Ads dependent business this could be a costly decision.
Publications like Search Engine Roundtable have reported that Google has been sending suspension warning emails to publishers, app owners and others if their sites and apps are not compliant with its GPDR EU User Consent Policy.
So, compliance is heating up! We wouldn't want you to be a victim of not heeding the advice.
Final thoughts on Consent Mode
All that is left for me to share is my encouragement to get this reviewed and sorted. I know many websites out there are either still not using any cookie banners for EEA users, or are potentially not applying consent properly to their tag fires. So, with this latest nudge (or more like shove) from Google, perhaps now is the time to dedicate to getting things done?
And fortunately for you, we’ve been helping our clients with this, so could be the perfect partner to help you too!
Get in touch with the team if you’d like to discuss your analytics requirements.
Extra juicy bits of Consent Mode / GTM knowledge…
If you’ve got this far, I’ll reward you for your perseverance by sharing something that baffled me for ages until I understood where I could find the information. It’s regarding Google tags, GTM and how to ensure that when consent is/isn’t granted the Google tag is getting the right information about consent.
When triggering the GA4 configuration tag in GTM, the setting is normally All Pages because there are built-in consent checks. However, when you use the Tag Assistant, you might have wondered how Google will respond to the tag fire when the conditions at the time the tag is triggered may not be in line with the consent preferences.
For example, before consent is granted the page view event would have a denied consent status. The g tag will see a gcs G100 status (using the method for checking this shared above) and Google will have to treat this as a cookieless action.
However, if you use those checking tools to view the gcs code of other page views and interactions, you should be able to see that when GTM might imply consent is denied, the gtag sees the granted status due to the timing of the tag fires.
For some web owners, you may also need to shift the GA4 configuration tag to load on ‘Window Loaded’ rather than ‘All Pages’ (which is under Container Loaded) to allow for consent updates to be fed into the tag.
I just found that when viewing solely in GTM I was banging my head as to why I couldn’t get the tags to fire under granted consent conditions, but when viewing the gtag values it reassured me when the gcs value was for a granted status.
+
I would also recommend, where possible, that if you can dynamically populate your consent default tag with the consent-based dataLayer variables that persist during the session, then on new page loads you won’t have to fire the default tag (denied) and then an update tag (granted) on every subsequent page view. The update tag is only called when there is an action to change the consent settings.
I may have lost you towards the end as I went a bit technical, but if you know, you know, and hopefully this bit of advice saves you! 😉
