Can I count accepting, rejecting and undecided visitors from BigQuery?

Partly. The `privacy_info.analytics_storage` field separates three states, but rejecting rows carry no identity, so they can only be counted at the event level; user and session counts are not possible there. Rows with an empty value can carry identity, because a hit sent before the consent signal is passed brings its cookie with it. If you compare anything, the denominator should be `page_view`, not raw events. An empty value does not mean the visitor expressed no preference either; the reason cannot be read from the export.

Can't I just read the consent rate from the CMP's own panel?

Partly. Because the banner runs before consent, most CMPs show accept and reject counts in their own panel without any extra setup. But the panel usually gives only the split among visitors who decided: the share who saw the banner and never touched it, and the new versus returning split, are missing in most products. The data also stays in the panel, so it cannot be compared with the GA4 side in the same place. It is enough for tracking, not for breakdowns or cross-checks.

How do I measure visitors who change their consent decision later?

Not from the BigQuery export. When a visitor rejects and then accepts on the same page, earlier requests are reprocessed and recorded as if accepted, so the change erases its own evidence. When the change happens across pages, rejected rows have no identity and cannot be linked to later accepted rows. The measurement is done by writing banner decisions as records to a separate table, or as events to a cookieless tool.

Why should the tag that forwards banner decisions not carry a consent condition?

Because with the condition, reject decisions are never forwarded and exactly the group you want to count drops out of the dataset. Only accepting visitors remain and the accept rate shows 100%. Measuring the decision does not collect personal data, it only counts the decision itself; tying that measurement to consent produces blindness, not protection.

Does the cookieless tool that receives decision events need consent itself?

It depends. Counting the decision is not processing personal data, but the tool's tracker script may read and send fields such as `screen` and `navigator.language`. What matters is sending, not reading: according to the European Data Protection Board (EDPB) guidelines, information falls in scope the moment it leaves the device over the network. In the Umami `v3.3.1` tracker, `umami.track('ad')` merges the default payload, so those fields still go out, while the object form `umami.track({ ... })` replaces the payload. The cleanest stance is to send the decision event straight to the `/api/send` endpoint without loading the script at all. Session replay is a separate matter: that recording also covers form interactions and needs masking and consent.

Why don't the reject rate in the cookieless tool and the cookieless share in GA4 match exactly?

They are close but they do not measure the same thing. The GA4 side gives a page view share, the cookieless tool a decision share. If rejecting visitors browse fewer or more pages than accepting ones, the two rates naturally diverge. The GA4 reject cohort also includes automated traffic that never touches the banner, while the decision layer counts only real clicks. A difference with a stable direction is a finding, not an error. Look at the measurement only when the gap grows over time.

Can't I join the two datasets on a basic key such as `transaction_id`, `user_id`, `session_id` or `client_id`?

No, a consent decision has no such key. Rejecting rows in GA4 have no identity at all, and the cookieless tool uses its own session identifier, which does not match GA4's. The comparison stays at the daily total level. Order-level joining is a different problem, and there the shared key is `transaction_id`.

I use basic consent mode and my cookieless share is zero. Is that a good sign?

No, it means the measurement is switched off. In basic consent mode the tag is fully blocked until consent is given, so no row at all reaches BigQuery from a rejecting visitor. A zero rate does not mean 'nobody rejects', it means 'I cannot see the ones who reject'. In this setup the consent rate can only be read from the cookieless decision layer.

Measuring Consent Rate: Where Accepts, Rejects and Later Changes Get Counted

Consent rate cannot be fully measured from the GA4 export, because an accepting row carries its identity, a rejecting row does not, and the evidence of a changed decision is erased during reprocessing. This post covers how far the export goes, how the decision is counted in a cookieless layer, and how the two sides are compared in BigQuery at the daily total level.

2026-08-29 Updated: 2026-10-14

TL;DR

Consent rate cannot be measured from a single system. In the GA4 export an accepting row carries its identity, a rejecting row does not, and the evidence of a later change is erased during reprocessing. The decision itself is counted in a cookieless layer that consent cannot switch off, while the GA4 side only gives an upper bound. The two sides are compared in BigQuery at the daily total level, not row by row.

Get Access Sign In

Subscribers Only

The full article plus 25 more subscriber-only posts come with a subscription.

analytics

Subscribers Only

RELATED

Linking a Banner Click to a Purchase: Promotion Events, the Carrier Layer and the Consent Boundary

Session Integrity from Landing to Purchase: Counting the Break in BigQuery

Setting Up Clarity with GTM in a Consent Compliant Way

Setting Up Umami with GTM in a Consent Compliant Way: The Transmission Threshold, the Decision Layer and the Replay Call

GA4 Landing Page (not set): A Diagnostic Playbook

Joining Google Ads and GA4 at Row Level: A Shared Key and a Two-Layer Reading

Tracing the Source of GA4 and Ads Signals in Shopify

The Analytics Quota Budget: Event Design Sets the Ceiling, Not Traffic

Connecting a Shopify Order to an Ad Click: Choosing a Join Key for Offline Conversions

GA4 Source/Medium Debugging: Detecting the Real Source with First-Party Cookies