Google Consent Mode v2: how it works and what to set up

Consent Mode is a Google API that adjusts how Google tags (GA4, Google Ads, Floodlight) behave based on consent state. It does not show a banner or store consent. Your consent management platform (CMP) does that, then passes the result to Google through Consent Mode.

Google's developer documentation defines four consent types that matter for ads and analytics:

• ad_storage: storage such as cookies related to advertising.
• analytics_storage: storage related to analytics, such as visit duration.
• ad_user_data: consent for sending user data to Google for online advertising.
• ad_personalization: consent for personalised advertising, including remarketing.

Google announced the two new signals, ad_user_data and ad_personalization, in November 2023 and began requiring them for EEA traffic in March 2024, when the Digital Markets Act took effect. Advertisers who want measurement, ad personalisation and remarketing on traffic from the European Economic Area need them.

Google documents two ways to implement Consent Mode. The difference is what happens before the visitor makes a choice.

Basic mode blocks Google tags until the visitor interacts with the banner. Google's documentation says no data is sent before consent, not even the default consent status. If the visitor declines, Google gets nothing from that visit. Conversion modelling falls back to a general model.

Advanced mode loads Google tags immediately with consent set to denied. While consent is denied, tags send the consent state and cookieless measurement pings. Google uses those pings for an advertiser-specific model, which Google describes as more detailed than the basic model.

Our take: advanced mode recovers more conversion data, but it sends pings to Google before consent. Decide on that with whoever owns privacy in your business, not only with the ads team.

Every page runs two commands. First, a default command sets the starting state for each consent type, usually denied for EEA visitors. Google's documentation requires this call on every page before any command that sends measurement data. Second, an update command runs when the visitor accepts or rejects, and again whenever they change their mind.

wait_for_update sits in the default command and gives the CMP a set number of milliseconds to send the update before tags fire. It matters for returning visitors whose choice is already stored.

Region-specific defaults let you apply denied defaults only where you need them. Google's documentation specifies ISO 3166-2 codes, so an EEA rule is a list of country codes such as DE, FR and IT, not a single EU value.

ads_data_redaction, when set to true while ad_storage is denied, redacts ad click identifiers in requests sent by Google Ads and Floodlight tags.

url_passthrough carries ad click and analytics parameters such as gclid, dclid and _gl in page URLs when cookie storage is denied, so a conversion later in the session can still be attributed.

All three consent platforms in our dataset are recorded with Consent Mode v2 support. Confirm the current integration details in each vendor's documentation before you commit.

• Cookiebot: built-in Consent Mode v2 support plus automated cookie scanning. A common fit for e-commerce sites running Google Ads.
• Usercentrics: Consent Mode v2 support aimed at larger teams, with white-label options. No automated scanner in our dataset, so plan to maintain your cookie inventory yourself.
• iubenda: Consent Mode v2 support bundled with privacy policy and terms generators. Useful for small businesses that need both.

Run your setup through the Consent Mode v2 readiness checker to find missing signals and get a prioritised fix list. Then confirm in Google Tag Assistant that the default fires before any tag and that accept and reject both produce an update.

For the step-by-step Google Tag Manager setup, with code for defaults, updates and CMP connection, use the Consent Mode v2 setup playbook. The GTM template and test cases cover the wiring and the checks.