Cookie Consent Blocking Google Analytics? Fix It

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering solutions for agency and in-house clients.

Your GA4 sessions fell off a cliff the week legal made you switch on a cookie banner. The board wants to know why the traffic “disappeared”, and the honest answer is that it didn’t: your consent banner stopped Google Analytics from counting most of it. Below is what broke, how to measure the real damage, and how to get the numbers back without breaking the compliance that forced the banner on you.

Why does a cookie consent banner block Google Analytics?

A cookie consent banner blocks Google Analytics because GA4 sets first-party cookies to identify visitors and count sessions, and a compliant banner holds those cookies back until the visitor clicks accept. Every visitor who ignores the banner, rejects it, or leaves before answering is never counted. Many people never click accept, so the banner can erase a large slice of your reported traffic the day it goes live.

Here’s the mechanism. GA4 tracking runs on a first-party cookie set on your own domain (the _ga cookie). A properly configured Consent Management Platform (CMP), the tool that shows the banner, blocks that cookie and the GA4 tag until the visitor opts in. No opt-in means no cookie, no tag, no hit sent to Google, and no session in your reports. The visit still happened; your analytics just never saw it.

Two things make the drop look worse than a slow leak. It appears suddenly, on the exact day the banner launched, which is why it reads like a tracking outage rather than a consent side effect. And it lands hardest on EU and UK visitors, where consent is legally required, so a business with heavy European traffic can lose a third of its reported sessions while a mostly US audience barely moves.

How much data did the cookie banner actually cost you?

Quantify the loss before you touch the fix, because the number is what you take back to the board. The gap between “traffic collapsed” and “we lost visibility on the visitors who declined consent” is the whole conversation, and GA4 has the evidence to prove which one you’re looking at.

Run these three checks:

1. Line up the drop with the launch date. In GA4, chart daily sessions across the banner go-live date. A consent problem shows a clean step down on that exact day, not a gradual decline. A gradual slide points at something else, like a broken tag or a redirect.
2. Segment by region. Add a country or region breakdown. If the fall is concentrated in EU and UK traffic and North America holds steady, consent is the cause, because that’s where the banner is doing its job.
3. Confirm the consent state on the tag. Open GA4 DebugView or Google Tag Assistant and load your own site. Decline the banner and watch whether the GA4 tag fires at all. If it stays silent when consent is denied, you have no Consent Mode in place and every decline is a lost visit.

If the sessions that vanished map to the visitors who declined, your data isn’t wrong. It’s incomplete in a way you can now recover. For a wider sweep of symptoms like this, our GA4 audit checklist walks through the same kind of before-and-after diagnosis across the whole property.

What is Google Consent Mode v2, and how does it recover the data?

Google Consent Mode v2 is a signalling layer that tells Google how each visitor answered your cookie banner, so Google can adjust tag behaviour instead of going dark. It controls four consent parameters: analytics_storage, ad_storage, ad_user_data and ad_personalization. The last two arrived in the v2 update that Google required from March 2024 for advertisers running remarketing or audiences in the European Economic Area.

Consent Mode runs in one of two ways, and the choice decides how much you get back. Google documents both in its Consent Mode developer guide:

• Basic Consent Mode blocks Google tags entirely until a visitor consents. Nothing is sent for a decline, so there’s nothing to model. It’s the simpler set-up, and it leaves most of the gap open.
• Advanced Consent Mode loads the tags in a restricted state and sends anonymous, cookieless pings even when consent is denied. Those pings carry no identifiers and set no cookies, so they stay compliant, but they give Google enough signal to estimate the missing activity.

The recovery comes from behavioural modelling. When advanced mode is feeding Google cookieless signals, GA4 uses consent mode modelling to estimate the sessions, users and conversions the declined visitors would have produced, and folds those estimates back into your reports. The modelling needs a consistent volume of daily traffic and consented data to train on, so it switches on for busier properties faster than quiet ones. It never fully replaces observed data, but it closes most of the hole a raw banner leaves.

How to fix cookie consent blocking Google Analytics

Fixing the drop means wiring your consent banner and Google’s tags together so consent is respected and the lost signal is modelled back. Work through it in order:

1. Quantify the loss first. Use the three checks above so you know the size of the gap and can prove the fix worked afterwards.
2. Choose advanced Consent Mode unless a strict data policy rules out the cookieless pings. Advanced mode is what makes the modelling possible; basic mode gives you compliance but keeps the data hole.
3. Set the defaults to denied. Consent Mode must set every parameter to denied before your banner loads, then update to granted only when the visitor accepts. Defaulting to granted, or updating after the tags fire, is the single most common misconfiguration and it silently double-counts or leaks data.
4. Connect your CMP to the consent signal. Cookiebot, OneTrust, Cookie Script and the rest can all pass consent to Google, but only when the integration is switched on and mapped to the right categories. A banner that looks compliant on screen often isn’t wired to the tags underneath.
5. Verify every consent state. In DebugView or Tag Assistant, test accept, reject and ignore. Confirm the GA4 tag fires cookielessly on a decline and fully on an accept, with the correct parameters each time.
6. Give the modelling time. Once advanced mode is live, GA4 needs days of traffic before modelled conversions appear. Don’t judge the recovery on day one.

Most of this is Google Tag Manager and CMP configuration, not code. If your conversions stopped rather than your sessions, the cause can sit next to consent rather than in it, which our guide on GA4 not tracking conversions covers in detail.

Cookieless tracking and third-party cookies: what actually changed?

GA4 has always run on first-party cookies, so the consent banner problem has nothing to do with third-party cookies, and enabling third-party cookies won’t fix it. The _ga cookie lives on your own domain. When people search for “enabling 3rd party cookies” to fix a GA4 drop, they’re chasing the wrong lever, because the block is on a first-party cookie their own banner is holding back.

Third-party cookies are an advertising concern, not a GA4 measurement one, and even that story changed. Google kept third-party cookies in Chrome rather than removing them, per its Privacy Sandbox update in April 2025, so the deprecation many teams planned around didn’t land. Cross-site advertising signal still degrades from browser tracking prevention and ad blockers, but that’s a separate problem from your consent banner.

“Cookieless tracking” in the consent context means exactly what advanced Consent Mode does: sending anonymous pings with no cookie and no identifier so declined visitors can still be modelled. Server-side tagging extends the same idea by moving collection off the browser, which helps most where ad spend is heavy and consent or ad-blocker loss already shows in your reports.

Don’t fix the data by breaking the law

Recovering your numbers and staying compliant are the same job done properly, not a trade-off. The wrong instinct after a data drop is to loosen the banner, default consent to granted, or fire tags before the visitor answers. Each of those recovers sessions on paper and creates real GDPR and PECR exposure, which is a worse problem than an incomplete report.

Getting consent wrong cuts both ways: too loose and you risk a fine, too tight and you lose the data you need to run the business. Done right, the same configuration satisfies both. Dolphin Analytics compliance work helped a client avoid exposure to a potential GDPR fine of up to €20M, and the same fix helped the agency protect a six-figure client retainer, by getting consent set up so the tracking stayed both legal and accurate.

Recovering consent-blocked data is a scoped project, not a settings toggle: it means auditing your CMP, configuring Consent Mode v2, reworking the GTM tags and proving the recovery against source data. See how Dolphin Analytics approaches tracking and consent for the checks we run, or start with the free tracking audit and tell us what dropped and when. We’ll come back with what broke, what it’s costing, and what the fix involves.