Typed Extraction Stops GA4 event_params Type Drift

The event_params field in the GA4 BigQuery export is an array of key–value structs. Each value is itself a struct with four typed fields: string_value, int_value, float_value and double_value. Normally only one is populated, and which one depends on how the tag sent the parameter. This schema-on-read design makes tracking easy to iterate on, but it carries a cost in production.

That cost appears as type drift. A parameter can move to a different typed field for a subset of events: transaction_id arrives as string_value from one tag and as int_value from another, or item_list_name, expected as text, is logged as the integer 12345. A query that reads only value.string_value then returns NULL for those rows, and any SUM or COUNT built on it undercounts without raising an error. A hard CAST fails outright the first time an unexpected value appears.

Many implementations unnest and cast event_params directly in each query or model, with no error handling. When a new value type appears, dashboards drift and models that depend on the parameter, including causal inference models, either break or quietly return wrong figures. Tracing a type mismatch across millions of rows is slow, and it is entirely preventable.

A better design routes every parameter through one dbt staging model, such as stg_ga4__event_params, that acts as a hardened gateway. It flattens only explicitly listed parameters and ignores unknown keys until someone adds them to the list. For each listed parameter it reads every typed field that may hold the value, for example COALESCE(value.string_value, CAST(value.int_value AS STRING)) for an identifier, and uses SAFE_CAST so that an unexpected value becomes NULL instead of failing the run. Identifiers belong in STRING columns. Numeric parameters such as value or quantity should be cast once, to NUMERIC or INT64, rather than re-cast from string_value in every downstream model, where repeated casts add cost and hide precision loss.

A server-side collection layer such as Robin Signals adds a second line of defence: parameter types can be defined and enforced at the point of collection, before the data reaches BigQuery. The staging model remains the contract for everything already in the export.

This upfront rigour turns event_params from a liability into a dependable input. BI tools receive consistent types, statistical models receive trustworthy features, and the team spends its time on analysis rather than on reactive data repair.