GA4 traffic dropped after your cookie banner: the four causes

Short answer: some of the drop is genuine consent loss and you're supposed to see it — those visitors declined, and their data doesn't exist any more. The rest is one of three install faults: the consent update never reaches Google, the CMP blocked Google Tag Manager itself, or the default state arrives after your tags have already fired. Tag Assistant's Consent tab separates them in about ten minutes. An empty Consent tab means consent mode was never implemented on the page. A denied default that never flips to granted means the update is missing. And "Could not connect, your Google tag may be blocked from loading" means the container never ran at all.

This turns into a panic because four different failures produce the same headline in the same weekly report. The shape of the drop tells you which one you have, and the shapes are quite different once you know to look.

Cause 1: people declined, and that part of the drop is meant to happen

If your banner works, your GA4 numbers went down because they were previously counting people who would have said no.

There's no fix for this and you shouldn't want one. Restate the baseline instead: every year-on-year comparison from now on sets a consented population against a total one. Say so in writing before somebody asks why revenue per session moved.

There's a UK wrinkle worth knowing. The ICO finalised its guidance on storage and access technologies in April 2026, and it carries a statistical purposes exception introduced by the Data (Use and Access) Act: no consent is needed where "the sole purpose of the storage or access is to enable the person … to collect information for statistical purposes about how the service is used with a view to making improvements to the service". Traffic analysis, scroll depth, device types, referrers and page speed are all marked as likely to qualify.

Read the conditions before acting on it. The ICO says the exception "does not apply to purposes related to online advertising", requires consent for "connecting a visitor ID to their site activity (eg where users purchased a product on your website ('conversions') to be shared with advertising partners)", and says it stops applying if you "retain the individual-level information (after aggregating it)". A GA4 property linked to Google Ads, exporting to BigQuery and building remarketing audiences is on the wrong side of all three. It also still requires you to give users "a simple means of objecting, free of charge" — so it removes the consent requirement, not the banner.

This isn't legal advice and the enforcement position is new. The practical read: the exception is real, narrower than the coverage suggests, and a normal advertising-linked GA4 install doesn't fit inside it.

Cause 2: the consent update never fires, so everyone stays denied

Here the default is set correctly, the visitor clicks Accept, and nothing tells Google about it.

This happens when the CMP renders a banner but was never wired to Google's consent API — a template with the Google Consent Mode integration switched off, a hand-rolled banner that writes a preference to localStorage and stops there, or a GTM setup where the CMP tag fires but the consent update tag was never built. The banner does its visible job perfectly. The signal just doesn't arrive.

The shape gives it away: the drop is close to total rather than proportional, and it's flat across every day of the week. Genuine consent loss varies with traffic mix. A missing update doesn't vary at all.

Google's own troubleshooting route confirms it: open the Consent tab in Tag Assistant, check the On-page Default column, then click Accept and check On-page Update. Default denied and Update unchanged is the fault.

Cause 3: the CMP blocks Google Tag Manager itself

Automatic cookie blocking works by rewriting script tags in the page — and the GTM container is a script tag. If it isn't excluded, the blocker rewrites it too, and nothing runs: no GA4, no Ads, no cookieless pings, not even the consent signal that would have told Google a person was there.

Cookiebot's own documentation is explicit about the fix. Mark both the Consent Mode snippet and the Google Tag Manager snippet with data-cookieconsent="ignore", which "will ensure that these scripts can't unintentionally get blocked by the auto blocking feature", and load them in a fixed order: Consent Mode first, then Google Tag Manager, then the Cookiebot script. Get that order wrong and you can produce the fault while every setting looks correct.

<script data-cookieconsent="ignore">
  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",
    security_storage: "granted",
    wait_for_update: 500
  });
</script>

The symptom is unmistakable once you've seen it: traffic doesn't fall 40%, it falls to near zero, including internal traffic from your own office. Tag Assistant reports "Could not connect, your Google tag may be blocked from loading", then connects normally after you accept the banner.

This is the exact inverse of the more common problem, where the CMP is installed and the tags fire anyway. Auto-blocking only knows about script tags it can see at scan time, so it misses the ones GTM injects later and catches the one that would have injected them.

Cause 4: the default arrives after the tags, so the first hit is unconsented and the rest are missing

Ordering is a hard requirement, not a best practice. Google's instruction is to "call the gtag('consent', 'default', ...) command on every page of your site before any commands that send measurement data (such as config or event)", and it states plainly that "if your consent code is called out of order, consent defaults won't work."

In GTM the mechanism is the Consent Initialization trigger, which "will always fire before all other tags, including any Initialization triggers". It's for consent tags only — Google's documentation says anything else needing to run early belongs on a normal Initialization trigger. Putting your GA4 configuration on Consent Initialization to make it "run first" is a common and expensive misreading.

When the order breaks, data doesn't vanish, it gets strange. The first hit escapes before the denied default lands, so you get a page view; everything after it is blocked. Reports fill with single-hit sessions and engagement rate collapses. wait_for_update: 500 exists for this window — it gives the consent tool a fixed number of milliseconds to call update before tags fire.

The arithmetic, honestly

Say half your visitors decline. What you lose depends on which consent mode you run and whether you clear Google's modelling thresholds — and for most sites the thresholds decide it.

Under basic consent mode, Google tags don't load until the visitor interacts, and if they decline, "no data is transferred to Google at all". Those 50% produce nothing, and conversion modelling falls back to a general model.

Under advanced, tags load on page open, and while consent is denied "consent state and measurements without cookies are sent". That earns an advertiser-specific model instead of a generic one — but only if the property qualifies: at least 1,000 events per day with analytics_storage='denied' for seven days, and at least 1,000 daily consented users for seven of the previous 28. What Advanced actually buys you covers why most sites never reach that.

Two things get left out of every version of this explanation.

Modelled data appears under one reporting identity only. GA4's blended identity "uses the user ID if it is collected. If User-ID information is not available, then Analytics uses the device ID. If no identifier is available, Analytics uses modeling." Device-based "uses only the device ID and ignores all other IDs that are collected." If someone set your property to device-based — often done years ago to reconcile with something else — you'll never see a modelled user however comfortably you clear the thresholds.

Modelling doesn't reach most of what you use. Google excludes modelled data from audiences, user explorer, cohort and user lifetime explorations, segments with a sequence, retention reports, predictive metrics, and data export including BigQuery. Standard reports partially recover; your warehouse, your remarketing lists and your retention curves stay at consented-only levels indefinitely. If your reporting runs through BigQuery, modelling does nothing for you at all.

The honest expectation: headline numbers land between consented-only and modelled, everything downstream sits at consented-only, and under the thresholds those are the same figure.

The ten-minute diagnostic

Run these in order and stop at the first thing that's wrong.

1. Open your site in a fresh private window with Tag Assistant connected. If it can't connect, that's cause 3 — the container is blocked. Accept the banner; connecting afterwards confirms it.
2. Select the earliest Consent event and open the Consent tab. Google's troubleshooting guide notes this tab "is empty when consent mode is not implemented on the page". Empty means no default ran: cause 4.
3. Check the On-page Default column. All four of ad_storage, ad_user_data, ad_personalization and analytics_storage should read denied before anything else fires.
4. Accept the banner and check On-page Update. No change is cause 2 — the CMP isn't wired to the consent API, whatever its dashboard says.
5. Type dataLayer in the console and read it top to bottom. The sequence you want: consent default, then gtm.js, then your GA4 configuration, then a consent update after your click. Any other ordering is the bug.
6. Only now compare rates. If all five steps pass, it's cause 1, and the number you want is your accept rate.

Do step 5 by hand once even if you'll automate it later — it shows you the sequence every tool is checking.

What to do with the answer

For causes 2, 3 and 4, fix the wiring and expect the numbers to land lower than before the banner but higher than they are now. That gap is the part that was genuinely broken.

For cause 1 the work isn't technical. Set the new baseline in whatever people compare against, annotate the launch date in GA4 so nobody spends a quarter hunting a phantom, and judge your accept rate against your consent interface rather than last year's traffic.

Then check the thing that isn't in the four causes at all: whether ad_user_data and ad_personalization are being sent. A site can pass every step above and still be advertising blind. That's the work we do, and it's cheaper to check than to discover.

Sources

1. 1.Google — Set up consent mode on websites (default and update commands, ordering) · Checked 2026-07-27
2. 2.Google — Consent mode overview (basic vs advanced implementation) · Checked 2026-07-27
3. 3.Google — Troubleshoot consent mode with Tag Assistant · Checked 2026-07-27
4. 4.Tag Manager Help — Tag Manager consent mode support (Consent Initialization trigger) · Checked 2026-07-27
5. 5.Analytics Help — [GA4] Behavioural modelling for consent mode (thresholds and exclusions) · Checked 2026-07-27
6. 6.Analytics Help — [GA4] Reporting identity (blended, observed, device-based) · Checked 2026-07-27
7. 7.Cookiebot Support — Google Tag Manager and Automatic cookie blocking · Checked 2026-07-27
8. 8.ICO — Guidance on the use of storage and access technologies: what are the exceptions (final guidance, April 2026) · Checked 2026-07-27
9. 9.Perfmetrix — UK private clinic consent benchmark (our own scan data) · 2026-07-08