DATA SCIENCE CAPSTONE PROJECT
Customer Churn Prediction & Retention
Intelligence System
An End-to-End, Full-Stack Data Science Project for NexaTel Communications
Covers: SQL & Databases • EDA • Feature Engineering • Machine Learning • Web Development •
Deployment
Suggested Duration: 1.5 Weeks | Individual Project | Resume & Portfolio Ready
1. Project Overview
This capstone project simulates the real, end-to-end work of a data scientist inside a company — not an
isolated notebook exercise. You will be handed a business problem, raw data sitting in a database, and be
expected to carry it through every stage a working data scientist owns: understanding the business
question, querying and shaping data in SQL, exploring and cleaning it, engineering features, training and
evaluating machine learning models, and finally shipping a real, usable tool a non-technical employee
could open in a browser. By the end, you will have a live, deployed application and a GitHub repository
you can put directly on your resume and speak to confidently in interviews.
Learning Objectives
• Design a normalized relational database schema and write real, business-driven SQL queries
• Perform structured, business-focused exploratory data analysis (EDA)
• Engineer and justify features that genuinely improve model performance
• Correctly scale and preprocess data — and understand when and why each step matters
• Train, tune, and compare multiple ML algorithms, and choose the right evaluation metric for an
imbalanced business problem
• Explain model predictions in business language, not just numbers
• Build a working frontend + backend application around a trained model
• Deploy a complete application on free-tier hosting so it is publicly usable
• Package the entire project professionally for a resume, portfolio, and GitHub
What You Must Do Yourself vs. Where AI Tools Are Allowed
This project is graded on your reasoning and understanding, not just on a working output. Use the table
below as the rule of thumb.
Project Area Rule
Do this yourself and be ready to explain every decision. You may
Business understanding, EDA, feature engineering,
use AI to look up concepts, but the analysis, choices, and
model training & evaluation
reasoning must be your own.
Do this yourself — it is one of the most tested skills in data
Database schema design & SQL queries
science interviews.
Your choice: code it manually, or use any AI coding tool/agent
Frontend & backend web development (e.g., Antigravity, Cursor, GitHub Copilot, Claude, ChatGPT). Either
is acceptable.
Any tool or assistant is allowed, but you must end up with a real,
Deployment
working, public link.
2. The Business Scenario
Company Background
NexaTel Communications is a mid-sized regional telecom provider offering mobile, home internet, and
streaming bundle services to roughly 500,000 subscribers. NexaTel operates in a competitive market
where switching providers is easy and largely painless for customers — which makes customer retention
one of the company's most important, and most expensive, ongoing challenges.
The Problem
Over the last two fiscal quarters, NexaTel's customer churn rate has climbed to roughly 26.6%, translating
into an estimated multi-million dollar loss in recurring monthly revenue. The VP of Customer Retention
does not have a way to know, ahead of time, which customers are about to leave — today, the company
only finds out after a customer has already cancelled. Retention offers (discounts, plan upgrades,
proactive support calls) are currently sent out reactively and inconsistently, which wastes budget on
customers who were never going to leave, while genuinely at-risk customers slip away unnoticed.
What the Company Is Asking You to Deliver
1. An analysis identifying which customers are churning, and why — in plain business language
2. A predictive model that flags high-risk customers before they cancel
3. A simple internal web tool the retention team can use daily, with no data science background
required
4. Clear, actionable explanations retention agents can use to justify an offer or intervention
Stakeholders & What They Care About
Stakeholder What They Care About
VP of Customer Retention Lowering the churn rate and protecting recurring revenue
Retention Agents A simple tool with a clear risk score and reasons — not raw model output
Finance Team A concrete revenue-at-risk figure they can put in a budget conversation
IT / Engineering Something reasonably clean and documented enough to eventually integrate
3. Dataset & Resources
The Dataset
For this project, NexaTel has provided an anonymized extract of 7,043 customer records with 21 fields
covering demographics, account details, subscribed services, and churn status. This maps directly to the
widely-used IBM / Kaggle Telco Customer Churn dataset — use it as your “company database export” for
this project:
[Link]
Column Dictionary (Key Fields)
Field Description
customerID Unique customer identifier
gender, SeniorCitizen, Partner, Dependents Customer demographics
tenure Number of months the customer has stayed with the company
PhoneService, MultipleLines Phone service details
InternetService DSL, Fiber optic, or None
OnlineSecurity, OnlineBackup,
Add-on internet services
DeviceProtection, TechSupport
StreamingTV, StreamingMovies Streaming add-ons
Contract Month-to-month, One year, or Two year
PaperlessBilling, PaymentMethod Billing details
MonthlyCharges, TotalCharges Billing amounts
Churn Target variable — Yes / No
Tools & Libraries
Category Suggested Tools
Language Python 3.10+
SQLite (simplest, file-based, free) or free-tier PostgreSQL (Supabase,
Database
[Link]) or MySQL
Data & EDA pandas, numpy, matplotlib, seaborn, plotly
SQL from Python sqlite3 / SQLAlchemy / psycopg2
Feature engineering & preprocessing scikit-learn, pandas
Imbalanced data imbalanced-learn (SMOTE)
Modeling scikit-learn, XGBoost, LightGBM
Category Suggested Tools
Model tuning GridSearchCV / RandomizedSearchCV / Optuna
Explainability SHAP
Backend Flask or FastAPI (or [Link]/Express if preferred)
Frontend HTML/CSS/JS, React, or Streamlit
Version control Git + GitHub
Render, Railway, Vercel, Netlify, Hugging Face Spaces, Streamlit Community
Deployment
Cloud
4. Project Pipeline Overview
The full project moves through ten phases. Each is explained in detail in Section 5.
Phase Deliverable
0 — Business Understanding Problem statement + business questions
1 — Database & SQL Normalized schema + SQL query file
2 — Exploratory Data Analysis EDA notebook + written insights summary
3 — Feature Engineering Engineered feature set + justification notes
4 — Preprocessing & Scaling Clean, scaled, leakage-free train/test data
5 — Model Training & Evaluation Trained models + comparison report + [Link]
6 — Explainability (recommended) SHAP analysis, per-customer “reasons”
7 — Web Application Working frontend + backend, running locally
8 — Deployment Live, public URL
9 — Documentation README + case study + resume bullets
5. Step-by-Step Instructions
This is the core of the project brief. Work through each phase in order — each one builds on the last.
Phase 0 — Business Understanding
Goal
Translate a vague business complaint into a specific, measurable data science problem.
Steps
1. Rewrite the scenario. Read the business scenario in Section 2 and rewrite it in your own words as a
formal 2–3 sentence problem statement.
2. Define success. Define your target variable (Churn: Yes/No) and decide which type of error costs the
business more — missing a customer who churns, or false-alarming on one who won't. This decision will
drive your metric choice later.
3. List business questions. Write 8–10 business questions your analysis should answer, e.g. “What is the
overall churn rate?”, “Does contract type affect churn?”, “Are customers with tech support less likely to
churn?”
4. Estimate revenue at risk. Multiply churned customers × average MonthlyCharges to produce a dollar
figure this becomes your project's headline statistic.
Deliverable
A one-page Problem Statement document (Markdown or PDF).
Phase 1 Database Design & SQL
Goal
Practice real database skills — in most companies, no one hands you a clean CSV. They hand you a
database.
Steps
1. Set up a database. Simplest option: SQLite (no server, one file). Or use a free cloud PostgreSQL
instance (Supabase or [Link], free tier).
2. Design a normalized schema. Split the single flat CSV into logical tables (aim for 3rd Normal Form),
for example: customers (customer_id, gender, senior_citizen, partner, dependents, tenure), accounts
(customer_id, contract, paperless_billing, payment_method, monthly_charges, total_charges), services
(customer_id, phone_service, internet_service, online_security, tech_support, streaming_tv,
streaming_movies, …), and churn_status (customer_id, churn).
3. Load the data. Write a Python/SQL script that reads the CSV, splits it according to your schema, and
loads it into these tables.
4. Write 12+ business SQL queries. Save queries that answer real business questions, e.g.: overall churn
rate; churn rate by contract type; churn rate by internet service type; average tenure of churned vs.
retained customers; average monthly charges of churned vs. retained customers; the top 5 customer
segments (contract × payment method) with the highest churn; total monthly revenue at risk; churn rate
for customers with tenure under 6 months and no tech support; correlation between number of
subscribed services and churn (using JOINs across your tables).
5. Document your queries. Save all queries in a single .sql file, with a comment above each one
explaining the business question it answers.
Deliverable
[Link] (table definitions), [Link] (business queries with comments), and a short bullet-point SQL
findings summary.
Phase 2 Exploratory Data Analysis (EDA)
Goal
Understand the data deeply before touching a model — this is where most of a data scientist's real
insight comes from.
Steps
1. Load from your database, not the raw CSV — pull your data into pandas via the SQL layer you built in
Phase 1.
2. Univariate analysis. Look at the distribution of tenure, MonthlyCharges, TotalCharges, and the overall
churn rate as a percentage.
3. Bivariate analysis. Plot churn rate against each categorical variable (contract, internet service,
payment method, etc.) using grouped bar charts.
4. Correlation analysis. Build a correlation heatmap of numeric features and check for multicollinearity
(e.g., tenure vs. TotalCharges).
5. Find data quality issues. Look for missing values, wrong data types (TotalCharges is often stored as
text with blank entries in this dataset — find and handle it), duplicate IDs, and outliers.
6. Segment analysis. Cross-tabulate churn against two or more variables at once (e.g., Contract ×
Tenure buckets) to find your single most at-risk customer segment.
7. Write a plain-language insights summary. One page, no code — written the way you would actually
email it to the VP of Retention.
Deliverable
An EDA notebook (01_eda.ipynb) with visuals, plus a written insights summary.
Phase 3 Feature Engineering
Goal
Turn raw columns into signals a model can actually learn from.
Steps
1. Fix issues found in EDA. Handle the blank TotalCharges values (typically customers with tenure = 0)
and any other data quality problems.
2. Create derived features, for example: tenure_group (bucketed into 0–12, 13–24, 25–48, 49+
months); total_services (count of subscribed add-on services per customer); avg_monthly_spend_ratio
(TotalCharges ÷ tenure, handled carefully for tenure = 0); a combined risk flag (e.g., short tenure +
month-to-month contract + no tech support); a payment-method risk flag (manual/check payments
often correlate with churn).
3. Encode categorical variables. One-hot encode nominal variables; use ordinal encoding where order
genuinely matters (e.g., contract length).
4. Justify every new feature. Write 1–2 sentences per feature: why you expect it to help, and whether
your EDA supports that.
5. Check for data leakage. Make sure no feature indirectly encodes the target — nothing computed
from information that would only exist after a customer has already churned.
Deliverable
A feature engineering notebook/script, plus a short table listing each engineered feature and its
justification.
Phase 4 Preprocessing & Scaling
Goal
Prepare the data correctly for modeling — and understand why each step matters, not just run it.
Steps
1. Split first. Create a stratified train/test split (churn is imbalanced) before doing anything that “looks”
at the target.
2. Scale correctly. Fit your scaler (StandardScaler or MinMaxScaler) on the training set only, then
transform both train and test. Never fit a scaler on test data — this is a classic mistake, and interviewers
ask about it directly.
3. Know which models need scaling. Write a short note on which algorithms need scaling (Logistic
Regression, SVM, KNN) and which don't (tree-based models like Random Forest and XGBoost).
4. Handle class imbalance. Check the churn / no-churn ratio, then apply either class_weight='balanced'
or SMOTE (from imbalanced-learn) — fit only on the training data.
5. Save your processed datasets so that modeling is reproducible without re-running preprocessing
every time.
Deliverable
A preprocessing script/notebook, plus saved, reproducible train/test files.
Phase 5 Model Training & Evaluation
Goal
This is your core deliverable as a data scientist: train, evaluate, and defend a model choice.
Steps
1. Train at least 4 models: Logistic Regression (interpretable baseline), Random Forest, Gradient
Boosting (XGBoost or LightGBM), and one more model of your choice (SVM, KNN, etc.).
2. Evaluate every model on: Accuracy, Precision, Recall, F1-score, ROC-AUC, and a Confusion Matrix.
Explain in writing why Recall/F1 matter more than Accuracy for this problem (the classes are
imbalanced, and missing a churner is expensive).
3. Compare visually. Plot ROC curves for all models on a single chart.
4. Tune your best candidates. Take your two best models and tune hyperparameters with GridSearchCV
or RandomizedSearchCV (e.g., tree depth, n_estimators, learning rate, regularization strength).
5. Choose and justify a final model. Not just “it had the highest score” — state which metric you
optimized for and why that is the right tradeoff for this business problem.
6. Save your final model. Export [Link] along with your fitted scaler and encoder objects — you will
need all of them again at prediction time.
Deliverable
A modeling notebook with full comparisons, a model comparison table, and [Link] (+ [Link],
[Link]).
Phase 6 Model Explainability (Recommended)
Goal
Be able to explain why a specific customer is flagged — not just that they are.
Steps
1. Compute global feature importance using SHAP on your final model — which features drive churn
most overall?
2. Compute per-customer SHAP values so that for any single prediction, you can show the top 3 factors
pushing that customer toward or away from churn.
3. Carry this into your app. This “why” is what turns your web app from a black box into a real business
tool — used directly in Phase 7.
Deliverable
A SHAP summary plot, plus logic that generates a short “top reasons” explanation per prediction.
Phase 7 Building the Web Application
Goal
Ship something a non-technical retention agent could actually use.
Steps
1. Design the tool. A form where an agent enters or looks up a customer's details and instantly sees a
churn risk score, a risk level (Low/Medium/High), and — if you completed Phase 6 — the top reasons
and a suggested retention action.
2. Build the backend. A Flask or FastAPI service that loads [Link] (plus your scaler/encoder), exposes
a /predict endpoint, and returns a JSON prediction.
3. Build the frontend. Any framework works — a clean form and result display is enough; a small
dashboard tab summarizing your EDA findings is a strong bonus.
4. Tooling choice is yours. Build it by hand, or use an AI coding tool/agent (e.g., Antigravity, Cursor,
Copilot, Claude, ChatGPT) to generate it — as long as you understand what it built and can explain it.
5. Test locally, thoroughly. Try valid inputs, edge cases, and unusual combinations (e.g., a customer
with tenure = 0) before moving on.
Deliverable
A working full-stack app running locally, in a clean folder structure (backend/ and frontend/), with a
[Link] or [Link].
Phase 8 Deployment
Goal
Make it live and publicly reachable — a link you can put on your resume.
Steps
1. Push to GitHub. A clean, public repository — use a .gitignore and never commit large data files or
secrets.
2. Deploy the backend. Free options: Render, Railway, or PythonAnywhere (Render is the most
common free choice for Flask/FastAPI).
3. Deploy the frontend. Free options: Vercel, Netlify, or GitHub Pages. If you built the whole thing in
Streamlit, deploy the single app to Streamlit Community Cloud or Hugging Face Spaces instead.
4. Connect frontend to backend. Point the frontend at your deployed backend's public URL (never
localhost), then redeploy.
5. Test the live link end-to-end, exactly the way a stranger encountering it for the first time would.
Deliverable
A live, public URL, plus the public GitHub repository link.
Phase 9 Documentation & Resume Packaging
Goal
Package the work so it actually helps you get hired.
Steps
1. Write a strong [Link]: problem statement, your approach, tech stack, key results with real
numbers (e.g., “Achieved 84% recall on the churn class, projected to help retain ~$X in at-risk monthly
revenue”), screenshots, and the live demo link.
2. Write a one-page case study for LinkedIn/portfolio, structured as Problem → Approach → Key Insight
→ Result → Business Impact, written for a non-technical reader.
3. Draft 2–3 resume bullet points based on this project, using real, defensible numbers from your own
work.
4. Record a 2–3 minute demo video walking through the live app (optional, but strongly
recommended).
Deliverable
A polished GitHub repository, a case study writeup, and finished resume bullet points.
7. Free Deployment Platforms — Cheat Sheet
Platform Best For Notes
Free web service tier; sleeps after inactivity,
Render Backend (Flask/FastAPI)
wakes on request
Vercel Frontend (React/static) Fast global CDN, generous free tier
Similar to Vercel, simple drag-and-deploy option
Netlify Frontend (static/JS)
too
GitHub Pages Static frontend only No backend/server-side support
Free CPU tier; great single-deploy option for ML
Hugging Face Spaces Full app (Streamlit/Gradio)
apps
One-click deploy directly from a GitHub repo,
Streamlit Community Cloud Streamlit apps
free
Railway Backend Free tier with usage limits
Use if you want a cloud database instead of local
Supabase / [Link] Cloud PostgreSQL
SQLite
8. Final Deliverables Checklist
☐ Problem statement document (Phase 0)
☐ [Link] + [Link] with 12+ commented business queries (Phase 1)
☐ EDA notebook + written insights summary (Phase 2)
☐ Feature engineering notes with justifications (Phase 3)
☐ Preprocessing pipeline / saved train-test data (Phase 4)
☐ Model comparison report + final [Link] (+ scaler/encoder) (Phase 5)
☐ SHAP explainability analysis — recommended (Phase 6)
☐ Working full-stack web app, tested locally (Phase 7)
☐ Live, public deployed URL (Phase 8)
☐ Public GitHub repository with a strong README
☐ One-page case study for portfolio/LinkedIn
☐ Finished resume bullet points
9. Grading Rubric
Component Weight
Business Understanding & Problem Framing 5%
Database Design & SQL 15%
EDA & Insights 15%
Feature Engineering 10%
Model Training, Evaluation & Justification 25%
Web Application (Frontend + Backend) 15%
Deployment (must be live and working) 10%
Documentation & Resume Packaging 5%
Total 100%
10. Resources & Links
• Dataset — Telco Customer Churn (Kaggle) — [Link]
customer-churn
• SQL practice — SQLBolt — [Link]
• SQLite documentation — [Link]
• Supabase — free cloud PostgreSQL — [Link]
• pandas documentation — [Link]
• scikit-learn documentation — [Link]
• imbalanced-learn (SMOTE) — [Link]
• XGBoost documentation — [Link]
• SHAP documentation — [Link]
• Flask documentation — [Link]
• FastAPI documentation — [Link]
• Streamlit documentation — [Link]
• Render deployment docs — [Link]
• Vercel deployment docs — [Link]
• Hugging Face Spaces docs — [Link]
11. Final Notes
This project is intentionally built to mirror what a junior data scientist actually does in their first six
months on the job: a messy business problem, a database instead of a clean CSV, an ambiguous set of
requirements, and an expectation that something real gets shipped not just a notebook with a high
accuracy score. Treat every phase as something you would need to defend out loud in an interview: why
this feature, why this metric, why this model, why this deployment choice.
When it's finished, this project should be the first thing you show in an interview: a live link, a clean
GitHub repo, and a one-page story that ties a business problem to a measurable result. Good luck.