What makes a good event?

A good event captures meaningful behaviour clearly enough to be used.

It should show that something important happened in the product, relate to a workflow step, and support a metric or decision the team cares about.

For example:

registration.form_submitted

This event is useful because it describes a specific behaviour in the registration workflow. It is clearer than a vague event such as button_clicked, and more measurable than a broad label such as registration_activity.

Good events are understandable, purposeful, and reliable.

Event quality checklist

A good event should pass this checklist:

• it captures meaningful behaviour
• it maps to a workflow step
• it fires at the right moment
• it uses a clear and predictable name
• it includes useful properties
• it supports a metric, question, or decision
• it has an owner or reviewer

Bad / better event names

Good events capture meaningful behaviour

An event should exist because it helps answer a product question.

It might show whether users:

• started a workflow
• reached a meaningful step
• encountered a problem
• completed an outcome
• returned later to continue
• behaved differently by device, entry point, or user type

For registration, useful events might include:

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

These events describe progress through the workflow. Low-level interactions such as button_clicked, modal_opened, or field_focused can be useful when they explain a specific problem, but they should not be the default.

Good events fire at the right moment

The timing of an event changes what it means.

For example, registration.completed could fire when:

• the form is submitted
• the account is created
• the email is verified
• the user accesses the product for the first time

Each version describes a different point in the workflow and produces a different completion metric.

A good event definition should make clear when the event fires and what must be true at that moment.

Good events are named consistently

Event names should be predictable.

A consistent naming pattern helps product, engineering, and analytics teams understand what an event means without decoding each one from scratch.

For example:

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

These names are easier to work with than a mixed set such as:

RegPageLoad
submit_registration
emailSuccess
completeSignup

The exact convention matters less than using one convention consistently.

Good events include useful context

The event name records what happened. Properties add context.

For example:

registration.form_error_shown

This event becomes more useful when it includes properties such as:

• error type
• field affected
• device type
• entry point
• user type
• workflow version

Without context, an event may be technically correct but difficult to interpret.

Common problems with events

Weak events often have one or more of these problems:

• the name is vague
• the event fires at the wrong moment
• the event duplicates another event
• the event is too closely tied to a screen or component
• the event is missing useful properties
• the event captures activity without a clear measurement purpose
• different teams interpret the event differently

These problems make metrics harder to trust and dashboards harder to explain.

How to apply this

Before adding an event, ask:

• what behaviour does this event capture?
• which workflow step does it relate to?
• when exactly should it fire?
• what properties does it need?
• what metric or question could use it?
• what decision could it support?

A good event should pass this test before it is implemented.

Related articles

• Event naming convention examples
• Writing instrumentation requirements
• Event catalogue template

Key takeaway

A good event captures meaningful behaviour at the right moment, with a clear name and useful context.

Good events make workflows observable and give teams evidence they can use to create reliable metrics.