---
title: Reading a Cohort Retention Table: Six Key Patterns
description: How to read a cohort retention table: rows, columns, diagonals, flattening, paid vs organic, mix shifts and small cohorts, with what you can and can't conclude.
url: https://retentioncohorts.com/read/
---

[Home](https://retentioncohorts.com/) / 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 cohort | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 Sep Tue 148 installs | 34 | 23 | 28 | 24 | 19 | 16 | 16 | 16 | 27 | 18 | 8 | 17 | 15 | 16 |
| 2 Sep Wed 152 installs | 34 | 36 | 32 | 28 | 24 | 20 | 19 | 36 | 14 | 18 | 17 | 17 | 18 |  |
| 3 Sep Thu 154 installs | 41 | 30 | 23 | 27 | 27 | 23 | 38 | 18 | 13 | 18 | 13 | 13 |  |  |
| 4 Sep Fri 142 installs | 38 | 26 | 22 | 21 | 18 | 35 | 20 | 18 | 15 | 14 | 12 |  |  |  |
| 5 Sep Sat 148 installs | 36 | 27 | 26 | 26 | 39 | 20 | 16 | 12 | 12 | 16 |  |  |  |  |
| 6 Sep Sun 249 installs | 29 | 26 | 22 | 36 | 17 | 14 | 15 | 16 | 10 |  |  |  |  |  |
| 7 Sep Mon 262 installs | 29 | 20 | 39 | 16 | 17 | 16 | 13 | 12 |  |  |  |  |  |  |
| 8 Sep Tue 278 installs | 32 | 42 | 21 | 21 | 18 | 19 | 13 |  |  |  |  |  |  |  |
| 9 Sep Wed 258 installs | 52 | 25 | 20 | 19 | 17 | 14 |  |  |  |  |  |  |  |  |
| 10 Sep Thu 266 installs | 31 | 20 | 18 | 15 | 14 |  |  |  |  |  |  |  |  |  |

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 cohort | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 Sep Tue 148 installs | 34 | 23 | 28 | 24 | 19 | 16 | 16 | 16 | 27 | 18 | 8 | 17 | 15 | 16 |
| 2 Sep Wed 152 installs | 34 | 36 | 32 | 28 | 24 | 20 | 19 | 36 | 14 | 18 | 17 | 17 | 18 |  |
| 3 Sep Thu 154 installs | 41 | 30 | 23 | 27 | 27 | 23 | 38 | 18 | 13 | 18 | 13 | 13 |  |  |
| 4 Sep Fri 142 installs | 38 | 26 | 22 | 21 | 18 | 35 | 20 | 18 | 15 | 14 | 12 |  |  |  |
| 5 Sep Sat 148 installs | 36 | 27 | 26 | 26 | 39 | 20 | 16 | 12 | 12 | 16 |  |  |  |  |
| 6 Sep Sun 249 installs | 29 | 26 | 22 | 36 | 17 | 14 | 15 | 16 | 10 |  |  |  |  |  |
| 7 Sep Mon 262 installs | 29 | 20 | 39 | 16 | 17 | 16 | 13 | 12 |  |  |  |  |  |  |
| 8 Sep Tue 278 installs | 32 | 42 | 21 | 21 | 18 | 19 | 13 |  |  |  |  |  |  |  |
| 9 Sep Wed 258 installs | 52 | 25 | 20 | 19 | 17 | 14 |  |  |  |  |  |  |  |  |
| 10 Sep Thu 266 installs | 31 | 20 | 18 | 15 | 14 |  |  |  |  |  |  |  |  |  |

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.

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

Organic Paid

**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](https://retentioncohorts.com/learn/paid-d1-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 Sep | 6, 7, 8 and 10 Sep |
|---|---|---|
| Organic | 43% | 42% |
| Paid | 24% | 23% |
| Blended | 37% | 30% |
| Paid share of installs | about 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 cohort | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 Sep Tue 52 installs | 19 | 10 | 8 | 8 | 8 | 10 | 2 | 10 | 15 | 10 | 4 | 6 | 2 | 8 |
| 2 Sep Wed 48 installs | 27 | 35 | 33 | 17 | 21 | 21 | 17 | 33 | 10 | 23 | 17 | 15 | 19 |  |
| 3 Sep Thu 55 installs | 27 | 16 | 20 | 16 | 20 | 18 | 24 | 7 | 2 | 11 | 7 | 11 |  |  |
| 4 Sep Fri 50 installs | 18 | 18 | 4 | 10 | 12 | 22 | 8 | 8 | 8 | 8 | 6 |  |  |  |
| 5 Sep Sat 47 installs | 28 | 9 | 13 | 9 | 23 | 2 | 4 | 6 | 2 | 9 |  |  |  |  |
| 6 Sep Sun 152 installs | 22 | 18 | 18 | 24 | 14 | 10 | 14 | 11 | 5 |  |  |  |  |  |
| 7 Sep Mon 168 installs | 19 | 11 | 31 | 12 | 15 | 10 | 10 | 9 |  |  |  |  |  |  |
| 8 Sep Tue 175 installs | 25 | 36 | 13 | 14 | 11 | 14 | 9 |  |  |  |  |  |  |  |
| 9 Sep Wed 160 installs | 39 | 16 | 15 | 10 | 13 | 13 |  |  |  |  |  |  |  |  |
| 10 Sep Thu 171 installs | 25 | 12 | 11 | 16 | 13 |  |  |  |  |  |  |  |  |  |

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 cohort | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 Sep Tue 148 installs | 73 | 69 | 68 | 65 | 64 | 63 | 61 | 59 | 56 | 47 | 39 | 34 | 28 | 16 |
| 2 Sep Wed 152 installs | 82 | 80 | 76 | 74 | 68 | 65 | 64 | 61 | 50 | 44 | 37 | 31 | 18 |  |
| 3 Sep Thu 154 installs | 79 | 75 | 73 | 72 | 68 | 66 | 62 | 47 | 42 | 34 | 24 | 13 |  |  |
| 4 Sep Fri 142 installs | 77 | 73 | 69 | 67 | 65 | 63 | 51 | 43 | 37 | 25 | 12 |  |  |  |
| 5 Sep Sat 148 installs | 71 | 64 | 63 | 61 | 59 | 46 | 40 | 32 | 25 | 16 |  |  |  |  |
| 6 Sep Sun 249 installs | 64 | 61 | 57 | 54 | 43 | 39 | 33 | 24 | 10 |  |  |  |  |  |
| 7 Sep Mon 262 installs | 61 | 57 | 55 | 43 | 37 | 31 | 22 | 12 |  |  |  |  |  |  |
| 8 Sep Tue 278 installs | 67 | 59 | 49 | 44 | 37 | 27 | 13 |  |  |  |  |  |  |  |
| 9 Sep Wed 258 installs | 67 | 50 | 46 | 38 | 28 | 14 |  |  |  |  |  |  |  |  |
| 10 Sep Thu 266 installs | 51 | 40 | 32 | 24 | 14 |  |  |  |  |  |  |  |  |  |

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](https://retentioncohorts.com/compute/), or explore them on the [cohort explorer](https://retentioncohorts.com/).

See this on your own app

Linkrunner shows classic, rolling and cumulative retention for your own install cohorts, so these six patterns can be checked on real data rather than a sample.

- [How to Read a Mobile Retention Curve](https://linkrunner.io/blog/how-to-read-a-retention-curve?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=read&utm_content=panel)
- [How to Measure App Retention by Channel](https://linkrunner.io/blog/measure-app-retention-by-channel?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=read&utm_content=panel)
- [Create a free account (25k installs free)](https://dashboard.linkrunner.io/sign-in?utm_source=retentioncohorts&utm_medium=referral&utm_campaign=read&utm_content=panel)

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