Online Tool Store
· 4 min read
How to Build a Retention Cohort Table
Manesh Jayawardhana
CIO & Co-founder
Overall retention is 34% and someone wants to know whether that’s good. It isn’t a question the number can answer, because it’s an average across users who joined last week and users who joined two years ago — two populations with nothing in common.
A cohort table separates them. And once you’ve built one, the useful reading isn’t the one most people do first.
What a cohort table shows
Group users by when they joined — by week, month, or quarter. Each group is a cohort. Then, for each cohort, measure how many were still active one period later, two periods later, and so on.
Lay that out as a grid: cohorts down the side, periods across the top. Every row shows one cohort ageing. Every column shows different cohorts at the same age.
The rows always decline. That’s not information — every cohort loses people over time, and a row that didn’t decline would mean something had gone wrong with the measurement.
The columns are where the answer lives. Comparing the March cohort’s month-three retention against the June cohort’s month-three retention tells you whether the product got better at keeping people. That comparison is the entire reason to build the table.
Why people get stuck here
- Reading across instead of down. The declining row looks like bad news and says nothing.
- A vague definition of “retained”. A login is a weak signal; completing a core action is a strong one. Whichever you pick, changing it mid-analysis invalidates every comparison.
- Partial periods. The newest cohort’s later columns haven’t happened yet, so they show as low and make the recent past look worse than it is.
- Cohort periods that don’t match the product. Weekly cohorts for a tool people use monthly produce noise, not signal.
What a good cohort table looks like
Both counts and percentages
Percentages let you compare cohorts of different sizes. Absolute counts stop you over-interpreting a cohort of eleven people. You need both visible.
Incomplete periods marked
Cells representing periods that haven’t fully elapsed should be visibly flagged or blank. Leaving them in as low numbers is the fastest way to convince a room that retention is collapsing when it isn’t.
A period that matches usage
Weekly cohorts suit products with daily or weekly habits. Monthly suits most subscription and B2B products. Quarterly suits anything with a long sales cycle. The wrong period turns real signal into noise.
| You Compare | You Learn | Careful Of |
|---|---|---|
| Across a row | How one cohort ages | Always declines — not a finding |
| Down a column | Whether new cohorts retain better | The real improvement signal |
| Bottom-right cells | Recent cohorts, late periods | Usually incomplete data |
Common mistakes to avoid
- Celebrating a high number in a cohort with thirty users.
- Changing the definition of an active user halfway through the analysis.
- Including the current, partial period and reading the dip as churn.
- Building monthly cohorts for a product with a weekly rhythm, then wondering why nothing is visible.
- Presenting the whole grid without saying which comparison matters — a wall of percentages invites everyone to find their own story.
How to do it with Cohort Analysis Builder
The Cohort Analysis Builder lays out the grid and flags the cells you shouldn’t trust yet, all in your browser.
- Provide signup dates and activity dates, one row per user event.
- Choose a cohort period that matches how often people actually use the product.
- Define “retained” once, and write the definition down next to the table.
- Read down the columns first, then across the rows for context.
- Ignore or exclude partial periods before drawing any conclusion.
Other analysis views — treemaps, comparison tables, chart builders — are in the tools directory.
Frequently asked questions
Why compare down the column rather than across the row?
Across a row you’re watching one cohort get older, which always declines. Down a column you’re comparing different cohorts at the same age, which is the only way to see whether changes to the product are working.
What counts as retained?
Whatever action means value in your product. A login often overstates retention badly; a completed core action is more honest. Pick one, define it precisely, and never change it mid-analysis.
Why does the newest cohort always look bad?
Because its later periods haven’t happened. Those cells are incomplete, not low. Exclude them, or the curve will mislead everyone in the room.
Final thought
Build the table for one comparison: same age, different cohorts. If the numbers going down a column are rising over time, whatever you changed is working. Everything else in the grid is context.