Cohort retention analysis groups users by when they signed up and tracks each group separately, usually as a triangle of percentages or a set of curves. It exists because a single blended retention number hides whether things are getting better. A big new cohort with weak retention can drag the average down while every older cohort holds steady. Before anyone claims retention is improving, this is the analysis to run.
How it works
Each row of the triangle is a cohort, each column a period since signup, each cell the share of the cohort still active. Read down a column to compare cohorts at the same age, and along a row to see one cohort's curve. A curve that flattens above zero means some users found lasting value. One that keeps falling means the product is renting attention.
Dave Boyce's Freemium treats that flattening as the quantitative sign of product-market fit, and his example shows month-six retention rising from 21% for a January cohort to 48% for July (Ch 11). The comparison only holds if every cell was counted with the same definition of active.
What it assumes your events already do
| Event | What the framework uses it for | What it reports when the event breaks |
|---|---|---|
Signupaccount_created | Assigns each user to a cohort. | If a migration resets signup dates, users jump cohorts and the newest row fills with people who are not new. |
Return visitsession_started | Defines active in each period. | Changing the active event creates a step in every cohort in the same calendar month, which reads as a sudden shift in retention. |
User-to-account joinaccount_id on every event | Builds account cohorts for B2B products. | Users who lose their account property drop out of account cohorts, and retention looks worse for the largest customers. |
Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.
The retention drop that was a definition change
Illustrative example. The company and the figures are invented to show the mechanism.
A team changes the active event from app_opened to report_viewed, to make the metric mean more. The change goes live in May. Every cohort's May cell drops by twelve points and stays lower.
Six months later a quarterly review compares the June cohort with January and concludes onboarding got worse. Nothing in onboarding changed. The definition did: January's early months were counted with the old event and June's with the new one.
Checks before you trust it
- Version the definition of active and mark the triangle wherever it changes.
- Look for steps that hit every cohort in the same calendar month; product changes hit new cohorts, tracking changes hit all of them.
- Confirm signup time is the original signup, not a migration or re-registration date.
- Choose user or account cohorts deliberately and keep the choice fixed.
Heard in The Question
Interviews in The Question that bear on this framework:
- Interview 01: the founder who uses product data to retire a recurring idea. Product data confirms or kills a hypothesis that people formed first, and the expensive gap is the number nobody collects.
- John Adib: when agents read your analytics, event names break first. Once an agent rather than an analyst queries the analytics, ambiguous event names stop being hygiene and start producing wrong numbers in the business review.
Check the events under it
Before Cohort retention analysis goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.