Uncontrolled Event Parameter Cardinality in GA4 and BigQuery

GA4's event-and-parameter model removed the fixed custom dimension slots of earlier versions and made it possible to capture far more detail. A problem that has emerged in many implementations is uncontrolled growth in the number of distinct values a parameter takes. It looks harmless at first, but it complicates data management and analysis downstream.

The first symptoms usually appear in the GA4 interface: an (other) row in reports once a dimension exceeds the cardinality limits. The BigQuery export is not grouped this way, so interface reports and export queries disagree, which confuses analysts. In several implementations item_id, intended for product SKUs, gradually filled up with developer test IDs, arbitrary strings and error messages. That damages not only reporting accuracy but the integrity of the data itself.

The effects grow in BigQuery. Joining, grouping or filtering on a parameter with millions of distinct values is slow and expensive, and every junk value becomes another row in product-level tables and another key in downstream joins. Routine analysis becomes slow and costly. A simple monitor helps: counting distinct values per parameter key each day exposes a parameter whose cardinality suddenly jumps.

Two measures address the problem. The first is governance: acceptable parameter values, such as the SKU format for item_id, are defined before deployment. The second is the pipeline. dbt can clean and structure the data after it reaches BigQuery, for example with tests that reject values outside the expected pattern, but prevention at the source works better. Robin Signals supports this by defining, transforming and enforcing schemas for events and parameters before they reach GA4 or other destinations, which reduces cardinality problems at the point of origin.

Managing parameter cardinality is a discipline rather than a one-off fix. Small tracking decisions affect the whole stack, from GA4 reports to downstream models and machine learning pipelines. Moving from 'track everything' to deliberate, structured collection pays back in data quality, performance and analytical efficiency.