GA4 Event Naming Conventions: The Standard That Prevents Data Chaos

Six months into a GA4 implementation, most teams discover the same problem: they have contact_form_submit, ContactFormSubmit, contact-form-submitted, and form_submit_contact — all for the same action, sent by different team members at different times. GA4 treats each as a separate event. Your reports are fragmented. Your filters don't work. Your funnels are inaccurate.

Event naming conventions are infrastructure. Set them up correctly at the start, or spend months cleaning up the mess.

GA4's Own Naming Requirements

Before setting your own conventions, understand what GA4 enforces: - Event names are case-sensitive: purchase and Purchase are different events - Maximum 40 characters per event name - Must start with a letter (not a number or underscore) - Can only contain letters, numbers, and underscores — no hyphens, spaces, or special characters - Reserved names cannot be reused: ad_activeview, ad_click, ad_exposure, app_clear_data, app_exception, app_install, app_remove, app_store_refund, app_update, app_upgrade, click, dynamic_link_app_open, error, firebase_campaign, first_open, first_visit, in_app_purchase, notification_dismiss, notification_foreground, notification_open, notification_receive, notification_send, os_update, page_view, screen_view, scroll, session_start, user_engagement - Automatically collected events (above) fire by default — don't replicate them with custom events

The Standard: snake_case Everywhere

The universal convention in professional GA4 implementations is snake_case — lowercase words separated by underscores. This matches GA4's own recommended event names (page_view, add_to_cart, begin_checkout) and Google's official event schema.

✅ Correct: - form_submit - cta_click - video_play - account_created - plan_upgraded

❌ Wrong: - FormSubmit (PascalCase) - formSubmit (camelCase) - form-submit (hyphen — invalid in GA4) - FORM_SUBMIT (uppercase) - form submit (space — invalid)

The Event Naming Structure

Use a verb_object or object_verb structure consistently:

Pick one pattern and stick to it. Object-first is often better for analytics because it groups related events together in alphabetical lists.

Parameter Naming Standards

Every event parameter must also follow snake_case:

dataLayer.push({
  event: 'form_submit',
  form_id: 'contact-form',         // ✅ snake_case
  form_name: 'Contact Us',         // ✅ snake_case
  form_location: 'homepage_hero',  // ✅ snake_case
  formType: 'contact',             // ❌ camelCase
  'form-destination': 'sales',     // ❌ hyphen
});
javascript

Reserved parameter names (used by GA4 automatically, don't reuse): engagement_time_msec, firebase_event_origin, ga_session_id, ga_session_number, page_location, page_referrer, page_title, screen_resolution, source, medium, campaign

Building Your Event Taxonomy

Before writing a single GTM tag, document your event taxonomy in a shared spreadsheet. At minimum, include:

This document is your single source of truth. When a new developer joins, they check this before creating any new events. When a naming conflict arises, this resolves it.

Handling Legacy Data

If you inherited a GA4 implementation with inconsistent naming, you have three options:

Option 1: Create new events and run both in parallel Keep the old ContactFormSubmit event and add the new form_submit event. After 30 days of data with both, you can use form_submit for all new analysis and ignore the old one. This preserves historical continuity.

Option 2: Rename in GTM If the old event fires via GTM, just rename it in the GA4 Event tag. No data loss, immediate fix.

Option 3: Use Custom Channel Grouping For reports where you need historical + future data combined, use GA4's custom channel grouping or custom dimensions to group the inconsistent events under a unified label.

Common Naming Mistakes to Avoid

Use our Event Naming Enforcer tool to automatically scan your GA4 property for naming convention violations and generate a remediation report. Connect your GA4 to check →