What makes a good event?
A good event captures meaningful behaviour clearly enough to be used.
It should relate to a workflow step, fire at the right moment, use a predictable name, include useful context, and support a metric, question, or decision.
For example, registration.form_submitted is useful because it describes a specific behaviour in the registration workflow. It is stronger than button_clicked, because it names what happened rather than which interface element was used.
Event quality checklist
A good event should pass this checklist:
- captures meaningful behaviour
- maps to a workflow step
- fires at the right moment
- uses a clear and predictable name
- includes useful properties
- supports a metric, question, or decision
- has an owner or reviewer
This checklist is deliberately small. If an event fails several of these tests, the problem is probably not naming. The behaviour may not be clear enough yet.
Bad and better event names
| Weak event name | Better event name | Why it is better |
|---|---|---|
button_clicked |
registration.form_submitted |
Names the behaviour, not the interface element |
registration_activity |
registration.email_verified |
Says what actually happened |
success |
checkout.payment_confirmed |
Makes the outcome specific |
page_2_next |
application.documents_uploaded |
Survives interface changes better |
mobile_form_submitted |
registration.form_submitted with device_type=mobile |
Keeps context as a property rather than overloading the name |
Timing changes meaning
The timing of an event changes what it means.
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. Each produces a different completion metric. A good event definition removes that ambiguity by stating exactly when the event should fire and when it should not.
Properties make events usable
A clear event name is not enough. Events often need properties to support interpretation.
For example, registration.form_error_shown may need error_type, field_name, entry_point, device_type, and workflow_version.
Those properties let the team understand where the problem appears, which users are affected, and whether a change in the product may have influenced the pattern.
Common failure modes
Weak events often fail in predictable ways:
- the event name is vague
- the event fires too early or too late
- the event is too closely tied to a screen or component
- the event duplicates another event
- required properties are missing
- different teams interpret the event differently
- the event captures activity without a clear purpose
These problems become metric problems later. It is cheaper to fix the event definition before implementation than to explain an unreliable metric after launch.
Key takeaway
Do not ask for an event until you can describe the behaviour it should prove.
A good event is not just tracked. It is defined well enough to be understood, tested, reused, and trusted.