Products do not produce ready-made metrics. They produce behaviour and system activity.
A person views a form, submits details, encounters an error, verifies an email, uploads a document, revises a plan, or reaches the product for the first time. Instrumentation records selected activity as events. Teams then calculate metrics from those event records.
The title of this article is deliberately blunt. The precise version is:
Products produce behaviour and system activity. Instrumentation records selected activity as events. Teams calculate metrics from those event records.
That distinction prevents a common mistake: naming the metric before defining the behaviour underneath it.
The metric-first trap
Metric requests often sound clear before anyone asks what the words mean.
| Metric-first request | Better question | Define first |
|---|---|---|
| Track registration conversion | What observable behaviour shows that someone registered and reached the product? | Workflow boundary, completion point, and event evidence |
| Track engagement | Which recurring behaviour suggests that people are receiving value? | Value behaviour, frequency, context, and population |
| Track activation | What does a newly activated person or account actually do? | Activation behaviour and the workflow leading to it |
| Track drop-off | Where do people pause, leave, or fail within a specific workflow? | Entry, steps, exits, completion, and attempts |
The better question does not remove the metric. It gives the metric something defensible to measure.
Events are selected evidence
An event is a structured record that instrumentation creates when an observable condition is met.
For example:
registration.form_submitted
This event can show that the form reached a successful submission condition. It does not prove that the form was easy, that the person understood the next step, or that registration ultimately delivered value.
An event record is evidence of selected activity, not a complete account of the experience.
That is why event quality matters. If an event fires at the wrong moment, has a vague name, duplicates another event, or captures an interface detail with no meaningful behavioural interpretation, every metric built from it becomes harder to trust.
The event may fire perfectly and still measure the wrong behaviour.
Metrics are calculated from event records
A registration workflow might record:
registration.form_viewed
registration.form_submitted
registration.email_verified
account.first_accessed
From those events, a team could define:
- form submission rate;
- email verification rate;
- registration completion rate;
- time from registration start to first product access;
- abandonment between submission and verification.
The completion metric does not need an event called registration.completed. It can be derived from the relationship between a defined start and the first behaviour that satisfies the workflow’s completion rule.
That difference matters. An event name should describe the activity that was observed. The metric can represent the wider workflow state the team wants to understand.
“Registration conversion” on its own remains ambiguous. It could mean form submission, account creation, email verification, first product access, or completion within seven days. Each definition may be useful. Each answers a different question.
Use this distinction in practice
Before asking for a metric, describe the behaviour behind it.
Instead of:
What is our activation metric?
Ask:
Which observable behaviour would show that a new user has received meaningful value?
Instead of:
What is our registration conversion rate?
Ask:
Where does registration begin, what counts as completion, and which event records provide evidence of both?
Instead of:
How do we measure engagement?
Ask:
Which repeated behaviour matters, for whom, over what period, and why?
These questions are harder than choosing a familiar metric label. They are also where useful measurement begins.
Define the behaviour first. Decide what evidence is worth recording. Then calculate the metric the question actually needs.