What happens to your GA4 data when users reject cookies

It depends entirely on which Consent Mode your site runs. With no Consent Mode, or with basic, GA4 receives nothing at all from a visitor who rejects: no pageview, no session, no conversion. With advanced Consent Mode the tag still sends a cookieless ping carrying the page, the referrer and a timestamp, but no client ID, and Google models part of the rest back.

The three states your site can be in

Almost every argument about consent and analytics comes down to a question people rarely ask out loud: when someone clicks reject, does anything leave the browser at all? There are only three possible answers, and your site is in exactly one of them right now.

If you have a banner that blocks tags and no Consent Mode wiring, the GA4 tag simply never runs for that visitor. If you run basic Consent Mode, the tag is held back until consent arrives, so a reject means it never loads either. In both cases the visit produces no data whatsoever. If you run advanced Consent Mode, the tag does load, checks the consent state, and sends a stripped down ping with analytics_storage set to denied. That ping is the entire difference between a gap Google can estimate and a gap that stays empty forever.

signal still reaching GA4no data leaves the browser

This is worth confirming rather than assuming. Plenty of teams believe they run advanced because their CMP advertises Consent Mode v2 support, while the tags on the page tell a different story. We wrote a separate walkthrough on telling basic and advanced apart in a live browser.

What GA4 keeps, and what it quietly loses

Assume the good case: advanced Consent Mode, pings flowing. You still do not get your data back. You get an anonymous shadow of it, and the shape of that shadow is what breaks reports.

The cookieless ping has no client ID and no session ID. GA4 therefore cannot connect two pageviews from the same rejecting visitor, so each hit arrives looking like a brand new person. Your user counts drift, your session counts inflate, and new versus returning becomes meaningless for that slice of traffic. Anything built on identity goes with it: user journeys, User Explorer rows, cohort behaviour. Conversions still fire as events, but with no identity to attribute them to, they tend to pile up under direct or unassigned traffic, which is exactly where a paid channel's credit goes to die.

The event counts survive better than the people counts. That is the honest summary, and it explains a pattern we see constantly in client accounts: pageviews look roughly plausible while every user scoped and attribution scoped number underneath them is subtly wrong.

How to tell which state your site is in

1. Open your site in a fresh incognito window

   A normal window carries an old consent decision, which is the single most common reason this test gives a false result. Incognito guarantees you see what a first time visitor sees.

2. Open the Network tab, then click reject

   Filter requests for collect. Do this before dismissing the banner, so you capture what fires in the moments around the decision rather than after it.

3. Look for a request that fires anyway

   A /g/collect request that still goes out after you rejected means the tag is running in advanced mode. An empty panel means basic, no Consent Mode at all, or a tag that is broken in a way nobody has noticed.

4. Read the gcs parameter on that request

   This is the part that settles the argument. Open the request and find gcs in the payload. A value of G100 means both storage signals arrived denied, which is exactly what a correctly wired reject looks like. Its presence proves the consent state reached Google rather than being dropped on the way.

5. Check your volumes against Google's thresholds

   Advanced mode only converts into modelled data if your property qualifies, and most small sites do not. The numbers are in the next section, and they are worth knowing before you count on recovery you will never receive.

Modelling is not a refund

This is where the incumbent explanations stop, and where the expensive surprises live. Behavioural modelling is real and it does help, but it comes with published conditions that almost nobody checks against their own traffic.

Google's documentation is explicit: a property needs at least 1,000 events per day with analytics_storage denied for at least 7 days, and at least 1,000 daily users sending events with consent granted on 7 of the previous 28 days. Meeting both, Google notes, still does not guarantee eligibility. Below those volumes there is no modelling at all, no warning, and no banner in the interface telling you so. Your reports simply show the consented half of your traffic and present it as the whole picture.

The second limit is the one that catches sophisticated teams. Modelled data never leaves the GA4 interface. Google excludes it from the BigQuery export, from audiences, from user explorer and cohort explorations, from retention reports and from predictive metrics. So the estimate that makes your standard reports look healthier is absent from your warehouse, and absent from the audiences you build campaigns on. Your ad platform is still targeting consented users only. Your data team is still modelling on consented users only. The two numbers will never reconcile, because they were never measuring the same population.

That is the honest floor. A perfectly wired advanced setup recovers a meaningful share of what the banner costs you, and some of it stays gone regardless of what you buy.

What this actually costs

The scale is the reason any of this deserves attention. Across Amplio Data client implementations we typically find around 34% of sessions sitting behind the banner, invisible to analytics that were never wired for consent. Wiring consent the way Google expects typically recovers 20 to 40% of the conversions consent was costing. Both are measured ranges across Amplio Data client implementations, not a guarantee: recovery depends on your traffic mix, your regions and how your tags are configured. We went through where that third of your traffic goes in a separate post, and through the signals themselves in our plain English guide to Consent Mode v2.

The practical takeaway is smaller than the numbers suggest. Find out which of the three states you are in, today, in an incognito window. If nothing leaves the browser on reject, you are not losing data to privacy law. You are losing it to a configuration nobody finished. That is the gap Velo is built to close: the banner, the default denied signals and the Consent Mode v2 wiring ship as one configured layer, so the reject path is deliberate rather than accidental.

Common questions