GA4 BigQuery Export: Parity Checks and Data Validation

Why GA4 Reports and BigQuery Exports Differ

GA4 standard reports and the BigQuery export operate on different data pipelines, and several factors cause them to produce different numbers for the same metrics.

First, GA4 reports apply sampling when data volumes exceed thresholds in the standard interface. BigQuery exports are always unsampled, so they may actually be more accurate for large properties.

Second, GA4 reports include modeled data from Consent Mode conversion modeling, which fills in conversions for users who declined analytics cookies.

The BigQuery export contains only observed, cookied user data and does not include modeled events.

This means properties with significant non consenting audiences will see higher conversion counts in GA4 reports than in BigQuery.

Third, GA4 applies its attribution model to reports, while BigQuery exports contain raw event level data. Rebuilding attribution in BigQuery requires replicating GA4's session logic, which is non trivial.

Fourth, intraday exports are provisional and can be revised, so comparing today's BigQuery data against today's GA4 reports will always show a discrepancy until the daily export finalises.

Key Parity Checks to Run Regularly

Session count parity is the most fundamental check. Query BigQuery for distinct session counts by grouping on user_pseudo_id and ga_session_id, then compare against GA4's session metric for the same date range.

A variance beyond 5% in either direction warrants investigation. Event count parity is the next check. Total event_name counts from BigQuery should align with GA4 event reports within a small margin.

Revenue parity is the highest stakes check for e commerce properties: sum the value parameter from purchase events in BigQuery and compare against the purchase revenue metric in GA4.

Discrepancies here often trace back to currency parameter inconsistency, missing value parameters on some purchase events, or the modeled conversion gap described above.

User count parity is trickier because GA4 applies identity resolution across devices when Google Signals is enabled.

BigQuery's user_pseudo_id count will typically be higher than GA4's reported user count for the same reason.

Validating Your Export Configuration

Before running parity checks, confirm your export is correctly configured. Verify that the BigQuery project and dataset are set up in GA4 Admin under BigQuery Links. Check the export frequency.

Daily exports cover the previous full day, while streaming exports send data within minutes but cost more and have a higher chance of duplicates.

Confirm that the export includes all event parameters you need, not just the standard schema. Custom parameters must be explicitly registered as custom dimensions in GA4 before they appear in the BigQuery schema.

Finally, check for schema evolution issues: if your GA4 implementation changed the structure of an event's parameters mid stream, BigQuery may have both old and new schemas interleaved, causing query failures or silent data loss for parameters that changed type.

Running these structural checks alongside the numeric parity checks gives you confidence that your BigQuery data is both complete and correctly structured.