Skip to content

Answer library  /  Conversion Tracking  ·  Troubleshooting

What is Google Consent Mode and how does it work?

Google Consent Mode is an API that tells your Google tags what a visitor agreed to, so they fire normally, send cookieless pings, or hold back. It doesn't collect consent. On one store I audited, visitors accepted the banner and the Google Ads beacons still went out as gcs=G1--, because nothing passed the yes along.

Google Consent Mode is a JavaScript API that sits between your cookie banner and your Google tags. Your consent management platform (CMP) tells Consent Mode what the user agreed to. Consent Mode then tells every Google tag on the page how to behave. That’s the whole job.

It’s easy to confuse the two halves. The CMP collects the choice. Consent Mode reads that choice and adjusts tag behavior. If you only install one half, you get a banner that looks compliant but tags that still ignore consent, or tags that go silent because no signal ever reaches them.

Consent Mode controls four signals:

  • ad_storage: whether advertising cookies can be set
  • analytics_storage: whether analytics cookies can be set
  • ad_user_data: whether user data can be sent to Google for ads
  • ad_personalization: whether data can be used for personalized ads and remarketing

The last two arrived with Consent Mode v2 in November 2023, when Google began strengthening enforcement of its EU user consent policy, and the enforcement tied to them took effect in March 2024. If you use Google tags on EEA, UK and Swiss traffic for personalized ads or remarketing, those signals have to reach Google. Without them, remarketing and audience lists stop populating from that traffic.

Default state, then update

Consent Mode runs in two steps. First you set a default state before any tag fires. For EEA traffic the safe default is denied across all four signals. Then, once the user interacts with the banner, your CMP calls an update to flip the relevant signals to granted or leave them denied.

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

The wait_for_update value tells Google tags how long to hold before assuming denial. That window matters. If a tag fires before the default loads, it runs with no consent context, and you get the worst of both worlds: a hit that may breach consent and a signal Google can’t model from.

Basic mode vs advanced mode

This is the distinction most setups get wrong, and it changes what data you actually keep.

In basic mode, Google tags don’t load at all until the user grants consent. If consent is denied, nothing fires. No pings, no modeling input. You lose all visibility into denied-consent users.

In advanced mode, tags load on every page but adjust behavior based on consent. When consent is denied, tags send cookieless pings: no identifiers, no cookies, just an anonymous signal that an event happened. Google uses those pings as input for conversion modeling, which estimates the conversions you can’t directly observe.

Advanced mode is what most advertisers want, because it feeds the modeling that fills the gap left by denied consent. Basic mode is simpler and more conservative, but you forfeit the modeled conversions. Pick deliberately. An account can land in basic mode by accident when the CMP blocks the tags from loading, and the owner never realizes modeling was on the table.

Conversion modeling

When consent is denied and you’re in advanced mode, Google fills the reporting gap with modeled conversions. It uses the cookieless pings plus aggregate, observed behavior to estimate conversions from users it couldn’t track individually. Google requires a traffic threshold before modeling kicks in. Small accounts may not hit the volume needed, so the modeled numbers can stay flat even with advanced mode configured correctly.

Modeled conversions show up inside your Google Ads conversion columns. They’re estimates, not raw counts, so reconciling them against a server-side source or your backend will never be exact. That’s expected behavior, not a bug.

Consent Mode problems rarely show up as error messages. They’re silent gaps you only find when conversions drop or audiences stop growing, or when you read the beacons. The failures to check for:

No default state set. Tags fire before the consent default loads, so the update never has anything to override. Check that the default block runs first in the data layer, above your GTM container or gtag snippet.

CMP and Consent Mode not wired together. The banner records a choice but never pushes an update call. Consent stays at the default forever. In GTM, confirm the CMP template is firing the consent update, not just writing a cookie.

Granted, but the beacons say otherwise. On one store I audited, returning visitors had accepted the banner, the consent cookie and the CMP’s own API both said yes, and every consent-scoped Google beacon still went out carrying gcs=G1--. Two causes stacked. For a returning visitor, the CMP’s free tier never sent the granted update, because that feature sat behind the paid tier. A bridge tag that did push the update ran on DOM-ready, after the page-view and conversion beacons had already left. The fix read the consent cookie server-side and printed the granted state at the very top of the page, ahead of every tag, and the beacons flipped to G111 the same day.

v1 signals only. A setup built before 2024 sends ad_storage and analytics_storage but not ad_user_data or ad_personalization. European remarketing audiences slowly drain. Audit the tag for all four signals.

Basic mode by accident. The CMP is set to block Google tags entirely, so advanced mode and its modeling never run. If your conversion volume from European traffic looks like a cliff rather than a slope, check whether tags are being blocked rather than adjusted.

Consent checks layered on top in GTM. Some accounts use a CMP, native Consent Mode, and a GTM trigger condition that also gates the tag. Three layers, each capable of blocking, and a tag that fires far less than anyone expects. Simplify to one source of truth, and clear out what’s left over. When I audited my own container, a paused Cookiebot tag and two orphan consent triggers were still sitting there months after I’d removed Cookiebot.

How to verify it works

Open Google Tag Assistant or the browser console and watch the consent state. You want to see the default event fire first with denied values, then an update event after you interact with the banner, with the signals you granted flipping to granted. In GTM preview mode, the Consent tab shows each tag’s required consent and whether it was met at fire time.

Then read what the page actually sends. Accept your own banner, reload, open the network tab, filter for collect or google, and read the gcs parameter. After G1, the first digit is ad storage and the second is analytics storage: 1 is granted, 0 is denied, and a dash means no state was set. G111 is both granted. G100 is both denied. G1-- after you said yes means nothing on the page passed your choice to Google. Run the test as a returning visitor, not in a fresh incognito window, because the first-visit path is the one every setup gets tested on, and the failure above only appeared on the second visit.

If the default fires, the update fires, all four v2 signals are present, and your tags read them, Consent Mode is doing its job. If conversions still look wrong after that, the problem is downstream in your tag configuration or attribution, not in Consent Mode itself. Consent Mode governs the gate. It doesn’t fix what happens once the tag is through it.

Consent also gets blamed for gaps it didn’t cause. When I measured three ecommerce accounts from May to August 2026 for the Ecommerce Tracking Accuracy Benchmark, the gaps I could measure came from configuration: on two of three accounts the Conversions column carried cart events, and on all three, 99.4% to 99.8% of All conversions wasn’t a purchase. No account in that sample exposed a modeled-versus-observed split through the API, so consent effects couldn’t be measured at all. Check the definitions before you blame the banner.

When to bring me in

Bring me in when Google Ads, Meta and your store report different numbers for the same sales, when a purchase or lead event stopped firing after a site change, or when you can’t say which number to trust.

I'm Conner Crowe, and I write every audit myself. Send the free audit request and add me as a read-only user, and within 24 hours of access you'll have a written read on which numbers to trust and what to fix first. No call needed, and nothing in your account or store changes.

Request a free Google Ads audit

See how I fix conversion tracking.

See it in Google Ads

Where to look in your account.

Whether the measurement itself is healthy

Goals, then Conversions, then Summary, then Diagnostics

  1. Enhanced conversions health, one bar per conversion action. Excellent means the hashed customer data is arriving and matching.
  2. Urgent. When I captured this, one of my own two actions had an issue, and See details names it. Check this tab after any site or checkout change.
  3. Consent mode status for the website. Google reads the consent signals your cookie banner sends; Excellent means they’re arriving.

From my own Google Ads account, October 2026. Tap or click the screen to see it full size.

Tools for this diagnosis

All my free tools

Related questions

Back to the full conversion tracking: the diagnosis library

Want your tracking checked?

Same check,
run on your tracking.

Add me as a read-only user and I'll write the audit myself: which of your numbers to trust and what to fix first, 5 to 7 pages, back within 24 hours of access. No call needed. If you'd rather talk first, a call is open too.