Back to blog

Google Consent Mode v2: what it is, why it matters and how to set it up

Consent Mode v2 is how your cookie banner talks to Google's tags. Without it, either the site tracks people who rejected, or Google Ads and GA4 lose those people's conversions. What it is, how it works and what it doesn't do.

offensive security · writes what we see in the audits

Short answer

Consent Mode v2 is the API through which your cookie banner tells Google's tags what the visitor accepted, using four signals (ad_storage, analytics_storage, ad_user_data and ad_personalization). Everything starts as denied and is updated after the choice. It doesn't replace the banner and doesn't block other companies' tags.

You installed a cookie banner, the visitor clicked "Reject", and Google Ads keeps counting their conversion. Or the opposite: the banner blocks everything properly and, ever since, half your conversions have vanished from the Ads dashboard.

Both problems have the same cause: the banner and Google's tags aren't talking to each other. Consent Mode is the protocol that makes that conversation happen.

It's a Google API where the site declares, before any tag runs, what the visitor allowed. Google's tags (GA4, Google Ads, Floodlight, and the ones that go through Google Tag Manager) read that state and adjust their behavior: set a cookie or not, send identifiers or not.

The flow has two moments:

  1. default — on page load, before the tags, the site declares everything as denied.
  2. update — when the visitor chooses in the banner, the site updates whatever was accepted to granted.
// on page load, before any Google tag
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied'
});

// after the visitor accepts analytics, but not advertising
gtag('consent', 'update', {
  analytics_storage: 'granted'
});

What changed in v2

Version 2, which Google started requiring in March 2024 for traffic from the European Economic Area, added two signals to the two that already existed:

Signal Controls
ad_storage advertising cookies
analytics_storage analytics cookies (GA4)
ad_user_data new — sending user data to Google for advertising
ad_personalization new — using the data for remarketing and personalized ads

Without the two new signals, Google treats the European visitor as not having consented to advertising, and features such as remarketing and audience lists stop being fed.

And in Brazil? Google's formal requirement targets the EEA and the UK. Outside Europe — in Brazil, for example — if you only advertise locally, the reason to set it up is a different one: Brazil's data protection law (LGPD), like the GDPR, requires consent before tracking, and Consent Mode is the way to respect a rejection without losing all measurement.

Basic mode vs. advanced mode

Here's the difference that decides how much data you lose.

  • Basic: Google's tags only load after consent. Whoever rejects sends nothing — not even an anonymous signal. Simple and conservative, but Ads goes blind to that share of traffic.
  • Advanced: the tags load from the start, in the denied state. For people who rejected, they don't set cookies and send only pings with no identifier. Google uses those signals to model the conversions it can't observe.

Advanced recovers part of the conversions, but it involves sending signals to Google even from people who rejected. Whether that's acceptable depends on your legal reading and on what you disclose in your policy — it's your decision, not the tool's.

Three common confusions:

  • It's not a banner. It doesn't ask the visitor anything. It needs a banner that collects the choice and calls update.
  • It doesn't block anything outside Google. Meta Pixel, TikTok, Hotjar and Clarity don't read Consent Mode. For them, the blocking has to be done by the banner — holding the script until consent.
  • It's not proof of consent. The record of who accepted what, and when, is still the banner's job.

How to set it up

The steps, in any tool:

  1. The denied default must run before any Google tag. If GTM loads first, the first page has already tracked.
  2. The banner must call update with the right categories: analytics → analytics_storage; advertising → ad_storage, ad_user_data and ad_personalization.
  3. The choice must be reapplied on every page — a visitor who accepted yesterday can't go back to the denied state today.
  4. In GTM, check under Admin → Container Settings → Consent Overview that each tag declares the signals it depends on.

To test: open Google's Tag Assistant, load the page without accepting and check that the initial state is denied. Accept and check the update.

With Cokei

In Cokei, M2HP's consent platform, Consent Mode v2 is a switch in the dashboard (from the Pro plan up). When it's on, the Cokei script:

  • declares the default with all four signals denied on load, before Google's tags;
  • calls update when the visitor chooses, mapping the banner's categories to the signals;
  • reapplies the choice on every page, from the consent cookie;
  • and does the same when the visitor reopens preferences and changes their mind.

For tags that are not Google's, Cokei does real blocking: it holds the script until the category is accepted. And it states in writing where automatic blocking doesn't reach — tags fired from inside GTM are one of them, and that's exactly where Consent Mode is the way to go.

Want to check whether your site respects rejection before touching anything? The Sentinela audit flags trackers loading before consent, and the post on the LGPD findings explains how to fix each one.

A cookie banner that holds up to LGPD and GDPR, with nothing built by hand.

Cokei is the consent platform from M2HP, the company behind Sentinela: it finds the cookies on your site, holds back the ones that need consent and records each visitor’s choice. Reject weighs the same as accept. Free plan with no end date.