Dimensions and segments

Dimensions and segments help teams understand where a metric changes, for whom it changes, and under what conditions.

A metric may show that something is happening. Dimensions and segments help the team interpret the pattern.

For example, registration completion rate may look stable overall, but behave differently by device type, entry point, user type, or workflow version. Without those comparisons, the team may miss the part of the workflow that needs attention.

Dimension and segment table

Dimensions usually depend on event properties. If the property is missing or unreliable, the dimension will be hard to use.

What dimensions and segments are

A dimension is a characteristic used to break down or compare a metric.

Examples include:

• device type
• entry point
• user type
• channel
• geography
• workflow version
• organisation type

A segment is a specific group within a dimension.

For example:

Dimension:
Device type

Segments:
Mobile
Desktop
Tablet

Dimensions create the structure for comparison. Segments are the groups being compared.

Why they matter

Overall metrics can hide important differences.

A team might report:

Registration completion rate:
62%

That number may be accurate, but it does not show whether the experience is working equally well for different users or contexts.

A breakdown might show:

Registration completion rate by device type:

Desktop: 74%
Mobile: 48%
Tablet: 55%

The overall metric gives a signal. The dimension helps the team see where the signal is concentrated.

This changes the product conversation. Instead of asking whether registration is generally underperforming, the team can ask why mobile users are struggling.

Dimensions add context to metrics

Dimensions are useful when they help explain behaviour, not just when they are available.

For account registration, useful dimensions might include:

• entry point, because invited users may behave differently from self-serve users
• device type, because form completion may vary on mobile and desktop
• user type, because new and returning users may have different expectations
• workflow version, because recent changes may affect completion
• channel, because users arriving from different sources may have different intent

These dimensions help the team compare behaviour in ways that support investigation or decisions.

They should be chosen because they help interpret the metric.

Segments should be meaningful

A segment should represent a group the team can understand and potentially act on.

For example, these segments may be useful:

• mobile users
• invited users
• users entering from checkout
• users on the new workflow version
• users applying through an organisation

These segments point to different contexts, behaviours, or product decisions.

Less useful segments are often too small, too arbitrary, or too disconnected from the product question. A segment should not be added only because the data exists.

A useful test is:

If this segment behaves differently, would we know what to investigate or do next?

If the answer is no, the segment may not be useful for this metric.

Dimensions are not separate metrics

A common mistake is to create separate metrics for every context.

For example:

Mobile registration completion rate
Desktop registration completion rate
Invited user registration completion rate
Self-serve registration completion rate

These may be useful views, but they do not need to become separate metric definitions.

A cleaner approach is:

Metric:
Registration completion rate

Dimensions:
device_type
entry_point
user_type
workflow_version

The metric stays stable. The dimensions provide different ways to interpret it.

This keeps the measurement system easier to maintain.

Properties enable dimensions

Many useful dimensions come from event properties.

For example:

Event:
registration.form_submitted

Properties:
entry_point
device_type
user_type
workflow_version

The event records what happened. The properties provide context. Those properties can then be used as dimensions when analysing metrics.

If useful properties are missing, the team may still have the event, but lose the ability to compare behaviour in meaningful ways.

That is why dimensions should be considered during event and instrumentation design, not only when building dashboards.

Dimensions can reveal different problems

The same headline metric can hide different issues.

For example, if registration completion falls, a dimension may show that the issue is concentrated among:

• mobile users
• users entering from an email invitation
• users on the latest workflow version
• users from a particular organisation type
• users encountering a specific form error

Each pattern suggests a different investigation.

The dimension does not explain the cause by itself. It helps the team decide where to look.

Keep dimensions focused

Too many dimensions can make measurement harder to use.

A dashboard that breaks every metric down by every possible property may create noise rather than clarity.

Use dimensions that help the team:

• compare meaningful groups
• diagnose a problem
• evaluate a product change
• understand different user contexts
• identify where action may be needed

Avoid dimensions that are rarely used, poorly defined, unreliable, or too granular to support decisions.

Common mistakes

Common mistakes include:

• reporting only overall metrics
• creating too many separate metrics instead of using dimensions
• adding dimensions because data is available, not because they help interpretation
• using segments that are too small to be meaningful
• ignoring whether properties are captured reliably
• comparing groups without understanding differences in intent or context
• treating a segment difference as an explanation rather than a signal to investigate

Dimensions and segments should improve interpretation, not make measurement harder to understand.

How to apply this

When defining a metric, ask:

• which groups or contexts might behave differently?
• which dimensions would help us interpret the metric?
• which event properties are needed to support those dimensions?
• are the segments meaningful enough to compare?
• would a difference between segments change what we investigate or decide?
• are the dimensions reliable and consistently captured?

Start with a small set of useful dimensions. Add more only when they improve understanding.

Related articles

• Event catalogue template
• Building a metric tree
• Designing dashboards around decisions

Key takeaway

Dimensions and segments add context to metrics.

They help teams move beyond overall numbers and understand where behaviour differs, which groups are affected, and what the team may need to investigate next.