Duplicate event_params Keys and Unnest Fan-Out in GA4

The event_params array in the GA4 BigQuery export holds the custom dimensions and metrics needed for anything beyond basic event counts. Unnesting it is usually the first step, and that apparently simple step can introduce subtle, often undetected integrity problems.

The main risk is a duplicate key within a single event. GA4 normally sends each standard parameter once, but custom implementations or unusual ingestion paths can produce an event with two instances of a parameter such as product_id. Unnesting event_params and joining it back to the event row then turns an expected one-to-one relationship into one-to-many. Rows multiply, and metrics such as event counts or summed engagement_time_msec inflate.

The safer approach extracts each parameter explicitly instead of using a general LEFT JOIN UNNEST(event_params). For a parameter expected once per event, such as transaction_id, a scalar subquery works: (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'transaction_id' LIMIT 1) AS transaction_id. It always returns a single value or NULL, so the event grain is preserved. Without LIMIT 1, a duplicated key makes BigQuery fail with 'Scalar subquery produced more than one element'. Where repeated values are legitimate, ARRAY_AGG inside the subquery keeps all of them without multiplying rows.

LIMIT 1 picks one instance and hides the rest, so it should be paired with a data test that counts events in which a key appears more than once. That turns a silent workaround into a monitored exception.

This discipline matters even with cleaner sources. Collection layers such as Robin Signals often deliver data in a more structured form than the raw GA4 export, which removes some unnesting complexity, but transformations in BigQuery and dbt still have to handle edge cases.

Before unnesting event_params, it is worth stating the expected uniqueness of each parameter, confirming that duplicate keys are handled, and checking that unexpected NULL values cannot propagate. These checks are cheap compared with debugging inflated metrics later.