BigQuery export schema changes
The GA4 BigQuery export has a documented but evolving schema. Google adds fields, changes nested structures, and the intraday and daily tables do not always carry identical columns. A query written against an old shape can break or silently miss new data. This page explains how the export schema changes, where the risks are, and how to write queries that survive evolution.
How the export schema evolves
The GA4 BigQuery export ships a documented schema of nested and repeated fields — event_params, user_properties, items, and more. Google periodically adds fields and occasionally adjusts nested structures as the product evolves. New columns appear without notice in your tables, and existing queries that select explicit columns will not pick them up.
Queries that unnest by a hard-coded key, or assume a field exists, are the most fragile when the shape shifts.
- Nested/repeated fields like event_params and items
- New fields appear as the product evolves
- Hard-coded unnest keys are fragile to change
Querying defensively
Reference the official export schema, not memory, when writing queries, and re-check it when results look wrong. Use safe accessors for nested values, avoid SELECT * in production pipelines, and pin the columns you depend on. Watch for the intraday-vs-daily table differences so a field present in one is not assumed in the other.
Monitor for new fields and schema changes deliberately rather than discovering them through a broken report.
How it appears in analytics and logs
A query that suddenly returns nulls, errors, or fewer columns after a date often means the export schema changed and your query targets the old shape.
Diagnostic use case
Write BigQuery queries against the GA4 export that survive schema additions, and detect when a new field or nested change affects your results.
What WebmasterID can help detect
WebmasterID's stable first-party event schema gives you a versioned reference that does not shift under you the way a third-party export can.
Common mistakes
- Assuming the export schema is fixed and never adds fields.
- Hard-coding unnest keys that change with the schema.
- Querying intraday tables as if identical to daily tables.
Privacy and accuracy notes
The export can contain user-level and pseudonymous data; treat schema changes as a chance to review what fields you ingest. This page is educational, not legal advice.
Related pages
- Schema drift in event data
Schema drift is the gradual, uncoordinated change of event names, parameter keys, value types, or enumerations in an analytics stream. A renamed event, a parameter that switches from string to number, or a new value an enum did not expect can break joins, drop rows from filters, or quietly corrupt aggregates. This page explains how drift arises in event pipelines and how to guard against it.
- Intraday vs daily export tables
The GA4 BigQuery export writes provisional intraday tables during the day and a finalised daily table afterwards. Intraday data is incomplete and can be reprocessed, and once the daily table lands the intraday one is removed. Querying both, or trusting intraday as final, causes double counts and shifting numbers. This page explains the two table types and how to query them correctly.
- BigQuery vs UI discrepancies
When GA4's BigQuery export and the reporting interface show different totals, it is usually not a bug. The UI applies sampling, data thresholds, (other) aggregation, and behavioral/conversion modeling on top of the raw event stream; BigQuery exports the unmodeled, unsampled events. Knowing which transformations the UI adds explains most gaps.
- MCP analytics
Query first-party events on a stable, versioned schema.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.