How to predict customer churn
Customer churn prediction is the process of estimating whether an active customer will cancel, stop buying or become inactive during a defined future period. A workable target is:
"Will this active customer cancel within the next 60 days?"
For a scoring date of January 1, 2025, the model should use data recorded on or before that date and predict the customer's outcome during the following 60 days.
The process is:
- Define the churn event and prediction horizon.
- Create historical customer snapshots.
- Train a transparent baseline model, such as logistic regression.
- Compare it with a tree-based model, such as gradient boosting.
- Evaluate precision, recall, lift, calibration and expected profit.
- Send risk scores to customer success, marketing or sales workflows.
- Test whether the chosen retention action changes the outcome.
A churn model estimates who is likely to leave. It does not show which retention action will work. That requires an experiment or an uplift model.
What Is Customer Churn Prediction?
Customer churn prediction estimates the probability that a customer will cancel, stop purchasing or become inactive during a defined future period.
Avoid targets such as "predict churn soon." A model needs a clear:
- Churn event: cancellation, account closure, non-renewal or inactivity
- Prediction date: when the score is generated
- Prediction horizon: the next 30, 60, 90 or 180 days
- Eligible population: customers who are active and contactable on the prediction date
Churn can be voluntary, such as a customer cancelling, or involuntary, such as a failed payment. These events often need different interventions and may be better handled by separate models.
At a Glance
| Decision | Recommended approach |
|---|---|
| Initial model | Logistic regression for a transparent baseline |
| Stronger tabular model | Gradient-boosted trees or another tree ensemble |
| When timing matters | Survival analysis or another time-to-event model |
| Data split | Time-based training, validation and test sets |
| Primary metrics | Precision at a contact limit, recall, lift and calibration |
| Business threshold | Expected incremental profit, not a default 0.5 probability |
| Main risk | Data leakage from information recorded after the prediction date |
| Operational output | Customer ID, churn probability, risk segment and recommended action |
Step 1: Define the Churn Label and Prediction Window
The model is only as useful as the label it learns.
For a subscription company, the label might be:
churn = 1 if the customer cancels within 90 days after the scoring date
churn = 0 if the customer remains active for the full 90-day period
For an ecommerce company, churn might mean that a customer makes no purchase within 180 days. The right period depends on the normal purchase cycle. A customer who buys once a year should not be labelled as churned after 30 days of inactivity.
Use three periods in the customer timeline:
Historical feature window → Prediction date → Future outcome window
For example:
- Historical feature window: customer behaviour during the previous 90 days
- Prediction date: January 1
- Outcome window: whether the customer churns by April 1
Only use information available on or before January 1 when creating the features.
Step 2: Collect the Right Customer Data
Useful churn features describe customer engagement, value, friction and relationship history.
| Feature group | Example variables |
|---|---|
| Customer profile | Segment, region, industry, acquisition channel, tenure |
| Product usage | Login frequency, active days, feature adoption, usage decline |
| Transaction history | Order frequency, recency, average order value, refunds |
| Subscription | Plan, renewal date, contract length, upgrade or downgrade history |
| Billing | Failed payments, overdue invoices, price changes |
| Customer support | Ticket count, unresolved tickets, response time, complaint topics |
| Engagement | Email opens, campaign clicks, webinar attendance, survey responses |
| Relationship | Account manager contact, health score, last meeting date |
| Sentiment | Review sentiment, support sentiment, cancellation reasons |
Changes over time are often more informative than static values. Examples include:
- Percentage decline in weekly usage
- Days since the last purchase
- Number of support tickets in the past 30 days
- Increase in payment failures
- Reduction in the number of active users
- Difference between current and previous-month engagement
Low usage does not always mean high churn risk. It may be normal for a particular customer segment. A sudden decline against the customer's own baseline can be more useful than a comparison with the whole customer base.
Step 3: Build a Historical Training Dataset
Each training row should represent one customer at one historical prediction date.
| customer_id | snapshot_date | tenure_months | usage_change_30d | support_tickets_30d | contract_type | churn_next_90d |
|---|---|---|---|---|---|---|
| C001 | 2025-01-01 | 14 | -42% | 3 | Monthly | 1 |
| C002 | 2025-01-01 | 28 | +8% | 0 | Annual | 0 |
You can create multiple historical snapshots for the same customer, but future outcomes must not appear in earlier rows.
The dataset should contain:
- A customer identifier
- A snapshot or scoring date
- Features calculated only from historical data
- A binary churn label or time-to-churn outcome
- Revenue, margin or customer lifetime value if you want to rank customers by economic value
Separate training and test data by time. For example:
- Training: January 2024 to December 2024
- Validation: January 2025 to March 2025
- Test: April 2025 to June 2025
A random split can produce an overly positive result when customer behaviour changes over time. A future test period gives a better indication of how the model will perform after deployment.
Step 4: Choose the Right Type of Churn Model
Logistic Regression Is the Best Baseline
Logistic regression estimates the probability that a customer will churn within the selected horizon. It is quick to train, relatively easy to explain and useful for showing whether a feature has a positive or negative relationship with churn.
Use it when:
- Stakeholders need clear explanations
- The dataset is small or moderate in size
- You need a dependable benchmark
- Retention teams need to understand the main risk factors
Gradient-Boosted Trees Are a Stronger Next Test
Tree-based models can capture nonlinear relationships and interactions, such as:
- Usage decline being more important for new customers
- Support problems being more serious for high-value accounts
- Payment failures being especially predictive near renewal
AWS's customer churn tutorial demonstrates a standard process involving feature preparation, multiple classification models and analysis of the factors associated with churn. Google BigQuery ML also supports logistic regression, boosted trees, random forests and other model types for prediction.
Compare the tree-based model with logistic regression using the same time-based validation and test periods. A more complex model is only useful if it improves ranking, calibration or business results enough to justify the additional explanation and maintenance work.
Survival Analysis Is Better When Timing Matters
A binary model answers:
"Will this customer churn within 90 days?"
A survival model can estimate:
"How long is this customer likely to remain active, and how does the risk change over time?"
Survival analysis is useful when customers have different observed tenures or when many customers have not churned by the end of the dataset. Research on churn modelling notes that fixed-horizon classification can hide when churn happens, while survival methods model time-to-event and handle censored observations.
Step 5: Evaluate the Model Using Business Metrics
Accuracy is rarely enough for churn prediction. If only 5% of customers churn, a model that predicts "no churn" for everyone can achieve 95% accuracy while producing no useful retention list.
Precision
Precision answers:
Of the customers predicted to churn, how many actually churned?
High precision matters when retention actions are expensive or intrusive.
Recall
Recall answers:
Of all customers who churned, how many did the model identify?
High recall matters when missing a likely churner costs more than contacting some customers unnecessarily.
Precision-Recall AUC
Precision-recall analysis is useful when churn is an imbalanced classification problem. The precision-recall curve shows the tradeoff between finding more churners and creating more false positives.
Lift
Lift compares the churn rate in a selected group with the average churn rate.
For example:
Top 10% risk segment churn rate: 24%
Overall customer churn rate: 6%
Lift = 24% ÷ 6% = 4x
A 4x lift means the highest-risk 10% of customers churn at four times the average rate.
Calibration
A calibrated model produces probabilities that broadly match actual outcomes. If 100 customers receive a 70% churn probability, about 70 of them should churn during the defined horizon.
Calibration matters when scores feed into financial calculations or when you assign different retention treatments to different risk bands.
Step 6: Set the Retention Threshold Using Expected Value
Do not automatically contact every customer with a churn probability above 50%. That threshold is a modelling convention, not a business decision.
A basic prioritisation formula is:
Expected value =
Probability of churn
× Customer value at risk
× Probability the intervention prevents churn
− Cost of intervention
Example:
- Churn probability: 35%
- Contribution margin at risk: $600
- Estimated probability that the intervention saves the customer: 25%
- Intervention cost: $20
Expected value = 0.35 × $600 × 0.25 − $20
Expected value = $32.50
This customer may be worth contacting because the estimated value is positive.
Use incremental retention impact where possible. A discount sent to a customer who would have stayed anyway is not a successful retention intervention. Randomised holdout groups can show whether an offer, call or product change actually alters the outcome.
Step 7: Make Predictions Usable
A churn score does not tell a retention team what to do. Each prediction should include context.
A useful output might contain:
| Field | Example |
|---|---|
| Customer | Acme Corporation |
| Churn probability | 0.72 |
| Risk segment | High |
| Main signals | Usage down 48%, two unresolved tickets, renewal in 21 days |
| Customer value | $18,000 annual margin |
| Suggested action | Executive check-in and support escalation |
| Contact limit | Prioritise this week |
Treat risk explanations as signals, not proof of causation. A model may find that customers with several support tickets churn more often, but that does not prove the tickets caused the churn.
The CRM or customer success platform should also show who owns the next step, when the customer should be contacted and what result should be recorded.
Common Customer Churn Prediction Mistakes
Using Information That Was Unavailable at Scoring Time
This is data leakage. Examples include:
- Cancellation confirmation status
- A final cancellation survey
- A refund issued after cancellation
- An account closure reason
- A support ticket created after the customer decided to leave
Google's machine learning guidance says that training features must be available at prediction time. It also recommends monitoring for training-serving skew and label leakage in production systems.
Using a Random Data Split
Randomly mixing old and recent customers can allow the model to learn patterns that would not be available when making future predictions. Use a time-based test set that represents the period after training.
Optimising for AUC While Ignoring Contact Capacity
A model can rank customers well and still be impractical if the retention team can contact only 500 customers per week. Measure precision, recall and lift at the actual operating limit, such as the top 5% or top 1,000 customers.
Treating Every Churner the Same
Different churn causes call for different responses:
- Price sensitivity may require plan changes
- Low adoption may require onboarding or training
- Product dissatisfaction may require service recovery
- Payment failure may require billing support
- Contract renewal risk may require account management
The prediction workflow should pass the likely risk signals to the person who can respond to them.
Failing to Monitor Model Performance
Customer behaviour, product usage and pricing change over time. Monitor:
- Churn rate by month
- Precision and recall when labels mature
- Calibration by risk band
- Feature distributions
- Prediction volume
- Performance by customer segment
- Retention outcomes for contacted and holdout groups
Google's production machine learning guidance recommends monitoring the data pipeline, model age, feature behaviour, training-serving skew and live model quality. Deployment is the start of ongoing measurement, not the end of the project.
A Practical Implementation Sequence
For most teams, use this order:
- Define one clear churn event and prediction horizon.
- Create a reliable customer snapshot table.
- Build a rules-based benchmark.
- Train logistic regression.
- Compare it with gradient-boosted trees.
- Test it using a future time period.
- Measure lift and precision at the team's contact capacity.
- Add customer value and intervention cost.
- Send scores to the CRM or customer success platform.
- Run holdout experiments to measure incremental retention.
- Retrain and monitor the model as customer behaviour changes.
The operating standard is straightforward: use time-correct data, judge the model at the capacity your team actually has, set thresholds with economics rather than convention, and test retention actions against a control group. The most complex algorithm is not automatically the most useful one.