Example: turning a workflow into metrics

This example follows the same registration workflow from Section 2 and turns it into events, metrics, dimensions, and decisions.

The point is not to create the perfect registration dashboard. The point is to show the reasoning from behaviour to evidence to measures.

Starting workflow

Workflow:
Register for an account

User intent:
Create an account so I can access the product.

Entry point:
User starts account creation.

Steps:
1. View registration form
2. Enter details
3. Submit form
4. Verify email
5. Access product

Completion:
User accesses the product for the first time.

This workflow gives the team a behavioural structure. Now the team can decide what evidence would make the steps observable.

Event design

Workflow step Event What the event proves
View registration form registration.form_viewed The user reached the form
Submit form registration.form_submitted The user submitted registration details
Validation error shown registration.form_error_shown The user encountered a form error
Verify email registration.email_verified The user completed email verification
Access product registration.completed The user reached the product after registration

The events do not explain everything, but they provide the behavioural evidence needed to create metrics.

Metric definitions

Product question Metric Example definition
Are users starting registration? Registration start count Count of users who trigger registration.form_viewed
Are users able to submit the form? Form submission rate Users who trigger registration.form_submitted ÷ users who trigger registration.form_viewed
Are users encountering form problems? Form error rate Users who trigger registration.form_error_shown ÷ users who trigger registration.form_viewed
Are users completing verification? Email verification rate Users who trigger registration.email_verified ÷ users who trigger registration.form_submitted
Are users reaching the product? Registration completion rate Users who trigger registration.completed ÷ users who trigger registration.form_viewed

Each metric answers a different question. Together they help the team understand where the workflow is healthy and where it may need investigation.

Useful dimensions

The team should not only look at the overall metrics. It may need to compare behaviour by:

  • entry point
  • device type
  • user type
  • workflow version
  • channel
  • error type

For example, a stable overall completion rate could hide a mobile problem. A high form submission rate could still hide a specific validation error. A lower completion rate for invited users could point to the invitation flow rather than the form itself.

Dimensions turn a broad signal into a more focused investigation.

Decisions the metrics can support

The metrics should support practical decisions:

Signal Possible decision or investigation
Low form submission rate Review field design, guidance, trust signals, or perceived effort
High form error rate Improve validation rules, labels, hints, or error messages
Low email verification rate Investigate confirmation screen, email content, deliverability, or resend behaviour
Low first product access Improve post-verification handover or first-use experience
Mobile underperformance Prioritise mobile usability review or performance checks

The metric does not decide for the team. It helps the team ask the next better question.

What this example shows

The workflow creates the structure. The events provide evidence. The metrics summarise patterns. The dimensions add context. The decisions explain why the measurement matters.

The important move is not the specific registration example. It is the reasoning: do not invent the metric in isolation. Trace it back to behaviour and forward to use.

Key takeaway

A metric is strongest when it can be traced back to a workflow step and forward to a decision.

That traceability is what turns event data into product measurement.