Conversions Dropped After Consent Mode v2? How to Diagnose It
Your Google Ads conversions dropped 40-70% the week Consent Mode v2 or a new cookie banner went live, and GA4 sessions look thin. The cause is one of two things: users declining tracking, which is expected and partly recoverable through modeling, or a consent implementation that keeps Google tags denied for everyone, which is a bug.
I audit these setups weekly. Most "consent killed our tracking" cases turn out to be the bug, not the consent. Here is how to tell them apart in about 15 minutes.
What Consent Mode v2 actually blocks
Consent Mode v2 manages four signals: ad_storage, analytics_storage, ad_user_data, and ad_personalization. The last two were added in v2 and gate whether user data can be sent to Google's ad systems at all.
In advanced mode, when a user declines, Google tags still fire but send cookieless pings. No cookies are read or written, no client ID persists between pages, and each request carries the consent state. Those pings feed conversion modeling in Google Ads and behavioral modeling in GA4. That is the intended design: you lose the individual user, Google estimates the aggregate.
The modeling has thresholds. GA4 behavioral modeling needs roughly 1,000 events per day with analytics_storage denied for 7 days, plus about 1,000 daily consented users for 7 of the last 28 days. Google Ads conversion modeling needs roughly 700 ad clicks over 7 days per country-domain grouping. Smaller stores never clear these bars, so declined traffic simply vanishes from reports with nothing modeled back.
In basic mode, tags do not load until consent is granted. No pings, no GA4 modeling for declined users, and Ads falls back to a more general model. Basic mode always loses more data than advanced.
Broken implementation vs expected loss
Three implementation bugs cause most of the catastrophic drops I see:
- Default consent never set. A consent default must execute before any Google tag loads. If it is missing, tag behavior is undefined and modeling signals are unreliable. The correct pattern, in the page head before gtag.js or GTM:
gtag('consent', 'default', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
wait_for_update: 500
});- The banner never updates consent. The user clicks Accept, but no gtag('consent', 'update', ...) call fires, or it fires with the wrong signal names. Everything stays denied for 100% of users, including the ones who said yes. This is the single most common cause of a 60-90% drop.
- The CMP hard-blocks the scripts. Many CMPs ship with auto-blocking that prevents gtag.js or GTM from loading at all until consent. That silently converts your advanced consent mode into basic mode, or worse, blocks tags even after acceptance if script categorization is wrong. No pings means nothing to model.
Expected loss looks different. With a compliant EU banner, typically 20-35% of visitors decline, depending on banner design. Observed conversions dip by a similar share, then modeling gives part of it back over one to two weeks if you clear the thresholds. A drop that roughly matches your decline rate is consent behavior. A drop far beyond it is a bug.
Diagnose it in 15 minutes
Do these checks in order, in an incognito window so you start with no stored consent.
- Tag Assistant. Open tagassistant.google.com, connect your domain. In the left panel, select the first page-load message and open the Consent tab. You should see an on-page default (all four signals denied) registered before the container loads. Accept the banner, then check that an on-page update appears and flips the signals to granted. Missing default row = bug 1. Missing or wrong update = bug 2.
- Browser network tab. DevTools, Network, filter for collect. GA4 hits go to google-analytics.com/g/collect (or a regional endpoint). Inspect the gcs query parameter: G100 means ad_storage and analytics_storage both denied, G111 both granted, G110 ads granted only, G101 analytics granted only. Before any banner interaction you should see G100 with requests still firing (advanced mode). After accepting and clicking around, new hits must show G111. If gcs stays G100 after acceptance, the update call is broken. If there are no collect requests at all before consent, your CMP is hard-blocking and you are in basic mode whether you intended it or not. The gcd parameter encodes default and update per signal; a signal encoded as l was never set at all, which points at a missing default.
- GA4 DebugView. Enable debug mode, accept the banner, fire a test purchase or add_to_cart, and confirm the events arrive in Admin, DebugView. Consented events that never reach DebugView mean the tag is blocked downstream of consent.
- Google Ads. Open the conversion action and check its diagnostics for consent warnings. Ads flags actions receiving traffic without proper consent signals.
- Meta, if it dropped too. A hard-blocking CMP takes every vendor down at once. Verify the pixel in Events Manager, Test Events. If Meta events also stopped for consented users, the CMP script categorization is the problem, not Google.
What recovers the data
Fix the consent flow first. Region-scoped denied defaults with wait_for_update, an update call that fires immediately on banner choice, and a stored choice that re-applies on every subsequent page load. Verify gcs on page two of a session, not just page one. Add gtag('set', 'url_passthrough', true) so ad click IDs survive into the session for declined users via URL parameters.
Enhanced conversions. Send hashed email and phone with the purchase event. For consented users this recovers matches that Safari's tracking prevention and ad blockers would otherwise lose, and it feeds the models better data. Note that user-provided data only transmits when ad_user_data is granted, so a broken update call also silently disables enhanced conversions.
Server-side tagging. A server GTM container on your own subdomain sets first-party cookies that outlive Safari's 7-day JavaScript cookie cap, gets past most ad blockers, and improves match quality on every consented hit. It does not override consent, denied stays denied, but it makes your consented majority count fully. In most EU stores I work on, the revenue recovered from the consented 70-80% exceeds what the declined minority ever represented.
Numbers still don't add up?
Tell my assistant what you see and I will reach out to you directly. Every rated job on Upwork is 5.0, check them live.
FAQ
How much conversion loss is normal after implementing Consent Mode v2?
Expect observed conversions to dip roughly in line with your decline rate, typically 15-35% in the EU, with modeling recovering part of that within one to two weeks if your traffic clears Google's thresholds. A 60-90% drop is almost never consent behavior. That scale of loss points at a missing default, a banner that never sends the update call, or a CMP hard-blocking the tags.
What does gcs=G100 mean on my GA4 requests?
It means ad_storage and analytics_storage were both denied on that request. That is correct before the user makes a consent choice. If gcs stays G100 after the user accepts the banner, the consent update call is not firing, and every visitor is being tracked as declined.
Should I use basic or advanced consent mode?
Advanced mode fires tags as cookieless pings for declined users, which enables conversion modeling in Google Ads and behavioral modeling in GA4. Basic mode blocks tags entirely until consent, so declined users produce nothing to model. Most EU stores run advanced mode; confirm the choice with whoever handles your privacy compliance, since it is a legal position as much as a technical one.
Does server-side tracking let me bypass the cookie banner?
No. Consent applies to server-side tagging the same as browser-side, and a denied user must stay denied end to end. What server-side does is make consented traffic count fully by beating ad blockers and Safari's cookie limits, which in practice recovers more revenue than the declined minority represents.
Want it checked by professionals?
Seven days of platform conversions next to your real orders is enough for us to name the likely cause. No charge, usually under an hour.