What is a cohort explained simply

What a cohort actually is

A cohort is a group of users tied together by a shared start event — the moment their clock began ticking inside your product. The start event is almost always signup, first purchase, or activation, and once you fix it, every user in the cohort can be compared at the same point in their lifecycle. The April cohort is everyone who signed up in April; the iOS-launch cohort is everyone whose first session happened the week the iOS app shipped. The label is just shorthand for "people who entered the product under these conditions, at this time."

The reason analysts keep dragging this concept into every metric review is that without a fixed start event, time-based metrics quietly mix populations that have nothing in common. A user who signed up yesterday and a user who signed up two years ago are different organisms — different activation rituals, different price points they paid, different feature surface they were onboarded into. When you average across them you get a number that describes nobody.

Why product averages lie

Picture a PM at a subscription company opening the dashboard on Monday morning. Overall 30-day retention is sitting at 35%, flat for a quarter. Leadership reads "flat" as "healthy." It isn't. Cohorted, the picture splits in two: the cohort from a year ago retains at 50% because those users self-selected into an early-adopter price, while the cohort acquired through a recent paid-ads push retains at 20% because the targeting was loose. The blended 35% is the arithmetic of an old cohort that hasn't churned yet plus a new cohort that's already collapsing. The mean is technically correct and completely misleading.

The cleanest analogy is height in a school. "Average height in our school is 150 cm" tells you nothing useful — the school contains both first-graders and twelfth-graders. Split by grade and the comparison becomes real: first-graders average 130 cm, twelfth-graders 175 cm, and now you can compare your school to another school grade-by-grade. Cohorts do the same thing for product analytics. You stop comparing apples to a fruit basket and start comparing April-cohort week-4 retention to March-cohort week-4 retention.

This is why the first question a senior analyst asks when handed a retention number is "cohorted by what?" It's not gatekeeping — without the cohort definition, the number is genuinely uninterpretable.

Types of cohorts

The start event you pick is the cohort's identity. Four families cover almost every real-world case:

Time-based cohorts (daily, weekly, monthly signups) are the default at most companies because they're the easiest to compute and the easiest to reason about. Channel cohorts come next — slicing acquisition by paid, organic, referral, and partnership channels is how you separate the $50 CAC cohort from the $8 CAC cohort and find out which one actually pays back. Feature-exposure cohorts are the bread and butter of every experimentation team: the "treatment" group is a cohort, the "control" group is a cohort, and the only thing they share is the date their assignment fired.

Behavioral cohorts are the most interesting and the most dangerous. "Users who made a first purchase" is obviously a different population from "users who only browsed," so any metric difference between them is partly causal and partly self-selection. Reporting "buyers retain 4x better than browsers" without acknowledging that is a classic junior-analyst trap.

What you measure inside a cohort

A cohort by itself is just a list of user IDs and a start date. What turns it into analysis is the metric you compute as those users age. Four metrics dominate:

• Retention. What fraction of the cohort is still active at day N, week N, or month N. The default cohort metric.
• LTV / revenue per user. Cumulative revenue contributed by the cohort, divided by cohort size. Tells you whether the cohort pays back the cost to acquire it.
• Engagement depth. Sessions per user, events per user, minutes per user — usually as a function of weeks since signup.
• Churn. The inverse of retention. Useful when churn is the metric leadership tracks contractually (B2B SaaS, telecom).

Picking the right metric depends on the business model. For consumer mobile, D1, D7, D30 retention is the industry standard and Apple and Google literally publish benchmarks against it. For subscription SaaS, you care about net dollar retention by signup quarter — a different metric entirely, because expansion revenue from inside the cohort is part of the answer. For a marketplace, cohorted GMV per buyer is what investors will ask about during diligence.

The cohort table and heatmap

The canonical visualization is a triangle table. Rows are cohorts (typically the signup month or week), columns are time since signup (day 0, day 7, day 14, day 30…), and the cell value is the metric — usually retention as a percentage. Newer cohorts have fewer columns filled in because they haven't aged yet, which is what gives the table its triangular shape.

Cohort   | D0   | D7   | D14  | D30
2026-04  | 100% | 45%  | 35%  | 28%
2026-03  | 100% | 50%  | 40%  | 32%
2026-02  | 100% | 48%  | 38%  | 30%

Read this table column-by-column, not row-by-row. The April cohort has worse D7 retention than March and February — 45% vs 48–50% — which is a real signal that something changed for April signups. Maybe the acquisition channel shifted. Maybe a regression hit onboarding. Either way, the cohort table surfaces the regression weeks before the blended average would.

The heatmap is the same table with color encoding. In Python with seaborn it's a one-liner:

import seaborn as sns
sns.heatmap(retention_pivot, annot=True, fmt='.0%', cmap='YlGnBu')

Green and blue cells mean strong retention, yellow and red mean weak. The pattern your eye should scan for is whether the columns are stable across rows (healthy product) or whether recent rows are systematically lighter (decaying product).

A minimal SQL example

Here is the absolute simplest cohort query: "of users who signed up on a given day, how many were active again seven days later?"

WITH cohort AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_name = 'signup'
      AND event_time::DATE = '2026-04-01'
),
returned AS (
    SELECT DISTINCT user_id
    FROM events
    WHERE event_time::DATE = '2026-04-08'
)
SELECT
    (SELECT COUNT(*) FROM cohort) AS cohort_size,
    COUNT(*) AS returned_users,
    ROUND(100.0 * COUNT(*) / (SELECT COUNT(*) FROM cohort), 1) AS d7_retention_pct
FROM cohort
INNER JOIN returned USING (user_id);

In production you'd parameterize on signup date and aggregate across all cohorts, usually with DATE_TRUNC on signup and DATEDIFF on activity. But this explainer version captures the conceptual shape: define cohort membership, define a return event, intersect, divide.

If you want to drill SQL cohort questions like this on actual interview prompts, NAILDD has a library of cohort and retention problems built from real data analyst loops.

Classic vs rolling retention

There are two conventions for what "retained on day N" actually means, and confusing them is one of the most common interview mistakes.

Classic retention (sometimes called "D-retention") requires the user to be active strictly on day N. If a user comes back on day 6 and day 8 but not day 7, classic D7 retention says they churned. It's the stricter definition and the one most consumer mobile companies report.

Rolling retention counts the user as retained on day N if they were active on day N or any day after. Same user with the day-6-and-day-8 pattern is retained on D7 under rolling — because they were active later. Rolling is mathematically smoother and is the default in some BI tools, but it's a noisier signal for product decisions because a comeback six months later still counts as "retained."

Common pitfalls

The most common cohort mistake is mismatched horizons. An analyst compares the D7 retention of last week's cohort to the D30 retention of a cohort from two months ago and concludes the new cohort is worse. They're worse-looking because they're younger, not because they're actually retaining at a lower rate at the same age. The fix is rigid: always compare cohorts at the same point in their lifecycle, never at the same wall-clock date.

A second pitfall is weighting by cohort size without thinking. If the March cohort is ten times larger than the April cohort, a simple average of their retention rates is dominated by March and tells you essentially nothing about April. When you need a single blended number, weight explicitly by cohort size, or — better — report the cohort-level numbers separately and let the reader weight them mentally.

A third trap is ignoring weekly seasonality. D7 retention measured for a Tuesday-signup cohort lands on the next Tuesday; for a Friday-signup cohort, it lands on Friday. If your product has different weekday vs weekend usage patterns (most do), the day-of-week effect bleeds into the cohort comparison. Either aggregate to weekly cohorts, or always smooth with a 7-day rolling window when reporting daily retention curves.

A fourth, subtler pitfall is cohorts that are too small. Below roughly 500 users per cohort, the noise floor on retention percentages is large enough that week-over-week wiggles look like real signal. For early-stage products with low daily signup volume, switch to weekly or monthly cohorts so each row in the table is statistically meaningful. A 30-user cohort showing 35% D7 retention has a confidence interval that easily spans 20–50% — useless for decision-making.

A fifth is forgetting the denominator definition. "Retention at D7" sounds unambiguous until you ask whether D0 is the signup day or the day after. Both conventions exist — standardize internally and ask before answering on an interview.

Related reading

• Cohort analysis data science interview
• How to calculate cohort retention in SQL
• How to calculate D1 D7 D30 retention in SQL
• How to calculate LTV by cohort in SQL
• Churn explained simply
• Product metrics — DAU MAU ARPU LTV explained
• SQL window functions interview questions

FAQ

What is the difference between a cohort and a segment?

A cohort is defined by a start event in time — when did the user enter this group. A segment is defined by attributes — country, device, plan tier, age range. The two are orthogonal and routinely combined: "the April signup cohort, segmented to iOS users" is a perfectly valid analysis unit. The distinction matters because cohorts age and segments don't; April-cohort users will eventually become June-cohort-age users, but an iOS user doesn't suddenly become an Android user.

How big should a cohort be to be statistically meaningful?

Roughly 500 users is the lower bound for stable retention percentages, and that's a soft floor — for engagement metrics with high variance per user, you may want 1,000+. Below that, the noise on any single cohort's metric is large enough to swamp the real signal. The pragmatic fix when you have low signup volume is to widen the cohort window: switch from daily to weekly cohorts, or weekly to monthly, until each cohort clears the threshold.

Should I report D7 or W1 retention?

D7 retention is the share of users active on the 7th day after signup under the classic definition; W1 retention is the share of users active at any point during the first week after signup. W1 is always greater than or equal to D7 because the W1 window contains the D7 day. Consumer mobile defaults to D7 because it's stricter and more comparable across products. B2B SaaS often defaults to W1 because the product isn't designed to be opened daily. Pick the one that matches your product's expected usage cadence.

Can a single number summarize a cohort?

It can, but you lose information. Common single-number summaries are D7 retention for consumer products and LTV at 90 or 180 days for subscription products. Both miss the shape of decay — a cohort with 60% D7 and 10% D30 is very different from 40% D7 and 30% D30, even if their D90 LTV is similar. Use the scalar for dashboards; use the full heatmap when deciding.

When do cohorts stop being useful?

Cohort analysis assumes the population is reasonably stable over the analysis window. When the product changes drastically — major UX overhaul, pricing change, regulatory shift — old cohorts become uninterpretable because the product they signed up for no longer exists. Cohorts also struggle for products with very long natural lifecycles (multi-year enterprise contracts) where you'd wait years for a cohort to mature. In both cases, supplement with snapshot metrics and acknowledge the limitation rather than pretending the cohort table is the whole truth.