Event naming convention examples

An event naming convention gives teams a predictable way to name the activity their instrumentation records.

The convention should help a reader understand what happened without knowing the screen, component or implementation that produced the record. It should also leave enough room for the event definition to explain the exact fire condition and limitations.

Recommended pattern

A practical pattern is:

domain.object_action

Examples:

registration.form_viewed
registration.form_submitted
registration.form_error_shown
registration.email_verified
account.first_accessed
service_request.published
quote.submitted
quote.revised
quote.withdrawn
conversation.message_sent
quote.accepted
job.completion_reported

The first part provides a stable domain or workflow context. The remaining words describe the object and action in plain language.

A team may prefer another predictable structure, such as domain.object.action. The exact separator matters less than choosing one convention, documenting it and applying it consistently.

Name the observed fact

A good event name should be accurate even when read outside the dashboard that originally used it.

Use completed actions or state changes

Event records normally describe something that happened:

form_viewed
form_submitted
email_verified
request_published
quote_revised
quote_accepted

Avoid mixing styles such as:

form_view
submit_form
emailSuccess
publishRequest
quoteRevisionDone

Past-tense wording is not a complete definition, but it makes event streams easier to read as records of activity.

Do not hide ambiguity inside “completed”

Names such as registration.completed, onboarding.completed or journey.success often conceal several possible meanings.

Registration might mean:

• account details submitted
• account created
• email verified
• product accessed for the first time

Use the observable state that actually occurred, such as registration.email_verified or account.first_accessed. Define workflow completion separately as the rule that combines the relevant evidence, population and time window.

The same principle applies to service work. If the platform records that one party marked a job as finished, job.completion_reported is more defensible than job.completed unless the system has independent evidence of completion.

Use properties for context

Do not create another event name for every segment, route or version.

Avoid:

quote.submitted_by_new_provider
quote.submitted_for_solar_installation
quote.submitted_after_site_visit
quote.submitted_version_2

Use one event name and attach documented properties:

Event:
quote.submitted

Properties:
request_id
quote_id
provider_id
quote_version
service_type
requires_site_visit
provider_tenure_band
submission_route

The event name records what happened. Properties provide the minimum context needed for interpretation.

Do not add message content, addresses, telephone numbers or other personal data merely because the underlying product record contains them. Event properties should follow a defined measurement purpose and the relevant privacy, access and retention controls.

Keep actor and object relationships clear

Multi-sided products need identifiers that distinguish who acted and what the action affected.

For example, conversation.message_sent may need:

conversation_id
request_id
actor_role
sender_account_id
recipient_role
message_sequence_number

The actor role may be customer, provider or administrator. The event name can remain stable while the properties allow appropriate comparisons.

Avoid encoding every actor combination into separate names unless the actions genuinely have different meanings or fire conditions.

Keep names stable when the interface changes

A stable behavioural event should survive changes to button labels, page layouts and component structures.

quote.accepted can remain the same whether the customer confirms through a modal, a dedicated review page or a redesigned comparison table. The fire condition remains the successful acceptance state change.

Interface-level events can be useful for temporary usability analysis. They should not replace durable behavioural events merely because they are easier to implement.

Review the complete definition

A naming convention improves readability, but it cannot repair an unclear event.

Before approving a name, confirm:

• the observable claim
• the exact fire condition
• when the event must not fire
• the actor and affected objects
• repeat, retry and reversal behaviour
• required properties
• what the event does not prove
• validation and ownership

The best event name is not the cleverest or shortest. It is the one that remains accurate when another team uses it months later without the original author in the room.