The Workflow–Event–Metric model

The Workflow–Event–Metric model is the core design model of Measuring Products.

It separates three layers that product teams often collapse into one another: the workflow people perform, the event evidence instrumentation records, and the metrics teams calculate from that evidence.

The compact model is:

Workflow → Events → Metrics

It gives teams a practical place to begin before a conversation turns into a debate about dashboards, event names, or KPIs. But it is not the whole measurement process.

Purpose comes before the model

A workflow does not decide what deserves attention. A product question or decision gives measurement its purpose.

From purpose to action

Question or decision What does the team need to understand?
Workflow Which bounded behaviour matters?
Observable behaviour What activity or state can be observed?
Events Which records provide useful evidence?
Metrics Which calculations answer the question?
Interpretation What changed, how confident are we, and what remains uncertain?
Decision or next question Act, investigate, continue monitoring or revise the design.

Workflow → Events → Metrics is the compact design model. The complete process is iterative rather than perfectly linear.

This distinction matters. Starting with a workflow is useful only after the team has some reason to understand it.

The reason might be to monitor an important service, investigate friction, evaluate a change, compare experiences, prioritise work, or check whether an existing metric is still trustworthy.

The Workflow–Event–Metric model then structures the measurement design itself.

Workflow: define the behaviour that matters

A workflow describes how a person or organisation attempts to achieve a meaningful outcome.

It gives measurement a boundary:

where the relevant behaviour begins;
which steps represent meaningful progress;
where people can pause, repeat, leave, or fail;
what counts as completion for the question being asked.

Workflows are more useful than screens because the same behaviour may cross several pages, features, systems, roles, or offline steps. They are more focused than complete user journeys because the team can define a specific outcome and measurement boundary.

A workflow is not automatically linear. The model applies to optional steps, repeated attempts, long pauses, and outcomes that occur partly outside the product.

Events: decide what evidence to record

Products produce behaviour and system activity. Instrumentation records selected activity as events.

An event should represent an observable condition, such as:

registration.form_submitted

The event record is evidence that the condition occurred. It does not explain the person’s intent, confidence, or complete experience.

Event design therefore asks:

What activity would provide useful evidence of the workflow?
At which exact condition should the event fire?
Which properties are genuinely needed to interpret it?
What does the event not prove?
How will the team validate and maintain it?

The aim is not to record every interaction. It is to capture the minimum evidence needed to answer an identified question responsibly.

Metrics: calculate a measure for a job

Metrics turn event records and other evidence into measures that a team can interpret.

A metric may count activity, calculate a rate, compare groups, follow a cohort, measure elapsed time, or indicate a wider condition. Its definition needs more than a name and formula.

A trustworthy metric normally specifies:

the question it serves;
the unit being counted;
the eligible population;
the numerator and denominator;
the time window or cohort;
filters and exclusions;
useful dimensions;
source evidence;
known limitations.

The same event records can support several metrics, and the same metric label can hide several incompatible definitions. “Registration conversion”, for example, could end at form submission, account creation, email verification, or first product access.

The model forces that ambiguity into the open before the number reaches a dashboard.

Interpretation connects metrics to decisions

A metric is not a decision and rarely explains itself.

Suppose registration completion falls. The measure tells the team that a defined pattern changed. It does not establish why.

The team may need to compare workflow steps, device types, entry routes, cohorts, technical errors, support contacts, or research findings. It may also discover that the instrumentation or definition changed rather than the user experience.

Interpretation turns the measure into a responsible conclusion:

What appears to have changed?
How confident are we?
Which explanations remain plausible?
What evidence is missing?
What action or investigation is justified?

The loop then ends with a decision or a better question. Measurement is useful when it changes what the team understands, chooses, investigates, or monitors.

The model in practice

Take account registration.

A stakeholder request might begin as:

Track registration conversion.

The model turns that request into a traceable measurement design:

Registration measurement design

Product question: Are people able to create an account and reach the product?
Workflow: Register for an account
Workflow steps: View the registration form

Enter and submit details

Resolve any validation errors

Verify the email address

Access the product for the first time
Event evidence: registration.form_viewed

registration.form_submitted

registration.form_error_shown

registration.email_verified

account.first_accessed
Possible metrics: Form submission rate

Form error rate

Email verification rate

Registration completion rate

Time from registration start to first access
Interpretation: Compare steps, attempts, devices, entry routes, and supporting research to understand where confidence is low or behaviour changes.
Decision: Decide which part of the registration experience to investigate, improve, monitor, or leave unchanged.

The registration completion rate is still part of the design, but it no longer floats on its own. The team can trace it backwards to a defined workflow and observable evidence, then forwards to an interpretation and possible decision.

Notice that the example does not require an event called registration.completed. Completion is a metric rule. It can be derived when someone who entered the workflow reaches account.first_accessed within the defined period.

This keeps the event grounded in observed activity and the metric grounded in the question.

Use the model when the conversation becomes vague

The model is especially useful when a team says:

“We need to measure onboarding.”
“We need a dashboard for this feature.”
“We should track engagement.”
“This metric has lost trust.”
“Engineering needs event requirements.”
“Leadership wants a KPI, but nobody agrees what it represents.”

Work through these questions:

What question or decision gives this work a purpose?
Which workflow contains the relevant behaviour?
What activity can be observed responsibly?
Which event records provide useful evidence?
Which metric definition answers the question?
How will the team interpret the result?
What might happen next?

The sequence is a design dependency, not a claim that product behaviour or analysis is perfectly linear. Teams will move backwards, revise definitions, discover missing evidence, and ask new questions.

That is healthy. The model exists to keep the layers clear while the understanding improves.

A workflow is not an event. An event is not a metric. A metric is not an explanation. An explanation is not automatically a decision.

Keeping those distinctions visible is what makes the measurement system easier to design, implement, challenge, and trust.