Event naming convention examples

An event naming convention gives teams a consistent way to name the behaviours a product captures.

It helps product, engineering, and analytics teams understand what an event means without decoding each name from scratch.

A good convention should make events easier to read, implement, search, and maintain. It should also keep event names connected to workflows and meaningful behaviour.

Bad / better event names

When to use it

Use an event naming convention when a product captures more than a handful of events, or when several teams contribute to tracking.

It is useful when teams need to:

• reduce inconsistent event names
• make events easier to understand
• connect events to workflows and steps
• avoid duplicate or overlapping events
• make tracking plans easier to review
• keep dashboards and metrics easier to explain

The convention does not need to be complex. It needs to be predictable.

A simple naming pattern

A useful starting pattern is:

workflow.step.action

For example:

registration.form.viewed
registration.form.submitted
registration.email.verified
registration.completed

This pattern shows where the event belongs, which part of the workflow it relates to, and what happened.

Some teams may prefer a slightly shorter pattern:

workflow.object_action

For example:

registration.form_viewed
registration.form_submitted
registration.email_verified
registration.completed

Either pattern can work. The important thing is to choose one, document it, and use it consistently.

Example: account registration

For a simple registration workflow:

View registration form
↓
Enter details
↓
Submit form
↓
Verify email
↓
Access product

The event names might be:

registration.form_viewed
registration.form_submitted
registration.form_error_shown
registration.email_verified
registration.completed

These names are useful because they are specific enough to understand, but not tied too closely to individual interface components.

For example, registration.form_submitted is clearer than button_clicked, because it describes the behaviour the team cares about. It is also clearer than registration_activity, because it says what actually happened.

Name events after behaviour

Event names should describe meaningful behaviour, not just interface activity.

Prefer names like:

registration.form_submitted
checkout.payment_confirmed
application.document_uploaded
subscription.plan_selected
retrofit_plan.created

Avoid names like:

button_clicked
modal_opened
page_2_next
blue_cta_tapped
component_interacted

Low-level interactions can be useful when they explain a specific problem, but they should not become the default naming pattern.

The event name should help someone understand what happened without needing to inspect the interface.

Keep names stable when the interface changes

Event names should not change every time the interface changes.

A workflow step may stay the same even if the screen, button, or component changes.

For example, the behaviour might remain:

registration.form_submitted

even if the submit button label changes from “Create account” to “Continue”, or the registration form moves into a modal.

This stability makes metrics easier to compare over time. If event names follow interface labels too closely, normal product changes can create unnecessary breaks in the measurement system.

Use outcomes and errors clearly

Events should make outcomes clear.

For example:

registration.form_submitted
registration.form_error_shown
registration.email_verified
registration.completed

Avoid vague names such as:

registration.success
registration.fail
registration.error

These names may not explain what succeeded, what failed, or where the error happened.

Error events should be specific enough to support diagnosis. The event name can describe the type of moment, while properties can capture the detail:

Event:
registration.form_error_shown

Useful properties:
error_type
field_name
entry_point
device_type
workflow_version

The event name says that an error was shown. The properties explain which error and where it happened.

Be consistent with tense and wording

Choose a consistent style for actions and outcomes.

For example, use past-tense event names when the event records something that has happened:

form_viewed
form_submitted
email_verified
payment_confirmed
document_uploaded

Avoid mixing styles:

form_view
submit_form
emailSuccess
paymentConfirm
doc_upload_done

Mixed styles make events harder to search, compare, and maintain.

The exact grammar matters less than consistency. A team should be able to predict the event name from the workflow step.

Use properties instead of overloading names

Do not put every detail into the event name.

For example, avoid creating separate events such as:

registration.mobile.form_submitted
registration.desktop.form_submitted
registration.invited_user.form_submitted
registration.self_serve.form_submitted

Use one event name and capture the context as properties:

Event:
registration.form_submitted

Properties:
device_type
entry_point
user_type
workflow_version

This keeps the event model cleaner and makes metrics easier to define. The event name records what happened. Properties explain the context.

Common mistakes

Common event naming mistakes include:

• naming events after buttons or components
• mixing naming patterns across teams
• using vague names such as success, fail, or activity
• creating separate event names for every segment or device
• changing event names when interface labels change
• using abbreviations that only one team understands
• naming events before defining the behaviour they capture

These mistakes make events harder to use and metrics harder to trust.

How to apply this

When naming an event, ask:

• which workflow does this event belong to?
• which step or behaviour does it capture?
• what happened?
• is the name understandable without seeing the interface?
• will the name still make sense if the UI changes?
• should any detail be captured as a property instead?
• does the name follow the agreed convention?

Start with a small convention and apply it consistently. The goal is not a perfect naming system. The goal is a naming system that helps teams understand and maintain the evidence their product captures.

Related articles

• What makes a good event?
• Event catalogue template
• Instrumentation specification template

Key takeaway

A good event naming convention makes events predictable, readable, and connected to behaviour.

Name events after meaningful workflow behaviour. Use consistent grammar. Keep names stable. Capture context with properties instead of overloading the event name.