TL;DR
- A churn dashboard that tracks cancellations is a lagging indicator. By the time the event fires, the decision was made weeks ago.
- An early warning dashboard tracks the behaviours that precede the decision — login frequency drops, feature abandonment, champion departure, competitor research signals.
- You can build this entirely in PostHog using cohorts and insights. No data warehouse, no ML model, no dedicated data engineer required.
- The prerequisite is a tracking plan that captures the right events. If your instrumentation is incomplete, the cohorts will be incomplete.
- Seven steps: define activation event → build at-risk activation cohort → build declining engagement cohort → build champion-left indicator → build competitor research signal → assemble dashboard → connect alerts.
Why your churn dashboard is a lagging indicator
The standard PostHog churn setup tracks a cancellation event — a user triggers subscription_cancelled or similar, and it appears in the dashboard. The team reviews the chart weekly and reports on monthly churn rate. This is useful for measuring what happened. It is useless for preventing what is about to happen.
The cancellation event fires after the decision to cancel has been made — commonly by 30–60 days. By the time the event appears in the dashboard, the user has typically already stopped using core features, mentally evaluated alternatives, and disengaged from the product. The dashboard is reading the outcome of a process that completed weeks ago.
A post-mortem report has its uses: cohort analysis of churned users, churn rate trend over time, revenue impact. But none of that surfaces accounts at risk before they cancel. For that, you need a different dashboard — one built around leading indicators rather than the churn event itself.
The estimated lead time between when behavioural warning signals appear and when the cancellation event fires. The window between signal and decision is where intervention is possible. A churn event dashboard reads the outcome. An early warning dashboard reads the process.
Step 1: Define your activation event
Before you can build a meaningful early warning system, you need to know what activation looks like in your product. The activation event is the specific user action that correlates most strongly with long-term retention — the moment a user first experiences the core value of the product.
If you already know your activation event with confidence, proceed to Step 2. If you are not certain, start by identifying three to five candidate events: completing the primary setup step, using the core feature for the first time, inviting a teammate, creating the first meaningful piece of content or data. These are the actions that most plausibly mark "the product is now working for this user."
Retention cohort comparison
For each candidate event, build a retention cohort in PostHog: users who completed the event in the first 7 days versus users who did not, and compare their 30-day retention rates. The event with the largest retention rate differential between the "did" and "did not" cohorts is your activation event.
This analysis is worth doing carefully. A vaguely defined activation event produces a vaguely useful cohort. The at-risk activation cohort is only as good as the event it is built around.
Step 2: Build the at-risk activation cohort
Once your activation event is defined, the at-risk activation cohort identifies users who signed up in the last 30 days and have not yet completed it. These are users in the critical window between sign-up and genuine adoption — the period where value-not-realised churn is forming.
At-risk activation cohort
In PostHog: navigate to Persons & Cohorts → Create new cohort. Add the following filters:
This cohort is your primary value-not-realised at-risk signal. A user who passes day 7, day 14, or day 21 without completing the activation event has an increasing probability of churning before genuine adoption. The cohort does not fire a cancellation event — it surfaces the users who are on a path to churn if the activation gap is not closed.
This cohort also feeds the first insight in the dashboard: activation cohort size over time, trended weekly. A growing cohort indicates that acquisition is outpacing activation — a problem that compounds into churn at scale.
Step 3: Build the declining engagement cohort
The at-risk activation cohort catches users who never adopted. The declining engagement cohort catches users who did adopt and have since gone quiet. These are different populations with different churn drivers and different interventions.
Declining engagement cohort
In PostHog: create a new cohort with the following filters:
This cohort identifies the login frequency drop signal. A user who was logging in regularly and has since stopped is the single most common pattern in the run-up to cancellation. The 14-day silence threshold is a starting point — products with longer natural usage intervals (monthly reporting tools, for example) may need to extend this window to 21 or 30 days to avoid false positives.
The declining engagement cohort surfaces users who were genuinely adopted and are now disengaging. This distinguishes them from the at-risk activation cohort, where the user never adopted. The intervention for each is different: re-onboarding for the first group, re-engagement for the second.
Step 4: Build the champion-left indicator
For B2B products with multiple users per account, individual-level cohorts miss an important signal: the account where the primary user — the champion who drove adoption and owns the relationship — has stopped logging in, and no secondary user has picked up activity. This is the champion-left signal, and it is one of the strongest account-level leading indicators of churn.
Champion-left cohort (account-level)
This cohort requires PostHog Groups to be set up for your accounts or organisations. With groups enabled:
If your PostHog setup does not yet have the primary user property defined, a practical starting point is: accounts where the user who had the highest session count in the prior 90 days has had zero sessions in the last 7 days, and total account sessions in the last 7 days are zero. This can be approximated with a saved cohort and a weekly manual refresh until the property is instrumented properly.
The champion-left signal typically has a shorter intervention window than the other cohorts — once the account goes completely dark, the risk of cancellation increases rapidly. Treat accounts entering this cohort as highest-priority outreach.
Step 5: Build the competitor research signal
The competitor research cohort identifies users who visited the integrations or connections page and also triggered a data export event within the same 7-day window. This combination is the highest-specificity signal for competitor-switch intent in the product data. Each action individually is low-signal; together, in the same short window, they indicate a user actively evaluating an exit.
Competitor research cohort
The naming of your export event matters. If your product tracks data export as a generic $pageview on the export page rather than as a distinct event, the cohort will have lower precision. Where possible, fire a dedicated event (e.g., data_export_triggered) at the moment a user initiates an export — this gives the cohort a much cleaner signal to work with.
Step 6: Assemble the dashboard
With the four cohorts built, the dashboard assembles them into a single view that gives the team a weekly snapshot of churn risk across the product. Each cohort drives one or more insights in the dashboard.
Four core insights
Each insight in the dashboard should link directly to the underlying cohort, so the team can drill down from the aggregate number to the individual users or accounts in each risk state. The dashboard is not just a reporting surface — it is a triage tool. The team should be able to go from "declining engagement cohort is up 18% this week" to a list of specific accounts in one click.
The signals you track are only as good as your tracking plan. If your events are inconsistently named or missing across product surfaces, the cohorts above will be incomplete. An analytics audit is often the prerequisite to a working early warning system. The dashboard reveals the gaps — if a cohort is consistently empty when you expect it to have members, the issue is usually missing event instrumentation, not an absence of at-risk users.
Step 7: Connect to an alert or workflow
A dashboard that requires manual review will be reviewed inconsistently. The highest-value churn signals — particularly the champion-left cohort — need to surface automatically to the person whose job is to act on them. PostHog supports webhook-based alerts that can fire when an insight crosses a defined threshold.
Cohort growth alerts
The goal is to remove the dependency on someone remembering to open the dashboard. The alert fires when a signal crosses the threshold. The CS or product team receives it, reviews the drill-down cohort list, and initiates outreach on the highest-priority accounts before the week is out.
For teams with CRM tooling, it is worth exploring whether a PostHog webhook can write directly to the CRM — creating a task or updating an account health score automatically when a user enters one of the at-risk cohorts. This closes the loop between the early warning signal and the intervention workflow without requiring a manual handoff.
| Signal | PostHog query type | Churn archetype | Typical lead time |
|---|---|---|---|
| At-risk activation: signed up but no activation event by day 7+ | Cohort with person property filter + did-not-complete event | Value-not-realised | Commonly 2–4 weeks before churn decision |
| Declining engagement: active 14–44 days ago, silent last 14 days | Cohort with two time-windowed event filters | Any archetype; most common in feature-gap and budget-cut | Typically 3–6 weeks before cancellation |
| Champion-left: primary user silent 7+ days, no secondary activity | Cohort with person property + group-level filter | Champion-left | Often 1–2 weeks; highest urgency signal |
| Competitor research: integrations page + export in same 7-day window | Cohort with two co-occurring event filters | Competitor-switch | Commonly 2–4 weeks before cancellation |
| Support ticket silence: regular tickets stopped after sustained volume | External data (CRM/support tool); joined to PostHog by account ID | Gave-up (friction-driven) | Typically 3–5 weeks before cancellation |
Churn Analysis & Prevention
In the Churn Analysis & Prevention cohort, you build this dashboard against your own product data — not a demo dataset. You leave with the activation event defined, the cohorts built and populated, the dashboard assembled, and the alert routing connected to your CS workflow.
Frequently asked questions
Do I need a data warehouse to build this?
No. The early warning dashboard described here is built entirely within PostHog using cohorts, insights, and dashboard panels. No data warehouse, no SQL, no external tooling required. The one prerequisite is that your product is instrumented with the events the cohorts depend on — specifically a core feature event, a session start event, and page view events for the integrations page. If those events exist in your PostHog instance, the dashboard can be built in a few hours.
How often should the early warning dashboard be reviewed?
Weekly is the appropriate cadence for most teams. The cohorts update in real time, but reviewing them daily creates noise and alert fatigue. A structured weekly review — typically in the CS or product team standup — allows the team to identify accounts that entered an at-risk cohort in the past 7 days and triage intervention priority before the week is out. For high-velocity products with short trial periods, daily review of the at-risk activation cohort specifically may be warranted.
What if I don't have a clear activation event?
Start by identifying 3 to 5 candidate events — the actions that represent genuine product engagement in your context, such as completing a core setup step, using the main feature for the first time, or inviting a teammate. Build a retention cohort in PostHog for each candidate: users who completed the event versus users who did not, 30-day retention rate. The event with the largest retention differential is your activation event. This analysis takes an afternoon if your events are already tracked.
Can PostHog send alerts when an at-risk cohort grows?
Yes. PostHog supports webhook-based alerts that can be connected to Slack, email, or any downstream system. You can configure an alert to fire when a specific insight crosses a threshold — for example, when the at-risk activation cohort size exceeds a set number or grows by more than a defined percentage week over week. This removes the dependency on manual dashboard review and surfaces critical signals to the team automatically.
About the Author
Jake McMahon writes about analytics architecture, product instrumentation, and the decisions B2B SaaS teams make when building their data foundations. ProductQuant helps teams design what to instrument, set it up correctly the first time, and connect analytics to decisions that affect revenue.
Build the dashboard against your own data — not a tutorial dataset.
The Churn Analysis & Prevention cohort walks through each step of this build using your real PostHog data. You define the activation event, build the cohorts, assemble the dashboard, and leave with a working early warning system.