Why Consent Mode Makes Your Conversions Drop (and How to Verify What's Really Tracked)

"We added a cookie consent banner, and our conversion count fell off a cliff." This is one of the most common complaints in ad operations and site optimization. You changed nothing about your tags — yet the numbers in your reports dropped. Almost always, the cause is a misunderstanding of how Consent Mode actually behaves.

Do any of these sound familiar?

• Conversions dropped 20–40% starting the day you launched the consent banner
• Your GA4 users and conversions are clearly lower than before
• Google Ads now shows more conversions labeled "modeled"
• You clicked "Allow" on the banner, but you can't tell whether your own test is being tracked

This guide explains how Consent Mode causes conversions to drop or go missing, the difference between basic and advanced mode, the top 5 misconfigurations, and how to verify — in your real production environment — exactly how you're being tracked right now.

First principle: Consent Mode is not an on/off switch for tracking

The biggest reason this goes wrong is treating Consent Mode as a simple toggle: "no consent = zero tracking, consent = 100% tracking." In reality, tag behavior changes gradually depending on the consent state.

Consent Mode v2 communicates four main "consent types" to your tags:

Consent type	What it controls
analytics_storage	Whether analytics cookies (GA4, etc.) are allowed
ad_storage	Whether advertising cookies are allowed
ad_user_data	Whether user data may be sent to Google for ad purposes
ad_personalization	Whether data may be used for remarketing (ad personalization)

The key point: even when these are "denied," the tag does not necessarily stop completely. How much still runs depends entirely on whether you're on "basic" or "advanced" mode — covered next. Mistake this, and you fall into the "I set it up but the numbers don't add up" swamp.

Basic vs advanced mode: the drop looks completely different

Consent Mode has two broad implementations, and conversions drop for fundamentally different reasons in each. Watching the numbers without knowing which one you're on will never lead you to the cause.

Basic Consent Mode

Tags don't load at all until the user consents.

• Before consent: nothing fires — zero requests reach Google
• After consent: the tag loads and measurement begins from that point

It looks simple, but there's a trap. Any page navigation or action before the user clicks "Allow" is entirely uncounted. In particular, when a conversion completes while the banner is still showing (a fast form submit, completion in another tab), that result vanishes completely.

Advanced Consent Mode

Tags load from the start, but while there's no consent they send only cookieless, anonymous signals (cookieless pings).

• Before consent: only a minimal, non-identifying signal is sent
• After consent: it switches to normal, cookie-based measurement
• Google uses those anonymous signals to fill the gap with conversion modeling (estimation)

Advanced mode loses less, but in exchange some of your numbers become estimates, not actuals. That's why "modeled conversions" increase in Google Ads — it's by design, not a malfunction.

Key takeaway: when it "feels like the numbers dropped," suspect lost data (missing actuals) on basic mode, and replacement by estimates on advanced mode. The cause and the fix are completely different.

How the "consent" signal is actually sent

Before you start verifying, knowing how the browser communicates consent state to Google makes everything downstream much easier.

GA4 and ad requests (the …/g/collect calls you can see in DevTools Network) carry a parameter called gcs. This is the "Google Consent Signal," and you can read it roughly like this:

• gcs=G100 … both ad_storage and analytics_storage denied
• gcs=G110 … ad_storage granted only
• gcs=G101 … analytics_storage granted only
• gcs=G111 … both granted

In v2, a parameter called gcd additionally carries the more detailed consent state, including ad_user_data / ad_personalization.

In other words, you can see directly in the Network tab which consent state your page is sending requests under right now. This is the single most important checkpoint.

Top 5 reasons conversions drop

When the numbers fall, the cause usually comes down to these five. Work through them top to bottom.

1. The default is "denied," and many users don't consent

In Consent Mode, the initial (default) state before the user chooses is typically set to "denied." And in reality, a significant share of users never click "Allow." On basic mode, all of their results are lost — a common cause of no conversions showing in Google Ads. The size of the drop is roughly proportional to the share of users who decline.

2. On basic mode, pre-consent conversions disappear

As noted, basic mode delays loading the tag itself. Fast conversions that complete while the banner is showing are structurally uncountable. If "visitors reach the thank-you page but it isn't tracked," suspect this.

3. The CMP isn't sending the consent update

A consent banner (CMP) must tell your tags the moment a user clicks "Allow." If that "update" wiring is missing, the tag keeps treating the state as "denied" even after the user consents, and measurement never starts. This is an extremely common setup mistake.

4. ad_user_data / ad_personalization aren't set

If you haven't implemented the two parameters that became mandatory in Consent Mode v2, Google Ads can no longer use those conversions for remarketing or parts of optimization. The tag may fire, but the "usable" results shrink on the ad side.

5. Misconfigured region settings

You may have set "stricter consent in specific regions," but the region targeting is too broad or too narrow. Users in unintended regions get restricted, and the overall numbers fall more than expected.

Conversion modeling: how much does it actually recover?

On advanced mode, Google fills the consent gap with modeled conversions — statistical estimates of what the non-consenting users would have generated. But the recovery isn't automatic or guaranteed.

Requirements for modeling to kick in:

• Consent Mode must be correctly implemented (or IAB TCF v2.0)
• You need at least 700 ad clicks per day over a 7-day period, per country and domain grouping
• A consent rate of roughly 20%+ is needed for the model to have enough real data to work with

How much does it recover? Google reports that conversion modeling recovers, on average, more than 70% of ad-click-to-conversion journeys lost to consent declines. But treat that as a ceiling for high-volume properties, not a guarantee. Below the modeling thresholds, the model can't run at all — and you need to stack Enhanced Conversions and server-side tagging for partial recovery instead. Browser-level privacy features like Safari's ITP compound this gap further, making server-side recovery even more critical.

What this means in practice: If your site has moderate traffic (below 700 daily ad clicks), you won't get modeled conversions at all. Your reported numbers will simply be lower — and the gap is real, not recoverable through Consent Mode alone.

Consent banner design: the biggest lever you control

The share of users who consent is not fixed — it's heavily influenced by how your consent banner is designed. Industry data for 2026 shows a surprising pattern:

• When users interact with a consent banner, they accept 69% of the time on desktop and 76% on mobile
• The problem is that 47% of desktop visitors generate no consent signal at all — they neither accept nor refuse ("no-choice")
• The real problem isn't willingness to consent — it's engagement with the banner itself

Design factors that improve consent rates:

• Visual integration: Banners that match your site's branding feel trustworthy, not like a third-party intrusion
• Non-blocking layouts: A banner that covers the entire page causes users to bounce or ignore it. Progressive consent (a minimal banner on arrival, expanded contextually after engagement) improves interaction rates
• Mobile optimization: Mobile-first designs consistently achieve higher consent rates than desktop-first designs adapted for mobile
• Avoid dark patterns: Hiding the "reject" button, using confusing language, or making acceptance visually dominant can draw regulatory fines — several EU DPAs (France, Norway, Germany) have issued penalties for deceptive banner design
• CLS impact: Banners that cause layout shift hurt both consent rates and SEO (Core Web Vitals)

A well-designed banner typically achieves 30–50% consent rates, while a poorly designed one may see rates below 15%.

Why conversions drop even though the tag "fires"

The tag is running (firing), yet the report numbers fall. This is the most confusing pattern with Consent Mode. The reason: firing (a request is sent) and being measured (a complete, cookie-based record) become decoupled depending on consent state. This pattern is explored in depth in when a conversion fires but isn't recorded.

When there's no consent, even if the tag fires:

• Cookies can't be used, so cross-session and repeat-visitor logic breaks
• It can't be tied to the ad click, so you lose which ad drove the result
• On advanced mode only anonymous signals are sent, and the gap is filled by modeling (estimates), not actuals

So even if you confirm "collect is firing in Network," if its contents read gcs=G100 (denied), it is not recorded as a complete, ad-usable conversion. Checking only whether the tag fires will never reveal a Consent Mode problem.

How to verify "how am I being tracked right now" in production

Method 1: Watch gcs in DevTools Network

The most reliable check.

1. Open the page you want to verify (especially the thank-you page) and open the "Network" tab in DevTools
2. Filter for collect or conversion
3. In the requests being sent, check the gcs parameter
4. See whether the gcs value changes when you click "Deny" vs "Allow" on the banner

What it tells you: which consent state requests are being sent under, at this exact moment. gcs=G111 means both granted; if it stays G100, it's still running as denied.

Common pitfall: if you click "Allow" but gcs stays at G100, cause #3 (the CMP isn't sending the update) is the prime suspect. The classic case: the consent "default" was set, but the "update" was never wired up.

Method 2: Check consent state in Tag Assistant / GA4 DebugView

Google Tag Assistant (tagassistant.google.com) shows each tag's Consent state in a list. GA4 DebugView also lets you trace the consent state tied to each event.

What it tells you: you can reconcile "which consent state the tag fired under" not just from the sending side but from the admin side too.

Method 3: Test in both "Allow" and "Deny"

The most important rule when verifying Consent Mode: don't stop at one pattern.

• Measurement when you click "Allow" on the banner
• Measurement when you click "Deny"
• Measurement before you interact with the banner (undecided)

Only after checking how gcs and the result change across all three states can you know whether your real visitors are handled correctly in every state.

What checking on your own machine can't tell you

Every method above is useful, but testing once on your own machine has two blind spots that are specific to Consent Mode:

1. You almost always verify in "Allow." Whoever runs the test instinctively clicks "Allow" on the banner. But the people pulling your numbers down are the ones who "Deny" or stay undecided. Judging "it's tracking fine" from the granted state alone misses the entire loss.
2. Anything involving an ad click is hard to reproduce. To properly see "how a visitor who came via an ad and then denied consent is treated on the ad side," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.

Consent Mode problems happen on the path of "the other person who denied," not "the you who allowed." The fact that it looks fine when you allow is exactly what breeds complacency.

A checklist to verify with confidence

• Do you know whether your site is on basic or advanced mode?
• Did you check the current consent state via the gcs parameter in Network?
• Did you test all three states — Allow, Deny, and undecided?
• When you click "Allow," does gcs actually change to G111 (both granted)?
• Have you implemented ad_user_data / ad_personalization (the two v2 mandatory params)?
• Is your CMP (consent banner) sending the consent update to your tags?
• Are your region settings scoped as intended?
• On the thank-you page, are fast conversions that complete before consent going missing?
• Does it hold up under real production visitor conditions (don't judge from the single "Allow" pattern on your machine)?

Frequently asked questions

Q. How much do conversions drop after adding a consent banner? A. It varies, but the size is roughly determined by the share of users who decline and whether you're on basic or advanced mode. Basic mode loses actual data, so the drop is larger; advanced mode fills some of the gap with modeling, so the drop is relatively smaller.

Q. What is a "modeled conversion"? Is it a malfunction? A. No. On advanced mode, it's a conversion Google statistically estimates and fills in, based on anonymous signals from non-consenting users. It isn't a direct measurement, so the number behaves differently, but it's working as designed.

Q. I'm clicking "Allow" but it isn't tracking. Why? A. The most common cause is that only the consent "default" was set, while the "update" sent to the tag when "Allow" is clicked was never wired up. Check whether gcs in Network stays at G100 even after you allow.

Q. Where can I see the gcs parameter? A. In your browser's DevTools "Network" tab, select a collect or conversion request and find gcs=... in its URL (query parameters). G111 means both granted; G100 means both denied.

Q. If I haven't enabled Consent Mode, does this not apply to me? A. If you serve ads to users in the EEA or UK, supporting Consent Mode v2 is a Google requirement under the Digital Markets Act (DMA) — so if you have those users, not having it is itself a compliance risk. The DMA designates Google as a "gatekeeper" and requires it to obtain user consent before cross-service data processing. Google passes this requirement to advertisers: no valid consent signal means Google restricts how your conversion data can be used for bidding, remarketing, and audience building. Conversely, even outside that scope, if you've added a consent banner, the losses in this article can still occur.

Q. Is the impact of Consent Mode the same for GA4 and ads? A. Similar, but not identical. analytics_storage affects GA4; ad_storage / ad_user_data / ad_personalization affect the ad side. If GA4 is tracking but only ad conversions drop, focus on the ad-related consent parameters.

Conclusion: verify with "the production user who denied," not "the you who allowed"

Conversions dropping under Consent Mode can't be diagnosed by watching whether the tag fires. What matters is verifying — down to the contents of gcs — whether your real visitors are handled correctly in every state: Allow, Deny, and undecided. For a step-by-step framework that covers Consent Mode alongside other common tracking issues, see the conversion tracking verification checklist.

ConversionOK runs your live page in an independent, isolated browser and intercepts the actual requests and consent signal (gcs) in both the granted and denied states. No need to click your own ad, and no blind spot from unconsciously verifying only in "Allow." Start with a free static check to confirm the entry point of your measurement under each consent state.