Retention & Churn
Standard retention metrics, such as D1, D7 and D30 return rates, tell you that users leave. They do not explain why or where. Complex professional software requires more informative measures. People may stop because they cannot learn it or accomplish their work. They may also finish a project, change roles, lose access or move to another tool. Non-return does not identify the reason.
The metrics in this section — together with Engagement Trend Analysis from Understanding Your Users — each examine a different aspect of churn. Used together, they provide several views of recorded behaviour. The figures, windows and classifications below are proposed examples, not validated benchmarks. They still require investigation with users:
- Engagement Trend Analysis (Understanding Your Users) — early warning that a user's activity is declining, before they churn
- Session Milestone Funnel — where in the lifecycle people give up (which milestone has the steepest drop-off)
- First Session Quality — what predicts churn from the very first interaction (retained vs. churned first-session behaviours)
- Churner Segmentation — which patterns precede non-return; explanations require follow-up
- Cohort Retention Curves — whether return rates differ before and after a change; causation requires further checks
- New User Onboarding Journeys — how individual trajectories diverge during the critical first six weeks
Session Milestone Funnel
Helps detect: Conceptual Burden (the milestone with the steepest drop-off often corresponds to a concept barrier in your learning curve). Cross-reference the drop-off with relevant tasks and observations to investigate a possible barrier.
What It Measures
The percentage of users who reach increasing session milestones: 1, 2, 3, 5, 10, 25, 50, 100. The drop-off between each milestone shows the recorded session counts reached; it does not establish when or why people gave up.
Why It Matters
This is the most direct measure of whether users continue using the software. Unlike time-based retention (D7, D30), session milestones measure recorded returns, not commitment to learning. Sessions may be required by work or divided by application behaviour. Example transitions to investigate are:
- Session 1→2: Did they come back at all?
- Sessions 3→5: Why did they continue or stop?
- Sessions 10→25: What could they accomplish independently?
- Sessions 25→50: Did their work require continued use?
How to Implement
Track cumulative session count per user. Report the percentage who reach each milestone:
Calculate the drop-off rate between each pair of adjacent milestones. The steepest drop identifies where you have the greatest scope to improve retention.
What to Watch For
| Biggest Drop At | Likely Problem | Investigation Focus |
|---|---|---|
| 1→2 | First experience fails to hook | Onboarding, first-run experience, "time to first meaningful output" |
| 3→5 | Initial friction too high | Early learning curve, concept barrier |
| 10→25 | Learning wall after initial enthusiasm | Intermediate learning curve, feature discovery gap |
| 25→50 | Insufficient depth for sustained use | Advanced feature accessibility, professional workflow support |
First Session Quality
Helps detect: Visibility (did first-session users discover enough features to see the software's value?), Closeness of Mapping (did the software match their mental model quickly enough for them to produce a meaningful first output?).
What It Measures
Compare first-session metrics between users who were retained (returned for 5+ sessions) and users who churned (never returned or returned only once or twice). Differences can suggest associations with later return. Validate any proposed prediction on separate data and check the reasons with users.
Why It Matters
The first session can be consequential. Users do not need to accomplish everything immediately, but they do need to feel the software is worth learning. It must convey both capability ("this tool can do what I need") and accessibility ("I can figure this out").
How to Implement
Split all users into two groups based on their retention outcome. Compare their first sessions across multiple dimensions:
| Metric | Retained Users | Churned Users | Interpretation |
|---|---|---|---|
| Session duration | Longer (e.g., 25 min) | Shorter (e.g., 8 min) | Short use may reflect difficulty or a short task |
| Features explored | More (e.g., 8 types) | Fewer (e.g., 3 types) | Check whether these users needed more features |
| Project complexity | Higher | Lower | Size does not establish a meaningful output |
| Errors encountered | Similar or fewer | Similar or more | Error experience may not differ, but recovery matters |
One candidate signal to investigate is whether the user produces a meaningful first output — something they can look at and think "this tool helped me create that." Track whether first-session users complete a project, render a result, or produce an export. If churned users rarely reach this point, investigate whether the first-run experience helps them reach a useful result.
What to Watch For
-
Very short churned sessions (under 10 min): Check whether they finished a short task, were interrupted, lost access or encountered an early obstacle.
-
Long but unproductive churned sessions (30+ min): If observation confirms an unmet goal, investigate learning, performance and recovery. Duration and feature use alone do not establish that nothing was accomplished.
-
Similar metrics across both groups: If retained and churned users look identical in their first session, the measured events may not distinguish the experiences. Investigate unmeasured difficulties as well as professional need, organisational changes and other external factors.
Churner Segmentation
The segments below suggest questions about Visibility, Closeness of Mapping and Conceptual Burden. Behavioural labels do not establish a motive or a design failure.
What It Measures
Categorise users who stopped using the software by their behaviour pattern before leaving. Churn encompasses several problems with different causes and different solutions.
Why It Matters
Treating all churned users the same leads to unfocused interventions. A user who bounced after two minutes has a completely different problem from someone who used the software productively for three months and then stopped. Segmenting by behaviour pattern lets you direct resources towards the largest segment and the problem most amenable to improvement.
How to Implement
Define descriptive non-return segments first. The labels below are shorthand for hypotheses; confirm “Struggled”, “Lost Interest” and “Project Completed” through follow-up rather than inferring them from counts. Adapt the example criteria to project cadence:
| Segment | Criteria | Possible Explanation to Check | Design Response |
|---|---|---|---|
| Bounced | 1 session, under 10 minutes | First impression failed. Software didn't match expectations, or the barrier to getting started was too high. | Improve first-run experience, reduce time-to-first-output, check positioning/marketing alignment. |
| Struggled | 2–3 sessions, low feature use (< 5 feature types) | Tried to learn but couldn't get traction. Hit the concept barrier too hard. | Improve onboarding, reduce early learning curve, add guided tutorials for core workflows. |
| Lost Interest | 4+ sessions then stopped, moderate feature use | Got started but didn't find enough value or depth. May have completed their immediate need without finding reason to return. | Improve feature discovery, progressive depth revelation, "what's next" suggestions. |
| Project Completed | Completed output confirmed by the user before leaving | Accomplished their goal and moved on. May return for the next project. | Possibly not a problem — track return rate. If many return months later, this is healthy project-based usage. |
What to Watch For
The relative size of each segment tells you where to focus:
-
Bounced dominates: Investigate the early experience, short tasks and external reasons for non-return.
-
Struggled dominates: Check whether these users had an unmet goal and a learning barrier.
-
Lost Interest dominates: The software may lack depth, or the features users need aren't discoverable. Cross-reference with Feature Adoption data to find the gap.
-
Project Completed dominates: Often healthy — especially for tools used on a project basis rather than daily. Track whether these users return for subsequent projects.
Track segment sizes over time. After design interventions, the target segment should shrink. Check task mix, eligible population and the reasons for non-return before attributing a change in segment size to the intervention.
Cohort Retention Curves
Can help evaluate UH-driven interventions over time, alongside task outcomes and qualitative evidence. If you redesigned a feature to reduce Conceptual Burden, cohort retention curves show whether users who joined after the change retain at higher rates than those who joined before.
What It Measures
D1, D7, D14, and D30 return rates tracked per weekly signup cohort, visualised as overlapping retention curves. Unlike aggregate retention rates (which blend users from different periods), cohort curves isolate each group of new users to show whether retention is improving or worsening over time.
Why It Matters
Aggregate retention metrics mask trends. If your D30 retention is 25%, you don't know whether it was 20% three months ago and climbing, or 30% three months ago and sliding. Cohort curves make these trends visible by showing each weekly group separately. Use return rates alongside successful work, quality and control; their importance depends on the product's use pattern.
How to Implement
Group users by the week they first used the software. For each cohort, calculate the percentage who return at key intervals:
| Cohort Week | Users | D1 | D7 | D14 | D30 |
|---|---|---|---|---|---|
| Mar 3 | 42 | 48% | 31% | 24% | 19% |
| Mar 10 | 38 | 52% | 35% | 28% | 22% |
| Mar 17 | 45 | 55% | 38% | 30% | — |
| Mar 24 | 51 | 58% | 40% | — | — |
In practice, allowing a one-day window around each interval (e.g., D7 = return on day 6, 7, or 8) produces more stable curves without losing signal. Report cohort sizes and uncertainty. Five users is not an established minimum that makes a curve reliable; small cohorts may need aggregation or a different observation period.
Plot overlapping line charts, with one line per cohort. The trend across lines shows whether your product is retaining users more successfully.
What to Watch For
-
Improving curves over time: Each new cohort line sits higher than the previous — return rates are improving; check attribution against acquisition, seasonality, work demand and other changes.
-
Sudden drop in a specific cohort: A bad release or external event. Identify what changed that week.
-
Flat D1 but good D30: The software doesn't demand daily use, but users return when needed — typical of project-based professional tools. This is healthy, not a problem.
-
Strong D1 but steep D7 drop: Users come back the next day out of curiosity but don't sustain engagement through the first week. Investigate learning barriers as well as completed work and external changes.
New User Onboarding Journeys
Can suggest questions about Conceptual Burden and Premature Commitment. A trajectory of feature use does not reveal how difficult a concept feels or whether a familiar method is limiting the task.
What It Measures
The progression pattern of individual new users over their first six weeks, classified into journey archetypes based on how their sophistication, session frequency, and feature adoption evolve. Rather than treating all new users as one group, this metric recognises that users follow fundamentally different trajectories.
Why It Matters
Aggregate onboarding metrics describe an average that need not represent any individual user. A "Slow Starter" who begins to progress in week four is invisible in D7 retention but still warrants design attention. A "Fast Learner" who churns anyway reveals something different entirely — possibly insufficient depth rather than insufficient accessibility. Journey classification allows you to design for each trajectory rather than an average that obscures their differences.
Kujala et al.'s (2011) UX Curve research showed that user experience trajectories are highly individual1 — some users' satisfaction improves steadily, others peak and decline, others start low and recover. This motivates asking about individual trajectories; it does not validate these telemetry-based skill classifications.
How to Implement
For each new user, track weekly metrics across their first six weeks:
| Week | Sessions | Sophistication | Features Used | Productive Sessions |
|---|---|---|---|---|
| 1 | 3 | 6 | 4 | 0 |
| 2 | 4 | 9 | 6 | 1 |
| 3 | 5 | 14 | 8 | 2 |
| 4 | 4 | 18 | 9 | 3 |
| 5 | 3 | 20 | 10 | 2 |
| 6 | 4 | 22 | 10 | 3 |
Classify into archetypes based on trajectory shape:
| Archetype | Pattern | Illustrative Proportion |
|---|---|---|
| Fast Learner | Sophistication score doubles within three weeks, high feature discovery rate | 15–20% |
| Steady Grower | Gradual, consistent increase in sophistication and features | 25–30% |
| Slow Starter | Flat or minimal growth for 3+ weeks, then may accelerate | 15–20% |
| Bouncer | One active week only, never develops beyond initial session | 30–35% |
The archetypes and proportions are illustrative. “Fast Learner” here means rapidly increasing recorded use, not demonstrated learning. Validate the relationship with task performance before using these labels to describe people.
What to Watch For
-
Large Bouncer segment (>40%): The first-experience problem dominates. These users never got far enough to evaluate the software properly. Focus on reducing time-to-first-meaningful-output.
-
Slow Starters who never accelerate: If scores remain stable, check whether users need a broader repertoire and whether they can achieve their goals. If some eventually accelerate, investigate what triggered their breakthrough — that trigger should be made more visible and accessible.
-
Fast Learners who churn: If users who learn quickly still leave, the product may lack sufficient depth, or they completed a specific project and moved on. Cross-reference with Project Complexity to distinguish these cases.
-
Archetype distribution shifts after design changes: After improving onboarding, the Bouncer segment should shrink and Steady Growers should expand. If Bouncers shrink but Slow Starters grow, investigate whether the difficulty moved, whether tasks changed or whether the classification itself is misleading.
Session Continuity
Helps detect: Premature Commitment (users forced to start over rather than resume), Provisionality (can users save provisional states and return to them?), Visibility (can users see where they left off and what state their work is in?).
What It Measures
Whether users resume previous work across sessions or start fresh each time. Key metrics: project reopen rate, time gaps between sessions on the same project, first action after opening (resume vs. create new), and usage of workspace state features (saved layouts, bookmarks, recent files, project files).
Why It Matters
Complex professional work is inherently interrupted and resumed. Barbara Mirel's (2004) research documents that problem solvers routinely "mark their places" — capturing views, jotting notes, bookmarking positions — so they can pick up after interruptions.2 Software that doesn't support this forces users to reconstruct context from scratch, which is cognitively expensive and wastes the orientation they built up in prior sessions.
Session continuity is a proxy for whether your software supports the natural rhythm of professional work. Users of complex tools rarely complete a project in a single session. If most sessions start fresh rather than resuming prior work, either the tool doesn't support resumption well, or projects are so simple they don't span sessions — and either explanation needs checking.
Mirel specifically notes (Ch 7) that users need support for "what did I see before interruptions and what did it mean?"2 — software that cannot answer this question forces users to spend the opening minutes of each session reorienting rather than working.
How to Implement
Track several signals per session:
1. Project Reopen Rate
- What percentage of sessions open an existing project vs. start with a blank canvas?
- Segment by user maturity — compare users doing similar sustained work, rather than assuming veterans must reopen more projects.
2. Time Between Sessions on the Same Project
- For users who do reopen projects, how long was the gap?
- Short gaps (hours to one day) suggest active work. Long gaps (weeks) suggest the user set the project aside and returned — these are the sessions where context reconstruction is most costly.
3. First Action After Open
- Track the first meaningful action when a user reopens an existing project: do they immediately begin modifying existing work (resumption) or create a new element (possibly reorienting)?
- A high rate of "navigate/browse first" actions after reopening suggests users need to reorient before they can resume — investigate missing context alongside deliberate review and changed requirements.
4. Workspace State Feature Usage
- Track usage of features that support resumption: saved workspace layouts, bookmarks, recent file lists, project notes, undo history persistence, viewport state restoration.
- Low usage may indicate these features are too hidden, too limited, or non-existent.
These ranges are example investigation triggers, not established healthy or concerning benchmarks.
| Metric | Example Pattern | Alternative to Investigate |
|---|---|---|
| Project reopen rate | 60%+ of veteran sessions | Below 30% for veterans |
| First action after reopen | Immediate modification | Extended browsing/navigation |
| Time to first productive action (reopened projects) | Under 2 minutes | Over 5 minutes |
| Workspace state feature usage | Increases with maturity | Flat or absent across maturity |
What to Watch For
- Low project reopen rates across all maturity levels: The tool may not support sustained, multi-session work well. Check whether project save/open is buried, whether project files preserve enough state, or whether users are using the tool only for quick single-session tasks.
- Long gaps followed by short sessions: Users who return to a project after days or weeks but then leave quickly (under 10 minutes) may have encountered a resumption problem or completed a brief check. Ask what they intended to do and what prevented it.
- New-project-only pattern in users who churn: Users who never reopen a project and eventually churn may be completing simple tasks without finding reason to build sustained work — or they may be hitting the resumption barrier and choosing to start fresh each time until they give up entirely.
- Veterans with low resumption rates: If even experienced users start fresh frequently, check project cadence and reuse practices before attributing this to state management. Cross-reference with Wayfinding aspirational analytics — high reorientation time after reopening is a wayfinding problem specific to resumption.
Tool Identity and Loyalty
Widens the frame beyond any single dimension: touches Role Expressiveness (does the tool's vocabulary match how an expert already thinks of the work?) and Conceptual Burden (scaffolding that eases the burden for a novice is the same scaffolding an expert experiences as a ceiling).
Usage metrics can reveal stalled progress or unsuccessful sessions. They say less about a practitioner’s attachment to a tool, or the freedom they expect from it.
The tension between helpful scaffolding and unwanted prescription connects to Design Principles for Creative Tools and Extensibility. For retention research, it is a reason to ask experienced users whether the tool still accommodates the way they wish to work, even when sessions and completed projects suggest that everything is going well.
Periodic qualitative discussions and regular attention to community forums can help explain continued use or a decision to switch. A dashboard can identify changes in behaviour; understanding their reasons requires provision to hear from the people behind them.