Avoid Premature Aggregation of GA4 BigQuery Event Data

Premature aggregation of GA4 event data is common in BigQuery pipelines, even in experienced teams. It usually starts with good intentions, such as simplifying the data structure or speeding up queries, but it always removes context. It is not a minor optimisation choice; it limits every analysis that follows.

Typical examples are collapsing all page_view events into a session count, summing purchase events into a daily total, or flattening event_params into a fixed set of columns and discarding the original array. Each step loses sequence, cardinality and interaction detail, the information that defines user behaviour. Questions about user journeys, attribution paths and the causal impact of specific interventions then become hard or impossible to answer.

The value of the GA4 BigQuery export, and of comparable privacy-first collection tools, lies in its event-level detail. That detail supports more than counting: it describes journeys, sequences and interventions as they actually happened. Averages and totals hide the mechanics of user interaction, and with them most of the material for causal analysis.

The core events table in BigQuery should therefore keep full raw granularity for as long as is feasible, as an immutable source of truth. Transformations for specific analytical needs and for performance belong in dbt, typically as incremental models. The distinction is grain, not structure: a flattened staging table that keeps one row per event preserves the detail, whereas a table with one row per session or per day does not. Analytical models should be built from the raw events, not on top of aggregates that replace them, so that any derived table can be rebuilt when the question changes.

The principle looks minor, but it determines what the team can do. Reconstructing user paths, modelling complex attribution and running granular causal impact analysis all depend on it. It is the difference between estimating and knowing.