Google Consent Mode v2

What Consent Mode Actually Does

Without Consent Mode, a consent management platform simply blocks Google tags when a user declines. The tag never fires and Google receives nothing.

With Consent Mode, the tag still fires but sends cookieless pings carrying no identifiers. Google uses these to model the conversions and users it cannot observe directly.

The practical difference is measurement continuity. Accounts running blocked tags see traffic and conversions disappear entirely for non-consenting users; accounts running Consent Mode see modelled estimates instead.

The Four Consent Signals

v2 introduced two additional parameters alongside the original two:

• analytics_storage — permits analytics cookies and measurement
• ad_storage — permits advertising cookies
• ad_user_data — permits sending user data to Google for advertising purposes
• ad_personalization — permits personalised advertising and remarketing

The two v2 signals are mandatory for advertisers targeting the EEA. Without them, remarketing audiences and conversion measurement for European traffic degrade substantially.

Basic Versus Advanced Implementation

Basic — tags are blocked until consent is granted. No data flows before consent, including no cookieless pings. Simpler and more conservative; modelling quality is lower because Google sees nothing about non-consenting users.

Advanced — tags load immediately in a restricted state and send cookieless pings regardless of consent choice. Produces materially better conversion modelling.

Advanced gives better data. Whether it is appropriate depends on your legal position and your regulator, and that is a question for counsel rather than for marketing.

Conversion Modelling

Where consent is declined, Google estimates the conversions that likely occurred using observed patterns from consenting users with similar characteristics.

Modelled conversions appear in reporting without being labelled separately in most views, which matters when reconciling platform figures against your own back-end data. The gap between Google-reported conversions and CRM-recorded conversions is frequently modelling rather than tracking failure.

Modelling requires threshold volumes. Small accounts may see no modelling at all, and therefore a genuine reduction in reported conversions.

Implementation and Verification

Consent Mode is configured through a certified CMP or manually through Google Tag Manager. The default state must be set before any tag fires — a common implementation error is setting defaults too late, so tags fire in an unconsented state.

Verify with Tag Assistant and the browser network tab: confirm the consent parameters appear on requests, confirm they change when consent is granted, and test all three states — granted, denied, and no interaction.

Choosing Between Basic and Advanced, Honestly

The choice is presented as a technical setting and is really a policy decision, because the two modes behave differently before a user has answered the banner.

Basic holds the tags back entirely until consent is given. Nothing is sent, nothing is collected, and an unconsented visitor is invisible. It is the more conservative reading and the easier one to defend.

Advanced loads the tags immediately and sends cookieless pings carrying no identifiers, which is what feeds the modelling. More data, more complexity, and a position you have to be able to justify — because something did leave the browser before the user answered.

Two things decide it. What your legal advice says about transmitting anything pre-consent in your jurisdictions. And whether you have the volume for modelling to work at all — below the platform's thresholds you get the complexity of advanced mode and none of the benefit, which is the most common wasted implementation.

India is not a lighter-touch case. The DPDP framework is consent-based with no legitimate-interest basis, so a configuration built for a market with one does not transfer.

Verifying It Rather Than Assuming It

Consent mode fails silently. The banner appears, the tags fire, the dashboard fills, and nothing tells you the signals are wrong.

The checks worth running, in order:

• Watch the network requests before and after consenting. Confirm what is sent in each state, and that the consent parameters actually change.
• Check the default state is denied, and that it is set before any tag loads. A default of granted, or one applied too late, is the most common and most serious misconfiguration.
• Test a decline, not just an accept. Almost nobody does, and the decline path is the one that carries the risk.
• Verify the update fires when consent changes, including when a user later withdraws it.
• Check region-specific defaults if you serve multiple jurisdictions.

And document the configuration next to the analytics documentation. They are owned by different people, changed independently, and together they determine every number the business runs on.

Sources

What each claim on this page rests on. Entries are typed so you can see which are primary.