Turn behaviour into metrics

From events to metrics

Events record what happened. Metrics help teams understand the pattern.

A product might record that a user viewed a form, submitted details, verified an email, or completed a workflow. Those events become useful when the team counts, combines, filters, or compares them to answer a product question.

A metric is not the event itself. It is a measure created from event data.

For example:

Events:
registration.form_viewed
registration.form_submitted
registration.email_verified
registration.completed

Metrics:
Form submission rate
Email verification rate
Registration completion rate
Time to complete registration

The events provide evidence. The metrics help the team interpret that 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	Number of users who triggered `registration.form_submitted`
Combine	Uses two or more events together	Users who submitted the form and verified email
Filter	Limits the metric to a relevant population	Completion rate for mobile users only
Compare	Compares events, periods, or groups	Completion rate before and after a workflow change
Calculate	Creates a formula from event evidence	`registration.completed ÷ registration.form_viewed`

The metric becomes useful when the calculation matches the product question.

Metrics are built from event logic

A useful metric needs a clear definition.

For example, “registration completion rate” could mean:

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, but each answers a different question.

The metric name is not enough. The team needs to define the logic behind it.

Good metrics answer product questions

Metrics are useful when they help the team understand something they need to decide.

For registration, the question might be:

Are users able to create an account and access the product without unnecessary friction?

That question could lead to metrics such as:

registration start count
form submission rate
form error rate
email verification rate
registration completion rate
time to complete registration
drop-off between form submission and email verification

These metrics are useful because they describe progress through a workflow. They help the team see where users move forward, slow down, fail, or leave.

The same events can produce different metrics

A set of events can support several metrics.

For example, registration.form_submitted and registration.email_verified could be used to 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 why event design matters. A well-designed event can support multiple useful metrics. A vague or poorly timed event may only create confusion.

Metrics need context

A metric is easier to interpret when the team understands its source, scope, and constraints.

A useful metric definition should include:

the question it helps answer
the events used to calculate it
the calculation logic
the population included
any filters or exclusions
the reporting period
the decision it supports

Without this context, two teams may use the same metric name but mean different things.

Metrics can hide the behaviour underneath

A metric summarises evidence, but it can also hide detail.

For example, a registration completion rate may fall from 60% to 50%. That tells the team something changed, but not where the change happened.

The team still needs to look at the underlying workflow:

View form
↓
Enter details
↓
Submit form
↓
Verify email
↓
Access product

The problem could be form abandonment, validation errors, email verification, first product access, or a change in the type of users entering the workflow.

A metric should point the team back to the behaviour, not replace it.

How to apply this

When creating a metric from events, ask:

what product question should this metric answer?
which workflow does it describe?
which events are used to calculate it?
what is the exact formula?
which users or sessions are included?
what filters or exclusions apply?
what decision could this metric support?

These questions help teams move from event data to metrics that can be explained, trusted, and used.

Metrics should answer questions
Metric catalogue template
Example metric definitions

Key takeaway

Metrics are created from events.

A good metric has clear event logic, useful context, and a connection to a product question. It should help the team interpret behaviour, not hide it.