# Analyze retention by cohort

- **Canonical URL:** https://playbook.affpartners.io/en/practices/retention-cohorts/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/retention-cohorts/index.md
- **Module:** Retention
- **Time:** 90 minutes for the first report

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.

## Outcome

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

## 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

- **Report:** AppMetrica, Firebase, Amplitude, or a spreadsheet with each user's first-launch date and later visits.
- **Definitions:** One shared meaning of install, registration, visit, first useful action, and FTD for the whole team.
- **Period:** At least 4–6 full weeks, so the D7 comparison does not include days that have not happened yet.

## Terms in plain language

- **Retention — The share of users who return:** Definition: Shows how many people reopen the app after a set period from installation or registration. Example: If 18 of 100 new users return after seven days, D7 retention is 18%.
- **D1 / D7 / D30 — Return after 1, 7, or 30 days:** Definition: D means day. The metric shows what share of a new user group returned after the selected number of days. Example: D7 = 18% means 18 of every 100 new users returned after seven days.
- **Cohort — Users sharing a date or characteristic:** Definition: Cohorts compare similar users without mixing different periods, versions, or markets. Example: Users who installed the app during the same week form a weekly cohort.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **FTD — A user's first deposit:** Definition: The first time a registered user funds their account. It is the outcome of the whole journey, not a single button to promote more aggressively. Example: If 100 people complete registration and 24 make a first deposit, FTD conversion is 24%.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

## 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.

## 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**
  - **Source:** Build weekly cohorts by first launch and show D1, D7, and D30 only for completed periods.
  - **If access is unavailable:** 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**
  - **Source:** Split one cohort into those who reached the first useful outcome in their first session and those who did not.
  - **If access is unavailable:** If there is no event, use the closest confirmed result: an item saved, a lesson finished, or successful verification.
- **Change history**
  - **Source:** Put app versions, major releases, and campaigns next to the table — they may explain differences between weeks.
  - **If access is unavailable:** If no changelog exists, rebuild the calendar from store releases and the launch dates of major communications.

## Build a useful cohort comparison

1. **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.
   - **Example:** Cohort — the week of first launch; return — any useful action, not a technical background open.
2. **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.
   - **Example:** For D7, take cohorts that completed at least eight days ago.
3. **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.
   - **Example:** Compare Android 4.2 with iOS for the same week — not platform × country × source × campaign all at once.
4. **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.
   - **Example:** D7 for Android 4.2 is 8 percentage points lower three weeks in a row, with more than 500 users per group.
5. **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.
   - **Example:** 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.

## 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.

## Key rule

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

---

- [HTML version](https://playbook.affpartners.io/en/practices/retention-cohorts/index.html)
- [All practices](https://playbook.affpartners.io/en/)