Event naming conventions
An event naming convention is the agreed rule for what events are called: the case, the separators, and the vocabulary. It sounds trivial but it is the difference between clean analytics and a fragmented mess where signup, sign_up, and SignUp count as three things. This page covers the conventions that work, reserved names to avoid, and why a documented taxonomy matters more than any single rule.
What this means
A naming convention fixes the form of event names so the same action always produces the same name. GA4 events are case-sensitive and use snake_case by convention (page_view, add_to_cart). The exact rule matters less than picking one — lowercase, a single separator, verb_noun order — and writing it down so everyone follows it.
Reserved names and a taxonomy
Some names are reserved or automatically collected (page_view, session_start, first_visit) — reusing them for something else causes collisions. Beyond that, maintain a documented taxonomy: the allowed event names, what each means, and their parameters. A taxonomy a team can look up is what stops the slow drift into a dozen near-duplicate names that fragment every report.
- Pick one case and separator; snake_case is the GA4 norm
- Avoid reserved/auto-collected names for custom events
- Document the allowed names and their meaning
How it appears in analytics and logs
Several event names for one action (signup, sign_up, SignUp) means the convention is not enforced. Reusing a reserved or auto-collected name can collide with platform behaviour.
Diagnostic use case
Adopt one documented event-naming taxonomy so the same action always produces the same event name, keeping reports consistent across people and time.
What WebmasterID can help detect
WebmasterID encourages a small, documented set of semantic event names with no PII, so the taxonomy stays stable and reports do not fragment over time.
Common mistakes
- Letting each developer invent their own names.
- Reusing reserved or auto-collected event names.
- Mixing cases and separators across the same site.
Privacy and accuracy notes
Event names are stored and visible in tooling — never encode personal data in a name (no user_123_signup). A name should describe the action type, nothing about the person. This is educational, not legal advice.
Related pages
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- The session_start event
The session_start event marks the beginning of a visit. In GA4 it is fired automatically the first time a user is active in a new session, and it underpins every session-scoped metric. Understanding when a session begins — and the timeout that ends it — explains why session counts behave the way they do across midnight, campaigns, and idle periods.
- Events reference (docs)
A documented event taxonomy to model yours on.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.