Profile GA4 event_params Before Building Causal Models

The detail in the GA4 BigQuery export invites analysts to move straight to complex joins, model building or causal experiment design. Before that effort is spent, one common cause of project failure deserves attention: the unvalidated event parameter.

GA4's flexible data model is powerful, but it is also a weakness when nobody watches it. Parameters, especially custom ones, often vary in type or presence across events, and even across instances of the same event. An item_id parameter may arrive as a string on one path and as an integer on another, or be missing entirely, depending on the user journey or the frontend component that sent the event. These small discrepancies cause failed joins, skewed aggregates and broken causal assumptions in unexpected places.

In one project measuring the causal impact of a new product recommendation algorithm with a CausalImpact model, considerable effort went into model development, cohort definition and data preparation in BigQuery. The analysis showed a negligible effect, contrary to the hypothesis. The cause turned out to be a subtle difference in how product_id was logged on the desktop and mobile sites. Statistical rigour starts well before the modelling does.

The remedy is systematic profiling before any dbt model or analysis script is written. Unnesting event_params and grouping by key shows which parameters are actually sent. Adding COUNTIF(value.string_value IS NOT NULL), COUNTIF(value.int_value IS NOT NULL) and COUNTIF(value.double_value IS NOT NULL) per key reveals any parameter that arrives in more than one typed field. A second pass grouped by key and a string rendering of the value, such as COALESCE(value.string_value, CAST(value.int_value AS STRING), CAST(value.float_value AS STRING), CAST(value.double_value AS STRING)), exposes unexpected values. Splitting both queries by platform or device.category would have caught the desktop–mobile discrepancy above.

Once the profile is understood, dbt tests should assert the same schema and integrity rules automatically on raw and staging tables, so that drift is caught when it happens rather than at the end of an analysis. Collection tools that enforce predefined schemas prevent many of these issues from arising at all.

Skipping parameter validation is building on an unstable foundation: the result may look sound until it faces analytical scrutiny. Time spent on validation is what makes causal inference credible to stakeholders.