Google Consent Mode v2: Setup Guide (2026)

If you run Google Ads or GA4 on a site with visitors in the EU or UK, Google Consent Mode v2 is no longer optional. Since early 2024, Google requires a valid consent signal before its tags will use cookies for ads measurement and audience building. Get it wrong and you lose conversion tracking, remarketing audiences, and a big chunk of your measurement data — quietly, with no error message.

This guide explains what Consent Mode v2 actually does, how the four signals work, and how to set it up correctly in 2026 — both the manual way and the no-code way with a consent management platform (CMP). It is a technical overview, not legal advice; consult a qualified advisor for your specific compliance obligations.

What is Google Consent Mode (and why v2 is mandatory now)

Google Consent Mode is a framework that lets your Google tags — GA4, Google Ads, Floodlight — adjust their behavior based on whether a visitor has consented to cookies. Instead of either firing fully or not firing at all, tags read a set of consent states and act accordingly.

The original Consent Mode covered analytics and ad storage. Consent Mode v2 added two new signals tied directly to advertising features. As of March 2024, those signals became a hard requirement: if you want to use European Economic Area user data for personalized advertising and remarketing in Google Ads, your tags must receive valid v2 consent signals. Without them, Google stops building remarketing audiences from EEA traffic and degrades conversion measurement.

In short: Consent Mode v2 is the bridge between your cookie banner and Google's ad and analytics products. If you serve European visitors and want your campaigns to keep working, it has to be wired up correctly.

Basic vs Advanced Consent Mode

There are two implementation modes, and the difference matters for both your data and your compliance posture.

• Basic Consent Mode blocks Google tags entirely until the user makes a choice. No pings are sent before consent. If the user declines, nothing is sent at all. This is the more conservative option — cleaner from a privacy standpoint, but you lose all signal from non-consenting users, so Google has less data to model from.
• Advanced Consent Mode loads Google tags immediately but, before consent, sends only anonymous, cookieless pings — no identifiers, no cookies. Once the user consents, full measurement kicks in. For declined users, Google uses those anonymous pings plus modeling (conversion modeling and behavioral modeling) to estimate the activity it cannot directly observe.

Most sites that care about measurement choose Advanced mode because conversion modeling recovers a meaningful portion of otherwise-lost conversions. Basic mode is simpler and stricter. There is no universally "correct" choice — it depends on your risk appetite and how much you rely on Google's modeled data. Whichever you pick, the consent signals themselves are wired up the same way.

The four consent signals

Consent Mode v2 is built on four parameters, each set to either granted or denied. Your banner is responsible for setting these accurately based on what the user actually clicked.

• ad_storage — controls whether cookies can be used for advertising purposes (for example, the Google Ads conversion cookie).
• analytics_storage — controls cookies used for analytics, such as GA4's measurement and session cookies.
• ad_user_data — controls whether user data can be sent to Google for advertising purposes. New in v2.
• ad_personalization — controls whether data can be used for personalized advertising and remarketing. Also new in v2.

The two newer signals (ad_user_data and ad_personalization) are what make this "v2." They are what Google checks before building EEA remarketing audiences. A common mistake is updating only the two original signals and leaving these undefined — which Google treats as missing consent and degrades your ad features accordingly.

Best practice is to default all four to denied before the user interacts with the banner, then update them based on the user's choice. That default-deny posture is also what most EU regulators expect: no non-essential cookies until consent is given.

How Consent Mode v2 connects your banner to Google Tag Manager

The mechanism is the data layer. When the page loads, a default consent state is pushed before any Google tags fire. When the user makes a choice, an update command pushes the new state. Google Tag Manager reads these states and gates each tag accordingly.

The order is critical: the default consent command must run before GTM and before any Google tags. If your tags load first, they fire under whatever Google's fallback assumes — and on EEA traffic that means missing or wrong consent. In practice this means the consent default snippet sits high in the <head>, ahead of the GTM container snippet.

GTM has built-in consent support. Each Google tag has consent settings that say, in effect, "only fire fully when analytics_storage is granted" (for GA4) or "respect ad_storage, ad_user_data, and ad_personalization" (for Google Ads). When the signals flip from denied to granted, GTM lets the tags do their full job.

Step-by-step: implementing with a CMP vs manual gtag

You have two realistic paths. Here is what each looks like.

The manual gtag route

1. Set defaults before anything else. Add a gtag consent "default" command in the <head>, above your GTM or gtag.js snippet, with all four signals set to denied (you can grant by region if you only restrict EEA traffic).
2. Build a banner. Code a cookie banner that captures Accept, Reject, and granular category choices.
3. Fire an update on choice. When the user clicks, call a gtag consent "update" command mapping their choices to the four signals — for example, accepting marketing sets ad_storage, ad_user_data, and ad_personalization to granted.
4. Persist the choice. Store consent so returning visitors are not re-prompted, and re-apply it on every page load before tags fire.
5. Handle re-consent and changes. Provide a way for users to change their mind, and re-fire the update accordingly.

This works, but it is fiddly. You are now maintaining banner UI, consent storage, regional logic, the data-layer timing, and an audit trail — and any mistake silently breaks tracking.

The CMP route

A consent management platform handles all of the above. A Google-certified CMP automatically pushes the correct default and update commands, maps user choices to all four v2 signals, persists consent, handles geo-targeting, and logs proof of consent. You drop in one script, and Consent Mode v2 is wired up correctly — including the data-layer timing that trips up manual setups.

Verifying with Tag Assistant and GA4 DebugView

Never assume it works — verify. Two free Google tools tell you the truth.

• Google Tag Assistant — connect to your site and load a page. In the consent view you should see the consent state both on-page-load (your defaults, ideally all denied) and after update (reflecting the user's choice). Click Accept and confirm all four signals — including ad_user_data and ad_personalization — flip to granted. If the two v2 signals stay undefined, your setup is incomplete.
• GA4 DebugView — with consent denied, you should still see cookieless pings arriving (in Advanced mode) but no analytics cookies set. With consent granted, full events flow. This confirms the analytics_storage gate is behaving.

Also check that the default fires before GTM: in Tag Assistant, the consent "default" event should appear before the container loads. If it appears after, fix your script order.

Common mistakes that break conversion tracking

These are the failures we see most often when a free cookie scan turns up trackers firing without proper consent:

• Only updating the two original signals. Forgetting ad_user_data and ad_personalization is the single most common v2 error. Google treats the missing signals as denied for ad features.
• Wrong script order. The consent default loading after GTM means tags fire before the consent state is set.
• No default at all. Without an explicit default, Google falls back in ways you do not control, and EEA ad features quietly degrade.
• Tags that ignore consent. A hardcoded analytics or pixel snippet that bypasses GTM will fire regardless of the banner. Real-browser scanning is how you catch these — source-only scanners miss tags injected by tag managers, iframes, and JavaScript at runtime.
• Banner says one thing, signals say another. If "Reject all" still grants analytics_storage, you have both a compliance problem and a data-integrity problem.

Automating Consent Mode v2 with CookieBrain (no code)

CookieBrain is a Google-certified-style CMP built to make Consent Mode v2 a non-event. You install one script line, and the banner automatically sets all four consent signals — ad_storage, analytics_storage, ad_user_data, and ad_personalization — with the correct default-deny-then-update sequence, before your Google Tag Manager container loads.

Because CookieBrain scans your site in a real headless browser, it catches the trackers that actually fire — including ones loaded by GTM, iframes, and runtime JavaScript that source-only scanners miss — and AI-categorizes each cookie so your banner maps choices to the right signals automatically. It serves the banner from Cloudflare's edge in under 50ms, supports geo-targeting so you can apply stricter defaults to EEA and UK traffic, and works on any stack: WordPress, Shopify, Webflow, or custom code.

That removes the fragile, hand-wired parts of Consent Mode v2 — the data-layer timing, the four-signal mapping, the consent logging — and replaces them with something you can verify in Tag Assistant in minutes.

Want to see what is firing on your site before consent? Run a free cookie scan with no account needed — it will show you every tracker a real browser catches and flag anything firing without consent. When you are ready to wire up Consent Mode v2 properly, start a 14-day free trial on any plan (no card required) and have it live in one line.