Subscription churn prediction

What it does

Subscription churn prediction scores unified customers on the likelihood they won't renew a recurring product or service. It reads subscription history — start and end dates, recurrence frequency, amounts — alongside customer activity, and produces a churn probability per profile for a window you choose.

Key facts

Out-of-box model, generally available, created from Insights > Predictions > Create. Contributor permissions or higher.
Minimum 1,000 customer profiles within the prediction window. That's higher than transactional churn's 500 floor, and it is a genuine constraint on smaller B2B subscription books.
Two to three years of subscription history, and at minimum double the prediction window you set.
Required subscription fields: subscription ID, subscription start date, subscription end date, transaction date, an is-recurring boolean, recurrence frequency in months, subscription amount, and the customer identifier.
Customer activity data is not optional here in practice: the docs ask for at least two activity records for 50% of the customers you want scored. Activity fields are primary key, timestamp, event name and event details.
Data mapped through the Subscription semantic activity type, with customer activities mapped through their own semantic type.
Less than 20% missing values across the fields you supply.
Two configuration numbers: days since a subscription ended before you count someone as churned, and how many days ahead to predict.
Output table carries ChurnScore (0–1) and IsChurn (binary at a 0.5 threshold).
Grades follow the same shape as transactional churn: A is 50%+ accuracy with churned predictions exceeding the historical average by 10% or more, B is the same accuracy with less than 10% above average, C is under 50% accuracy or below the historical average.
Retraining is on a schedule you set, monthly recommended. Results include model performance, a churn likelihood distribution and the most influential factors.
There's a sample data guide published for this model, which is the fastest way to get a working demo without touching client data.

When to use / skip

Use it where the client has genuine recurring contracts with defined terms — SaaS, memberships, insurance, maintenance plans, media subscriptions. The distinguishing feature is that non-renewal is an observable event with a date, which is what this model trains on. If churn at your client is inferred from absence of activity rather than an expiry date, you want transactional churn instead.

Skip it where the subscription book is small. A thousand profiles inside the prediction window is a real hurdle for enterprise B2B clients with a few hundred large accounts, and no amount of history compensates. Those clients are usually better served by a measure and a segment over renewal dates plus account manager judgement, and you should say so rather than forcing the model.

Also worth skipping when renewals are effectively automatic and cancellation is rare — heavily auto-renewing consumer subscriptions with 2% annual churn give the model very few positive examples, and you'll spend the engagement explaining why the grade is poor.

Configuration decisions

Days-since-end before a customer counts as churned. In practice this is the grace period the business already operates, and it varies wildly between clients. Get the number from finance or ops, not from IT.
Prediction window. Align it to the renewal cycle: predicting 90 days ahead on annual contracts only surfaces a quarter of the book at a time.
How to model upgrades, downgrades and plan changes. These arrive as subscription transactions and you have to decide whether a downgrade is a churn signal or normal behaviour.
Which activity sources to ingest to clear the "two records for 50% of customers" bar — usually product usage or portal logins, and that's a data engineering commitment.
Retrain cadence, and whether it runs before or after the monthly renewal batch. Retraining mid-cycle gives you a training set that looks unusual.
Whether to score at customer level or handle multi-subscription customers explicitly. The output is per profile, so a customer with several subscriptions gets one score.

Gotchas

The 1,000-profile requirement is measured within the prediction window, not across the whole database. A client with 5,000 lifetime customers but 600 active in the next 90 days does not qualify.
The activity data requirement catches people late. Teams configure subscription history, get to the activity step, and discover the usage telemetry lives in a system nobody planned to ingest.
Recurrence frequency is expressed in months. Weekly or fortnightly subscriptions don't map cleanly and need thinking about before you commit to the model.
Cancellations recorded only as a status change, with no end date written back, look like live subscriptions to the model. Check how the source system closes a contract before you trust the training set.
Changing either the churn definition or the window retrains the model and shifts every score. Anything downstream that assumes stable scores will move.
Model runs take hours on real volumes, and the input data usability report only exists after training completes. Your first run is your validation pass.

Consultant notes

Before scoping, ask for a count of subscriptions expiring inside the intended window. That single number decides whether this model is viable, and it's a five-minute query.
Use the published sample data guide to build the demo. It gives stakeholders a working picture while the real ingestion is still in flight, and it avoids demoing a grade C on half-loaded data.
Be blunt with the client that the model predicts non-renewal, not dissatisfaction. If they want the second thing, that's sentiment analysis or a survey programme, and it's a different conversation.
Show the influential factors to the retention team early. If the drivers don't match their intuition, either the data mapping is wrong or their intuition is, and both are worth knowing before go-live.
Check who acts on the output. A churn score that lands in a segment nobody works is the most common way these projects quietly fail after handover.

Worth another look if Microsoft relaxes the activity data requirement or the 1,000-profile minimum, which is what blocks most B2B subscription clients.