A metric name sounds more settled than it usually is.
“Registration completion rate” could support monitoring, diagnosis, evaluation or comparison. Each job may require a different population, time rule, breakdown and interpretation—even when the label on the chart stays the same.
The question does not merely give the metric a purpose. It changes the definition.
One metric name, several questions
Consider four questions about registration:
| Product question | Definition choice it changes |
|---|---|
| Can new users reach the product after starting registration? | Completion point, cohort window and eligible population |
| Where does registration lose momentum? | Step measures, attempt-level evidence and diagnostic breakdowns |
| Did the redesigned form improve completion? | Comparison period or experiment design, workflow version and evaluation caveats |
| Are invited users struggling more than self-serve users? | Entry-route dimension, comparable populations and segment size |
A single headline rate may contribute to each discussion, but it cannot answer all four questions by itself.
The question shapes the unit
Ask what the team is trying to understand:
- How much activity occurred? Count event records or workflow attempts.
- How many people succeeded? Count unique users.
- Did accounts become usable? Use accounts as the unit.
- Did organisations reach an approved outcome? Use organisations or cases.
The easiest identifier in the dataset is not necessarily the correct unit.
A user-level completion rate can be misleading when several users contribute to one account or one organisational outcome. An event-level rate can reward repeated attempts when the product question is about people completing efficiently.
The question shapes the population
“Are users completing?” is incomplete until the team defines which users are eligible.
Possible populations include:
- all new users who start account creation
- invited users only
- self-serve users only
- users exposed to the current workflow version
- first eligible attempt per person
- accounts created after a migration date
The selected population should match the decision. If the team is evaluating a new form, mixing users from the old and new versions weakens the comparison. If it is monitoring the whole service, excluding a difficult entry route may make the workflow look healthier than it is.
The question shapes time
Monitoring current activity may use a weekly period measure. Understanding eventual completion usually needs a cohort and a completion window. Evaluating a change needs enough time for the new population to mature.
Compare:
How many users completed registration this week?
with:
Of users who started registration this week,
how many reached the product within seven days?
The first measures current completions. The second measures progression for a defined cohort. Neither can substitute for the other without changing the question.
The question shapes the comparison
A number without a comparison may still be useful for monitoring, but it rarely explains whether action is needed.
The question may require comparison with:
- an earlier period
- a previous product version
- another entry route
- another device category
- an expected range or service standard
- an experiment control
- a relevant cohort
The comparison must be fair. A before-and-after view can be distorted by seasonality, traffic mix, instrumentation changes or incomplete cohorts. A segment comparison can be unstable when one group is very small.
The question shapes the dimensions
Add a dimension only when a difference would lead to a meaningful investigation or choice.
For example:
Are invited users less likely to reach the product than self-serve users?
requires a reliable entry_route property and comparable definitions across both groups.
By contrast, breaking the same rate down by every property available in the analytics tool creates options, not understanding.
The question shapes interpretation
Metrics narrow uncertainty; they do not remove it.
Suppose mobile completion is lower than desktop completion. The evidence identifies where the difference appears. It does not prove that screen size caused it. The mobile population may differ in intent, entry route, connection quality or another unobserved factor.
Similarly, a metric improving after a release does not prove that the release caused the improvement.
The question should therefore state what the metric can support:
- monitoring a condition
- locating a pattern
- prioritising investigation
- evaluating evidence alongside other factors
- deciding whether more research or analysis is needed
Write the question into the definition
A useful metric definition begins with a sentence such as:
Question:
Of new users who start account creation,
what proportion reaches the product within seven days?
Decision use:
Monitor registration health and identify when the workflow needs investigation.
That statement makes the required unit, population, boundary and time logic easier to challenge.
A metric without a question is underdefined. A metric with a question can still be wrong, but at least the team can see which choices it is making and whether they fit the decision.