Skip to main content

Capstone Project: Complete ML System

Capstone Project Lifecycle
Real World Capstone - E-Commerce Churn Prediction

Project Overview

You’ll build a Customer Churn Prediction System - predicting which customers will leave a subscription service. This project synthesizes everything you’ve learned:
  • Data exploration and cleaning
  • Feature engineering
  • Model selection and evaluation
  • Deployment considerations

Part 1: Problem Definition

Business Context

A telecom company loses 15-20% of customers monthly. Each lost customer costs:
  • Revenue loss: $500-2000/year
  • Acquisition cost for replacement: $300-500
  • And the hidden cost: every churned customer who complains publicly damages future acquisition
Your Goal: Identify at-risk customers BEFORE they leave, so the retention team can intervene with targeted offers (discounts, service upgrades, dedicated support).
Why this problem matters: Churn prediction is a staple ML interview question because it tests everything — business framing, feature engineering, class imbalance handling, metric selection, and threshold optimization. If you can walk through this project end-to-end in an interview, you demonstrate production-ready thinking.

Success Metrics

Choosing the right metric is a business decision, not a technical one. Here, missing a churner (false negative) costs 500+inlostrevenue.Wastingaretentioncallonahappycustomer(falsepositive)costsmaybe500+ in lost revenue. Wasting a retention call on a happy customer (false positive) costs maybe 50 in labor. That asymmetry drives our metric priorities:

Part 2: Data Exploration

Exploratory Analysis


Part 3: Feature Engineering

Prepare for Modeling


Part 4: Model Development

Baseline Models

Hyperparameter Tuning


Part 5: Model Evaluation

Detailed Metrics

Feature Importance


Part 6: Business Impact Analysis


Part 7: Production Considerations

Model Serialization

A common mistake is saving only the model and forgetting the preprocessing artifacts. In production, you need everything required to go from raw customer data to a prediction — the scaler, the feature names, the threshold, and ideally the model version and training date.

Inference Pipeline

Monitoring Dashboard


Project Checklist

1

Problem Definition

✅ Clear business objective and success metrics
2

Data Exploration

✅ Understand data quality, distributions, and patterns
3

Feature Engineering

✅ Create meaningful features from domain knowledge
4

Model Development

✅ Compare multiple algorithms, tune hyperparameters
5

Evaluation

✅ Use appropriate metrics, analyze errors
6

Business Impact

✅ Translate ML metrics to business value
7

Production

✅ Plan for deployment, monitoring, and maintenance

🏆 Congratulations!

You've Completed the Capstone!

You’ve built a complete, production-ready ML system from scratch. You now have:
  • Technical Skills: Data exploration, feature engineering, model training, evaluation, and deployment
  • Business Acumen: Translating ML metrics to business impact
  • Production Mindset: Monitoring, maintenance, and continuous improvement
This project alone is portfolio-worthy for ML engineering roles!

📝 Portfolio Documentation Template

Project Summary (for your portfolio/resume)

Title: Customer Churn Prediction SystemBusiness Impact:
  • Identifies 70%+ of at-risk customers 2 weeks before churn
  • Enables targeted retention campaigns
  • Estimated $X00K annual savings in customer lifetime value
Technical Highlights:
  • End-to-end ML pipeline from raw data to production API
  • Comparison of 5+ algorithms (Logistic Regression, Random Forest, XGBoost, etc.)
  • Feature engineering creating 20+ derived features
  • Threshold optimization for business-aligned precision-recall tradeoff
  • Monitoring and alerting system for model drift
Technologies Used:
  • Python, scikit-learn, XGBoost, pandas, numpy
  • FastAPI for model serving
  • MLflow for experiment tracking
  • Docker for containerization

GitHub README Structure

Interview Talking Points

  1. “Walk me through this project”
    • Start with business problem (churn costs $X)
    • Explain data exploration findings
    • Discuss feature engineering decisions
    • Compare model approaches
    • Show business impact calculation
  2. “What was the biggest challenge?”
    • Class imbalance (70/30 split)
    • Feature engineering from raw transaction data
    • Choosing the right threshold for business needs
  3. “How would you improve it?”
    • Real-time predictions with streaming
    • A/B testing different interventions
    • Incorporating more data sources
    • Automated retraining pipeline

🔗 Complete ML Mastery Checklist

Skills You’ve Mastered Across This Course:You’re now ready for:
  • ML Engineer roles (junior to mid-level)
  • Data Scientist positions
  • AI/ML-focused software engineering
  • Further study in deep learning, NLP, or computer vision

What’s Next?

You’ve completed the capstone, but there’s more to learn! Let’s tackle real-world challenges.

Continue Learning

Handle datasets where 99% of data is one class

Deep Learning

Move on to neural networks, transformers, and LLMs

Interview Deep-Dive

Model monitoring is where most ML projects fail — the model gets deployed and nobody watches it. Here is the monitoring framework I would set up:
  • Prediction distribution monitoring. Track the distribution of predicted churn probabilities daily. If the model suddenly starts predicting 80% of customers as high-risk (when historically it was 15%), something has changed — either the data or the model. I would use Population Stability Index (PSI) to compare the current prediction distribution against a reference period. A PSI above 0.2 triggers an investigation.
  • Input feature drift detection. For each of the top 10 features by importance, monitor the mean, variance, and null rate on a daily cadence. A significant shift in any key feature (e.g., average tenure dropping because of a marketing campaign that acquired many new short-tenure customers) directly affects model performance. Alert when KS-test p-value drops below 0.01 for any feature.
  • Delayed ground truth monitoring. Churn labels arrive with a delay (you know someone churned 30-60 days after the prediction). Once labels are available, compute rolling precision, recall, and AUC on a weekly window. Plot these over time and alert when any metric drops more than 5% from the baseline.
  • Business outcome tracking. Track the retention team’s success rate on model-flagged customers. If the team is intervening on model-identified churners but the retention rate is not improving, either the model is flagging the wrong customers or the interventions are ineffective. This is the ultimate ground truth.
  • Retrain triggers. I would retrain when any of these conditions are met: AUC drops below 0.75 (the business-agreed threshold), PSI on predictions exceeds 0.25, a major business event occurred (new pricing, new product, acquisition), or on a fixed quarterly cadence regardless of metrics. The quarterly cadence catches slow drift that no single alert catches.
Follow-up: How would you handle the cold-start problem — new customers who have no historical data for the features your model depends on?For new customers, features like “tenure_months” and “total_charges” are near zero, and behavioral features like “tickets_per_month” are undefined. I would handle this in two ways. First, impute with cohort-level defaults: for a new customer on a month-to-month plan with fiber optic internet, use the median feature values from similar customers in the training data. Second, build a separate “new customer” model (or a model segment) trained specifically on data from customers in their first 30 days, using features available at signup: plan type, payment method, acquisition channel. This model handles the cold-start period, then the customer transitions to the main model after 30-60 days of behavioral data.
This is where explainability meets production engineering. The business team does not care about SHAP theory — they need actionable explanations that a retention agent can use in a phone call.
  • Use SHAP values for individual explanations. For each flagged customer, compute SHAP values to identify the top 3-5 factors driving the churn prediction. Translate these into business language: “This customer is high-risk primarily because they are on a month-to-month contract (contributing 0.15 to churn probability), have filed 5 support tickets in the last month (contributing 0.12), and have not activated any add-on services (contributing 0.08).”
  • Pre-compute explanations in batch. Computing SHAP values at inference time adds latency. For a daily batch scoring job, compute SHAP values alongside predictions and store them. The retention team dashboard pulls pre-computed explanations, not real-time calculations.
  • Template the explanations. Create human-readable templates: “This customer is [risk level] because of [top factor], [second factor], and [third factor]. Recommended action: [action based on top factor].” The action mapping is domain logic: if the top factor is “month-to-month contract,” recommend an annual plan discount. If it is “many support tickets,” recommend a dedicated support escalation.
  • Calibrate the probability outputs. Gradient boosting probabilities are not always well-calibrated. A predicted 0.7 might not actually mean a 70% chance of churning. Use Platt scaling or isotonic regression to calibrate probabilities so the business team can trust the numbers. Calibrated probabilities enable statements like “of all customers we flag as 70%+ risk, historically 68-72% actually churn.”
Follow-up: What if SHAP explanations contradict business intuition — for example, SHAP says “high monthly charges reduces churn probability”?This happens and it is important to investigate rather than override. The model might be correct: high-spending customers who are still paying may be getting more value from the service and are less likely to leave. The relationship could also be confounded — high-spending customers might have longer tenure, and it is the tenure doing the heavy lifting while charges are correlated. I would check partial dependence plots to see the marginal effect of monthly charges, and SHAP interaction values to see if the effect changes depending on tenure. If the explanation genuinely misleads the retention team, I would either retrain the model with feature constraints (monotonic constraints in XGBoost can enforce “higher charges should not decrease predicted churn risk”) or simply exclude that feature from the explanation output while keeping it in the model.
This is where the rubber meets the road. A model’s AUC means nothing if deploying it does not actually reduce churn or increase revenue.
  • Randomize at the customer level, not the prediction level. Randomly assign customers to treatment (model-flagged customers receive retention intervention) and control (business-as-usual, no model-informed intervention). This isolates the model’s impact from other factors like seasonal effects or marketing campaigns.
  • Stratify the randomization. Ensure both groups have similar distributions of churn risk, contract type, tenure, and revenue. If the treatment group accidentally gets more month-to-month customers, the results will be confounded.
  • Define the primary metric before starting. The primary metric should be customer retention rate (or inversely, churn rate) measured 90 days after the experiment starts. Secondary metrics: revenue retained, customer lifetime value, cost per retained customer. Define these upfront to avoid p-hacking after seeing results.
  • Account for the cost of intervention. If the retention team calls 500 flagged customers and offers 50discounts,thatcosts50 discounts, that costs 25,000. The model is only valuable if the retained revenue exceeds the intervention cost. Calculate the ROI: (retained_customers x average_lifetime_value - intervention_cost) / intervention_cost.
  • Run the test long enough. Churn is a slow process. A 2-week A/B test will not capture the full effect. I would run for at least 90 days to observe whether flagged-and-contacted customers actually stay, or if the intervention merely delayed their departure by a few weeks.
  • Watch for interference effects. If retained customers talk to their friends in the control group, or if the retention team’s capacity is limited and they start prioritizing, the treatment effect can leak between groups. Use well-separated cohorts if possible.
Follow-up: The A/B test shows the model group has 3% lower churn but the result is not statistically significant. What do you do?First, check the power analysis. A 3% reduction in a 15% base churn rate requires a large sample size to detect with 95% confidence. If the experiment was underpowered (too few customers or too short), extend it. Second, look at the effect size by segment — the overall 3% might mask a 10% reduction in high-risk customers and zero effect on low-risk customers. If the model is highly effective for the top decile of predicted churn, that is a deployable result even if the overall average is not significant. Third, calculate the expected business value even with uncertainty. If the 95% confidence interval for churn reduction is [0.5%, 5.5%], the worst case still saves money, so deployment may be justified from a business perspective even without traditional statistical significance.