An overall metric can show that something changed. Dimensions and segments help the team see where the pattern appears and which groups deserve closer investigation.
They add context. They do not provide an explanation on their own.
The distinction
| Term | Meaning | Example |
|---|---|---|
| Metric | The measure being interpreted | Registration-to-access completion rate |
| Dimension | A characteristic available for breakdown or comparison | Entry route |
| Dimension value | One recorded value within that characteristic | Invitation |
| Segment | A group defined by one or more characteristics or behaviours | Invited mobile users on the new workflow |
| Event property | Captured context that may support a dimension | entry_route |
A segment is not always a single value within one dimension. It may combine several conditions, or be defined by behaviour such as repeated attempts.
Overall metrics can hide important differences
Suppose the overall registration-to-access completion rate is 62%.
A breakdown might show:
Self-serve desktop: 74%
Self-serve mobile: 51%
Invited desktop: 81%
Invited mobile: 69%
The overall rate hid both a device difference and a population difference. A simple mobile-versus-desktop comparison would also have hidden the fact that entry route and device may interact.
The breakdown gives the team a better place to investigate. It still does not establish why those groups differ.
Choose dimensions for a reason
Useful dimensions connect to a plausible product question or decision.
For registration, these might include:
- entry route, because invitation and self-serve registration reflect different contexts
- device category, because interaction and performance may differ
- workflow version, because the team may be evaluating a change
- account or organisation type, because setup requirements may differ
- country or service region, where policy or service design genuinely changes the workflow
Ask:
If this breakdown changed, would we know what to investigate, compare or decide?
If not, the dimension may be available but not useful.
Do not collect more properties merely to create future slicing options. Each property creates implementation, privacy, quality and maintenance costs.
Check whether the property can be trusted
A clean chart can conceal a weak dimension.
Before using a property, check:
- what sets the value
- when it is captured
- whether it can change during the workflow
- how missing or unknown values are handled
- whether old and new values use the same categories
- whether one person or account can belong to several values
- whether the property is derived or directly observed
For example, device_type may describe the device used at the start, at completion or at each event. Those choices matter when people switch devices.
A mutable property such as account type may also produce historical confusion if reports use the current value rather than the value at the time of the event.
Small segments create noisy stories
A segment can show a dramatic rate because it contains very few eligible cases.
Always expose or inspect the denominator. Consider:
- a minimum sample rule for routine reporting
- absolute counts alongside rates
- confidence intervals or uncertainty where appropriate
- combining categories only when that preserves meaning
- suppressing sensitive or identifiable small groups
A difference of 20 percentage points across ten attempts is not equivalent to the same difference across ten thousand attempts.
Do not use precise ranking to disguise unstable evidence.
Overlapping segments can be counted more than once
Segments such as mobile users, invited users and users with repeated attempts overlap. Adding their counts together would double-count people or attempts.
Make clear whether groups are:
- mutually exclusive categories
- overlapping analytical segments
- a hierarchy
- a combination of several dimensions
This matters for both interpretation and dashboard design. A collection of overlapping segment cards is not a decomposition of the total.
Population mix can move the overall metric
The overall rate can change even when every segment remains stable.
Suppose invited users complete at a high rate and self-serve users at a lower rate. If the product receives a larger share of self-serve traffic this month, the overall rate may fall without either workflow becoming worse.
This is a population-mix change. It is one reason to inspect important dimensions before attributing a trend to product performance.
The reverse is also true: an overall metric can stay stable while one important segment improves and another deteriorates.
Segment differences are signals, not causes
If mobile users complete at a lower rate, the difference may relate to layout, performance, validation, entry route, intent or another factor the product does not observe.
If a new workflow version performs better, the exposed population may also be different.
Use segment analysis to locate patterns and form better questions. Combine it with workflow evidence, research, technical investigation and appropriate evaluation methods before making a causal claim.
Keep one metric definition where the meaning is stable
You usually do not need separate definitions for:
Mobile registration completion rate
Desktop registration completion rate
Invited-user registration completion rate
Self-serve registration completion rate
A cleaner model is:
Metric:
Registration-to-access completion rate
Dimensions:
device_category
entry_route
workflow_version
Segments:
Invited mobile users
Self-serve users on the new workflow
Attempts with repeated submission
The metric definition remains stable. Dimensions and segments provide controlled ways to interpret it.
Use them to reveal where the evidence differs—not to manufacture explanations or multiply dashboards without purpose.