Think in measurement, not dashboards

The Workflow–Event–Metric model

The Workflow–Event–Metric model is a simple way to design product measurement.

It separates four layers that are often mixed together:

workflows describe what users are trying to do
events record what happened
metrics summarise the evidence
decisions explain why the measurement matters

The model follows a practical sequence:

Workflow
↓
Events
↓
Metrics
↓
Decisions

A workflow defines the behaviour that matters. Events capture evidence of that behaviour. Metrics help teams interpret the evidence. Decisions give measurement a purpose.

This sequence matters because many measurement problems start when teams jump straight to metrics or dashboards before agreeing what behaviour they are trying to understand.

Use this model when

Use the Workflow–Event–Metric model when a team needs to:

define what behaviour should be measured
turn a vague analytics request into a clear measurement design
connect events to workflow steps
explain how metrics are calculated from evidence
decide whether a dashboard is answering a useful question
review whether measurement still supports decisions

Diagram: Workflow–Event–Metric model

Workflow
What behaviour matters?

↓ informs

Events
What evidence should we capture?

↓ produce

Metrics
What measures help us understand progress?

↓ support

Decisions
What should we do next?

This is the core model for the site. Use it as the reference point for workflows, events, metrics, frameworks, dashboards, catalogues, and reviews.

Why the model is needed

Product measurement becomes confusing when teams use broad phrases such as:

We need to measure onboarding.

That could mean the onboarding journey, the events that should be tracked, the metrics that should appear on a dashboard, or the decision the team needs to make.

The model makes the conversation more specific. Instead of asking “What analytics do we need?”, the team can ask:

What workflow are we trying to understand?
What events would show meaningful behaviour?
What metrics would help us interpret the evidence?
What decision will this support?

Clear layers make measurement easier to design, implement, review, and trust.

Start with the workflow

A workflow is a meaningful sequence of behaviour. It describes something a user is trying to achieve, such as registering for an account, completing checkout, submitting an application, setting up a subscription, or creating a plan.

Workflows give measurement a clear subject. Without a workflow, teams often drift towards whatever is easiest to count: page views, clicks, visits, sessions, totals, or isolated feature usage.

A workflow helps the team agree:

what the user is trying to achieve
where the workflow starts
which steps matter
where users can pause, fail, abandon, or complete
what successful progress looks like

The workflow gives the team something concrete to measure before deciding what to track.

Capture events as evidence

Once the workflow is clear, the team can decide what evidence should be captured.

For a registration workflow, useful events might include:

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

These events make the workflow observable. If the team only tracks registration.completed, they may know how many users completed registration, but not where other users dropped out. If they track every click without connecting those events to the workflow, they may create noise rather than useful evidence.

Good event design captures enough behaviour to support the questions the team needs to answer.

Turn events into metrics

Metrics are created from events. They count, combine, filter, compare, or calculate from the evidence captured in the product.

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

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

These metrics help the team understand patterns in the workflow. For example, if many users submit the form but do not verify their email, the team has a more specific investigation than “registration is underperforming”.

The issue may be the verification email, the confirmation screen, email deliverability, or user expectations.

Connect metrics to decisions

The model does not end with metrics. A metric should support a decision, even if that decision is to monitor, investigate, compare, prioritise, or leave something alone.

For registration, the product question might be:

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

That question could support decisions such as:

Should we improve the registration form?
Should we change the email verification step?
Should we investigate deliverability?
Should we simplify the journey?
Should we compare behaviour by device, channel, or user type?

A metric without a decision may still be a valid number, but it is not doing useful product work.

The model in practice

Here is the model applied to account registration:

Workflow:
Register for an account

Workflow steps:
View form → enter details → submit form → verify email → access product

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

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

Decision:
Where should we improve the registration experience?

The example is deliberately simple. Most measurement problems do not begin with advanced analytics. They begin with unclear thinking about ordinary product behaviour.

What the model prevents

The model helps teams avoid common measurement problems:

metrics without defined behaviour
events without a clear purpose
dashboards without decisions
tracking plans that are hard to interpret
metric definitions that drift over time
analytics work that is disconnected from product questions

It also helps teams avoid confusing implementation with measurement design. Adding events to a product is not the same as designing a measurement system. The events need to connect to workflows, metrics, and decisions.

How to apply this

Use the model whenever a team is planning or reviewing product measurement.

Before creating a dashboard, writing instrumentation requirements, or requesting a metric, ask:

What workflow are we trying to understand?
What behaviour matters within that workflow?
What events would provide useful evidence?
What metrics would help us interpret that evidence?
What decision should this measurement support?

When reviewing existing measurement, trace unclear metrics backwards: which workflow does this metric describe, which events produce it, and what decision is it meant to support?

What is a workflow?
Events as evidence
From events to metrics
Designing a measurement framework
Workflow catalogue template

Key takeaway

The Workflow–Event–Metric model separates product measurement into clear layers.

Start with the workflow. Capture the events. Define the metrics. Use the metrics to support decisions.