Products generate events, not metrics

Products do not generate metrics. They generate things that happen.

A user views a page. A user opens a form. A user submits their details. A user encounters an error. A user verifies an email. A user completes registration.

These are events: records of behaviour in the product.

Metrics come later. They are created by counting, combining, filtering, comparing, or calculating from events.

This distinction matters because weak measurement often starts when teams name the metric they want before defining the behaviour underneath it.

Bad / better metric-first examples

The better question does not remove the metric. It gives the metric something solid to measure.

Events are records of behaviour

An event records that something happened in the product.

It might show that a user:

• viewed a screen
• submitted a form
• encountered an error
• verified an email
• completed a step
• finished a workflow

For example:

registration.form_submitted

This event does not explain the whole registration journey. It simply records that a specific behaviour happened.

Events give teams evidence of user behaviour. Without that evidence, metrics become difficult to define, explain, or trust.

Metrics are created from events

A metric is created from event data.

For example, a registration workflow might capture events such as:

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

From those events, a team might create metrics such as:

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

The events record what happened. The metrics help the team understand the pattern.

If the events are missing, vague, inconsistent, or captured at the wrong point in the workflow, the metrics built from them will be weak too.

The metric name is not enough

A team might say:

We need to track registration conversion.

That sounds reasonable, but it is not yet specific enough.

Does registration conversion mean:

• users who viewed the registration form and submitted it?
• users who started registration and verified their email?
• users who created an account and accessed the product?
• users who completed registration in the same session?
• users who completed registration within 24 hours?

Each version could produce a different number.

The problem is not the word “conversion”. The problem is naming the metric before defining the behaviour.

A clearer measurement conversation separates the layers:

Question:
Are users able to complete registration?

Workflow:
Register for an account

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

Metric:
Registration completion rate

Decision:
Where should we improve the registration experience?

Once the behaviour is clear, the metric becomes easier to define and easier to trust.

Events are evidence, not insight

Events show what happened. They do not explain what it means.

An event can tell us that a user submitted a form. It cannot tell us whether the form was easy, whether the user felt confident, or whether they understood what would happen next.

Insight comes from interpreting evidence in context. That may involve metrics, segments, user research, support feedback, experimentation, or operational knowledge.

For example, event data might show that many users submit the registration form but fewer verify their email. That pattern is useful, but the team may still need to investigate the verification email, confirmation screen, email deliverability, or user expectations.

Weak events create weak metrics

Metrics inherit the quality of the events beneath them.

A metric may be unreliable if the underlying events are poorly designed. Common problems include:

• events firing too early
• events firing too late
• missing steps in the workflow
• inconsistent event names
• unclear event definitions
• missing properties or context
• duplicate or unreliable tracking

For example, a team may track:

registration.completed

That event is useful, but it may not be enough. The team may also need to know whether the user verified their email, how long completion took, which device they used, where they came from, and whether they encountered errors along the way.

Good event design does not mean tracking everything. It means capturing enough evidence to support the metrics and decisions the team cares about.

How to apply this

Before asking for a metric, describe the behaviour behind it.

Instead of asking:

What is our activation metric?

Ask:

What does an activated user actually do?

Instead of asking:

What is our registration conversion rate?

Ask:

What observable steps show that a user has successfully registered?

Instead of asking:

How do we measure engagement?

Ask:

What meaningful behaviour would show that users are getting value from the product?

These questions help teams separate behaviour, events, metrics, and decisions before designing the measurement.

Related articles

• Events as evidence
• From events to metrics
• Event catalogue template
• Instrumentation specification template

Key takeaway

Products generate events, not metrics.

Events record behaviour. Metrics are calculated from those records. A metric is only as strong as the evidence it is built from.