In a subscription churn model, which event is the churn label when many accounts simply never renew?
answer
- one ending emits an event, one does not
- absence of a charge is the signal
- predicate over billing state, not a log row
- grace period makes the label final
- payment failure is not intent
basics
~20 sThere is no single event: an explicit cancellation is logged with a timestamp, but a silent non-renewal is an absence. The label must be a predicate over billing state, declared positive once the renewal date plus a grace period has passed with no new paid period.
solid answer
~50 sA subscription ends in more than one way, and only one of them emits an event. An explicit cancellation carries its own timestamp and is easy to label. A silent non-renewal produces nothing at all - the signal is the *absence* of a charge - so the label has to be written as a predicate over billing state: an account is positive if its paid access ends inside the horizon and no new paid period has begun by the renewal date plus a stated grace period. That grace period exists because late payments and retries are common, and it is what makes the label final. Payment failures are a third case: the outcome looks identical but the intent is absent and the useful intervention is a billing fix, so they are normally excluded or modelled as their own class.
go deeper
Remember that not every ending is logged: some accounts click cancel, others just stop paying, and only the first kind arrives as an event you can join.
Be able to write the label as a predicate with an observation time - paid access ending inside the horizon, confirmed once the grace period closes - and explain what the grace period trades.
Show judgement on the messy classes: involuntary churn, reinstatements and downgrades, and connect each choice to the intervention that would actually fire.
Treat the definition as a contract the business signs: it decides who gets contacted, which budget is spent and what the reported churn number means across teams.
## Two ways a paying account stops paying An **explicit cancellation** is an action. The account holder clicks through a cancellation flow, and the system writes a row with a timestamp, a reason code and sometimes a survey answer. It is the label everyone reaches for first, because it already looks like training data. A **silent non-renewal** is the opposite: nothing is written. A term ends, no renewal charge succeeds, and access lapses. The evidence is negative - the charge that did not happen - and negative evidence cannot be joined the way an event can. In many subscription businesses the silent path is the larger of the two, so a label defined purely on the cancellation event quietly trains the model on a minority of the churn it was asked to predict, and scores the rest as negatives. ## A label is a predicate plus an observation time The usable definition has three parts: 1. **The predicate** - for as-of date `T` and horizon `H`, the account is positive if its paid access ends on a date inside `(T, T + H]`. 2. **The observation time** - the predicate is only evaluated at `T + H + G`, where `G` is the grace period, because a renewal can still land late. 3. **The grace period itself** - a stated number of days, typically a week or two, after which no new paid period means the account is declared gone. That third part is a judgement call with consequences in both directions. A short grace period declares churn sooner and labels some accounts positive that would have renewed late, injecting noise. A long one is cleaner but pushes the label further into the future. ## The four ways a subscription ends | Ending | What is logged | Who decided | Usual treatment | |---|---|---|---| | Voluntary cancellation | a cancel event with a timestamp | the account holder | positive | | Silent non-renewal | nothing; a charge is absent | the account holder, by inaction | positive, declared after grace | | Payment failure | a failed charge and retry attempts | the payment rail | own class: excluded or modelled apart | | Pause or downgrade | a plan-change event | the account holder | normally negative, sometimes its own target | Payment failure is the case that most often gets waved through. The revenue outcome is the same, but the account holder never chose to leave, and the intervention that helps is a card-update prompt rather than a retention offer. Folding those rows into the positive class teaches the model to predict expiring cards, and the retention team then spends its budget on people who were not leaving. ## What the definition commits the rest of the design to - **The maturity lag.** The grace period is added to the horizon before any row can be labelled, so a generous grace period directly delays the training cut. - **The population the model flags.** Include payment failures and the flagged list fills with billing problems; exclude them and something else has to catch those accounts. - **Return within the window.** An account that cancels and resubscribes a fortnight later has to be either a positive, a negative, or excluded, and the choice has to be written down rather than left to whichever join runs first. - **Downgrades.** A move to the cheapest plan is revenue loss without an ending; if the business cares, it is a separate target, not a quiet extra positive. - **Reconstructability.** The predicate must be computable from logged billing state for any historical date, not just for today, or no training table can be rebuilt. ## Where this goes wrong - Labelling only the explicit cancellation event, and treating every silent lapse as a healthy account. - Leaving the grace period unstated, so two rebuilds of the table disagree on the same accounts. - Merging voluntary and involuntary endings because the revenue line is identical. - Deriving the label from a status column that reflects today's state rather than the state on the as-of date, which cannot be recomputed for the past. - Counting a pause as churn while the account is still expected to return and pay.
- An account cancels, then resubscribes eleven days later. Is that row positive?Whatever you decide, decide it explicitly and write it into the predicate. Treating it as positive teaches the model to flag accounts that never really left; treating it as negative hides a real cancellation the retention flow may have recovered by accident. A common resolution is a reinstatement window, shorter than the grace period, inside which a returning account is labelled negative and counted separately so the volume stays visible.
- Why not just label from the account status column in the billing system?Because a status column carries today's value with no history. It cannot answer what the account's status was on a past as-of date, so the training table cannot be rebuilt, and any row joined to it silently imports the outcome. A label has to be reconstructed from dated billing periods and charge events, which can be replayed for any date.
saying these in an interview costs you the question
- Churn is whatever the cancellation event table says it is
- A grace period is a billing detail with no effect on the label
- Payment failures and deliberate cancellations are the same positive class
- A pause counts as churn because the revenue stops
- The current account status column is a fine source for historical labels