Analytics · 9 min read · 2026-07-11
GA4 Event-Level Consent State: Audit Your Conversion Gap
GA4's BigQuery export has carried conversion event data for years, but until November 2025 it could not tell you how much of that conversion data was directly observed and how much was statistically modeled. The distinction matters enormously for SaaS teams trying to understand their real funnel. Modeled conversions are estimates; they carry uncertainty that does not show up in the reported number. The new event-level consent state field in the BigQuery export schema makes that uncertainty visible for the first time — and what it reveals about most GA4 setups is uncomfortable.
This post explains what the field contains, how to query it, what the output tells you about your conversion measurement quality, and what to do when the numbers are worse than expected.
What changed in the November 2025 BigQuery export schema
Google added eight new fields to the GA4 BigQuery events table export in November 2025. The additions include session quality scoring, predicted user behavior signals, and — most important for conversion accuracy — consent state recorded at the individual event level. The data export SLA also improved: standard export now lands in BigQuery within 4-6 hours of event recording, down from the previous 12-24 hour window.
The consent state field captures, for each exported event row, the consent state under which the event was collected. GA4 classifies events into several buckets based on how the underlying signal was obtained: directly observed from a consented session, modeled from a session where consent was withheld but behavioral signals were sufficient for estimation, or unattributed when no signal is available. For conversion events specifically, this field tells you how many of your reported conversions are based on actual user behavior versus statistical estimation. That ratio is the number most GA4 reports do not surface by default.
The consent-degradation problem in SaaS funnel measurement
GA4 reports show a single conversion number. Behind that number is a blend of directly observed events and modeled estimates, and the blend changes as consent rates change. In markets with high consent refusal rates — the EU under GDPR, California under the new CCPA GPC requirements, and any market where privacy-aware browser users are a significant share of traffic — the modeled fraction can be substantial. Industry-level estimates for EU SaaS traffic suggest that 25-40% of GA4 conversion events in high-privacy markets are modeled rather than observed.
For web analytics and top-of-funnel metrics, this is tolerable. For SaaS funnel events — trial signups, activation milestones, first payment — the modeling assumptions that work for aggregate pageview estimation do not necessarily hold. A user who explicitly refused analytics consent is systematically different from the average user in ways that affect conversion probability. The model does not know that. When a significant share of your "conversions" is modeled, you do not have a funnel measurement problem; you have a data quality problem that presents as funnel measurement.
How to query the event-level consent state
The consent state field appears in the BigQuery events table for GA4 properties that have BigQuery linking enabled. Query structure for auditing your conversion events looks like this: select your conversion event name (e.g., trial_signup, purchase), group by the consent state field, and count events in each group for your target date range. The result gives you a breakdown of how many conversions were directly observed versus modeled.
Before running the query, update any existing queries that use SELECT * on the events table. The November 2025 schema addition is the kind of change that breaks downstream pipelines silently — new columns appear, tools that do not handle schema evolution gracefully fail, and the failure often manifests as missing data rather than an explicit error. This is the same class of problem covered in decoding the GA4 BigQuery export schema. Use explicit column lists. Run the consent state query on a 30-day window to get a representative sample, not a single day, because consent rates vary by traffic source and day of week.
What you are looking for is the observed-to-modeled ratio for each of your high-value conversion events. A ratio where 15% or fewer conversions are modeled is generally acceptable for directional decision-making. A ratio above 25% means a meaningful fraction of your conversion data is estimated, and decisions made on those numbers carry uncertainty that should be explicitly acknowledged. Above 40% for a specific event type, the modeled data dominates and the conversion count should be treated as an approximation rather than a measurement.
What the session quality score tells you alongside consent state
The November 2025 update also added session quality scoring to the BigQuery export. Session quality is a GA4-computed signal indicating how likely a session is to lead to a conversion, based on behavioral patterns. Combined with the consent state field, this gives you a two-dimensional view of your conversion pipeline: you can see whether low-consent sessions (which produce modeled conversions) are disproportionately high or low quality compared to consented sessions.
For most SaaS products, the expectation is that consent-refusing users skew slightly lower on session quality than the average — they tend to be more privacy-aware, use ad blockers, and arrive from privacy-focused channels rather than paid acquisition. If your data shows the opposite (consent-refusing users with high session quality scores), that is a signal that your paid acquisition is systematically over-collecting consent while your organic and referral traffic is more privacy-asserting. That pattern has implications for how you interpret multi-touch attribution data — the organic channels that look underperforming in your attribution reports may be bringing higher-quality users who are simply invisible to your measurement stack.
Closing the consent-degradation gap
The event-level consent state audit tells you the size of the gap. Closing it requires choosing which layer to fix. The three realistic options are: improve consent rates, move conversion events to server-side tracking, or supplement GA4 with a parallel first-party measurement layer.
Improving consent rates addresses the symptom — if fewer users refuse analytics consent, fewer conversions are modeled. But in high-privacy markets, this approach has a ceiling, and it does not help with GPC users who opt out at the browser level regardless of your banner design. Server- side tracking for high-value conversion events (especially payment and account activation events that happen after login) is the highest-confidence option: a server-side event fires based on your application logic, not the browser environment, so it is not subject to consent refusal or ad blocking. A supplementary first-party layer — an analytics system that runs on your own infrastructure without third-party data sharing — avoids the consent problem by design and is not subject to GPC suppression requirements because it does not share personal data. That is the architecture that produces complete conversion data regardless of consent rate.
Making the audit operationally routine
The consent state query is not a one-time exercise. Consent rates change as your traffic mix changes — a new paid acquisition campaign brings different consent behavior than organic search, and a change to your consent banner design affects rates immediately. Building a scheduled BigQuery query that tracks the consented/modeled ratio for your key conversion events on a weekly basis turns this from an audit into a monitoring signal.
When the modeled fraction increases sharply, it usually means either a change in traffic source (more EU or California traffic, a new paid channel with lower consent rates) or a regression in your consent implementation (a tag change that broke consent mode, a CMP update that changed default states). Both are actionable. Neither is visible in standard GA4 conversion reports, which surface the blended number and leave you guessing why your funnel appears to have changed when the real change was in measurement fidelity rather than user behavior. The relationship between GA4 privacy settings and measurement quality is a thread worth pulling: consent state is where that thread starts.
FAQ
What is the GA4 event-level consent state field in BigQuery?
In November 2025, Google added eight new fields to GA4's BigQuery export schema, including consent state recorded at the individual event level. Previously, consent state was inferred from aggregate data or available only in GA4's UI reports. The BigQuery field lets you query which specific events — including conversion events — were collected under each consent state, and how many were modeled rather than directly observed.
Why does event-level consent state matter for SaaS conversion measurement?
Conversion counts in GA4 are a mix of directly observed events (from consented sessions) and modeled estimates (from sessions where consent was withheld). The event-level consent state field tells you the ratio. For SaaS teams measuring trial signups, activation milestones, and paid conversions, knowing that 15-30% of reported conversions may be modeled rather than observed is essential context for how much to trust reported funnel numbers.
How do I query the event-level consent state field in BigQuery?
The consent state fields added in November 2025 appear in the events table as part of the event parameters or as top-level columns (the schema varies by export version). Query the events table for your date range, filter on event_name = 'conversion' or your specific conversion event, and group by the consent state column to see the breakdown of directly observed vs. modeled events. Use explicit column names in your SELECT statement — SELECT * queries break when the schema adds new fields.
What should a SaaS team do if a large share of conversions is modeled?
A high modeled-conversion ratio (above roughly 20-25%) is a signal that consent rates are low and conversion reporting is substantially estimated. The most effective response is moving high-value conversion events to server-side tracking, which is not subject to browser-level consent refusal and produces directly observed data. Secondary options include improving consent banner acceptance rates and auditing whether your default consent state is correctly set to denied.
Does this BigQuery schema change break existing queries?
It can. The November 2025 update added eight new columns to the events table. Any downstream query, data pipeline, or Looker Studio report that uses SELECT * will fail or produce unexpected results if the tool does not handle schema evolution gracefully. The fix is straightforward: use explicitly named column lists in all queries. This is also good practice for GA4 BigQuery exports generally, since Google adds fields without breaking-change notices.