From events to metrics
Events record what happened. Metrics help teams understand the pattern.
A product might record that users viewed a form, submitted details, verified an email, or completed a workflow. Those records become useful when the team counts, combines, filters, compares, or calculates from them to answer a product question.
A metric is not the event itself. It is a measure created from event evidence.
Calculation patterns
Metrics are usually created from events in a few simple ways.
| Pattern | What it does | Example |
|---|---|---|
| Count | Counts how often something happened | Users who triggered registration.form_submitted |
| Combine | Uses two or more events together | Users who submitted the form and verified email |
| Filter | Narrows the population | Completion rate for mobile users only |
| Compare | Compares events, periods, or groups | Completion before and after a workflow change |
| Calculate | Creates a formula from event evidence | registration.completed ÷ registration.form_viewed |
The calculation is only useful when it matches the question.
Metric names are not definitions
“Registration completion rate” could mean several things:
- completed registrations divided by registration form views
- completed registrations divided by form submissions
- users who verified email divided by users who started registration
- users who accessed the product divided by users who clicked “create account”
Each version may be valid. Each answers a different question.
That is why a metric definition needs source events, formula, population, filters, exclusions, dimensions, and limitations. The name alone is not enough.
The same events can support different metrics
A set of events can support several useful measures.
For example, registration.form_submitted and registration.email_verified can help calculate:
- number of submitted forms
- number of verified emails
- email verification rate
- drop-off after form submission
- time from form submission to email verification
- email verification rate by device, entry point, or user type
This is one reason to design events carefully. A well-defined event can support multiple metrics. A vague or poorly timed event can create multiple arguments.
Metrics can hide behaviour
A metric summarises evidence, but it can also hide the detail a team needs.
A registration completion rate may fall from 60% to 50%. That tells the team something changed. It does not explain whether the issue is form abandonment, validation errors, email verification, first product access, or a change in the type of users entering the workflow.
A useful metric should point the team back to the behaviour, not replace it.
Practical rule
When creating a metric from events, write the definition before building the chart.
At minimum, define:
- the product question
- the workflow
- the source events
- the formula
- the population included
- filters and exclusions
- useful dimensions
- the decision or investigation the metric supports
If the team cannot define those things, it probably does not need a dashboard yet. It needs measurement design.
Key takeaway
Metrics are calculations with intent.
The event evidence gives the metric substance. The product question gives it a job.