An MBAN capstone group build on Google Cloud: BigQuery for the warehouse, Vertex AI for the churn model, Gemini for personalised retention outreach, Looker Studio on top — a single retention loop instead of two disconnected systems ("ML tells you who, GenAI tells you how, CS acts on it").
For a B2C SaaS subscription business, the unit economics are brutal and well-understood: acquiring a new customer costs several times more than retaining an existing one. The classic Bain & Company finding — that a 5% lift in retention can translate to a 25-95% lift in profit — gets quoted so often it's almost a cliché, but the underlying math is real. Retention is the single highest-leverage lever a subscription business has, and most companies underinvest in it because the work is less glamorous than growth marketing.
The structural problem inside retention programmes is that they tend to stall in two places, and I think about them as two separate failure modes that look similar but need different fixes:
Failure mode 1: the who-problem. You don't know which customers are actually at risk. Your CS team is reactive — they hear about problems when a cancellation email lands. By then the customer has already decided, and every contact after that point is a salvage operation rather than a retention one. Traditional supervised ML (logistic regression, XGBoost, LightGBM) solves this well: given behavioural and billing signals, it can rank your customer base by churn probability and surface the top decile to CS proactively.
Failure mode 2: the how-problem. Even with a perfect churn score, the next step is "a CS rep writes a personalised email to each at-risk customer." That step does not scale. Most organisations collapse it to "a templated outreach blast" that any customer can tell is templated, which burns the trust it was supposed to rebuild. This is where GenAI changes the shape of the problem: a good LLM with good context can draft outreach that is specific to the customer — their usage pattern, their tenure, their recent support ticket, their plan — at a marginal cost that makes per-customer personalisation actually viable.
The insight we built the project around: traditional ML answers "who"; GenAI answers "how"; the win comes from connecting them into a single loop where neither half operates in isolation.
The project was GCP-native end to end, for reasons of vendor coherence rather than religious preference. Each service earned its place:
BigQuery as the warehouse. Event-level data warehousing at SaaS scale is what BigQuery was built for. Columnar storage, separation of storage and compute, and — more than anything — the serverless pricing model that lets a capstone team run queries over hundreds of millions of rows without standing up a cluster. The dimensional model lived here, the feature engineering lived here, and the churn-score table that downstream systems read from lived here.
Vertex AI for model serving and GenAI access. Vertex gives you two things in one managed plane: the traditional-ML stack (AutoML tables, custom training jobs, model registry, online endpoints) and the Gemini API. That co-location matters more than it sounds — it means the same IAM identity, the same audit log, the same networking boundary covers both the churn model and the outreach generator. No duct tape between "our ML platform" and "our LLM platform."
Looker Studio for the dashboard. Not because it's the best BI tool on the market — it isn't — but because it connects natively to BigQuery without any ingest step, it's free, and it's what a CS operations lead can learn in an afternoon. The capstone audience was hypothetical business stakeholders, and Looker Studio is the BI tool they'd most plausibly be handed in real life.
Gemini for personalised retention outreach copy. The generative layer. Prompted with a structured context block (tenure, plan, last-watched content, recent support interactions, top churn-driver features), Gemini drafts a short outreach email or in-app message in a tone we specified. The CS rep reviews, edits, sends.
Before any modelling, we spent a disproportionate amount of time on the warehouse structure — and it was worth every hour. The tables that fed everything downstream:
dim_customer — one row per customer, slowly changing: signup date, plan tier history, geography, acquisition channel.fact_subscription — subscription-period-grained fact: plan, start/end, MRR, billing status.fact_engagement — session-grained: login, content consumed, feature usage, session duration.fact_support — support-ticket-grained: category, resolution time, CSAT, sentiment on the ticket text.