Capstone Project Brief — Cricket Streaming Churn — Data Analysis & Feature Engineering

Welcome to the Capstone

You have spent five modules mastering the full data-analysis and feature-engineering toolkit: exploratory data analysis, data cleaning and preprocessing, feature engineering from domain knowledge, feature selection, and production-grade scikit-learn pipelines. Now you put every technique together in one end-to-end project — predicting subscriber churn for CricketStream, a fictional cricket live-streaming service. This capstone mirrors the reality of applied data science, where no single technique wins but the disciplined combination of all of them does. You will work through the full workflow from raw behavioural data to a tested, serialised production pipeline, with leakage prevention at every stage and cricket-domain insight woven throughout.

Analogy🏏Cricket

🏏 Think of it like cricket: The capstone is the final Test match after five intensive training camps — each camp sharpened one skill, and the Test match demands all of them together in real match conditions. Just as a batsman who mastered footwork, shot selection, reading spin, and fitness must use all of them simultaneously against a quality attack, you must deploy EDA, cleaning, engineering, selection, and pipeline skills simultaneously against real-complexity data. Just as a single isolated skill is insufficient for Test cricket, no single data science skill is sufficient for a production problem. The insight is that the capstone is the integration challenge that exposes whether the skills have been internalised as a coherent workflow or merely memorised as isolated techniques.

The Business Problem

CricketStream has one million subscribers and is losing five thousand per month — a churn rate that threatens its revenue model. The product team wants a model that identifies subscribers most likely to cancel in the next thirty days, so targeted retention campaigns can be directed at the highest-risk users before they leave. Your task is to build and deliver the feature-engineering and prediction pipeline that powers this retention system. The model will be scored on AUC (area under the ROC curve), and the features you engineer — not the model architecture — are the primary lever for performance, as the dataset already has a reasonable baseline model attached.

Analogy🏏Cricket

🏏 Think of it like cricket: CricketStream losing five thousand of a million subscribers each month is a franchise watching loyal season-ticket holders quietly stop renewing before finals. Just as a smart club studies attendance and viewing patterns to spot which members are drifting away and sends them a targeted offer before they lapse, your model must identify subscribers most likely to cancel in the next thirty days so retention campaigns reach the highest-risk users while they can still be saved. Just as it is far cheaper to re-engage a wavering fan than to recruit a brand-new one, targeted retention beats mass discounting. And just as a club acts on the fixtures a member has skipped rather than guessing, your model acts on behavioural signals in the data. The payoff: a churn-prediction and feature-engineering deliverable that turns raw subscriber behaviour into a ranked list of who to save first, directing scarce retention budget where it protects the most revenue.

The Dataset

The CricketStream dataset contains one row per subscriber per weekly snapshot, with the following fields. Demographic features include plan_tier (free, standard, premium), tenure_days (days since signup), and region (North, South, East, West, Overseas). Behavioural features include weekly_watch_mins (watch time in the snapshot week), total_sessions (number of sessions), content_categories_watched (distinct categories), and live_vs_vod_ratio (fraction of watch time on live cricket vs. on-demand). Engagement signals include push_notifications_clicked, app_opens, and friend_referrals_made. Support history includes support_tickets_open (count of open tickets), last_ticket_sentiment (positive, neutral, negative, or none), and last_ticket_text (free text of the last support message). The target is churned, a binary flag set to one if the subscriber cancelled within thirty days of the snapshot. The dataset has intentional data-quality issues: missing values in several columns, a near-constant feature, and a skewed watch-time distribution that rewards careful preprocessing.

Analogy🏏Cricket

🏏 Think of it like cricket: the CricketStream dataset is a weekly scorecard kept for every single subscriber, one row per fan per week. Just as a player's scorecard mixes fixed profile facts with fluctuating match-by-match form, each row combines demographic features that rarely change — plan_tier, tenure_days, region — with behavioural features that shift every snapshot week: weekly_watch_mins is that week's runs scored, total_sessions the innings played, content_categories_watched the variety of shots attempted. Just as reading a single scorecard tells you little but a run of weekly cards reveals a batsman losing form, one snapshot is weak but the weekly sequence exposes a subscriber's engagement declining toward churn. And just as demographic facts set the baseline expectation a selector holds for a player, plan and tenure frame what normal engagement looks like. The payoff: understanding this per-subscriber-per-week structure is what lets you engineer the trend features that actually predict who is about to walk away.

Four-Phase Workflow

The capstone is structured in four phases matching the next four lessons. Phase one is EDA and data quality audit — profiling distributions, identifying issues, and documenting findings before touching any features. Phase two is data cleaning and feature engineering — fixing quality issues, creating the domain-driven features the cricket-streaming context motivates, and extracting datetime and text features. Phase three is feature selection and pipeline construction — selecting the strongest features with a two-stage filter-then-wrapper pipeline and wrapping everything in a leakage-safe, serialised artifact. Phase four is the final submission — assembling the complete pipeline, running the full test suite, saving with a model card, and documenting results in a written analysis. Each phase builds on the previous, and skipping a phase produces a weaker deliverable, which is the point: the value of the full workflow is greater than the sum of its parts.

Analogy🏏Cricket

🏏 Think of it like cricket: the four-phase capstone is a Test match played across its natural sequence, each phase setting up the next. Phase one — EDA and data-quality audit — is studying the pitch and conditions before a ball is bowled: profiling distributions and documenting issues, just as a captain reads the surface before choosing his approach, never acting on features before understanding the ground. Phase two — cleaning and feature engineering — is building the innings, fixing quality issues and crafting domain-driven features the way a batsman constructs runs from the shots the conditions reward. Phase three assembles and serialises the selection pipeline, like naming and sealing the final eleven. Phase four is the post-match analysis and written reflection, the debrief that certifies the result. Just as skipping the pitch inspection ruins the innings, each phase depends strictly on the one before. The payoff: a disciplined, ordered workflow that carries raw data all the way to a documented, defensible churn model.

Leakage Rules

Because the dataset is time-ordered snapshots, strict leakage rules apply throughout the capstone. All aggregation features must use only information available before the snapshot date: rolling averages must be shifted, time-since features must reference only past events. The train-test split must be time-ordered, with training snapshots strictly preceding test snapshots by at least thirty days — the same horizon as the prediction target. All transformers, scalers, encoders, and vectorisers must be fit on the training set only. These rules are not optional: a feature or split that violates them may appear to improve performance but will fail in production, which defeats the purpose of the capstone.

Analogy🏏Cricket

🏏 Think of it like cricket: The leakage rules are the spirit of the game — you can only use information available before the ball is bowled to decide how to play the shot. Checking the replay of where the ball pitched before the delivery has happened would be cheating, however much it would improve your shot selection. Just as cricket's integrity depends on playing only on available information, the capstone's integrity depends on predicting only from available information: no feature can peek at post-snapshot data, no model can be evaluated on data its training touched. The insight is that leakage rules are not technicalities but the integrity of the prediction — a model that peeks is not predicting, it is cheating.

Evaluation Criteria

AUC on the time-ordered test set: primary performance metric, targeting above 0.75 with well-engineered features.
No leakage: all features use only pre-snapshot information; any feature violating this is disqualified.
Feature quality: domain-motivated, interpretable features that a product manager can understand and trust.
Pipeline hygiene: everything inside a single Pipeline, all steps named, tested with a pytest suite of at least five tests.
Serialisation: fitted pipeline saved with joblib, accompanied by a model card documenting versions, metrics, and schema.
Written analysis: a brief (one-to-two page) explanation of which engineered features drove performance and why.
The project is a professional deliverable, not a notebook experiment — it must run end-to-end from raw data to predictions in one command.