Use cases

Churn prediction with foundation models: why your XGBoost ceiling is lower than you think.

Churn is the canonical enterprise ML problem: everyone has a model, the playbook is twenty years old, and almost every implementation looks the same. Aggregate each customer's history into a few hundred features, recency, frequency, monetary value, tenure, support contacts, and train a gradient-boosted tree to predict who cancels in the next 90 days.

It works, up to a point. Then it stops improving, and no amount of feature engineering moves it. That ceiling isn't a tuning problem. It's built into the representation.

Where the signal dies

Every aggregate feature is a decision about what to forget. "Average order value over 90 days" forgets whether the orders were growing or shrinking. "Days since last login" forgets whether the logins were getting shorter, more frustrated, more transactional. "Support tickets, last quarter: 2" forgets that both were about the same unresolved problem, and that the customer's tone shifted between them.

Churn lives in exactly what those features forget: the shape of the sequence. A customer rarely leaves in a way a snapshot can see, they drift. The weekly rhythm loosens. Sessions shorten before they stop. Baskets simplify before they disappear. By the time the drift is large enough to show up in a 90-day average, the customer has often already decided.

Feature-based churn models are trained on the shadow of the behavior, not the behavior.

The label problem nobody escapes

There's a second structural limit: labels. A supervised churn model learns only from customers who already churned, a few percent of the base, in one historical period, under one set of market conditions. All the unlabeled behavioral richness of the other 97% contributes nothing to the representation. Small, imbalanced, backward-looking training sets are why churn models decay so fast and generalize so poorly to new segments and products.

What changes with a foundation model

An enterprise foundation model flips both constraints. It's pretrained with self-supervision on every customer's raw event sequence, next-event prediction, no labels needed, so the representation is learned from the full behavioral corpus, not the churned few. The churn model itself becomes a small classification head fine-tuned on top.

Three things follow:

  • Earlier warnings. The pretrained model has learned each customer's normal grammar, so it registers drift as it happens, rhythm loosening, engagement thinning, rather than after it accumulates into a quarterly aggregate. In behavioral-sequence work this shows up as both higher AUC and, more importantly, longer lead time: flags arrive weeks earlier, while the customer is still reachable.
  • Less label hunger. Because the representation already encodes segment, trajectory, and intent, the head needs far fewer labeled churns to reach a given accuracy, which is what makes reliable churn models possible for new products and small segments that could never support a standalone model.
  • One definition away from every variant. Contraction instead of cancellation, dormancy instead of closure, downgrade risk, save-ability, each variant is a new head on the same base, days of work. In the feature-pipeline world each one is a new project.

Measuring it honestly

If you pilot this, hold the evaluation to the standard that matters operationally:

  • Temporal splits only. Train on history before a cutoff, test on the following quarter. Random splits leak the future and flatter every model, incumbents included.
  • Lead time, not just AUC. Two models with equal AUC are not equal if one fires 30 days earlier. Measure the gap between flag and cancellation, it's the window your retention team actually works in.
  • Precision at intervention capacity. Your team can call the top 500 accounts a week, not the top decile. Compare precision at that cutoff, because that's where the money is.
  • Silent churners. Score the model specifically on customers who never filed a complaint or ticket, the ones snapshot features miss and sequence models are supposed to catch. That's where the difference concentrates.

The compounding part

The churn head is rarely the end. The same base model, already paid for, yields lifetime value, propensity, and next-best-action heads, which is what turns "who is leaving?" into "who is leaving, what are they worth, and what offer keeps them?" That's the practical difference between owning a foundation model and owning a churn model: the second question costs days, not another project.

Get started

See churn coming weeks earlier.

A pilot starts with a sample of your event data and ends with a model that predicts your business better than anything you've deployed.

Book a demo