Practice 02.03 · Retention

Analyze retention by cohort

An overall retention rate mixes unlike users and rarely explains what to fix. Split people into comparable groups and find one difference tied to a specific experience.

Practice outcomeOne cohort table, a meaningful difference between groups, a likely cause, and a change to validate in the next period.

90 minutes for the first report

In plain language

A cohort is a group that started the journey together

Think of classes in the same school year: a group started using the app in the same week, so it can be compared with the neighboring week. Then, inside the group, you test one difference — platform, country, or the first useful action.

What you will need

ReportAppMetrica, Firebase, Amplitude, or a spreadsheet with each user's first-launch date and later visits.

DefinitionsOne shared meaning of install, registration, visit, first useful action, and FTD for the whole team.

PeriodAt least 4–6 full weeks, so the D7 comparison does not include days that have not happened yet.

Terms in plain language

When to use it

The team sees average retention but cannot tell which group changed, after which release, and which user experience it is tied to.

In plain language

How to build the first report

Start with first-launch weeks and one breakdown. The more segments you add at once, the easier it is to find a random difference with no clear action behind it.

Retention report

Build weekly cohorts by first launch and show D1, D7, and D30 only for completed periods.

In a spreadsheet, keep the first-launch date and later active days; count whether each user returned after 1, 7, and 30 days.

First useful action

Split one cohort into those who reached the first useful outcome in their first session and those who did not.

If there is no event, use the closest confirmed result: an item saved, a lesson finished, or successful verification.

Change history

Put app versions, major releases, and campaigns next to the table — they may explain differences between weeks.

If no changelog exists, rebuild the calendar from store releases and the launch dates of major communications.

Build a useful cohort comparison

Fix the start and the return

Choose one start event — usually first launch or registration — and one definition of an active day. Do not change definitions between groups.

Where to do it: In the report description above the table.
What the result looks like: Cohort — the week of first launch; return — any useful action, not a technical background open.

Take only full weeks

Compare only groups whose target day has already passed. You cannot evaluate D30 for users who arrived ten days ago.

Where to do it: In the report's period filter.
What the result looks like: For D7, take cohorts that completed at least eight days ago.

Add one breakdown

Pick platform, version, country, or the first useful action. A single breakdown ties the difference to a specific experience.

Where to do it: In the rows or the filter of the cohort table.
What the result looks like: Compare Android 4.2 with iOS for the same week — not platform × country × source × campaign all at once.

Find a stable difference

Check the group size and the neighboring weeks. A small gap of 20 users must not become a big product conclusion.

Where to do it: In the size, D1, and D7 columns.
What the result looks like: D7 for Android 4.2 is 8 percentage points lower three weeks in a row, with more than 500 users per group.

Tie the conclusion to a check

Write down the likely cause, an owner, and one change or investigation. A report without a next action does not help the product.

Where to do it: In the last column and the team's task.
What the result looks like: Review the new Android 4.2 onboarding screen; owner — the mobile team; due next week.

Practical examples

The drop sits in Android 4.2, not everywhere

D7 is 8 percentage points lower three weeks in a row, with more than 500 users per group; iOS for the same weeks is stable. The decision: review the onboarding changes in 4.2 rather than message everyone.

The first useful outcome explains the gap

Users who got a useful result in their first session show a D7 of 28%; the rest — 5%. The team makes the path to the result more visible and checks the next weekly cohort.

The finished artifact

One table — one conclusion

Compare four groups on one attribute first. Do not turn the first report into dozens of filters.

Cohort / segment	Size	D1	D7	Conclusion and action
Week of June 3–9 · all	2,400	32%	14%	Baseline
Reached the first useful outcome	1,080	51%	28%	Make the path more visible
Did not reach the value	1,320	17%	5%	Check onboarding
Android · version 4.2	620	24%	8%	Check release 4.2
iOS · same week	710	35%	16%	No platform-wide drop

Conclusion: the problem is concentrated in Android 4.2 and among users without the first useful outcome. The first action is to check that version's onboarding changes — not to send a blast to everyone.

Report checklist

Before drawing a conclusion, make sure you compare comparable groups and completed periods.

The cohort start and the active day are defined the same way for every row. D1, D7, and D30 are calculated only for completed periods. Every group has a size, and only one main breakdown is used. App versions, releases, and major campaigns are noted alongside. The conclusion ends with one action, an owner, and a check date.

How to know the analysis is useful

Segment clarity

The team can name the specific group and the difference, not just the overall retention rate.

Repeatability

The difference shows on a sufficient size and does not vanish when checking neighboring weeks.

Decision

One action is taken, and the next cohort will show whether the chosen journey changed.

Do not look for the average user: find a specific group, a clear barrier, and one decision the next cohort can test.