BigQuery intraday table schema
GA4's events_intraday_ streaming table is not always schema-identical to the finalized events_ daily table. Some fields populated after processing — certain attribution, session, or derived columns — may be empty or absent intraday. Queries written against the daily schema can fail or return nulls against intraday. This page explains intraday schema differences so real-time queries do not silently lose fields.
Why the shapes differ
The daily events_ table is produced after GA4 finishes processing, which is when some derived values — certain traffic-source attribution, session-derived fields, and post-processing flags — are filled in. The intraday table reflects events closer to arrival, so those derived columns can be null or, depending on the export, not present at all.
A query that references such a column against intraday returns nulls or errors, even though the equivalent daily query works.
- Derived/attribution fields may be unpopulated intraday
- Some columns appear only after daily finalization
- Daily-schema queries can null out or error on intraday
Writing tolerant queries
When querying intraday, select defensively: use SAFE references, coalesce missing derived fields, and do not depend on post-processed attribution for real-time views. Reserve precise attribution and session analysis for the daily table once it lands. Document which columns your dashboards trust intraday versus daily so a null is read as 'not yet derived', not 'broken'.
This differs from the intraday-vs-daily completeness issue: here the rows exist but a column's value does not yet.
How it appears in analytics and logs
A column that is full in events_ but null or missing in events_intraday_ reflects fields populated only after daily processing, not lost data.
Diagnostic use case
Write real-time GA4 export queries that tolerate the intraday table's schema instead of assuming it matches the finalized daily table.
What WebmasterID can help detect
WebmasterID's stable first-party event shape gives you a fixed reference when an intraday column is not yet populated.
Common mistakes
- Assuming intraday and daily tables are schema-identical.
- Relying on post-processed attribution columns in real time.
- Reading an intraday null as data loss.
Privacy and accuracy notes
Intraday rows may carry pseudonymous fields; handle them under your retention rules. This page is educational, not legal advice.
Related pages
- BigQuery streaming vs daily tables
The GA4 BigQuery export produces two table types: events_intraday_YYYYMMDD streaming tables that fill through the day, and events_YYYYMMDD daily tables finalized afterward. A row can appear in intraday and then again in the consolidated daily table. Querying both, or assuming intraday is complete, distorts counts. This page distinguishes streaming and daily export tables and how to query them safely.
- Event parameter unnesting in BigQuery
In the GA4 BigQuery export, event_params is an array of key/value records where the value lives in one of string_value, int_value, float_value, or double_value. Reading a parameter requires UNNEST plus a key filter, and doing it carelessly multiplies rows so event counts inflate. This page explains how to unnest event parameters correctly and why the wrong join over-counts.
- 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.
- Events documentation
Keep a stable, documented first-party event shape.
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.