Google Consent Mode v2: The Complete Implementation

Implement Google Consent Mode v2 with gtag.js, GTM, and server-side GTM — correct code for all four consent signals, basic vs advanced mode, and debugging.

Most Google Consent Mode v2 guides are written by marketing teams, for marketing teams: long on why, vague on how. Yet the actual implementation is a handful of JavaScript calls — and getting them in the wrong order, or forgetting two parameters, silently breaks your conversion tracking for every EEA visitor.

This guide is the opposite. Short on pep talk, long on correct, runnable code: the gtag default and update commands with all v2 signals, region-specific defaults, the Google Tag Manager setup, server-side GTM behavior, the basic-vs-advanced trade-off, and how to verify it all with Tag Assistant.

And it's timely: as of June 15, 2026, consent mode is the single control governing how Google Analytics data flows to Google Ads — the old Google Signals toggle no longer gates advertising data. If your consent signals are wrong now, your Ads data is wrong, full stop.

Google Consent Mode v2 is an API that tells Google's tags (Analytics, Ads, Floodlight) what a visitor has consented to, so the tags adjust their behavior — setting cookies and sending full data when consent is granted, and either staying silent or sending cookieless pings when it's denied. "v2" added two parameters in November 2023 — ad_user_data and ad_personalization — on top of the original ad_storage and analytics_storage. Since March 2024, Google requires these signals from advertisers using measurement, ad personalization, or remarketing features for users in the EEA (plus the UK and Switzerland under the same EU User Consent Policy).

One thing consent mode is not: a consent banner. It's the messenger, not the message. You still need a CMP or your own banner to actually collect consent — consent mode just relays the answer to Google.

Signal	Controls	Required by Google's EU policy?
`ad_storage`	Advertising cookies (read/write)	Yes
`ad_user_data`	Whether user data is sent to Google for advertising purposes	Yes (new in v2)
`ad_personalization`	Remarketing and personalized ads	Yes (new in v2)
`analytics_storage`	Analytics cookies (e.g. GA4's `_ga`)	Needed for GA4 to use cookies
`functionality_storage`	Functional cookies (e.g. language settings)	No (GTM consent checks only)
`personalization_storage`	Personalization cookies (e.g. video recommendations)	No
`security_storage`	Security/anti-fraud cookies	No

The two v2 parameters are where most legacy implementations fail. A consent mode v1 setup that only sends ad_storage and analytics_storage leaves ad_user_data and ad_personalization unset — and Google Ads features like audience building and enhanced conversions degrade for EEA traffic as a result.

Who actually has to do what

This gets garbled constantly, so let's be precise:

Advertisers (you run Google Ads, GA4 audiences, remarketing) serving users in the EEA/UK must send consent signals via consent mode v2. You can use a Google CMP partner or implement it yourself with a custom banner — Google's own documentation lists "manage consent settings yourself" as a supported path. No certification required.
Publishers monetizing with AdSense, Ad Manager, or AdMob are different: since January 16, 2024, serving personalized ads to EEA/UK users requires a Google-certified CMP integrated with the IAB TCF (Switzerland followed on July 31, 2024). Self-built banners don't qualify for personalized ads there.

If you're both (you buy ads and serve them), you need the certified-CMP route. If you're advertiser-only, the rest of this guide is everything you need.

Step 1: Set defaults before anything else

The default command must run before any config or event command — in practice, put it above the Google tag snippet in your <head>:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }

  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

wait_for_update: 500 tells tags to hold fire for up to 500 ms, giving an asynchronously loading CMP time to push the visitor's stored consent before the first hit goes out. Without it, returning visitors who already accepted get their first pageview measured as denied.

Step 2: Region-specific defaults

You usually don't want opt-in defaults in places that don't require opt-in consent. Consent mode supports layered defaults with ISO 3166-2 region codes — the most specific matching region wins, and Google determines the visitor's region automatically:

// Global default: granted
gtag('consent', 'default', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

// Stricter default for EEA + UK + Switzerland: denied until consent
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500,
  'region': ['AT','BE','BG','HR','CY','CZ','DK','EE','FI','FR','DE','GR',
             'HU','IS','IE','IT','LV','LI','LT','LU','MT','NL','NO','PL',
             'PT','RO','SK','SI','ES','SE','GB','CH']
});

Both default calls go in the same script block, before the Google tag. Sub-regions work too — 'region': ['US-CA'] applies a default only to California. (Whether granted-by-default is appropriate outside Europe is a legal question, not a technical one — see where opt-in consent is required.)

Step 3: Update on the visitor's choice

When the visitor interacts with your banner, push an update — for every signal, on accept and on reject:

function applyConsent(prefs) {
  gtag('consent', 'update', {
    'ad_storage': prefs.marketing ? 'granted' : 'denied',
    'ad_user_data': prefs.marketing ? 'granted' : 'denied',
    'ad_personalization': prefs.marketing ? 'granted' : 'denied',
    'analytics_storage': prefs.analytics ? 'granted' : 'denied'
  });
}

Persist the choice (a first-party cookie or localStorage) and re-apply it via update on every subsequent page load, inside the wait_for_update window.

Step 4: Optional but worth it

// Carry gclid/dclid across pages in URL params when ad cookies are denied
gtag('set', 'url_passthrough', true);

// Strip ad-click identifiers from requests when ad_storage is denied
gtag('set', 'ads_data_redaction', true);

url_passthrough recovers some conversion attribution without cookies; ads_data_redaction is a privacy-hardening measure many EU legal teams ask for. Both are set commands and belong alongside your defaults.

GTM uses the same underlying API, with consent-aware plumbing on top.

Set defaults before the container loads. Either place the same inline gtag('consent', 'default', …) snippet above your GTM snippet (it shares the dataLayer), or use your CMP's community template configured to fire on the built-in Consent Initialization — All Pages trigger, which runs before all other triggers. Don't use a Custom HTML tag on a normal Page View trigger for defaults — it fires too late.
Enable Consent Overview under Admin → Container Settings → "Enable consent overview". A shield icon appears in the Tags screen showing every tag's consent configuration at a glance, with bulk editing.
Rely on built-in consent checks for Google tags. GA4, Google Ads, and Floodlight tags automatically adjust behavior based on consent state — you don't add blocking triggers for them in advanced mode.
Gate non-Google tags with additional consent checks. Open a tag → Advanced Settings → Consent Settings → "Require additional consent for tag to fire", and list the signals it needs (e.g. require ad_storage for a Meta pixel). Tags with pixels and fingerprinting behavior have no built-in consent logic — unchecked, they fire regardless of consent.

Good news: if your web container is set up correctly, server-side consent mode mostly takes care of itself. Google's documentation is explicit that you only need to set up consent mode in the web container. The Google tag appends the consent state to requests sent to your server container — visible as the gcs parameter (e.g. G111 for granted, G100 for denied; one digit each for ad and analytics storage) and the gcd parameter, which encodes all four v2 signals.

Google tags inside the server container (GA4, Ads conversions, Ads remarketing) are consent-aware and adjust automatically: denied-consent GA4 traffic becomes cookieless pings, conversion pixels go out without third-party cookies, and remarketing requests are blocked outright.

The catch is third-party tags in the server container. A Meta CAPI or TikTok Events tag has no idea what gcd says — server-side tagging will happily forward personal data for users who refused consent unless you stop it. Read the consent fields from the incoming event in your tag templates (or gate the tags on a consent variable) and drop or trim non-consented data yourself. This is the single most common server-side compliance hole.

	Basic	Advanced
Google tags before consent	Fully blocked — nothing loads	Load immediately with denied defaults
Data when consent denied	None at all	Cookieless pings (consent state, timestamp, user agent, referrer, ad-click presence — no cookies, no IDs)
Conversion modeling	General model	Advertiser-specific model (more accurate)
GA4 behavioral modeling	Not eligible	Eligible (tags must load in all cases)
Regulatory comfort	Maximum	Debated

Advanced mode is the measurement-friendly option: those cookieless pings feed Google's conversion and behavioral modeling, recovering a chunk of the data lost to consent rejection. GA4's behavioral modeling additionally requires real volume — at least 1,000 daily events with analytics_storage='denied' for 7+ days, and 1,000 daily users with consent granted on 7 of the previous 28 days — so small sites often won't qualify even on advanced mode.

The trade-off: advanced mode sends something to Google despite refusal. Google designed the pings to be cookieless and non-identifying, but whether any transmission after a "no" sits comfortably with strict readings of ePrivacy is still debated among EU privacy professionals. Risk-averse legal teams pick basic mode for EEA traffic and accept the modeling loss; growth teams pick advanced. Decide deliberately.

The June 2026 change you should know about

Announced via Google Analytics' data-controls update and effective June 15, 2026: Google Signals no longer co-governs whether GA4 data flows to linked Google Ads accounts — it now only controls signed-in-user association for behavioral reporting. Consent mode is the single control: ad_storage determines advertising data collection for Ads, and later in 2026 Google will make ad_personalization the sole control for ads-personalization use of Analytics data. IP addresses flowing to linked Ads accounts are encrypted.

Practical upshot: the "we left Google Signals off as a safety net" era is over. Your consent mode signals are the policy now. Audit them.

Debugging: trust nothing, verify everything

Tag Assistant (tagassistant.google.com): connect your page and open the Consent tab. You should see the default state set before the container/config loads, then an update event when you interact with the banner. Per-tag, check which consent each tag required and whether it was met.
Network panel: filter for collect or googleadservices requests and inspect gcs and gcd parameters. gcs=G100 on a visitor who clicked "accept" means your update isn't firing or fires too late.
GTM Preview mode: the Consent tab on each event shows on-page consent state ("Default" vs "Update") per signal.
GA4 admin check: Admin → Data collection → Consent settings flags whether Google is receiving the v2 signals from your property.

Common mistakes

Defaults after config. The consent default must precede the Google tag snippet. If gtag.js loads first, the first hit goes out under no consent policy at all.
Only v1 signals. Missing ad_user_data/ad_personalization quietly degrades Ads features for EEA users.
Updating only on "accept". Reject must also push an explicit update — and the choice must be re-applied on every page load.
No wait_for_update with an async CMP: returning consenting visitors get their first pageview measured as denied.
Blocking gtag.js while claiming advanced mode. If the tag never loads, there are no pings and no modeling — you've built basic mode with extra steps.
Region list typos. 'UK' is not a code; the United Kingdom is 'GB'.
Unguarded third-party tags, client- or server-side. Consent mode governs Google's tags; everything else needs explicit gating.

Where CookieChimp fits

If you'd rather not hand-roll and maintain all of this, CookieChimp is a Google-certified CMP with consent mode v2 built in: one script tag sets denied defaults, fires the update with all four signals on the visitor's choice, applies geo-targeted defaults so EEA visitors get opt-in while US visitors get opt-out, and logs every consent for audit. It's the simple-yet-powerful route to the exact setup described above — and because it's certified and TCF-integrated, it also covers the publisher requirement if you monetize with AdSense or Ad Manager. See how it compares to Cookiebot and CookieYes.

FAQ

Is Google Consent Mode v2 mandatory?

If you advertise with Google (Ads, GA4 audiences, remarketing) to users in the EEA, UK, or Switzerland — effectively yes. Google has enforced its EU User Consent Policy via the v2 parameters since March 2024; without them, personalization, audience building, and measurement degrade or stop working for that traffic. With no EEA/UK/Swiss users and no Google ad stack, nothing forces you to implement it.

Do I need a Google-certified CMP for Consent Mode v2?

Only if you're a publisher serving personalized ads to EEA/UK (since January 16, 2024) or Swiss (since July 31, 2024) users through AdSense, Ad Manager, or AdMob — then a certified, TCF-integrated CMP is required. Advertisers can self-implement consent mode with a custom banner; Google explicitly supports that path.

What's the difference between ad_user_data and ad_personalization?

ad_user_data controls whether user data may be sent to Google for advertising purposes at all (it gates features like enhanced conversions). ad_personalization controls whether that data may be used for personalized advertising — remarketing lists, similar audiences. A user can permit measurement (ad_user_data: granted) while refusing remarketing (ad_personalization: denied).

Does consent mode replace a cookie banner?

No. Consent mode only transmits consent decisions to Google's tags — it doesn't collect consent, render a banner, or block non-Google scripts. You still need a banner/CMP to obtain valid consent under GDPR and ePrivacy, plus a blocking mechanism for every non-Google tag.

How do I check if consent mode v2 is working?

Open Tag Assistant (tagassistant.google.com), connect your domain, and check the Consent tab: defaults should be set before any tag fires, and an update should appear after banner interaction. Then verify network requests carry gcs/gcd parameters matching the choice you made, and check GA4's Admin → Consent settings diagnostic.

What is the difference between basic and advanced consent mode?

In basic consent mode, Google tags are fully blocked until the user consents — nothing loads, nothing is sent. In advanced mode, tags load immediately with denied defaults and send cookieless pings when consent is refused, which feeds Google's conversion modeling and makes GA4 behavioral modeling possible. Basic is the conservative choice; advanced recovers more measurement.

References

Google for Developers, "Set up consent mode on websites": developers.google.com
Google for Developers, "Consent mode concepts (basic vs advanced)": developers.google.com
Google for Developers, "Implement consent mode with server-side Tag Manager": developers.google.com
Google Tag Manager Help, "Updates to consent mode for traffic in the EEA": support.google.com
Google Tag Manager Help, "Tag Manager consent mode support": support.google.com
Google AdSense Help, "Requirements for using Google-certified CMPs": support.google.com
Google Analytics Help, "Updates to Google Analytics Data Controls": support.google.com
Google Analytics Help, "[GA4] Behavioral modeling for consent mode": support.google.com

Consent mode v2 is only as good as the consent system behind it. Get started with CookieChimp and ship a correct, geo-aware implementation in minutes.

Google Consent Mode v2: The Complete Implementation Guide

What is Google Consent Mode v2?

The consent signals, explained