Cohort analysis, without the jargon
Cohort analysis answers one practical question: after people arrive, do they come back, buy again, and pay back the cost of acquiring them? This page teaches the concept from zero, using the same kind of retention table teams use in product analytics, CRM, fintech, and e-commerce.
The idea in one sentence
A cohort is a group of people who start from the same point. Cohort analysis follows that group over time instead of mixing everyone into one average.
Start with a school-class analogy
Imagine every student who started first grade in September 2020. That class is a cohort. You can check how many reached grade 5, grade 9, or graduation. In a product, the same logic applies: everyone who signed up in March, placed a first order in April, or installed the app during one campaign can be followed month after month.
Why averages are dangerous
Averages mix old loyal customers with new fragile customers. Revenue can grow while new users are getting worse, simply because you are buying more traffic. Cohorts separate the story: January users behaved like this, February users behaved like that, paid-search users behaved differently from referrals.
The five words you need before reading the table
The starting group. Example: users who made their first purchase in March.
The event that puts someone into the cohort: signup, install, first purchase, loan approval, subscription start.
How much time has passed since the birth event. M0 is the starting month, M1 is one month later.
The action that proves the user came back. It should create value: purchase, transfer, lesson completed, booking, paid renewal.
The share of the original cohort that did the return event in a later period.
The same table, but with money instead of activity: revenue, gross margin, LTV, payback.
If 1,000 users signed up in January and 420 of them made a purchase in February, January M1 purchase retention is 42%.
M1 retention = 420 returning users / 1,000 users in the original cohort = 42%Read the cohort table slowly
The table below is fictional, but the shape is real. Each row is a monthly cohort. Each column is the age of that cohort. Empty cells on the right do not mean zero; they mean that not enough time has passed yet.
| Cohort | Size | Months since signup | ||||||
|---|---|---|---|---|---|---|---|---|
| M0 | M1 | M2 | M3 | M4 | M5 | M6 | ||
| Jan | 1,200 | 100% | 62% | 48% | 42% | 39% | 37% | 36% |
| Feb | 1,450 | 100% | 64% | 50% | 44% | 40% | 38% | |
| Mar | 1,380 | 100% | 66% | 52% | 46% | 42% | ||
| Apr | 1,620 | 100% | 68% | 54% | 48% | |||
| May | 1,750 | 100% | 70% | 56% | ||||
| Jun | 1,900 | 100% | 71% | |||||
How to read it
Read one row left to right
This shows one cohort aging over time. January starts at 100%, then you see how much of January survives after one, two, three months.
Read one column top to bottom
This compares cohorts at the same age. If March M1 is worse than January M1, something changed in acquisition, onboarding, product quality, pricing, or seasonality.
Do not compare old age with young age
January M6 and June M1 answer different questions. Compare M1 with M1, M3 with M3, and so on.
Remember the blank triangle
Newer cohorts have not lived long enough to have M4, M5, or M6 data. A blank cell is unknown, not bad.
The same table as a curve
If you average each column, you get a retention curve. A healthy curve drops early and then flattens. A weak curve keeps falling toward zero.
Cohort, segment, funnel: do not mix them up
These tools answer different questions. Teams get confused when they use the word "cohort" for every group of users.
| Tool | What it groups | Question | Example |
|---|---|---|---|
| Segment | Users with a shared trait | Who are they? | Users in Almaty on iOS |
| Funnel | A sequence of steps | Where do they drop? | Visit -> signup -> purchase |
| Cohort | A group followed through time | Do they stay or pay back? | March first-purchase users after 3 months |
A channel can look cheap on CAC and still be bad if customers do not repeat, do not repay, or churn before payback. That is why mature teams build both retention cohorts and revenue cohorts.
| Channel | CAC | M1 gross margin | M3 cumulative margin | Payback |
|---|---|---|---|---|
| Discount TikTok | $18 | $7 | $10 | No payback |
| SEO | $45 | $12 | $58 | Month 3 |
| Referral | $28 | $20 | $76 | Month 2 |
Do not start with a huge dashboard. Start with one business question and one clean table.
- Pick the question: Are new users returning? Are paid users profitable? Which channel creates repeat buyers?
- Pick the birth event. Use a real start point: first purchase, account opened, subscription started. Avoid vague events like page view.
- Pick the cohort period. For consumer apps use days or weeks; for e-commerce and subscriptions use months.
- Pick the return or value event. For fintech it might be transfer completed; for e-commerce, second order; for EdTech, lesson completed.
- Add source and product cuts only after the base table works: channel, campaign, city, platform, first category, language.
- Turn the table into a decision: cut a channel, repair onboarding, change CRM timing, fix product friction, or keep scaling.
Local examples for KZ and CIS teams
Do not stop at account opening. Build cohorts by first approved product, then track first transaction, repeat transaction, card funding, loan repayment, and margin.
Black Friday and Kaspi-style promos can create huge first-order cohorts with weak repeat behavior. Separate discount cohorts from normal-price cohorts.
Track the second and third order. A cheap first order can be noise if people only came for a promo code.
A signup cohort is too weak. Track payment, first lesson, first homework, week-two activity, completion, refund, and referral.
Common beginner mistakes
Using "app open" as the return event
Opening the app is often too weak. Use the action that proves value: transfer, order, booking, lesson, renewal.
Changing definitions every month
If January cohort uses signup and February cohort uses first purchase, the comparison is broken.
Reading tiny cohorts too confidently
A 40-person cohort can move by 10-20 percentage points because of a few people. Pool small cohorts or mark the result as directional.
Mixing acquisition quality with product quality
A bad cohort may come from worse traffic, a broken onboarding flow, seasonality, pricing, support delays, or a product change. Segment before blaming one team.
Looking only at retention, not margin
A cohort that returns because of heavy discounts can look active and still lose money.
Treating incomplete cells as zero
The newest cohorts have not had time to reach M4 or M6. Leave those cells blank until the period exists.
The page above is enough to understand the mechanics. The video is useful if you want to see the same idea explained verbally before you build a table yourself.
FAQ
Is cohort analysis only for product teams?
No. Marketing uses cohorts to judge channel quality, CRM uses cohorts to plan retention, finance uses revenue cohorts for payback, and product uses cohorts to find activation problems.
What period should I use: day, week, or month?
Use the natural rhythm of the product. Daily works for mobile apps and games. Weekly works for content, marketplaces, and onboarding. Monthly works for e-commerce, subscriptions, and banking products.
How many users do I need?
There is no universal minimum, but very small cohorts are noisy. If one user changes the result by several percentage points, pool cohorts or treat the result as a signal, not proof.
Can GA4, Amplitude, or Mixpanel build this?
Yes. GA4 has Cohort exploration, and product analytics tools such as Amplitude and Mixpanel are built around event-based retention analysis. The hard part is not the tool; it is choosing clean events.
Useful references
Need a cohort table tied to real CRM revenue, ad spend, and product events? Get in touch.