Last updated on April 6th, 2024 at 08:41 am
Here’s how to correctly enable consent mode v2 in the advanced configuration, with a step by step walkthrough.
Google’s Consent Mode v2 is the updated consent solution to keep effectively using Google’s Marketing Platform in the Cookie-less web ecosystem unfolding in 2024. Here’s an article dedicated to the explanation on what Consent Mode is, why is it called v2, and the two different implementations methods.
Jump to this article to start, as here I’ll explain how to enable the Advanced configuration only.
Consent Mode V2 Advanced Configuration Walkthrough
Here’s how to set Consent Mode v2 Advanced. To do this, you’ll need to work in Google Tag Manager and ensure that your CMP and Google Systems are communicating correctly. In most cases you’ll use a template tag from your CMP provider. In this guide, we will show how to set it up with Iubenda, but the same approach applies to other CMPs.
- Edit your website’s code to set all consent defaults to “denied” before Google Tag Manager container’s loads. In the case your CMP tag already does this step for you, you won’t need to follow step 1.
- Update your CMP tag with the correspondent Consent Mode v2 Template
- if non available, then
- Work with a developer to implement the necessary coding to update Google’s consent signals upon interaction with the CMP. Here’s an example on how to do it from Google Developers Blog.
- Activate Consent Mode on Google Tag Manager’s container
- Review the Consent Overview and set it up for all of your tags
- if non available, then
- Verify if Consent Mode v2 is set up correctly
Step 1: How to set the Default State of consent
If you’re using gtag.js, you can insert a code snippet, as follows
<script data-cookieconsent="ignore"> window.dataLayer = window.dataLayer || []; function gtag() {
dataLayer.push(arguments); } gtag("consent", "default", {
ad_personalization: "denied",
ad_storage: "denied",
ad_user_data: "denied",
analytics_storage: "denied",
functionality_storage: "denied",
personalization_storage: "denied",
security_storage: "granted",
wait_for_update: 500,
});
gtag("set", "ads_data_redaction", true);
gtag("set", "url_passthrough", true);
</script>If you are instead using Google Tag Manager, and your CMP doesn’t offer consent features like this, you can rely on Simo Ahava’s Consent Mode Google Tag Manager Template, which lets you specify and set your default consent state.
Step 2: Updating your CMP tag
Every CMP compatibile with Google is currently updating their tag templates to facilitate the operations to their users. In the case you’re using Iubenda, here’s the updated Tag Model. With this tag, you don’t actually need to implement step 1.
Also, depending on the functionalities of your CMP tag, you might have to remove from the previous code the string “wait_for_update” in the case this is present in the tag template, in order to avoid doubled rules.
Verify if Consent Mode v2 is set up correctly
After you’ve set the default consent status to denied, and after you’ve adapted your CMP behavior to correctly communicate to Google when to link cookie information to data and when not to, you’re technically ready.
Of course there are a couple of things to consider.
- Consent Mode v2 “listens” directly to the CMP you’re using; therefor, they must be speaking the same language. We have tasted this with two of the largest CMPs out there, which are officially supported by Google’s Consent Mode v2. They are
- For the Consent Mode to be working correctly, you’ll need to have also correctly configured your CMP.
So now, to verify that the installation is correct, here are the steps to follow.
Step 1: Use an online tool
First step I strongly suggest is to use an automation tool that will check the communication between your CMP and the Consent Mode script. We are Iubenda’s partners, and we use it for all of our customers, therefor at Fuel LAB we use Iubenda’s verification tool.
Follow the prompt, and just by entering your website’s url and an email (no newsletter subscriptions), you’ll get the feedback in no time.
Check if your Consent Mode v2 is set up correctly online
And you’ll get an email like this:
Step 2: Verify in Google Tag Assistant
Watch out: you will notice that at every new pageview, the consent seems to be re-set to denied, and then re-applied as granted after the “consent” event fires in every page. This would suggest that Consent Mode v2 isn’t configured properly, but Google themselves told me it’s a bug within Tag Assistant, and this shouldn’t be a concern.
What you want to make sure you see in here, is the consent tab with its storage labels as per screenshot. In step 3, we will actually verify with Chrome Web Tools that the consent update is correctly stored.
Next step (especially if the tool returned a negative feedback) in further debug is to verify that the consent tab in Google Tag Assistant (the preview mode of Google Tag Manager) is showing the default consent, and showing it updated after interaction with the CMP, while freely firing tags regardless.
Step 3: Verify in Chrome’s Inspector
I have added a detailed but simple decoding of every meaningful parameter for CoMo, such as GCD, GCS and so on. You can find it in the parameters definitions for consent mode v2
The final step you should take to debug your current installation is the following:
- Visit your website from incognito (also the GTM preview version is ok for this test)
- Do not interact with the consent banner
- Open the chrome web tools and go to the network tab
- Check if any Google Analytics or Google Ads calls are stored before the interaction with the cookie banner. Typically you’ll want to filter the entries with “collect”. Open that network call, and inspect the values GCS and GCD.
- GCS should be set to G100 before interacting with the cookie banner, or persistently after denying consent.
- GCD should be set to 11p1p1p1p5, before interacting with the cookie banner, or persistently after denying consent.
So, if you denied consent, the CGS and GCD should persist in this state all throughout navigation. However, when consent is given, these values should change as follows:
- GCS should be set to G111
- GCD should be set to 11r1r1r1r5
This change should then persist in every navigational event throughout your sessions.
Pietro Mingotti is an Italian entrepreneur and digital marketing specialist, best known as the founder and owner of Fuel LAB, a leading digital marketing and technical marketing agency based in Italy, operating worldwide. With a passion for creativity, innovation, and technology, Pietro has established himself as a thought leader in the field of digital marketing and has helped numerous companies achieve their marketing goals.
Hello,
my problem is the scanner from iubenda said “everything ok” on 2.2.2024, but after some days”not ok”.
My GCD is not 11p1p1p1p5, but instead 13p3p3p3p5.
The rest seems to be ok.
Do you know what the “3” means?
Hello!
Thanks for the question. It’s a tough topic as Google still doesn’t have public documentation about how these strings are matched to the consent stauts.
But, as your comment came in I was in a Google Developers call. The findings are the following:
11p1p1p1p5 means region based consent is unset.
13p3p3p3p5 means that the region based consent is set to granted.
Hello,
thank you. Based on
inital constent = 13p3p3p3p5
after consent given changing to 13r3r3r3r5
..everything is fine with consent mode v2 i understand.
My problem (?) is, the iubenda scanner says “consent mode v2 is not correctly configured”. (after some days it was saying its ok)
Could there be a problem in the config at iubenda itself?
Hello Humbertus,
The situation is complicated because many tools give false positives or negatives, and service providers are on the blind on how to assist us.
Even Google called me 3 times in 2 weeks to have me modify the setup as they weren’t sure of the data coming back.
I am going to update this guide, likely there will be one for advanced mode and one for basic mode. Until then, please use the chrome web tools to monitor the string results changing from p to r, and for that altered state to be maintained at every subsequent pageload.
Hello,
I am hoping you can shed some light on the new Google Consent Mode V2. I really could use some information.
1. We have Google Ads and GA4. Our Google Ads are targeted to United States location only. We do not want worldwide or anything outside the United States, because we only service in the US.
2. Is it necessary to go with a CMP plugin only? I have found one that I like and would be a good fit, but they are not a Certified CMP Partner by Google. Here is there website https://www.mooveagency.com/wordpress-plugins/gdpr-cookie-compliance/
Would this plugin work for someone like us?
Thank you
Jennifer
Hello Jennifer,
So, one thing is the topic of collecting consent, showing the cookie banner itself, and all the other regulations that are mandatory in Europe and other Countries. The US have different regulations, like the CCPA, CDPA, CPA… these regulations vary depending on jurisdiction, but they all handle the informed consent about cookies and the data transferred, to whom, where, how and why.
As far as I know, Google’s switch to Consent Mode v2 as mandatory isn’t just based on enforcing the behavior of tracking reflecting user’s consent. We were already doing that with asynchronous tracking, where we would fire tags only if the level of consent was applicable to the tag that was firing.
Now things are different. In consent mode v2, all tags fire. Period. They fire, but wether they are associated with cookie based information, so that Google can recollect the vents and associate them to a session, or wether they arrive as “simple” pings.
The whole point is allowing a differentiation between observed Data and Modeled Data in GA4 reporting, leveraging and enabling GA4 AI based machine learning and predictive models. This is the direction technology is going worldwide, not just in Europe. We also have customers in the US, and we have noticed on some accounts the disruption of tracking. This is because, even though you want to target only US citizens with your ads, how can you prevent European users to arrive to your website?
So, my final take also based on what I see, is that this doesn’t have to do with Privacy Regulations as such, but as the dawn of cookieless tracking, which is going to impact, indeed, every country.
All the best
Thanks for writing this detailed guide!
I wanted to check, Iubenda’s Tag template includes declaring all consent signals as denied by default (https://ibb.co/fY0FHrp <- screenshot of the tag template taken today).
If that's the case, why is there a need to embed the additional script prior to the GTM container code? I'm not saying you're wrong – just trying to understand.
Also, I keep getting confused about the expected behaviour on a first visit to a site where no consent has been granted. If all tags are dependent on consent being granted, does that mean that any tags that rely on that just won't fire on first page view? I'm not talking about GA4 here; more tags that are "pixels" or JS libraries / tracking for other third party platforms – eg a Marketing Automation platform.
It isn't the case that upon consent being granted the Tag criteria is re-assessed and they're run. Is that correct?
Hi Ross, thanks for the question.
First part: yes, I have shared your same questions with Google. If the Iubenda Template already sets all consent to denied, why do I have to write a script that supposedly does the same before? Well that’s because the setting of consent denied is supposed to be sent to Google even before the Tag Manager Container loads. So, the Iubenda settings are more like an additional override to make sure that when the Iubenda script fires, consent is set to 0 for sure.
Second part: what you describe is asynchronous tracking, where we would fire tags depending on the read consent from the cookies stored after interaction with the cookie banner. Now things are different. In consent mode v2, all tags fire. Period. They fire, but wether they are associated with cookie based information, so that Google can recollect the vents and associate them to a session, or wether they arrive as “simple” pings. When out of the context of Google Tags and going to third parties platform, this really depends on the platform.
Every single third party will have to come up with their own way to deal with cookieless pings. Technically though, this implementation is required only for Google Tags, because it’s Google who is going to stop processing data that doesn’t come from a Consent Mode v2 enabled property. They are enforcing this mandatorily, to keep their system functional and useful. Other third parties might decide to do things differently.
All the best
Thanks for that further info. It makes sense, and it’s easy to conflate consent mode v2 with all round consent management, legal compliance and data collection in any platform (although maybe it’s not a bad model to follow….?).
In my example I was thinking of someone rejecting personalisation cookies, and as per GDPR, ensuring that any platform that collected data performing such a function did not fire on first or subsequent visits.
And of course there’s a difference between the consent signals that Iubenda collect and these Google signals? Am I thinking about that correctly?
Hello Ross,
Exactly. While this sounds also to me like a very good model to replicate, this is Google’s own solution not for compliance really, but to compensate for data loss using machine learning (while staying compliant).
Google’s technologies rely heavily on the data sampled for free from all of us who install their tracking models on our websites; thus, having a seriously depleted amount of data passing trough (with async tagging, for example), would be a detrimental loss in terms of business.
Not to mention the loss on performance in advertising.
Therefor this way, they still get data, it’s just that it’s modeled where there wasn’t consent, only collecting the hits.
Iubenda stores consent in a 1st party cookie, and Google reads those values, as the language is aligned.
Cheers
Sorry Pietro, one other question.
To be fully v2 compliant, is it correct that we should add “ad_user_data” and “ad_personalisation” as additional consent tags against all Google-platform tags in GTM?
Because the current built in consent checks only list ad_storage and analytics_storage. With my setup, the two new consent signals don’t appear in the dropdown options. I can type those values, but I don’t know if that indicates something is wrong with my Iubenda configuration.
Ciao Pietro, grazie intanto per la guida!
Ho due domande a cui cerco risposta da giorni:
1. La consent mode v2 in modalità Advanced è o no compliant al GDPR?
2. Dopo aver impostato la Consent mode V2 (Basic) è normale vedere un calo degli utenti praticamente pari al 90%? Al momento l’ha impostato il nostro webmaster e ha installato il plugin di Cookiebot su WordPress; in origine pensavo di farlo con GTM, non so se cambi la situazione.
Grazie!
Ciao Giada!
Allora, ecco le rispote:
1) Si, consent mode v2, essa sia in modalità advanced o basic, è compliant con il GDPR in funzione del Digital Marketing Act perché di fatto o non passa alcun tag per Google, oppure passa un ping senza alcun identificativo e non viene usato il cookie.
2) E’ normale vedere un calo del traffico, in quanto ora in GA4 vedi solo i dati osservati. Tuttavia un calo del 90% mi sembra un pò troppo, in genere da benchmark noi stiamo notando una media del 40/45% di calo di traffico tracciato. Per verificare se è tutto normale, ti consiglio di accedere alla console di gestione della tua CMP (cookiebot) e verificare il tasso di consenso e di rifiuto. Se il tasso di rifiuto è del 90%, allora ci sta, e magari devi lavorare nel migliorare il banner per renderlo meno bloccante e scoraggiante. Se invece non è compatibile il tasso di non consenso con il drop che vedi, ci potrebbe essere qualche problema nella configurazione.
Buon lavoro!
Grazie mille Pietro. Il nostro webmaster sostiene che l’advanced non sia compliant, e per questo siamo rimasti un po’ titubanti. Ci sono link con info ufficiali in merito?
Grazie per la tempestiva risposta ancora, buon lavoro!
Giada
Ciao Giada,
Se il tuo webmaster è un avvocato specializzato in privacy e web tracking, allora direi di ascoltare quello che ti dice.
Google afferma che Consent Mode v2 è assolutamente compliant con il DMA che è l’accorto unilaterale tra Europa e Stati Uniti riguardo all’allineamento del comportamento online riguardo alla privacy utente. I ping che vengono inviati ai servizi Google quando non consensati, sono privi di qualsiasi identificativo. Non solo l’IP, ma qualsiasi identificativo. Di conseguenza, dal momento che non c’è modo per Google di ricollegare un hit a un’utente o un device (e nemmeno di collegare più hit della stessa visita tra di loro per comprendere che appartengono alla stessa sessione), non vi è alcuna violazione del GDPR nello specifico. Il GDPR non pone solo limitazioni riguardo al trasferimento dei _ DATI PERSONALI _ degli utenti al di fuori della comunità economica Europea. Ha tantissimi altri requirement.
Ad ogni modo, il problema reale non si pone nel caso dei dati inviati a Google, che ha pensato ad una soluzione per essere compliant, ma per tutti gli altri tag di marketing e delle informazioni basate sui cookie di terze parti. Credo che quello sia qualcosa di molto più preoccupante.
Buon lavoro 🙂
Forse può esservi utile prendere visione di questo: https://www.google.com/intl/it/about/company/user-consent-policy-help/
Grazie ancora Pietro.
Due curiosità: questa implementazione in modalità basic personalmente ad oggi, ci porta comunque una perdita altissima di utenti, oltre il 70%. In modalità advanced potrebbe andare meglio?
In ogni caso va meglio con l’implementazione tramite GTM, quella precedente tramite plugin di Cookiebot per WP, e non gestita da noi, aveva praticamente azzerato gli utenti.
Non trovo tanta chiarezza nei vari blog, ci sono più domande che risposte ancora 😅
Grazie e buon lavoro!
Ciao Giada, bentornata.
Si, sicuramente la modalità avanzata è molto meglio. Io fossi in te abiliterei quella, sennò non sfrutti quasi per niente le qualità di GA4 e dello smart bidding. Riguardo al calo, eh si, ahimè a seconda di come è implementato il cookie banner ed il tipo di audience del sito web, registriamo drop tra il 30 ed il 70%.
A presto
Ciao Pietro,
abbiamo implementato la modalità advanced il 1° agosto. Ipoteticamente cosa dovrei aspettarmi di vedere da GA4? perchè al momento non vedo variazioni significative nei volumi di traffico.
Vorrei capire oggettivamente cosa aspettarmi o se in caso posso aver sbagliato qualcosa.
Grazie per la chiarezza fornita fin ora nelle risposte : )
Ciao!
Se avete implementato COMO a inizio Agosto, non vedete sostanziali differenze perché da Febbraio / Marzo tutti noi in Europa vediamo in Analytics solo i dati osservati; addirittura, molti siti web, hanno visto il loro traffico azzerarsi in assenza di COMO correttamente implementata.
Tendenzialmente, se questo fosse stato fatto durante una collezione totale e non filtrata dei dati, avreste dovuto notare un calo del traffico registrato direttamente proporzionale al tasso di rifiuto del consenso della vostra CMP.
Pietro
Hello Pietro,
I would like to ask about the lack of loading signals before accepting the cookie consent banner. Is this correctly implemented? And how to check if the consent is configured correctly to enable behavioral modeling in GA4?
Hello Dawid,
May I ask what do you mean with “lack of loading signals” before accepting the cookie consent banner?
The last section of this article should guide you trough how to check the correct implementation. Unfortunately, modeling on GA4 is something that goes beyond your control.
For sure Consent Mode v2 must be enabled, is part of the requirements for modeled data to start showing up in the first place. But, we’ve noticed that so far, only two of our large accounts have had modeling enabled.
Google says that there’s no way to speed up the process, just to stick with the requirements. See them here-> https://support.google.com/analytics/answer/11161109?hl=en
all the best
Hi Pietro I have a specific question about consent mode v2:
1. From my understanding the consent mode v2 is applied because of legislation in EEA, but does google take it into account for USA or non-EEA countries? If we set defaults to denied and the CMP banner for USA is opt-in by default until the user opts out, many USA visitors won’t interact and will stay in denied. Does that mean google tags will receive cookieless pings from these users & not full data? If that’s the case – do we need to set Region Specific Default Consent values, setting Granted Defaults for USA & the rest of the countries with opt-in by default for example, doesn’t this supposed to be the CMP’s job?
Hello Ilin,
That’s a great question. First and foremost, I am Italian and therefor EU-laws focused in my article. When it comes to US laws, it’s important to talk to local lawyer specialized in online privacy, as I may be imprecise when it comes to legislations outside of EU.
Having said that, as far as I know, in the US the consent should be set automatically to “granted”; you can control this by using the CMP template in different tags, each of which fires at consent initialization depending if the user is visiting from the EU, or from the US. It’s still important though to set up Consent Mode v2, as if the users manually opt out of being tracked, then you’d still need consent mode v2 to enabled modeled data and conversion modeling.
To answer your final question, yes, that should be the CMP’s job, if you use a CMP plugin or a direct integration; if you are using Google Tag Manager, you are manually implementing the solution, and therefor you’ll need to set up these GEO informations manually.
Check out what Iubenda says about this here.
All the best
Buongiorno Pietro
E’ normale registrare un calo del 40% dopo aver installato GCM v2 con Tag Manager? Non capisco se è stato omesso qualcosa o sia normale. Sentendo competitor di settore mi dicono che loro non hanno perso nulla. Sbaglio forse qualcosa io? Grazie
Ciao Elvis 😉
Si, è normale se è compatibile con il tasso di consenso non garantito della tua CMP. Se usi Iubenda per esempio, accedendo alla tua dashboard e poi al tuo progetto, puoi vederne gli analytics, e verificare qual’è il tasso di consenso totale rifiutato; esso dovrebbe essere grossomodo compatibile con le perdite che registri (immagino tu stia parlando di analytics). Questo capita specialmente se hai appena attivato CoMo; tecnicamente si doveva passare a CoMoV2 come upgrade dalla Consent Mode già attuata da un paio d’anni, ma quasi nessuno lo faceva, quindi il drop è molto visibile.
Riguardo ai tuoi colleghi, le possibilità sono 2: o non hanno implementato loro correttamente CoMo, oppure hanno fatto il passaggio a v2 da una implementazione precedente, e quindi si, in quel caso non si nota perdita di traffico e dati. Ad ogni modo, se attivi la reporting identity di tipologia “blended”, se il tuo account rientra nei criteri di elegibilità, inizierai tra qualche settimana a vedere non solo dati osservati ma anche dati modellati, e recupererai correttamente questa quantità di traffico perso.