How do you decide whether a KPI computed only over still-active users is trustworthy enough to publish?
answer
- name the population the number describes
- who dropped out of the denominator
- composition shift, not behaviour change
- anchor the cohort at signup
- bound it both ways before shipping
basics
~20 sAsk what the number claims to describe. A metric whose denominator is this month's actives moves when weak users leave, so it reports composition, not behaviour. Publish it only alongside a cohort-anchored version, and name the conditioning in the metric itself.
solid answer
~50 sThe decision turns on whether attrition can move the metric in the direction the reader will interpret as progress. Any average taken over currently active users is conditioned on survival: when the least engaged churn, the mean rises with no individual having changed, which is a composition shift dressed as an improvement. My rule is that such a metric ships only with a cohort-anchored companion — fix the population at signup or at the start of the window and follow everyone in it, giving the departed an explicit terminal value rather than dropping them. Before publishing, I bound it: recompute assuming the departed behaved at their last observed level, then at the floor. If the direction of the trend survives both, the story is real. If it flips, the metric is reporting churn, and it goes back.
go deeper
Be ready to notice that a metric averaged over currently active users has a denominator that changes every period, and to ask what happened to the people who left before reading the trend.
Explain the mechanism concretely: removing the least engaged users from a mean raises it without any individual changing, so the series mixes behaviour change with composition change and cannot be read as either alone.
Show the working practice — rebuild the metric on a fixed cohort with an explicit value for the departed, run best-case and worst-case bounds for the leavers, and refuse to present a trend whose direction flips between them.
Own the standard and its cost. Cohort-anchored metrics look worse and move slower, and you are trading flattering numbers for trustworthy ones; make that trade explicitly, encode it in the metric layer and naming rules, and argue it before the quarter turns rather than after.
## The problem in one line A metric whose denominator is "users who are still here" has a survivorship filter built into its definition. The population it describes changes every period, and it changes in a way that is correlated with the metric itself — the users who leave are systematically the least engaged. That makes it an internal, self-inflicted version of the same bias that afflicts a table of surviving funds. ## The canonical failure Average session length among monthly active users rises 10% quarter over quarter. Leadership reads it as an engagement win. In fact no individual user changed behaviour at all; the bottom slice of light users stopped qualifying as active, and removing the low values from a mean raises it. The metric moved because the population moved. Worse, the same mechanism guarantees the metric *improves* fastest in the quarters where churn is worst, so it can be highest exactly when the business is doing worst. The general form: any statistic `mean(Y | still active)` is a conditional mean over a population defined by an outcome downstream of `Y`. Its trend confounds two things you need separately — how individuals changed, and who remained. ## The decision framework **1. State the population the number claims to describe.** Write it down in one sentence before anything else. "Average weekly sessions among users active this week" is honest; "average weekly sessions" is not, and the second is what usually ends up on the slide. Half of these failures die at this step. **2. Ask whether attrition can move the metric in the flattering direction.** If churned users sit systematically at one end of the distribution — and for engagement metrics they always sit at the low end — the metric drifts upward for free. If churn is unrelated to the metric, the exposure is small and a labelled survivor-conditional number may be fine. **3. Build the cohort-anchored companion.** Fix membership at the start of the window: everyone who signed up in month M, or everyone active at the start of the quarter. Follow all of them forward, and give the departed an explicit value rather than deleting them — usually zero for a volume metric, since zero sessions is what they actually did. The cohort-anchored series answers "did the people we had get better?", which is the question the reader thought they were asking. **4. Bound the uncertainty rather than pretending to remove it.** Recompute the metric twice: once with departed users held at their last observed value, once with them at the floor. These are deliberately crude sensitivity bounds, not a correction. If the conclusion holds under both, publish with confidence. If it flips, you have learned that your headline is a churn artefact. **5. Decide what you will not fix.** Some survivor-conditional metrics are genuinely the right measure. Satisfaction among current customers is a legitimate operational number for the support organisation; it just cannot be used to argue that the product is improving overall. The principal-level call is separating metrics that need correcting from metrics that need labelling. ## Making it stick organisationally - **Encode the population in the metric name.** If the definition conditions on survival, the name says so. A naming convention costs nothing and prevents the slide-deck version of the mistake, which is where the real damage happens. - **Default the metric layer to cohort anchoring.** Where the semantic layer or metric store lets you define a metric once, make the safe definition the easy one, so an analyst has to opt in to the survivor-conditional variant. - **Publish the denominator next to the number.** A metric shown without its population size hides exactly the movement that causes the artefact; when both are on the chart, a reader can see the denominator shrinking. - **Review at definition time, not at incident time.** The cheapest place to catch this is when a metric is proposed. Once a survivor-conditional number has been in a board deck for four quarters, correcting it looks like a regression and is politically expensive — which is itself an argument for getting it right early. ## The tradeoff to own Cohort-anchored metrics are less flattering, slower to move and harder to explain, and they will make quarters look worse than the survivor-conditional versions did. That is the cost, and it is real. The counter-cost is a leadership team steering on a number that improves when customers leave. A lead's job is to accept the first cost explicitly, in exchange for metrics whose direction can be trusted — and to say so before the numbers get worse, not after.
- Give a concrete case where the KPI improves purely because of who left.Average sessions per active user. The lightest users stop meeting the activity threshold and drop out of the denominator, so the mean of the remaining users rises even though nobody increased their usage. The effect is strongest in a bad churn quarter, which means the metric can peak exactly when retention is at its worst.
- How do you bound the damage when a proper correction is not available?Recompute the metric under two deliberately crude scenarios: departed users frozen at their last observed value, and departed users at the floor of the scale. Those bracket the plausible range without pretending to know what the leavers would have done. If the trend's direction survives both, publish it; if it reverses, the headline was an attrition artefact and should not ship.
- Is a survivor-conditional metric ever the right thing to report?Yes, when the population you actually need to manage is the survivors. Support load per current customer, or satisfaction among active subscribers, are legitimate operational numbers. The constraint is interpretive: they may not be used as evidence that the product is getting better, and their names must make the conditioning visible so nobody makes that leap.
- How do you stop this recurring across dozens of dashboards?Move the fix upstream of the dashboards. Require every metric definition to state its population in one sentence, make cohort-anchored denominators the default in the shared metric layer so the survivor-conditional form is an explicit opt-in, and require the denominator to be plotted next to any rate or average. Reviewing at definition time is far cheaper than retracting a board metric later.
saying these in an interview costs you the question
- Publishes any average over current actives without labelling it
- Reads a composition shift as a product improvement
- Assumes churned users would have behaved like the ones who stayed
- Treats attrition as noise that cancels out over time
- Shows a rate without ever showing its denominator