Retention Analysis
Retention Analysis helps you understand how well you keep users engaged over time. It answers the question: "Of the users who did X on Day 0, what percentage came back and did Y on Day 1, Day 2, and so on?"
Using cohort-based analysis, you group users by when they first acted and then measure what share of them returns in each following period.
Two Modes
A switch at the top of the page selects how you want to look at retention:
- Standard - one analysis across all cohorts, with a curve, a cohort matrix, and derived insights.
- Compare segments - pick two or more saved segments and lay their retention side by side.
Common Use Cases
| Use Case | Cohort Entry Event | Return Event | What It Measures |
|---|---|---|---|
| Product Stickiness | Sign Up | Page View | Are users coming back after signing up? |
| Purchase Retention | Purchase | Purchase | Are customers buying again? |
| Feature Adoption | Feature X Used | Feature X Used | Is the feature sticky? Do users keep using it? |
| Onboarding Success | Signup Completed | Core Action | Do onboarded users engage with the product? |
| Content Engagement | First Article Read | Article Read | Do readers come back for more content? |
| App Engagement | App Install | App Open | Are users opening the app regularly? |
Accessing Retention Analysis
Navigate to Analytics → Retention from the sidebar.
The Config Bar
Both modes share the same set of controls at the top of the page.
Cohort entry event vs. Return event
These two events are the foundation of every retention analysis, and the difference matters:
- Cohort entry event - the action that defines when a user "starts". Users are grouped into cohorts by the day they first did this event (signup, first purchase, app install, and so on).
- Return event - the action that counts as coming back. For each following period, we check whether a user did this event.
The two can be the same (measuring repeat behaviour, like purchase → purchase) or different (measuring engagement after an entry point, like signup → session started).
Interval and Periods
| Setting | Options | Description |
|---|---|---|
| Interval | Daily, Weekly, Monthly | The size of each retention period. |
| Periods | 7, 14, 30 | How many periods to track. |
Choosing an interval:
- Daily - best for high-frequency products (social apps, games).
- Weekly - a good balance for most products.
- Monthly - best for low-frequency products (B2B, utilities).
When the interval changes by itself
The matrix has one row per interval and one column per period, so a long date range on a daily interval asks for an enormous grid: ten years of days against thirty periods is over a hundred thousand cells. Past what the report can return, it uses the next interval up - daily becomes weekly - and says so under the Interval control.
Nothing is lost when this happens, only the resolution of the starting date, and a ten-year chart of single days was never readable anyway. Shorten the range if you want the finer interval back.
Min cohort size
Sets the smallest cohort worth showing, with options 1, 10, 25, or 50 (default 10). Cohorts below this size are dropped from the matrix rows, from "Users analysed" and from the cohort count, and they are drawn dashed in compare mode.
It also sets which cohorts every figure is calculated from: the headline percentages, the curve, the All cohorts row and the insights all describe exactly the rows the matrix shows, so the row always adds up to the rows under it. Weighting still keeps a large cohort counting more than a small one. Set it to 1 to include every cohort.
Export CSV
Export the retention data as CSV for further analysis or reporting. The button is enabled once you have run an analysis.
Standard Mode
KPI Row
- Users analysed - total users across all included cohorts.
- Day 1 - retention at the first period.
- Day 7 - retention at period seven.
- Day N - retention at the final period you selected.
(Labels follow your interval - weeks or months instead of days.)
The Retention Curve
The curve shows retention over time as a size-weighted average of the cohorts in the matrix. Weighting matters: a plain average would let a 2-user cohort sitting at 100% count just as much as a 996-user cohort sitting under 1%, which would badly misrepresent reality. Weighting by cohort size means each cohort influences the curve in proportion to how many users it actually contains.
The curve starts at D0 = 100% by definition - on the entry day, every user in the cohort is present.
The Cohort Matrix
Below the curve, the matrix shows one row per cohort and one column per period:
- The D0 column is omitted. It is always 100% by definition, so it is left out to keep attention on the periods that vary.
- An "All cohorts" row is pinned at the top as a weighted reference line - the same size-weighted average as the curve - so you can read each cohort against the overall trend.
- Heat scale - cells are tinted by retention. Zero cells are neutral: rather than being tinted at the cold end of the scale, they show a muted en dash, with the exact value on hover. This keeps genuine zeros from reading as "just low".
- "not yet" cells - a cohort that has not lived long enough to reach a period shows a dashed not yet, never a zero or a dash. It is also left out of that period's headline number, so a young cohort cannot drag the figure down.
- Size bar - each cohort shows a bar for its size, and a warning icon appears on any cohort below your Min cohort size.
Two toggles adjust the matrix:
- Hide all-zero cohorts - removes rows that never returned.
- Show users - switches cells between absolute user counts and percentages.
Example Matrix (Weekly)
| Cohort | Week 1 | Week 2 | Week 3 | Week 4 |
|---|---|---|---|---|
| All cohorts | 49% | 35% | 30% | 26% |
| Jan 1-7 | 45% | 32% | 28% | 25% |
| Jan 8-14 | 48% | 35% | 30% | 27% |
| Jan 15-21 | 52% | 38% | 33% | not yet |
| Jan 22-28 | 50% | 36% | not yet | not yet |
Reading this:
- 45% of users from Jan 1-7 returned in Week 1, 32% in Week 2.
- The pinned "All cohorts" row gives the weighted benchmark to compare each cohort against.
- Newer cohorts have higher Week 1 rates, so retention appears to be improving.
What This Means
The What this means section turns the numbers into plain-language insights, typically covering:
- The day-1 (first period) retention rate.
- The habit-loop reading - whether the tail has flattened out, which is the signal that you have reached a core of habitual users who keep coming back.
- The best-performing cohort.
- How many cohorts were excluded for being below the minimum size.
Compare Segments Mode
Compare segments mode places different audiences next to each other. It takes the segments you already maintain - the same ones your campaigns and journeys target - so an audience is defined in exactly one place rather than copied into a second definition that then drifts.
- Switch to Compare segments.
- Choose your Cohort entry event and Return event.
- Add 2 to 10 saved segments in the search box. The picker queries your segments as you type instead of loading the whole list, so it works in a workspace with thousands of them.
- Run the comparison.
Each segment is analysed on its own: users are grouped into cohorts by the day they first did the entry event, exactly as in Standard mode, and the line you compare is that segment's size-weighted curve.
What you see:
- Per-segment KPI cards - the headline retention numbers for each selected segment.
- Comparison curve - each segment's retention overlaid on one chart. The lines are drawn with straight segments connecting each interval, because retention is only defined at the interval points, not in between. Any segment below the minimum size is drawn dashed with a warning, so small samples are visually flagged.
- Small-sample banner - an amber banner appears when one or more selected segments fall below the minimum size, reminding you to read those lines with caution.
- Key milestones table - retention at periods 1, 7 and 14 for each segment (labelled with your interval, so Week 1 / Week 7 / Week 14 on a weekly analysis), with the +/- point difference versus the first selected segment so you can see who retains better or worse and by how much.
When a segment is too large to analyse whole
Some segments are larger than the analysis can resolve in one pass - the cap is 50,000 members. Above it the comparison measures a random sample of the segment. The sample is deterministic and random, never "the first 50,000", which would skew the answer towards whichever members happen to sort first. And the page says so, rather than charting a subset as though it were the whole audience:
- the segment's line is tagged partial in the chart legend;
- its KPI card and its milestones row each carry "Segment too large to analyse whole - measured on a random 50,000 of 480,000 members" - both the number measured and the segment's true size;
- an amber banner above the cards names every segment this happened to.
Read a partial line as a random sample of that segment, not as the segment's retention. Narrowing the date range or tightening the segment usually brings it back under the cap.
To remove the cap for a segment you compare often, turn on Keep this segment ready for reports on the segment itself. Its membership is then stored ready to use, the comparison analyses the whole segment at any size, and the card says "Whole segment - members as of ..." instead of the partial tag. The trade is that membership is rebuilt nightly rather than recomputed at the moment you ask, which is why the card names the time it was built. See Creating Segments.
A segment the analysis could not run at all is a different case: its row reads failed to load and draws no line. A failure is never charted as 0%, because "we could not measure it" and "nobody came back" are not the same answer.
Use Cases for Segment Comparison
| Comparison | What It Reveals |
|---|---|
| Power Users vs Casual Users | How engagement level affects retention |
| iOS vs Android Users | Platform-specific retention patterns |
| Paid vs Free Users | Impact of monetization on retention |
| Campaign A vs Campaign B | Which acquisition channel has stickier users |
| Feature X Users vs Non-Users | Whether a feature improves retention |
Creating Segments for Comparison
Segments are created under Segments. A segment can be built on events performed, event frequency, user properties, time windows, purchase and product behaviour, campaign and journey membership, subscription state and more - and it can carry exclude groups, which no simpler rule set can express.
See Creating Segments for the full filter list.
Key Metrics Explained
Day 1 / Week 1 / Month 1 Retention
The most critical retention metric. Shows how many users return after their first period.
Benchmarks vary by industry:
- Consumer apps: 25-40% D1 retention is good
- B2B products: 60-80% W1 retention is typical
- Games: 30-40% D1, 15-20% D7 is healthy
Retention Curve Shape
- Steep early drop, then flat - normal. You lose casual users early but keep engaged ones. The flat tail is the habit loop.
- Continuous decline - a problem. Even engaged users are leaving.
- Flat from the start - unusual. Either a very sticky product or a data issue.
Best Practices
Choose Meaningful Events
Good cohort entry events: signup completed, first meaningful action, onboarding completed.
Good return events: a core product action (not just page views), something that signals real engagement, or the same event as entry when measuring repeat behaviour.
Respect the Minimum Cohort Size
Leave Min cohort size at 10 or higher unless you have a specific reason. Small cohorts read as noisy 100% values and mislead the averages.
Focus on Early Retention
Day 1 and Week 1 retention are the strongest predictors of long-term retention. If users do not return early, they rarely come back.
Segment Your Analysis
Use Compare segments mode to compare retention by acquisition channel, user type, or feature usage. See Creating Segments for how to define one.
Common Issues
Cohort Sizes Vary Too Much
Use the percentage view (turn off Show users) and rely on the size-weighted "All cohorts" row rather than eyeballing individual small cohorts.
Return Event Too Broad
If you use a generic event like page_view, retention can look artificially high. Use more meaningful engagement events.
Date Range Too Short
With monthly retention, you need at least 3-4 months of data for useful insights.
Related
- Creating Segments - Define the audiences you compare
- Funnel Analysis - Track conversion flows
- Event Explorer - Find events for analysis