Auditing Custom Events in GA4: Schema, Naming, and Cardinality

Evaluating Naming Conventions

GA4 recommends snake_case for event names, and the platform itself uses this convention for all automatically collected events (page_view, session_start, first_visit).

Custom events that deviate from this convention, using camelCase, hyphenated names, or inconsistent capitalisation, create a schema that is harder to query in BigQuery and harder for new team members to understand.

An audit of custom event naming should check for: consistency of case across all custom event names, use of verbs for action events (button_click, form_submit, video_play rather than nouns like button, form, video), appropriate specificity (click is too generic; cta_button_click is specific enough to be useful), and avoidance of reserved event names that conflict with GA4's automatically collected events.

Checking the full list of event names in the BigQuery events table or via the GA4 Data API gives you the ground truth of what is actually being sent, which often differs from what the tag specification document says should be sent.

Cardinality Problems in Event Parameters

High cardinality, when a parameter takes thousands of distinct values, is one of the most common and most damaging custom event problems.

GA4 aggregates low frequency values in reports into an "other" bucket when cardinality is too high, making the parameter useless for analysis.

The cardinality limit depends on the report type, but in practice, parameters with more than 500 to 1,000 distinct values in a day start to experience aggregation problems in the standard reporting interface.

Common high cardinality mistakes include using order IDs, user IDs, product SKUs, or session timestamps as event parameters without first registering them as custom dimensions (where the cardinality handling is different).

If you need to capture these values, BigQuery is the appropriate destination rather than GA4 reports.

Auditing cardinality means querying the BigQuery export to count distinct values per parameter per day and flagging any parameter that consistently exceeds safe thresholds.

Coverage Gaps: What Is Not Being Tracked

Auditing what is being tracked is only half the job, the other half is identifying what is missing.

A coverage audit compares the existing custom event schema against the measurement plan (if one exists) and against the actual user journeys on the site.

For each key user action, downloading a resource, clicking a pricing plan, submitting a contact form, viewing a product demo video, check whether a custom event exists and whether it is firing reliably.

The fastest way to identify gaps is to manually walk through the key user flows on the site while monitoring GA4 DebugView and checking that every meaningful interaction generates an appropriate event.

Gaps discovered this way should be added to the measurement plan with an implementation priority based on the business value of tracking that specific interaction.

Building this coverage map is the foundation for meaningful funnel analysis and intent based segmentation.