# Cohort retention projection

> Model a 12-month retention scenario from three assumptions. Build a raw event cohort table before treating it as measured performance.

- Type: Tool: Model assumptions, then measure
- Tags: Metrics, Retention
- Growth levers: Retention (primary), also Activation
- ~836 words

---

**Illustrative cohort retention projection.**

A cohort table is a measurement. This widget is a planning scenario. It takes a cohort size, an assumed Month 1 retention rate, and a later-month multiplier, then shows the result those assumptions imply through Month 12. It receives no user IDs or event timestamps, so the output is not your observed retention.

Use it to make the question explicit: if 60% of a 1,000-user group returns in Month 1 and each later month keeps 95% of the previous month, what would that look like? Then build a cohort table to learn whether your product behaves that way.

## What the projection calculates

> **Formula:** Month 0 = 100%. Month 1 = assumed Month 1 retention, M. Each later month t = M × r^(t - 1), where r is the later-month multiplier. Displayed users = round(cohort size × retention fraction).

The default scenario is illustrative, not a benchmark or forecast: 1,000 users, 60% at Month 1, and a 95% later-month multiplier. Month 6 is 0.60 × 0.95^5 = 0.464268..., which displays as 46% and 464 users. Month 12 is 0.60 × 0.95^11 = 0.341281..., which displays as 34% and 341 users. The widget uses full precision before rounding the displayed percentage and user count.

| Month | Illustrative retention | Rounded users |
| --- | --- | --- |
| 0 | 100% | 1,000 |
| 1 | 60% | 600 |
| 6 | 46% | 464 |
| 12 | 34% | 341 |
*Default scenario values. They are arithmetic from the three inputs, not reported performance data.*

> **Important boundary:** At any multiplier below 100%, this model keeps declining toward zero. A 95% later-month multiplier is not a 95% floor, a stable core, a forecast, or a benchmark.

## A raw cohort table asks different questions

A real cohort starts with an event definition. [Google Analytics cohort exploration](https://support.google.com/analytics/answer/9670133?hl=en-NA) asks for an inclusion criterion and a return criterion, then applies daily, weekly, or monthly granularity. Other definition choices matter too. [Amplitude documents](https://www.amplitude.com/docs/analytics/charts/retention-analysis/retention-analysis-time) that rolling 24-hour and strict calendar windows can give different results, and that exact-period return is different from return on or after. Choose the rule before you compare the number.

| Question | Illustrative projection | Raw event cohort table |
| --- | --- | --- |
| What it consumes | Cohort size, Month 1 assumption, later-month multiplier | Stable identity, inclusion event, return event, timestamps, and a chosen time rule |
| What it computes | A constant post-Month-1 multiplier through Month 12 | Observed users or rate in each completed time bucket |
| Expected shape | It declines whenever the multiplier is below 100% | It may rise or fall under an exact-period rule |
| Best use | Make an assumption worth testing | Locate a measured difference and investigate it |
*The widget is a scenario model. A raw cohort table is the measurement surface.*

In an exact-period table, a person can miss Month 2 and return in Month 3. Actual period values do not have to follow the smooth downward shape above. Recent periods have a different problem: people have not had a full chance to return. [Amplitude marks incomplete periods](https://www.amplitude.com/docs/analytics/charts/retention-analysis/faq), and [Mixpanel describes incomplete buckets as still in flux](https://docs.mixpanel.com/docs/reports/retention). Do not compare them as final.

## Build the table before deciding what to fix

Write one definition and keep it fixed for every cohort you compare. Changing the return event, timezone, or time window midway makes a story, not a comparison.

1. **Inclusion event:** choose the moment a user enters the population you want to study. Signup is only one option.
2. **Value-bearing return event:** choose an action that signals the user received or pursued value. A generic open event can answer a different question.
3. **Stable identity:** use an account or user identifier that lets you recognise the same person or account across events.
4. **Cadence and timezone:** state whether each bucket is daily, weekly, or monthly, and where the calendar boundary sits.
5. **Retention rule:** record whether you count a return in the exact period, on a rolling window, or on or after a period.
6. **Completed windows:** flag or exclude buckets whose users have not yet had the full observation window.

For example, you might define a cohort as people who signed up, a return as people who completed their first project, and a period as a rolling 30-day window in one stated timezone. That definition is more useful than a smooth graph because it tells the team what to instrument, and it lets the next cohort be compared with the last one fairly.

## Read measured loss as a lead, not a verdict

If completed cohorts show a weaker early return period, inspect the path between inclusion and the value-bearing event. Only after that evidence exists should you calculate an [activation rate](https://www.productgrowth.blog/calculators/activation-rate) with the same population and period. If the gap appears after people first receive value, inspect the repeat-value journey instead. The sliders cannot tell you which explanation is true.

A newer cohort that looks stronger is a lead to investigate, not proof that a launch caused the change. Compare cohorts of the same age under the same definition, annotate shifts in channel mix and product exposure, then test the likely cause.

#### Is this a cohort analysis calculator?

It is a cohort retention projection tool, not an event-data cohort calculator. It starts at 100%, applies your Month 1 assumption, then applies the same later-month multiplier through Month 12. Use it to make assumptions visible. Use a raw event table to measure retention.

#### Can a measured cohort curve move upward?

Yes. Under an exact-period rule, a user can miss one period and return in a later one, so the measured rate can rise or fall. Incomplete right-edge buckets can move too. State the rule and compare only completed buckets before reading a change into the shape.

#### How many months should a cohort table cover?

The 12-month horizon here is a UI limit for the scenario, not a recommended measurement period. Choose a horizon that fits your product's return cycle, then wait until each bucket has completed before comparing it.

**Next job: Build the raw cohort table.** Choose one inclusion event and one value-bearing return event. Record the stable ID, timezone, cadence, retention rule, and completed-window policy before you inspect the curve. Write the cohort definition beside the table before you read the result.

---

All posts: https://www.productgrowth.blog/archive · Site: https://www.productgrowth.blog