Custom events are the backbone of any meaningful GA4 implementation. They capture the actions that matter to your business, form submissions, video plays, scroll depth milestones, checkout steps, anything beyond what GA4 automatically collects. But without a disciplined approach to schema design, naming, and cardinality management, custom events quickly become a liability rather than an asset. This guide covers how to audit your custom event implementation for quality, consistency, and long-term scalability.
What is a ga4event schema?
In GA4, every interaction is an event. An event has a name and up to 25 parameters. Theschemais the collective structure of all your events, which events you fire, what parameters they carry, and how those parameters are named and scoped.
A well-designed schema is predictable. A poorly designed one is a graveyard of inconsistent names, missing parameters, andhigh-cardinality dimensionsthat inflate the (other) row in your reports and make BigQuery queries expensive. Pair this audit with acustom dimensions auditso registered dimensions and emitted parameters stay in sync.
GA4 eventnaming rules(non-negotiable)
Google enforces specific hard rules for event names:
- Event names must start with a letter, never a number or underscore.
- Names can only contain letters, numbers, and underscores.
- Names are case-sensitive: button_click and Button_Click are two separate events in GA4.
- Reserved names (page_view, session_start, first_visit, etc.) cannot be used for custom events. Some of these are also problematic when accidentally marked as conversions, see theGA4 conversion tracking setupguide.
- Web streams do not have a hard limit on the number of distinctly named events, but app streams do have collection limits. Governance still matters even where the platform does not enforce a simple ceiling.
Beyond the hard rules, Google's own naming pattern, as seen in Enhanced Measurement events like scroll, file_download, and video_start, usessnake_caseexclusively. Following this convention keeps your implementation consistent with GA4's own taxonomy.
Commonnaming convention mistakes
A practical convention used by many teams is to document a clear event taxonomy before new tracking is published. Whether you prefix custom events or keep cleaner generic names, consistency matters more than inventing new variants on every release.
What iscardinalityand why does it break reports?
Cardinality refers to the number of unique values a dimension can have. High-cardinality dimensions, those with hundreds or thousands of unique values, cause GA4 to group data into an (other) row in standard reports. This happens when event parameters (or the event names themselves) contain dynamic values like user IDs, timestamps, session tokens, or product SKUs embedded directly.
For example, if you send a parameter called transaction_token with a unique value per transaction, standard reports can become hard to use very quickly. The practical goal is to keep report-facing dimensions interpretable and move highly granular identifiers into systems where that level of detail is expected, such as BigQuery.
In BigQuery, high-cardinality is less of a reporting problem but more of a cost and query performance issue, more unique values means larger tables and slower GROUP BY queries. Validate your event firing inGA4 debug modebefore pushing schema changes to production.
Auditing your custom events
Work through these validation steps first, then apply fixes to any issues found.
Validate
- Navigate to Reports > Engagement > Events and export the full event list. Check for mixed case variants, redundant suffixes, events with dynamic values embedded in the name, and reserved event names being misused.
- Go to Admin > Custom Definitions and verify every parameter you expect to appear in standard reports or Looker Studio is registered here. Missing registrations mean data is collected but invisible in reports.
- In GA4 Explorations, create a Free Form report with Event name as a dimension and add each event's parameters as secondary dimensions. Look for parameters with unusually high unique value counts, any pulling in IDs, hashes, or timestamps is a red flag.
- Check your GTM container for duplicate tags and compare live event counts in DebugView against expected counts. Both client-side gtag.js and GTM firing the same event doubles conversion signals.
- Review how user-level data is being sent. Subscription tier, logged-in status, and lifetime value should be user properties via gtag('set', {'user_properties': {'property_name': 'value'}}), not event-scoped parameters on a single event.
Fix
- Consolidate mixed-case and redundant event name variants by updating your GTM tags or gtag.js calls to use a single, snake_case name. Remember that event modifications affect future data, not historical reporting.
- For high-cardinality parameters, remove the dynamic value from the parameter and replace it with a bucketed or categorical version (e.g., replace a raw product SKU with a product_category).
- Register any unregistered parameters in Admin > Custom Definitions as either event-scoped or user-scoped custom dimensions to make them available in reports.
- Remove duplicate GTM tags causing double-counting. Set trigger conditions so only one tag fires per event, and validate in Preview mode before publishing.
- Move user-level attributes to gtag('set', {'user_properties': {'property_name': 'value'}}) so they are available on all subsequent events in the session, not just the event they were originally attached to.
Watch for
- Event names that reappear with slight variations after team members add tracking independently
- Custom dimension counts growing towards the 50 event-scoped and 25 user-scoped registration limits
- Parameters flagged in GA4 Explorations with (other) appearing unexpectedly soon after launch
Run an automated custom event audit across your GA4 property, naming issues, cardinality flags, and missing custom dimensions surfaced in minutes.
Governance: how to keep itclean over time
A naming convention document alone is not enough. The most durable approach is a centralised tracking plan, a living spreadsheet or wiki that documents every event, its parameters, their expected value types, and who approved the implementation. Share it across every team member who has publish access in GTM or deploys tracking code directly. Tie the tracking plan back to yourGA4 property configuration checksso settings, events, and dimensions are governed together.
Quick reference: GA4 custom event audit checklist
- All event names use snake_case and start with a letter
- No dynamic values (IDs, timestamps) in event names
- All custom parameters that need reporting are registered as custom dimensions
- No reserved event names are being reused
- No duplicate events from overlapping tag implementations
- User-level data is sent as user properties, not event parameters
- Report-facing custom dimensions have controlled cardinality and documented purpose
- A tracking plan document is maintained and shared across teams
Related guides
GA4 Bot Traffic: How to Detect and Filter It
Identify and remove non-human traffic that inflates your event counts and distorts conversion data.
CMP and GA4: Validating the Consent Signal Timing
Ensure your consent implementation fires in the correct order so you never collect data without a valid consent state.
Audit your GA4 custom events automatically
GA4Audits can flag schema and naming issues quickly, but custom event findings should still be reviewed against your tracking plan and reporting requirements.