You enable the BigQuery export, wait for tomorrow, and then notice a second, oddly named table sitting next to your daily one: events_intraday. It confuses newcomers and quietly trips up queries. Here is what it actually is.

What events_intraday is

The events_intraday_YYYYMMDD table holds the current day's data, streamed into BigQuery continuously as events arrive, rather than waiting for the once-a-day batch. It exists only when you enable streaming export, and it gives you near real-time access to today's events instead of a full-day delay. In effect it is the live edge of your data.

How it relates to the daily table

The intraday table is temporary and provisional. Once the day closes, GA4 processes that day's data and writes the final, complete events_YYYYMMDD daily table, and the matching intraday table is then removed. So the same day exists as intraday while it is live and as a daily table once it settles, but not usefully as both at once.

Why it can mislead you

The intraday data is not identical to the finished daily data, and treating them as the same causes subtle errors:

  • It is incomplete, since it only holds events collected so far today.
  • It can be revised, as late-arriving and reprocessed events change the final daily numbers.
  • Its schema can differ slightly, so a query written for the daily table may not run unchanged against intraday.

How to use it correctly

The rule of thumb is to use intraday only when you genuinely need today, and the daily tables for everything you report or trust. If you query across both, be deliberate about it: a wildcard like events_* can sweep in the intraday table and mix provisional data with final data, which skews totals. Filter to the daily tables for stable analysis, and reach for intraday only for live monitoring.

Streaming has a cost, batch does not

The intraday table only exists if you turn on streaming export, and that choice is not free: streaming export bills separately, while the standard daily batch export is included at no extra charge. So enable intraday only when near-real-time genuinely changes a decision, and leave it off if a next-day daily table is good enough, which for most reporting it is.

Telling them apart in a query

When you write SQL, the safest habit is to name the daily tables explicitly for anything you report, using a suffix filter that excludes the intraday shard, and to query the intraday table by name only when you specifically want today. If a wildcard result suddenly shows a partial, oddly low current day, an intraday table sneaking into the scan is almost always why. Either way, never mix a finished day and a live day in the same total without saying so, because one is settled truth and the other is still moving.

That extra oddly named table is simply the live edge of your export: today's data, streamed in early, provisional, and swept away once the final daily table lands. Use events_intraday when you truly need real-time, lean on the settled daily tables for anything you report, and keep a wildcard from quietly blending the two. Understand that split and the table that confused you becomes a useful early window rather than a source of mysterious mismatches.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.