Menu

Consent Mode V2 for Google Tags

An overview of Google's Consent Mode V2, adapted from the original work by Markus Baersch.
Simo Ahava in Analytics on #google tag , #consent mode , #privacy , #google tag manager , #google analytics Non-AMP version

**Last updated March 7, 2024. Clarified that you do NOT need to resend hits when consent is granted, if those hits were collected on the same page when consent was denied.

Google’s Consent Mode continues to be a hot topic, especially since in 2024 it will be required to implement Consent Mode in case a website or app is collecting data for audience building or remarketing with Google’s advertising services.

I’ve discussed consent mode before, and I’ve also built a Google Tag Manager community gallery template for managing Consent Mode on a website.

With V2, the biggest updates are two new consent signals, ad_user_data and ad_personalization, as well as a revamped URL schema for passing consent states to Google’s services.

This article is a guest post by Markus Baersch, who authored an excellent Consent Mode FAQ in his native language of German.

In this text, we’ll revisit the FAQ in English, and we’ll make sure it’s up-to-date with all you need to know about Consent Mode – especially V2.

Consent Mode is primarily about collecting additional signals from users who did not grant consent for having their personal data or browser storage accessed for data collection. These signals are then used by Google to model conversions (Google Ads, Floodlight, etc.) and visitor behavior (Google Analytics 4).

This article is a technical overview so we’ll gloss over the ethical and legal questions regarding data collection from unconsenting users. See the Summary chapter for some of Simo Ahava’s thoughts on the topic.

This method of collecting analytics and advertising pings from unconsenting users is based on the logic of avoiding access to browser storage. This way, cookies containing personal data (such as online identifiers) will not be accessed by Google’s services, and random, ephemeral identifiers are used instead.

Unconsented data isn’t surfaced in Google’s reports directly – instead, it goes through a modeling process where it’s shaped and molded to look like the real thing (data collected from consenting users).

In V2, the original Consent Mode signals (ad_storage for advertising cookies and analytics_storage for analytics cookies) are complemented by two additional signals:

  • ad_user_data: does the user consent to their personal data being used for advertising purposes?
  • ad_personalization: does the user consent to their data being used for remarketing?

Unlike ad_storage and analytics_storage, these flags don’t have a functional impact on how the tags behave on the site itself. They are additional parameters sent with the pings to Google services, designed to instruct these services on how user data can be used for advertising.

So while ad_storage and analytics_storage are upstream qualifiers for data (as they control which identifiers are sent with the pings), ad_user_data and ad_personalization are downstream instructions for Google services on how to process the data.

Consent Mode has additional, more advanced settings like ads_data_redaction, which prevents the passing of any click identifiers or third-party cookie decorations on the advertising streams. Additionally, there are settings like allow_ad_personalization_signals that also govern what type of data Google’s advertising services can access. If there is a conflict between these settings and Consent Mode, the “strictest” setting wins in favor of data protection.

Advanced vs. Basic Mode

Consent Mode V2 also introduced the concepts of Advanced Consent Mode and Basic Consent Mode.

Technically, these are not new things. Advanced Consent Mode is Consent Mode as we know it (and as Google wants us to use it). It means collecting pings of data from users who did not grant consent.

Basic Consent Mode means that Consent Mode is active on the page (or app), but Google’s tags are prevented from loading and collecting data until consent is granted.

In other words:

  • No Consent Mode: Consent Mode is not implemented on the page at all. All data collected to Google services is assumed to have consent from the user.
  • Basic Consent Mode: Consent Mode has been implemented, but data is collected only if the user grants consent.
  • Advanced Consent Mode: Consent Mode has been implemented, and data is collected from users when they grant consent and when they deny consent.

Which mode you choose has implications on the quality of modeling (source):

And that’s really the main question. How much do you value getting that modeled data? Is it worth collecting data from users who do not grant consent to Google’s services?

There has been some confusion about how Basic Consent Mode “works”.

It’s really quite unexciting. You implement Consent Mode on the site so that tags send the consent signals to Google’s services. However, you block tags from firing if consent has not been granted. In other words, you only send “consent granted” signals to Google, and Google will assume that no data has been collected from users who did not grant consent.

At the time of writing, this manual work is still yours to do. There is no magical “Basic Consent Mode” switch that automatically configures Google’s tags appropriately.

Google Tag Manager has a consent settings interface for managing consent settings in your tags.

Built-in Consent Checks lists all the consent states that the tag template code accesses. It is solely an indicator that the template accesses consent state in its code. What it does with this consent state depends on the tag template.

Additional Consent Checks lists all the consent states that need a granted status for the tag to fire. When the tag’s trigger goes off, if any of the listed consent states has the denied status, the tag will not fire.

These are solely Google Tag Manager settings. They have no analogy in gtag or Consent Mode itself. For example, even though Google Analytics 4 tags are sensitive to all four Consent Mode signals, they have Built-in Consent Checks only for analytics_storage and ad_storage. Why? Because those are the only consent states that actually alter how the tag code works. ad_user_data and ad_personalization are URL flags that are automatically added to the GA4 requests – the GA4 event tag does not need to interact with these states.

If consent is granted, then any hits collected on the same page while consent was denied will get automatically reprocessed to have the granted status.

This applies only to Advanced Consent Mode, of course, because that’s the only way of sending hits when consent is denied. With Basic Mode, you will need to start data collection manually when consent is granted.

Note that this only applies to hits collected on the same page. Hits that happened on previous pages will not get reprocessed because Google should not be able to link them due to lack of cookie identifiers.

Maybe, especially if you operate in or your site visitors are data subjects in the European Economic Area.

At the very least, in 2024, you’ll most likely need to implement Basic Consent Mode for all of your Google tags. It’s not necessarily a bad thing even if it requires additional tagging and implementation resources. As you’re collecting data only from users who grant consent (you are, right?), Basic Consent Mode simply means that you communicate this granted state to Google’s services with the collected data.

However, if you are using Google’s advertising services (either directly or through Google Analytics 4), Consent Mode might be mandatory.

  • If you are collecting first-party user data, or using the Google Ads user_id, or sharing Conversions from Google Analytics 4 to Google Ads, you must implement Consent Mode and set the ad_user_data flag.
  • If you are collecting data for remarketing with Google’s advertising services, you must implement Consent Mode and set the ad_personalization flag.

As far as I know, conversion tracking does not require Consent Mode and should work fine without it. However, you will of course lose some conversion modeling benefits if you choose not to implement Consent Mode.

If you want to or if you have to implement Consent Mode, you should do so as soon as possible. Consent Mode should be deployed as early as possible on the page or in the app render flow. Google Tag Manager for the web has a built-in trigger, Consent Initialization, for this.

Important: There is no need to change anything in your tagging setup or to start sending data without consent granted (Advanced Consent Mode)! The requirement is to implement Consent Mode, and Basic Consent Mode will do just fine. In this case, as before, you would just need to make sure that no data is collected and no tags are triggered before consent has been granted.

In most cases, you already have a Consent Management Platform in place, and enabling the new signals is just a checkbox somewhere.

If you are running a manual implementation of Consent Mode without any fancy integrations, you can read below for more details on manual configuration.

This is still unclear.

It is likely that audience building and remarketing capabilities will be crippled if not outright disabled for the data collected from your digital properties.

Similarly, links between Google Analytics 4 and Google’s advertising services regarding the features listed above will also be non-functional.

As mentioned before, it’s still not clear if and how much conversion tracking will be impacted. As it doesn’t rely on user data collection similar to audience generation and remarketing, it’s likely that it will continue to work to some extent.

In any case, if you want to use Google’s analytics and advertising services, we strongly recommend putting Basic Consent Mode on your backlog as soon as possible.

Does anything change from a data protection perspective?

Caveat, we are not your legal team.

To keep it simple: nothing changes. Assuming you have thus far only collected data from users who have granted consent.

The data collected from these users looks pretty much the same as before – it just has the additional “consent granted” signal in place, and it can also include explicit instructions that the data can be used for Google’s advertising services.

As for “Advanced Consent Mode”, its use needs to be extremely carefully deliberated with your legal team. Remember that you are collecting data from users who might not have opted into such a thing.

When Consent Mode is active, either in Basic or Advanced Mode, there are additional parameters sent with each analytics and advertising request to Google’s services.

You can use Google’s Tag Assistant, the Network tab of your browser’s developer tools, or a browser extension.

For the original version of consent mode, if you’re looking at the network requests, the parameter you’re looking for is called &gcs, and it has a value in the following format: G1xy.

x stands for consent to Google Ads cookies and is either 1 (granted) or 0 (denied).

y stands for consent to Google Analytics cookies and is either 1 (granted) or 0 (denied).

Possible values are thus:

Value Description
G100 No consent has been granted.
G110 Google Ads has consent, Google Analytics does not.
G101 Google Analytics has consent, Google Ads does not.
G111 Both Google Ads and Google Analytics have consent.

Note that G100 is only possible in “Advanced Consent Mode”.

With Consent Mode V2, the additional gcd parameter can be found in all requests, and you can read more about its composition below.

How do I read network requests?

If you debug network requests, you can simply filter for gcs to find all requests that have this parameter. This would include both Google Analytics and Google Ads requests.

Clicking on the request, you can then scroll to the request payload parameters to find the value of gcs in the list:

You’ll notice that there is another setting here, too: gcd. More on this below.

How do I use Tag Assistant?

If you go to https://tagassistant.google.com/, you can debug the consent states for any sites running Google Tags.

After adding the domain that you want to debug, you can choose a Tag ID from the top of Tag Assistant, then choose an event from the navigation on the left, and finally select the “Consent” tab to see what the state of different consent signals was at the time of the event.

If you see a warning that “a tag read consent before a default was set”, it means you have a race condition where your consent states are not established in time before any tags that reference them have time to fire.

Please note that these are internal parameters used by Google. Their values can change without warning, and trying to overinterpret how Consent Mode is encoded in URL parameters can be an exercise in futility. I really recommend using Tag Assistant to debug consent states.

The gcs parameter is solely for ad_storage and analytics_storage. For the new signals and for Consent Mode V2 in general, there is an additional URL parameter, gcd, that you’ll need to interpret.

gcd is included in all hits to Google services, even if Consent Mode isn’t active.

It encodes values for all four consent signals (ad_storage, analytics_storage, ad_user_data, and ad_personalization), and it includes information how the consent signal was generated.

The format of the string might be something like this:

&gcd=11<ad_storage>1<analytics_storage>1<ad_user_data>1<ad_personalization>5

The string starts with 11, uses 1 (or some other number) to separate the different consent signals, and ends with a number like 5 (or sometimes something else) to mark the end.

As for the possible values for the signals, here’s the table as we currently know it:

Letter Description Example
l The lowercase L means that the signal has not been set with Consent Mode. 11l1p1l1l5 (Only analytics_storage has been denied by default).
p denied by default (no update). 11p1p1p1p5 (all consent states are denied by default).
q denied both by default and after update. 11p1q1p1p5 (the user updated their consent choice to set analytics_storage to denied after it was already set to denied by default).
t granted by default (no update). 11t1t1t1t5 (all consent states are granted by default).
r denied by default and granted after update. 11r1r1r1r5 (the user grants consent to all services after they were first denied by default).
m denied after update (no default). 11p1m1p1p5 (all other states were denied by default, but analytics_storage was only set after the user denied it).
n granted after update (no default). 11n1n1n1n5 (the site did not set a default consent state and instead set all states to granted after the user chose so).
u granted by default and denied after update. 11u1u1u1u5 (the user withdrew all consents after they were set to granted by default).
v granted both by default and after update. 11v1v1v1v5 (all states were granted by default and by user confirmation).

If you are confused about “default” and “update”, check this article for more information on the two different commands for interacting with Consent Mode.

These letters are obscure and they might change in the future. Google obviously doesn’t intend for you to debug Consent Mode by looking at URL requests. Instead, the preferred way is with Tag Assistant, but sometimes (especially if you’re shuffling the data in your own services, too), understanding the URL parameter schema can be helpful.

Consent Mode is a Google invention. The idea of collecting data from unconsenting users and using it for modeling is all Google.

Other tags and services can theoretically make use of these flags, too. In Google Tag Manager, for example, you can create custom templates that react to any of the given consent states, even custom ones that you label yourself! But this isn’t “Consent Mode” - it’s just building tech around the flags and parameters that Google uses for Consent Mode.

Interestingly, it looks like Microsoft is parroting Google’s idea with their own Consent Mode implementation that bears striking similarities to Google’s.

Manual configuration

If your CMP doesn’t support a Consent Mode integration, or if you want to set everything up manually, you can certainly do so.

If you use Google Tag Manager, you can use my custom tag template to establish consent states for both “default” and “update” commands.

The “default” command should be set to fire on the Consent Initialization trigger so that the default state is established before any other tags fire.

Once you know the user’s consent preferences, you can fire the tag with the “update” command.

If you’re not using GTM or if you want to set everything up with JavaScript, you can use the gtag method for that.

// Set defaults
window.gtag = function() { dataLayer.push(arguments); }
window.gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// Call this function when consent is granted
const updateConsent = newConsentStates => {
  window.gtag('consent', 'update', newConsentStates);
  writeStatesToStorage(newConsentStates);
};

The code above is just a very basic example. What matters is that the default command is called before any Google tags fire and that the update command is called as soon as the user’s consent choices have been registered.

Setting Consent Mode can be quite a chore, especially if you’re going with manual configuration. However, it’s important to get it done properly so that you don’t end up with a liability. Markus Baersch has an excellent checklist for verifying the implementation here: https://www.markus-baersch.de/consent-checkliste-buch/ (German).

Summary

Consent Mode is still very tricky.

It’s risky to collect data from users who did not grant consent.

People who are pro-Consent-Mode are trying to pull this apart by saying that users did not necessarily deny consent for “anonymous pings” or that it’s not really “personal data” under GDPR and so forth. They might be right, although the notion of “anonymous data” with all that gets collected with a consent-denied ping is pretty ludicrous. Similarly, GDPR has an extremely wide net when it comes to personal data, so collecting things like Order IDs or User IDs from unconsenting users will almost certainly get you in trouble if you are audited for GDPR violations.

If you collect anything from a user who did not give consent to that particular service, you are putting yourself in many flavors of jeopardy:

  • Legal, if you do not have a legal basis to collect this data beyond consent.
  • Ethical, if you assume that the user is OK with you collecting data from them even if they denied consent.
  • Brand image, if it reaches the public that you are collecting data from users who denied consent.
  • Data security, if you inadvertently collect sensitive information from users who did not consent.

So collecting data from unconsenting users will always be a risk greater than that of not collecting data from unconsenting users. You need to assess this risk carefully.

Other than that, Basic Consent Mode, where data is only collected from consenting users, seems like a no-brainer at this point. It’s possible Google will simply switch it on automatically by default for all Google services.

You’ll just need to make sure that you only fire Google’s tags if consent has been granted.

Thank you so much to Mr. Markus Baersch for the groundwork he did for Consent Mode V2. It’s likely Google’s own documentation will catch up at some point, but even then I’m sure the content of this FAQ will be useful to English readers. Be sure to check out Markus’ original article in German here, as he has more details about Consent Mode V2 that I chose to omit for brevity’s sake.

If you have questions or comments about Consent Mode V2, let me know in the comments!