Cohort analysis: reading the table down, across, and diagonally
Cohort analysis groups customers by when they arrived and tracks each group separately over time, so you can tell whether the business is improving or just getting bigger. A blended retention rate cannot answer that question. A cohort table can.
The table has three axes and most teams read one of them. The first two are covered everywhere. The third gets almost no coverage at all.
Across a row is one cohort ageing. Down a column is different cohorts at the same age. And running diagonally through the table is calendar time, which is where anything that hit the whole business at once shows up. That third reading is the one that finds outages, pricing changes and broken payment migrations, and it is almost never taught.
Table of contents
- What a cohort analysis table actually contains
- Reading across: one cohort ageing
- Reading down: is the product getting better
- Reading diagonally: the calendar
- Logo cohorts and revenue cohorts disagree, usefully
- The right edge of the triangle is not data
- Four kinds of cohort, and what each one answers
- Where cohort analysis breaks on real data
- Building one that survives scrutiny
- Frequently asked questions
What a cohort analysis table actually contains
A retention cohort table puts acquisition period on the vertical axis and age in periods on the horizontal, with each cell holding the share of that cohort still retained at that age. It is triangular because a cohort acquired last month cannot have a month six number yet.
Here is a monthly customer cohort table for a business reporting at the end of July.
| Cohort | M0 | M1 | M2 | M3 | M4 | M5 | M6 |
|---|---|---|---|---|---|---|---|
| Jan | 100% | 91% | 87% | 85% | 84% | 80% | 79% |
| Feb | 100% | 90% | 86% | 84% | 79% | 78% | |
| Mar | 100% | 89% | 85% | 80% | 79% | ||
| Apr | 100% | 90% | 84% | 83% | |||
| May | 100% | 85% | 84% | ||||
| Jun | 100% | 89% | |||||
| Jul | 100% |
Seven cohorts, one table, and three completely different stories depending on which direction you read it.
Reading across: one cohort ageing
Reading across a row shows a single cohort's retention curve, and the shape of that curve tells you where the business loses people.
The January row falls 9 points in month one, 4 in month two, 2 in month three, then flattens near 80%. That shape is normal and diagnostic. A steep early drop is an activation problem: people bought something they never got working. The flattening is the point at which the remaining customers have integrated the product into how they work, and they behave very differently from the ones who left in week two.
A curve that never flattens is the worse pattern. Steady 3% monthly attrition forever means there is no core of committed users, just a slowly draining tank. That distinction is invisible in a blended churn rate, which averages the cliff and the plateau into a single number describing neither.
Where the curve flattens also fixes the biggest error in
customer lifetime value calculation. The 1 / churn shortcut assumes one constant rate. The row shows you there are at least
two.
Reading down: is the product getting better
Reading down a column compares different cohorts at the same age, holding tenure constant, which is the only fair way to ask whether recent changes worked.
Take the M1 column: 91%, 90%, 89%, 90%, 85%, 89%. Five cohorts sit in a tight band and May is 5 points below all of them. Since every cell in that column represents a customer's first month, a drop there points at onboarding, activation or acquisition quality rather than at anything happening later in the lifecycle.
The column is also the only honest way to evaluate a change you shipped. If you rebuilt onboarding in April, the April, May and June M1 numbers are the experiment, and the January to March M1 numbers are the control. Comparing April's M1 to January's M4 compares two different questions and gets you a confident wrong answer.
One caution: columns are size-weighted if you average them. A cohort of 900 customers from a paid acquisition push and a cohort of 90 from organic search carry equal visual weight in a percentage table and very unequal weight in a blended average. Keep cohort counts next to the percentages.
Reading diagonally: the calendar
The anti-diagonal of a cohort table is calendar time, and it is where an event that hit every customer simultaneously becomes visible. Nothing else in the table can separate a cohort problem from a company problem.
Work through the June cells in the table above. January's M5 is June. February's M4 is June. March's M3, April's M2 and May's M1 are all June as well. Line them up:
| Cohort | Cell | Value | Drop from prior period |
|---|---|---|---|
| Jan | M5 | 80% | 4 points |
| Feb | M4 | 79% | 5 points |
| Mar | M3 | 80% | 5 points |
| Apr | M2 | 84% | 6 points |
| May | M1 | 85% | 15 points |
Every cohort took an outsized hit in the same calendar month, at five different ages. Read row by row, that looks like five separate cohorts each developing an independent problem. Read diagonally, it is one event in June.
That pattern has a short list of causes: a price change, a failed payment processor or card-updater migration, an outage, a plan or packaging change, a dunning configuration that silently stopped retrying. Each of those is recoverable, and none of them is a product retention problem, which is what the row-wise reading would have you go fix.
The diagonal is also the reason a cohort table alone is rarely enough. It tells you June, and it tells you the whole base was affected. It cannot tell you which of those five causes it was, because the answer to that lives in billing events and deploy logs rather than in the retention grid.
Logo cohorts and revenue cohorts disagree, usefully
Logo retention counts customers and revenue retention counts dollars, and the gap between the two curves for the same cohort is a segment mix signal rather than a discrepancy.
When revenue retention sits well above logo retention, the accounts you are losing are smaller than the ones you keep, and the survivors are expanding. That is usually a healthy business discovering its real market. When logo retention is the higher of the two, you are keeping lots of small accounts and losing the large ones, which is a much worse position and easy to miss if you only track customer counts.
Benchmarkit's 2025 B2B SaaS Performance Metrics Benchmarks, drawn from 225 companies in May 2025, recommends calculating retention on a cohort basis rather than as a blended rate, precisely because the blended version hides this. Their median gross revenue retention has drifted from 90% to 88% over three years while median net revenue retention held near 101%, a spread that only cohort tables explain. We cover that spread in net revenue retention.
Run both tables. They cost the same query and they answer different questions.
The right edge of the triangle is not data
The oldest columns of a cohort table contain the fewest cohorts, so a number sitting at month 24 is often the average of two or three groups rather than a stable estimate.
In the table above, M6 has exactly one cohort in it. Quoting "79% retention at six months" from that cell is quoting January, not the business. The cells carry wildly different confidence and the table renders them identically, which is a presentation problem that produces real forecasting errors.
There is a selection effect stacked on top. Your oldest cohorts came from your earliest product, your earliest pricing and usually your founders selling personally to people they knew. They are not representative of what you sell today, and extrapolating their month 24 retention onto last month's self-serve signups is optimistic by a wide margin.
Two habits fix most of this. Show cohort counts alongside percentages so a cell backed by 12 customers looks different from one backed by 1,200. And cut the table at the last column where you have at least four or five cohorts, rather than showing a long tail that narrows to a single row.
Four kinds of cohort, and what each one answers
Cohort analysis is a method rather than a single table, and the cohort key you pick determines which question the table can answer. Mixing keys into one grid is the fastest way to produce something uninterpretable.
| Cohort key | Groups by | Answers | Watch out for |
|---|---|---|---|
| Acquisition date | Month the customer first paid | Is the business getting better over time | Marketing spikes create huge low-intent cohorts that distort blended averages |
| Behavioural | Completing an action (setup, first invite, first integration) | Which actions predict retention | Selection bias: people who complete setup were already more committed |
| Plan or tier | Which package they bought | Where retention actually lives in the pricing | Plan migrations move customers between cohorts mid-life |
| Acquisition channel | Where they came from | Which channels buy customers worth having | Attribution quality caps the whole analysis |
Acquisition cohorts are the default and the one to build first. The others are comparisons layered on top, and each needs its own table rather than a column in the first one.
Behavioural cohorts deserve a specific warning. "Customers who invited a teammate retain 40 points better" is true in almost every product and almost never causal. The invite is a symptom of intent, not a cause of retention, and teams routinely burn a quarter building prompts to force the symptom. Run the comparison, then treat it as a hypothesis rather than a roadmap.
Where cohort analysis breaks on real data
Four things distort cohort tables built from live billing data, and all four produce artefacts that look like retention problems.
Annual contracts inside a monthly table. An annual subscription cannot churn in month seven. It renews or cancels at month 12, so it renders as a flat line followed by a cliff. Mix annual and monthly plans into one table and you manufacture a month 12 drop that is a billing artefact, not behaviour. Build separate tables per billing term.
Involuntary churn read as a decision. A customer whose card expired appears in the table identically to one who cancelled in anger. Recurly's churn benchmark research, updated July 2026, puts involuntary churn at 1.06% of the 3.22% median annual SaaS churn rate, so about a third of every cohort's decline is a payment failure. It also concentrates in low-price bands, at 1.30% for $10 to $25 ARPC against 0.18% above $250. Split it out or your retention curve is a third payments infrastructure.
Seasonality misaligned across rows. Month 11 of the January cohort is December. Month 11 of the June cohort is May. For B2B products with holiday usage troughs and budget-cycle cancellations, those two cells are not comparable, and a column that looks like decay is sometimes just a calendar.
Cohorts too small to mean anything. At 40 customers, one churn moves retention by 2.5 points. Cohort tables invite eye-based pattern matching, and at small N the eye finds trends in noise reliably. Below about 100 per cohort, group into quarters.
Building one that survives scrutiny
A defensible cohort analysis needs four decisions made explicitly before any query runs: the cohort key, the retention event, the period grain, and the segment split.
- Cohort key. Acquisition month is the default and the right starting point. Behavioural cohorts (customers who completed setup, customers who invited a teammate) answer different questions and should never be mixed into the same table as acquisition cohorts.
- Retention event. Active subscription, logged in, or performed a core action. Subscription status is the one that ties to revenue; usage is the one that predicts it. They are both worth having and they are not the same table.
- Period grain. Monthly for subscription businesses, weekly for consumer products with short cycles, quarterly once cohorts get small.
- Segment split. Billing term first, then plan, then acquisition channel. The blended table is a summary of tables you should have looked at individually.
Then keep them running. The value of a cohort table is almost entirely in comparison over time, and a table rebuilt by hand each quarter does not accumulate that.
Frequently asked questions
What is cohort analysis in SaaS?
Cohort analysis in SaaS groups customers by the period they subscribed and tracks each group's retention, revenue or usage separately over time, instead of blending everyone into one rate. It separates the effect of getting bigger from the effect of getting better, which a company-wide average cannot do.
What is the difference between cohort analysis and retention analysis?
Retention analysis measures how much of your base you keep over a period. Cohort analysis is the method that makes retention interpretable, by holding acquisition date constant so you compare like with like. Retention is the number, cohorts are how you avoid averaging four unrelated populations into it.
How many customers do you need for cohort analysis?
Roughly 100 per cohort before percentage movements mean anything. Below that, single churns move the rate by whole points and the table shows noise as structure. Small businesses should cohort by quarter rather than by month.
What is a good retention curve shape?
A steep initial drop that flattens into a stable plateau, with the plateau as high as possible. The flattening matters more than the starting slope: a curve settling at 80% describes a product people keep, while one declining steadily at 3% a month has no committed core no matter how gentle the first month looks.
Ready to find out what your June was?
A cohort table can tell you that every cohort dropped in the same calendar month. It cannot tell you whether that was the price change, the payment migration, the outage or the dunning rule that quietly stopped retrying, because none of those live in the retention grid.
GainSignal watches billing events, product usage and the operational changes around them together, then reports the change, when it started, which cohorts it touched, and the evidence behind it. Involuntary churn separated from voluntary. Annual and monthly terms kept apart. The diagonal read for you, rather than after the quarter closes.