Find where the retention curve broke.
Retention is flat. The curve is not.
Teams track one retention number per cohort and compare it month to month. That averages away the only thing worth knowing: where in the curve the drop moved. Retention Cliff watches the whole curve, per channel, and names the week the shape changed.
Sixteen real series, one channel breaking, detection computed live in your browser.
The problem
A single number cannot tell you which retention problem you have.
Month-3 retention identical, week-2 retention destroyed. Same headline number, completely different cause and completely different fix. One is an onboarding failure you can fix this sprint, the other is a value failure that takes a quarter. Blending channels makes it worse: a channel that is a quarter of signups can break entirely and move the blended number by less than its weekly variance. And month-3 retention for cohorts that just broke is not observable for another two months, so the number you report is structurally the last one to know.
The insight
The shape of the break tells you the cause.
Retention is not one number, it is a curve, and each region of the curve has a different owner. Day-1 and day-7 belong to onboarding and to whatever promise the acquisition creative made. Week-2 belongs to habit formation. Month-3 belongs to durable value. When a break is confined to the early region and shows up alongside slower time to second session and fewer sessions per active user, that is a first-session problem, and you can stop looking at the roadmap. When it appears only in the late region with the early region intact, it is not. Detecting that pattern needs changepoint detection on each curve region separately, per channel, with multiple-comparison control so testing forty combinations does not manufacture two findings a week.
CUSUM on day-over-day percentage changes for sustained shifts and Bayesian Online Changepoint Detection (Adams & MacKay 2007) for abrupt ones, run per curve region per acquisition channel, then Benjamini-Hochberg FDR control across the whole run so the number of combinations tested is priced into every surviving alert.
How it works
Four steps, no data science team
A warehouse table with signup date, channel, and per-user activity is enough. Snowflake, BigQuery, Postgres, or an export. No new events, no SDK.
Day-1 and day-7 activation, week-2 and week-4 retention, month-3 retention, sessions per active user, and time to second session, each held separately per channel, campaign, and plan.
Each region runs through CUSUM and BOCD. What crosses is filtered by Benjamini-Hochberg across every region and slice tested, so a run over forty combinations does not hand you two false findings by construction.
Not "retention is down". Week-2 retention, paid social cohorts, starting Aug 9, with the activation and second-session signals that moved with it and the ones that did not.
Who it is for
The growth lead who has to explain the cohort chart
Growth and product teams past product-market fit, running paid acquisition across more than one channel, with a warehouse and a cohort table they already trust. Usually somebody has just been asked in a board meeting why retention moved and could not answer with a date.
Pricing
- –Full detection engine
- –Weekly digest
- –One warehouse connection
- –Every curve region, every channel
- –Two years of cohort history
- –Slack and email alerts
- –Campaign and creative slicing
- –Reverse ETL back to the warehouse
- –Self-hosted option
- –Custom curve regions
- –SSO and audit log
- –Detection tuning support
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| Amplitude | Cohort and retention charts, with slicing by any property. | Renders the curve and waits for you to notice. Nothing watches it, so the break is found by whoever happens to open the right chart with the right filter applied. |
| Mixpanel | Retention reports plus threshold alerting on saved metrics. | Alerts on one number crossing one line. That is the blended number again, and a threshold cannot tell a shape change from a level change. |
| Kubit / warehouse-native analytics | Product analytics computed directly on your warehouse tables. | Same modelling, same problem: the analysis is on demand. It is a better place to run a query, not something that tells you a query is now worth running. |
| A dbt model plus a Looker dashboard | What most teams past a certain size have actually built. | Correct and free, and nobody opens it. It also has no notion of how many comparisons it just made, so anyone who does add alerting to it gets a false alarm every few days and turns it off. |
The honest failure mode: growth teams do not believe a curve-region break is actionable until they have been burned by one, and the ones who have been burned already built a dbt model. That makes this a hard first sale into a team that thinks it already has the answer, and the buyer is a growth lead with no budget line for tooling rather than an engineering org with one. If the alert fires and the team cannot tie it to a change they made, they stop reading it after the second time, and the product has no second act.
Market
Sits inside the product analytics budget, not beside it
Companies running paid acquisition across several channels already pay $1,000 to $10,000 a month for product analytics. This is a fraction of that spend targeted at the one question those tools answer worst. Four thousand companies at the Growth tier is $29M ARR, and the qualifying population is every B2C and PLG company with more than one acquisition channel.