# Cohort analysis: what it is, with a worked example cohort table

> What is cohort analysis? A worked cohort analysis example: build a cohort table, read cohort retention by rows, columns and diagonals, and average it right.

- Source: https://productovi.com/blog/cohort-analysis-example
- By: Sergey Bruh
- Published: 2026-09-30
- Topics: Cohort analysis

What is cohort analysis? **Cohort analysis groups users by when they started (the cohort) and tracks each group separately over time**, so you can tell whether the product is improving for new users, whether one event hit everyone, and whether a single number on a dashboard is telling the truth. This cohort analysis example takes six months of sign-ups for an app, puts them into a cohort table and reads it the way a product team should. Below: the table, three ways to read it, the correct way to average cohort retention, and the two traps that make an averaged curve lie.

## Cohort analysis example: six monthly cohorts

Halves is a made-up app for splitting shared bills between flatmates, couples and friends on trips. Each row below is a **cohort**: everyone who signed up in that month, staff accounts excluded. Each column is a month since sign-up, and each cell counts how many of the cohort opened the app at least once in that month. The data runs to the end of March 2026, so younger cohorts have fewer columns.

| Cohort   | Users | M1  | M2  | M3  | M4  | M5  | M6  |
| -------- | ----- | --- | --- | --- | --- | --- | --- |
| Sep 2025 | 900   | 405 | 324 | 288 | 270 | 222 | 252 |
| Oct 2025 | 1,000 | 450 | 360 | 320 | 255 | 290 |     |
| Nov 2025 | 3,000 | 750 | 510 | 357 | 390 |     |     |
| Dec 2025 | 1,100 | 506 | 337 | 352 |     |     |     |
| Jan 2026 | 1,200 | 479 | 432 |     |     |     |     |
| Feb 2026 | 1,000 | 480 |     |     |     |     |     |

A cell is a count. To get retention, divide it by the cohort's users: for September in month 1, $405 / 900 = 45.0\%$. The whole table as percentages:

| Cohort   | M1    | M2    | M3    | M4    | M5    | M6    |
| -------- | ----- | ----- | ----- | ----- | ----- | ----- |
| Sep 2025 | 45.0% | 36.0% | 32.0% | 30.0% | 24.7% | 28.0% |
| Oct 2025 | 45.0% | 36.0% | 32.0% | 25.5% | 29.0% |       |
| Nov 2025 | 25.0% | 17.0% | 11.9% | 13.0% |       |       |
| Dec 2025 | 46.0% | 30.6% | 32.0% |       |       |       |
| Jan 2026 | 39.9% | 36.0% |       |       |       |       |
| Feb 2026 | 48.0% |       |       |       |       |       |

This is monthly bracket retention: "active at least once in month k". Whether that is the right measure for your product depends on its usage rhythm, which is covered in [how to calculate retention rate](/blog/how-to-calculate-retention-rate).

## How to read a cohort table

A [cohort table](/glossary/pa-cohort-table) answers three different questions, depending on the direction you read it.

### Rows: one cohort's life

Read September from left to right: 45.0%, 36.0%, 32.0%, 30.0%, then a dip to 24.7% and back up to 28.0%. The early fall is normal: curious people try the app and leave. The slowing fall afterwards is the good news: the people still there are finding a reason to stay.

### Columns: cohorts at the same age

Read month 1 from top to bottom: 45.0, 45.0, 25.0, 46.0, 39.9, 48.0. This is where you ask "is the first month getting better for new users?" Two cells stand out. November is far below the rest, and January is lower than its neighbors. Before explaining them, look at the third direction.

### Diagonals: one calendar month

A diagonal runs from bottom-left to top-right and collects every cell that fell in the same calendar month. February 2026 is January's M1, December's M2, November's M3, October's M4 and September's M5: 39.9%, 30.6%, 11.9%, 25.5% and 24.7%. Every one of them is lower than you would expect from its own row, and every row recovers in March.

When all cohorts dip in the same calendar month, the cause is in that month, not in the cohorts. At Halves, a February release broke the reminder about unsettled balances; it was fixed in early March. So January's weak month 1 says nothing about January's sign-ups. It is the February bug, seen from the youngest cohort.

This is the most useful habit in cohort analysis: before you blame or praise a cohort, check its diagonal.

![Read a cohort table along a row for one cohort's life, down a column to compare cohorts at the same age, and along a diagonal to catch one calendar month, like the February 2026 dip](/blog/cohort-analysis-example/diagram.png)

## How to average cohort retention

Someone asks for "our month-1 retention". The quick answer is the average of the six month-1 percentages:

$$
\frac{45.0 + 45.0 + 25.0 + 46.0 + 39.9 + 48.0}{6} = 41.5\%
$$

That treats November's 3,000 users and September's 900 as equals. To describe everyone who signed up, add the active users and divide by all the users:

$$
\frac{405 + 450 + 750 + 506 + 479 + 480}{900 + 1{,}000 + 3{,}000 + 1{,}100 + 1{,}200 + 1{,}000} = \frac{3{,}070}{8{,}200} = 37.4\%
$$

The four-point gap is November. It is the biggest cohort by far and the weakest: a paid social campaign in November brought three times the usual sign-ups, many of them people who installed the app out of curiosity and never had a bill to split. Without November, the weighted month 1 is $2{,}320 / 5{,}200 = 44.6\%$.

All three numbers are arithmetically correct. The honest report gives the weighted 37.4%, adds 44.6% without the campaign cohort, and names the reason. The simple average of 41.5% answers a question nobody asked.

## The averaged curve that rises for no reason

Now build one "average retention curve" by taking the weighted average of every column:

| Month since sign-up | M1    | M2    | M3    | M4    | M5    | M6    |
| ------------------- | ----- | ----- | ----- | ----- | ----- | ----- |
| Cohorts included    | 6     | 5     | 4     | 3     | 2     | 1     |
| Weighted retention  | 37.4% | 27.3% | 22.0% | 18.7% | 27.0% | 28.0% |

Retention seems to jump from 18.7% in month 4 to 27.0% in month 5. Nobody came back. Month 4 still includes November; month 5 contains only September and October, which were stronger all along. Every column averages a **different set of cohorts**, so the curve mixes a change in people with a change in time.

The fix is to compare months on the same cohorts:

- Month 1 → month 2 on September to January (the five cohorts that have both): $2{,}590 / 7{,}200 = 36.0\%$ → $1{,}963 / 7{,}200 = 27.3\%$.
- Month 4 → month 5 on September and October: $525 / 1{,}900 = 27.6\%$ → $512 / 1{,}900 = 26.9\%$. A small decline, not a jump.

Or skip the averaged curve and plot each cohort's row as its own line. The eye catches a different shape faster than any average, and you still see the February dip on every line.

## Split cohorts by segment

Sign-up month is only one way to cut users. The same table by **segment** often tells a bigger story. At Halves, cohorts split by the type of a user's first group behave very differently. Among the summer 2025 sign-ups, couples keep 52.7% a year after sign-up and stay flat from month 6, while trip groups fall to 5.6% by month 5 and climb back to 21.8% in month 12, mostly in new groups for the next trip.

A trip group ending when the trip ends is not [user churn](/glossary/pa-user-churn): the group's lifetime is over, the user's is not. Blend the segments into one curve and you get a line that describes nobody. Read each segment in its own rhythm, which is the whole of the [retention by segment case](/courses/product-analytics/retention-by-segment/theory).

## Cohorts beyond retention

The same table works for any metric you can track by cohort age:

- **Revenue:** cumulative gross profit per user by cohort is an LTV curve. It tells you what a new user is worth after 3, 6 or 12 months, which is what you compare with acquisition cost in the [LTV to CAC ratio](/blog/ltv-cac-ratio).
- **Conversion to paid:** the share of each cohort that has subscribed by month k.
- **Engagement:** average expenses per active user by month since sign-up.

In every case the rules above hold: weight by cohort size, check diagonals, and compare months on the same cohorts.

## How to build a cohort table

1. **Pick the cohort key:** sign-up date is the default; first purchase or first group are alternatives.
2. **Pick the period:** days, weeks or months, matching how often a healthy user comes back.
3. **Define the qualifying action:** "opened the app", not "any event", if the server creates events on its own.
4. **Exclude** staff, test and bot accounts.
5. **Count** distinct users per cohort and period since the start, and leave cells empty when that period hasn't finished yet.
6. **Divide** by cohort size, and keep the counts next to the percentages so anyone can re-weight them.

That is all a cohort table needs; any tool that can group by two columns will build it. For how cohort analysis fits the rest of the discipline, see [what is product analytics](/blog/what-is-product-analytics).

## Key takeaways

- Cohort analysis tracks groups of users who started at the same time, so changes in the product aren't hidden by changes in who is using it.
- Rows show a cohort's life, columns compare cohorts at the same age, diagonals show calendar events.
- Check the diagonal before judging a cohort: here January looked weak because of a February bug.
- Average a column by weighting with cohort size (37.4%, not 41.5%) and name outlier cohorts.
- An averaged curve built from columns with different cohorts can rise for no reason; compare months on the same cohorts.

## FAQ

### What is cohort analysis?

A way to measure behavior by groups of users who started at the same time, usually the same sign-up week or month. Instead of one retention number for everyone, you see each cohort's retention over time, side by side, so a better onboarding or a broken release shows up in the cohorts it actually affected.

### What is an example of cohort analysis?

Group users by sign-up month, count how many from each month are active one, two, three months later, and put the results in a table. Comparing the rows shows whether newer users stay better than older ones.

### How do you read a cohort table?

Across a row for one cohort's retention over time, down a column to compare cohorts at the same age, and along a diagonal to see everything that happened in one calendar month.

### Should I average cohort retention with a simple or a weighted average?

Weighted by cohort size when you want to describe all users: sum of active users divided by sum of cohort sizes. A simple average is fine only for comparing cohorts as units, and it should say so.

### How many cohorts do I need?

Enough to see a pattern that survives noise. With about 1,000 users per cohort, month-1 retention moves by roughly ±3 points by chance alone, so a difference of one or two points between two cohorts means little.

## Learn it hands-on

The free lesson [Reading a cohort table](/courses/product-analytics/cohort-table/theory) gives you a Halves cohort table to average, correct and report to the board, with quizzes and a written task checked by AI. Then try the [LTV curve](/courses/product-analytics/ltv-curve/theory) lesson, where the same cohort logic is applied to revenue. Both are part of the free course [Product Analytics: From Data to Decisions](/courses/product-analytics).

## Related lessons

- [Reading a cohort table](https://productovi.com/courses/product-analytics/cohort-table.md)
- [Case: retention analysis by segment](https://productovi.com/courses/product-analytics/retention-by-segment.md)
- [The LTV curve](https://productovi.com/courses/product-analytics/ltv-curve.md)