The Two New Signals in Google Consent Mode v2

What did Google Consent Mode v2 change?

In November 2023, Google Consent Mode v2 added two advertising parameters, ad_user_data and ad_personalization, alongside the ad_storage and analytics_storage signals that Google tags already read. Google's tag platform documentation states it plainly: "Consent mode was updated in November, 2023 and now contains two additional parameters" (Manage consent mode). The mechanics underneath, the default and update commands and the modeling Google runs on the results, are covered in a practical guide to consent mode. This page stays on what version 2 put on top of that.

What do ad_user_data and ad_personalization control?

The two parameters split one old question into two. Google's gtag reference defines ad_user_data as "Sets consent for sending user data to Google for advertising purposes" and ad_personalization as "Sets consent for personalized advertising" (gtag.js reference). One governs transmission, the other governs use. A visitor can agree to have data reach Google for conversion measurement and still refuse to be targeted with it, and version 2 gives that distinction a wire format.

Seven consent types exist across the API. Google's descriptions, quoted from its own pages:

Every one of these accepts exactly two values, granted or denied. Nothing else parses.

Is Google Consent Mode v2 required by the GDPR?

No, and the conflation is the most common error in writing on this subject. Google Consent Mode v2 is a requirement Google places on advertisers who want to keep using its products, carried by the EU user consent policy, which applies to "end users in the European Economic Area, the UK and Switzerland" and obliges advertisers to obtain consent for "the use of cookies or other local storage where legally required" and for "the collection, sharing, and use of personal data for personalization of ads" (EU user consent policy). The GDPR and the ePrivacy Directive impose the underlying legal duties. Neither names a JavaScript parameter.

The practical consequence: an implementation that sends granted for everything satisfies Google's plumbing and still breaks the law if no valid consent was collected. What makes consent valid in the first place sits upstream of any API, and is covered in what counts as tracking consent and in the GDPR consent requirements for web analytics. Wire up the signals after the legal question is settled, not instead of it.

Basic or advanced: which implementation do you choose?

Google documents two implementations of consent mode, and version 2 inherits both. In basic consent mode, the site will "prevent Google tags from loading until a user interacts with a consent banner", and "no data is sent before a user consents". In advanced consent mode, "Google tags load when a user opens the website or app" with defaults set to denied, and "when consent is denied, consent state and cookieless pings are sent. When consent is granted, cookies are written" (Google Ads Help).

The difference shows up in Google's modeling. The same help page describes basic mode as producing a "General model (less detailed modeling)" and advanced mode as producing an "Advertiser-specific model (more detailed modeling)". Advanced mode buys better conversion modeling by transmitting a cookieless ping from visitors who said no, which is a data protection decision a legal team should make rather than a growth team. Whichever you pick, the consent banner has to fire the update call and not merely repaint itself.

What breaks in Google's advertising products when the signals are absent?

Missing is not neutral. Google's Customer Match documentation states: "If these consents are missing, then the consent value is determined as not consented", and "Data from unconsented EEA users will not be processed and cannot be used for ad personalization using Customer Match" (About Customer Match and the EU user consent policy). The same page carries the dated requirement: "Starting in March 2024, for Customer Match lists to be used in EEA, both consent fields of ConsentStatus type must be set to 'GRANTED' to indicate that you have received the required user consent."

Which tags read the signals at all is also documented. Google lists the products whose tags "contain built-in consent checks" as Google Analytics, Google Ads, Floodlight and Conversion Linker (Consent mode in Google Analytics). A tag outside that list does not respond to a gtag('consent', ...) call, so blocking it is your job.

How do the default and update commands carry the new parameters?

The default command runs before any Google tag fires, and the update command runs when the visitor answers. Google's documented shape:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});
 
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

Two options matter for correctness. Google documents wait_for_update with "a millisecond value to control how long to wait before data is sent", for consent platforms that resolve asynchronously, and a region key set "according to ISO 3166-2" in the default command, where "the one with a more specific region will take effect". Getting default to run after gtag.js has already sent a page view is the failure that quietly voids the whole setup, and the same ordering trap is dissected in the Google Analytics cookie consent guide.

What has Google not documented?

Google has published no penalty schedule for consent mode, no fine, and no account suspension policy tied to the two parameters. The only hard date in Google's own pages for this update is the March 2024 Customer Match requirement quoted above; treat any other enforcement date circulating in blog posts as unsourced until Google publishes it. The documented consequence is functional rather than punitive: unconsented EEA data is not processed for personalization, and the audience or measurement feature that depended on it degrades.

There is a way out of the whole apparatus, which is to not send advertising signals to Google at all. Cookieless analytics removes the parameters from the question, and Flowsery's privacy-first analytics is cookie-free and EU-hosted, so there is no ad_storage decision to model around. Teams running Google Ads still need consent mode for the ads side, since one measurement tool cannot answer for another vendor's tags.

Frequently Asked Questions

Is Google Consent Mode v2 mandatory?

It is mandatory for advertisers who want Google's advertising and measurement features to keep working with EEA, UK and Switzerland traffic, under Google's EU user consent policy. It is not mandatory under the GDPR, which regulates the consent itself rather than how you transmit it to a vendor. A site that runs no Google advertising tags has no consent mode obligation from Google.

What happens if I only send ad_storage and analytics_storage?

Google's Customer Match documentation states that when the consent fields are missing, "the consent value is determined as not consented". The v1 parameters do not stand in for the v2 ones. Personalization features that depend on ad_user_data and ad_personalization treat that traffic as refused.

Can ad_user_data be granted while ad_personalization is denied?

Yes, and that combination is the point of splitting them. It means data may reach Google for advertising purposes while personalized advertising is refused. A consent banner with separate purpose toggles should map to that pair rather than collapsing both to one checkbox.

Does basic consent mode still count as Consent Mode v2?

Yes. Basic and advanced are implementation choices, and both carry the four advertising and analytics parameters. Basic mode blocks Google tags until the visitor interacts with the banner, so the parameters arrive only in the update call.

Which regions does Google's requirement cover?

Google's EU user consent policy names "end users in the European Economic Area, the UK and Switzerland". The Customer Match consent requirement quoted by Google references the EEA. Google's documentation does not extend the requirement to other regions.

Does consent mode restore the data that visitors refused?

No. Consent mode feeds Google's conversion modeling, which produces estimates rather than observations, and Google labels the two implementations as feeding a general model or an advertiser-specific model. The modeling caveats, and how they show up in reporting, are covered in the consent mode guide.

What is the difference between the v1 and v2 signals in consent mode?

The v1 signals are ad_storage and analytics_storage. Version 2 kept both and added ad_user_data and ad_personalization in November 2023, splitting the old single consent decision into separate signals for sending data to Google and for using it in personalized ads.

Which Google tags actually check the consent mode signals?

Google names Google Analytics, Google Ads, Floodlight and Conversion Linker as the products whose tags contain built-in consent checks. A tag outside that list ignores a gtag('consent', ...) call and keeps firing unless something else blocks it.

What does wait_for_update do in consent mode?

It is a parameter Google documents for the default command, set to a millisecond value that tells gtag.js how long to hold requests before sending them. It exists for consent management platforms that resolve asynchronously, so tags do not fire on the initial page load before the platform has reported a decision.

Can the region parameter set different defaults for different countries?

The default command accepts a region key using ISO 3166-2 codes, and Google applies whichever matching region is more specific. A site can set one default for the EEA and a separate one for everywhere else within the same default call.