Home / Read a table

How to read a cohort retention table

Six patterns you will meet in any cohort table, each shown on the sample app with what you can and cannot conclude from it.

Short answer

Each row is an install cohort and each column is days since install. Read across a row for one cohort's decay, down a column to compare cohorts at the same age, and along a diagonal for a calendar event. Before concluding anything, check the definition, the cohort size, the channel mix and whether the cells are mature.

What do the rows and columns mean?

A cohort retention table puts install days down the side and days since install across the top. Each cell is the share of that row's users counted as retained on that day, under one definition.

  • Across a row: one cohort ageing, from Day 1 onwards.
  • Down a column: different cohorts at the same age, the fair comparison.
  • The triangle: newer cohorts have not reached later days yet, so those cells are empty, not zero.
Figure A

Classic retention, every cohort

The sample app's ten daily cohorts.

Install cohortD1D2D3D4D5D6D7D8D9D10D11D12D13D14
1 Sep Tue148 installs342328241916161627188171516
2 Sep Wed152 installs34363228242019361418171718
3 Sep Thu154 installs413023272723381813181313
4 Sep Fri142 installs3826222118352018151412
5 Sep Sat148 installs36272626392016121216
6 Sep Sun249 installs292622361714151610
7 Sep Mon262 installs2920391617161312
8 Sep Tue278 installs32422121181913
9 Sep Wed258 installs522520191714
10 Sep Thu266 installs3120181514
0%85%+not reached yet

Source: Sample data: a made-up app to show the method, not a benchmark.

What you can conclude

  • How each cohort decays over its first days.
  • Whether newer cohorts start better or worse than older ones on the same day.

What you can't

  • Anything about a cohort for days it has not reached.
  • Averages that mix cohorts of different ages without saying so.

What does a bright diagonal mean?

Cells on a diagonal share one calendar date. In the sample app a feature release and a push notification went out on 10 Sep, and every cohort's classic retention jumps on whatever day 10 Sep was for it: the 3 Sep cohort on Day 7 (38%), the 9 Sep cohort on Day 1 (52%).

Figure B

The 10 Sep diagonal, outlined

Classic retention; outlined cells are all 10 Sep.

Install cohortD1D2D3D4D5D6D7D8D9D10D11D12D13D14
1 Sep Tue148 installs342328241916161627188171516
2 Sep Wed152 installs34363228242019361418171718
3 Sep Thu154 installs413023272723381813181313
4 Sep Fri142 installs3826222118352018151412
5 Sep Sat148 installs36272626392016121216
6 Sep Sun249 installs292622361714151610
7 Sep Mon262 installs2920391617161312
8 Sep Tue278 installs32422121181913
9 Sep Wed258 installs522520191714
10 Sep Thu266 installs3120181514
0%85%+not reached yet

Source: Sample data: a made-up app to show the method, not a benchmark. Outlined cells range from 27% to 52%.

Classic shows calendar events most clearly. Cumulative absorbs them into every later day, and rolling spreads them backwards across earlier days, so check the classic view before you credit a cohort.

What you can conclude

  • Something happened on that date that brought users back.
  • Its size, by comparing the diagonal with its neighbours.

What you can't

  • That the 9 Sep cohort is a better cohort: its Day 1 is a push day.
  • That the effect lasts: the next diagonal is back to normal.

When does a retention curve flatten?

Most curves drop fast in the first days and then level off at the users who have made the app a habit. Where the curve flattens matters more than the first-day drop: a curve that keeps falling has no stable core yet.

Figure C

Classic retention, pooled

All cohorts that reached each day, pooled. Later days rest on fewer cohorts.

Retention by day since install0%25%50%Day 1Day 3Day 7Day 10Day 14Classic 16%

Source: Sample data: a made-up app to show the method, not a benchmark. Day 14 rests on one cohort only.

In the sample, classic falls from about 35% on Day 1 to about 18% on Day 7, then barely moves. Note the later points rest on fewer cohorts, so they are less certain.

What you can conclude

  • Roughly where the habitual core sits, once several cohorts agree.
  • Whether a change shifts the plateau, not just Day 1.

What you can't

  • A plateau from one or two cohorts.
  • A flattening on a cumulative curve: it only rises and always levels off.

How should you compare paid and organic cohorts?

Split the same table by channel and compare on the same definition, the same Day N and mature cells only. In the sample app, organic users return more on every day: classic Day 1 is about 46% organic and 26% paid.

Figure D

Classic retention by channel, pooled

Organic and paid cohorts, same definition, same days.

OrganicPaid
Retention by day since install0%25%50%Day 1Day 3Day 7Day 10Day 14Organic 20%Paid 10%

Source: Sample data: a made-up app to show the method, not a benchmark.

A gap is normal: organic users usually arrive with intent. What matters is whether the gap is stable, and whether paid users who do return behave like organic ones. The guide on why paid Day 1 is lower than organic lists what to check.

What you can conclude

  • Which channel brings users who return more, on matched cohorts.
  • Whether a gap is widening after a targeting or creative change.

What you can't

  • That paid is unprofitable: retention is half of the picture, cost is the other.
  • Channel quality from cohorts of very different ages or sizes.

Why can blended retention fall when no channel got worse?

From 6 Sep the sample app scaled up paid installs. Each channel's classic Day 1 stayed flat, but because paid users return less and now make up most of the installs, the blended number dropped. This is the mix-shift trap, a form of Simpson's paradox.

Figure E

Classic Day 1, before and after paid scaled

Pooled cohorts. 9 Sep is left out because its Day 1 was the push day.

1 to 5 Sep6, 7, 8 and 10 Sep
Organic43%42%
Paid24%23%
Blended37%30%
Paid share of installsabout 34%about 63%

Source: Sample data: a made-up app to show the method, not a benchmark.

What you can conclude

  • The blend moved because the mix moved.
  • Each channel's own quality, read separately.

What you can't

  • That the product got worse from a blended drop alone.
  • That paid caused churn: it brought different users, it did not change existing ones.

How much can you trust a small cohort?

Small cohorts swing. In the sample, paid cohorts before 6 Sep had about 50 installs each, and their classic Day 7 ranges from 2% to 24% from one day to the next with nothing changing underneath. After 6 Sep, with about three times the installs, the paid range narrows to 9% to 14%.

Figure F

Paid only, classic retention

Same app, same channel; the early cohorts are smaller.

Install cohortD1D2D3D4D5D6D7D8D9D10D11D12D13D14
1 Sep Tue52 installs19108881021015104628
2 Sep Wed48 installs27353317212117331023171519
3 Sep Thu55 installs271620162018247211711
4 Sep Fri50 installs1818410122288886
5 Sep Sat47 installs2891392324629
6 Sep Sun152 installs22181824141014115
7 Sep Mon168 installs191131121510109
8 Sep Tue175 installs2536131411149
9 Sep Wed160 installs391615101313
10 Sep Thu171 installs2512111613
0%85%+not reached yet

Source: Sample data: a made-up app to show the method, not a benchmark.

Pool several days into weekly cohorts, or wait for more installs, before reading single cells. If one returning user would change a cell by several points, treat it as directional.

What you can conclude

  • Trends that hold across several neighbouring cohorts.
  • Pooled numbers over a week of installs.

What you can't

  • Day-to-day moves in small cohorts.
  • A single cell that disagrees with its neighbours.

Why do newer cohorts look worse on rolling retention?

Rolling counts every day from Day N to the last day in the data, so older cohorts have more chances to be counted. In the sample, rolling Day 1 is 73% for the 1 Sep cohort and 51% for the 10 Sep cohort, while classic Day 1 for those two is 34% and 31%.

Figure G

Rolling retention, every cohort

Down any column, newer cohorts have had fewer days to return.

Install cohortD1D2D3D4D5D6D7D8D9D10D11D12D13D14
1 Sep Tue148 installs7369686564636159564739342816
2 Sep Wed152 installs82807674686564615044373118
3 Sep Thu154 installs797573726866624742342413
4 Sep Fri142 installs7773696765635143372512
5 Sep Sat148 installs71646361594640322516
6 Sep Sun249 installs646157544339332410
7 Sep Mon262 installs6157554337312212
8 Sep Tue278 installs67594944372713
9 Sep Wed258 installs675046382814
10 Sep Thu266 installs5140322414
0%85%+not reached yet

Source: Sample data: a made-up app to show the method, not a benchmark.

What you can conclude

  • Rolling comparisons between cohorts observed for the same number of days.
  • That a cohort is still returning, as of a stated date.

What you can't

  • That newer cohorts are worse, from rolling alone.
  • A trend across cohorts of different ages.

Before you conclude anything

  1. Which definition is this: classic, rolling or cumulative?
  2. Which day is Day 0, and in which time zone?
  3. Are the cells mature, and are the cohorts the same age?
  4. How big is each cohort?
  5. Did the channel or campaign mix change?
  6. Is there a diagonal: something on one calendar day?

Turn any of these into numbers yourself with the SQL and spreadsheet formulas, or explore them on the cohort explorer.

Questions

What does a diagonal mean in a cohort table?

Cells on the same diagonal share a calendar date: each cohort reaches that date at a different age. A diagonal that is brighter or darker than its neighbours points to something that happened on that day, such as a release, a push or an outage, not to better or worse users.

Why do cohort tables have empty cells?

A cohort can only show Day N once Day N has happened. Newer cohorts have fewer days behind them, which gives the table its triangle shape.

How big should a cohort be before I trust it?

There is no fixed number. A practical test: if one more or one fewer returning user would change your decision, the cohort is too small, so pool more days or wait.

What is the difference between classic, rolling and cumulative retention?

Classic counts users active on exactly Day N. Rolling counts users active on Day N or any later day, and cumulative counts users active at least once from Day 1 to Day N. They use the same raw activity but answer different questions.

Why is my rolling retention higher than classic?

Rolling also counts users who skipped Day N but came back later, so it can never be lower than classic. The gap grows the longer a cohort has been observed, because late returns keep adding to it.

What is cumulative retention?

Cumulative retention is the share of an install cohort that opened the app at least once between Day 1 and Day N. It never falls as N grows and it is fixed once Day N has passed, which makes it a good activation measure.