Customer Churn Quickstart Lab

Project context

Create an end-to-end churn workflow that not only predicts risk but also explains which customers should be prioritized by the retention team. Churn prediction is one of the most common real-world classification problems, and it is a great vehicle for learning why "accuracy" is often the wrong metric: a model that always predicts "no churn" can look 90% accurate while catching zero actual churners. Nearly every subscription business, telecom, SaaS product, and bank runs some version of this model, which is exactly why it is one of the most frequently asked take-home assignments and interview case studies in applied data science. This project walks you through the full lifecycle that a real churn team follows, not just the model-fitting step that most beginner tutorials stop at. You will start by locking down what the label actually means, because label ambiguity is one of the most common and hardest-to-detect bugs in real projects: if "1" quietly means different things in different exports, every metric downstream is built on sand. From there you will practice leak-free feature engineering, which forces you to ask a question every practitioner needs to internalize: would this column have been known before the customer churned, or does it secretly encode the outcome? Getting this wrong is the single most common reason beginner models look great in a notebook and then fail embarrassingly in production. You will train a reproducible baseline classifier, which teaches you why fixing a random seed and split strategy is not a technicality but the only way to make later comparisons meaningful. The evaluation step is where this project earns its "advanced beginner" label: instead of reporting a single accuracy number, you will build and interpret a confusion matrix, understand precision and recall as a genuine trade-off rather than two more metrics to report, and connect that trade-off to a real business cost -- missing a churner is usually far more expensive than one unnecessary retention call. You will then explicitly choose a decision threshold and justify it, which is the step most tutorials skip entirely but that a hiring manager will almost always ask you about. Finally, you will translate raw probabilities into something a retention team could act on the same day: a ranked, banded list of customers with a recommended action attached to each one. This last step matters because a model nobody acts on has zero business value no matter how good its ROC curve looks. By the end of this project you will be comfortable with the vocabulary and reasoning that shows up in almost every classification interview question -- imbalanced classes, leakage, threshold tuning, recall-oriented evaluation -- and you will have a concrete artifact, a ranked risk table with a documented threshold rationale, that demonstrates you understand the gap between "a model that scores well" and "a model a business can actually use."