Every workflow metric depends on a boundary.
The entry point decides which attempts are eligible. The completion point decides which attempts count as complete. The time rule decides how long completion is allowed to take. Exits and pauses determine what sits between those two conditions.
These are not implementation details. They are part of the meaning of the metric.
The same workflow can produce different measures
Consider account registration:
| Measurement view | Entry point | Completion point | What it measures |
|---|---|---|---|
| Form completion | Registration form viewed | Details submitted successfully | Ability to complete the form |
| Account setup | Account creation started | Email verified | Ability to create and confirm an account |
| Product access | Account creation started | Product accessed for the first time | Ability to reach the product through registration |
None is automatically correct. Each answers a different question.
A dashboard labelled “registration completion” becomes misleading when this boundary is left implicit or changes without warning.
Entry points define the eligible population
An entry point is the observable condition that marks the start of analysis.
People may enter registration by:
- selecting Create account
- opening an invitation
- beginning registration during checkout
- following a campaign link
- being added by an administrator
These routes may reflect different intent and different product behaviour. An invited user may already understand why the account is needed. A self-serve visitor may still be deciding whether the product is relevant.
The entry rule should therefore state both the behaviour and the eligible unit:
Eligible attempt:
A new user starts account creation through any supported route.
If the product allows repeated attempts, decide whether the unit is a person or an attempt. Counting every restart as a new user can inflate the denominator. Counting only one attempt per person can hide repeated friction.
Exits, pauses and returns are different
A person who does not trigger the next event has not necessarily abandoned.
They may:
- return after a short break
- switch device
- wait for an email or external decision
- gather missing information
- ask another person to complete a step
- continue through a channel the product does not track
- decide not to proceed
Event data may show that progress stopped within the observed window. It does not, by itself, explain why.
Use neutral language such as did not continue within seven days when that is what the evidence supports. Reserve failed or abandoned for conditions the team has defined and can justify.
Completion needs a time rule
A completion metric is incomplete without saying how long an eligible attempt has to finish.
Compare:
Of the users who started registration this week,
how many reached the product within seven days?
with:
Of all users active this week,
how many started and completed registration during the same week?
The first is a cohort measure: it follows a group that started under the same condition. The second is a period measure: it counts activity occurring inside a reporting window.
They can produce different results even when both calculations are correct. Period measures often undercount workflows that take longer than the reporting interval or mix new attempts with older ones.
Use cohort logic when the question is whether eligible starters eventually complete. Use period logic when the question is about activity or operational volume during a period.
Completion may belong to a person, account or organisation
The selected unit changes the meaning.
A user may finish their part while the account remains incomplete. An analyst may create a retrofit plan while the organisation still needs to review and approve it. Several people may contribute to one application.
State whether completion belongs to:
- a person
- a workflow attempt
- an account
- an application or case
- an organisation
- another product object
Do not calculate a user-level rate when the outcome is genuinely account- or organisation-level merely because user identifiers are easier to query.
Product completion is not always value
Reaching the final screen proves only that the selected completion condition occurred.
An account may be created but never used. A retrofit plan may be generated but not trusted, approved or acted on. An application may be submitted but contain information that causes avoidable rework.
It can be useful to define two points:
- workflow completion — the bounded task reached its selected end condition;
- value or downstream outcome — the result was useful, accepted or led to further action.
These should not be collapsed into one event merely to make the dashboard simpler.
Completion can happen outside the product
Some workflows finish through manual review, a support conversation, an external transaction or an offline decision. The digital product may observe only part of the process.
When this happens:
- identify the external evidence needed
- document gaps and delays in that evidence
- avoid presenting digital completion as the complete service outcome
- decide whether the metric is a final outcome or a partial indicator
A clean digital funnel can conceal the part of the workflow where the actual decision is made.
Write the boundary as a rule
Before calculating a completion rate, write a definition such as:
Unit:
Registration attempt
Entry:
A new user starts account creation.
Completion:
The account reaches first product access within seven days.
Repeated attempts:
Use the first eligible attempt per user during the cohort period.
Exclusions:
Test accounts, staff accounts and migration-created accounts.
If the entry, unit, completion or time window changes, the metric has changed—even when the chart retains the same name.