All projectsML operations system

Customer Churn Prediction

An end-to-end churn analytics system that connects data ingestion, feature engineering, model training, explainability, retention actions, serving, and monitoring.

Scope: ML system architecture · Backend serving · Analytics workflow

The problem

What had to work beyond the model.

A churn score has limited value in isolation. The useful work is turning it into a repeatable workflow with inputs, explanations, recommendations, delivery, and checks over time.

Workflow

Covers ingestion, feature engineering, model training, scoring, and retention recommendations.

Decision support

Includes explanations and an analytics surface rather than exposing only a raw probability.

Operations

Repository documents monitoring, batch entry points, tests, containers, and CI.

System at a glance

How the pieces connect.

  1. 01Data inputs

    Customer, activity, transaction, and support data move through ingestion and feature-engineering stages.

  2. 02Model candidates

    The workflow supports baseline and boosted classifiers, then resolves an active model through a registry pattern.

  3. 03Decision service

    FastAPI exposes scoring, explanation, and retention-recommendation endpoints for downstream use.

  4. 04Command center

    A Streamlit surface and monitoring reports make model behavior, data quality, and retention actions inspectable.

Key engineering decisions

Choices that make the system usable.

  1. 01

    Designed a model registry pattern so the API and dashboard can resolve an active model source instead of relying on a hard-coded artifact.

  2. 02

    Included both a synthetic demo path and a Kaggle Cell2Cell workflow so the system can be inspected without pretending one dataset fits every use case.

  3. 03

    Made per-customer explanations and treatment/control assignment visible rather than exposing an unexplained probability.

  4. 04

    Made monitoring and retention logic visible parts of the architecture, not hidden implementation details.

Verification path

How the work can be inspected.

  • The repository documents batch entry points, tests, containers, and CI alongside interactive analytics.
  • Monitoring reports are designed to surface drift, missingness, classification quality, and calibration through Brier score.
  • The service separates score, explain, and recommend actions so reviewers can inspect the decision path.
Current boundary

This is an end-to-end engineering system, not a claim of a deployed churn program. No accuracy, retention lift, or A/B-test outcome is asserted without an evaluation report.

Technical stack
PythonFastAPILightGBMXGBoostscikit-learnStreamlitDockerSQLite
Want to discuss a similar system?

Let’s make the hard part usable.

Start a conversation