Google Consent Mode v2 in plain words

Consent Mode is the mechanism Google uses to hear what your visitor decided. Version 2 has been required since March 2024 for anyone using Google's advertising products with traffic from the EEA. This is what it does, without the jargon.

The problem it solves

Before Consent Mode, a banner had one blunt option: either let Google's tags load or block them entirely. Blocking meant Google saw nothing at all — no conversions, no audience data, a hole in the reports. Consent Mode replaces the on/off switch with a conversation: the tags always load, but they are told what they are allowed to do.

The four signals

Your banner sends four flags, each either granted or denied:

• analytics_storage — may Analytics store anything in the browser, such as the visitor id.
• ad_storage — may advertising store anything, which is what remarketing lists depend on.
• ad_user_data — may the data collected be sent to Google for advertising purposes.
• ad_personalization — may it be used to personalise ads and build audiences.

The last two were added in version 2, and they are the reason an older setup is no longer enough on its own.

Why a refusal does not empty your reports

When a visitor refuses, the tags stay loaded but stop writing to the browser. What Google receives instead is a "cookieless ping": a stripped signal with no identifier, saying that something happened. Google then models the missing part statistically from the visits that did consent, and fills the gaps in your conversion numbers.

The practical consequence is worth stating plainly, because it is the opposite of what most owners fear: a properly configured banner with Consent Mode loses far less measurement than one that simply blocks Google. Refusal is not silence — it is anonymity.

Default state, and the mistake to avoid

The order matters more than anything else here. The denied defaults must be set before any Google tag runs — in the very first script on the page. If the tags load first and the consent state arrives afterwards, the first request has already gone out with full storage, and both the rule and the point of the exercise are missed.

A second, quieter mistake is setting the defaults for the wrong region, or forgetting the region setting altogether, so EEA visitors get the permissive default meant for everyone else.

How to tell it is working

• Open your site in a clean browser profile and watch the network requests before answering the banner. Google's collect requests should carry the consent parameters, and no analytics cookie should exist yet.
• Refuse, and check that the requests continue but no identifier cookie appears.
• Accept, and check that the state flips and the cookie is written.
• In Google Tag Assistant, the consent state is shown per tag, before and after the answer.

Where ConsentKit sits in this

The client writes the denied defaults into the page ahead of every tag, updates all four signals the moment the visitor answers, and records that answer. There is nothing to configure for the common case: install the line first, above your other scripts, and the ordering takes care of itself.

Correct as of September 2026. Google changes the details of its own requirements from time to time; the four signals and the ordering rule above are the parts that have been stable.

Not sure whether your current setup sends the signals at the right moment? The free check below reports what your pages load, and in which order.