Predictive models in lifecycle: churn, propensity, and recommendations without the magic

A predictive model — a piece of software that learns patterns from past behaviour and outputs a probability for a future event — is, in lifecycle marketing, almost always one of three flavours. It looks at what your users have done, finds the patterns that preceded the outcome you care about, and gives every user a score for how likely they are to do that thing next.

The doctor analogy lands cleanest. A GP who's seen ten thousand patients can tell you, after a five-minute consult, that the bloke in front of her has a high chance of a cardiac event in the next year — not because she has a crystal ball but because she's pattern-matched against the ten thousand. A predictive model does the same trick across millions of users, on behavioural data rather than blood pressure. Same logic. More users. No bedside manner.

The three flavours, before we go any further:

Churn risk — probability the user will lapse (stop using the product) in a defined window. Propensity — probability the user will do the thing you want (purchase, upgrade, sign up) in a defined window. Recommendations — a ranked list of products or articles per user, ordered by predicted relevance.

Each one outputs a number. The job is deciding whether the number changes anything you do.

That's the test. Strip away the dashboards, the model accuracy charts, the AUC numbers (AUC — area under the curve, a single number from 0.5 to 1.0 measuring how well a model separates the two outcomes). The only question that matters: does this score cause your program to do something different? If the answer is no, you've bought a thermometer for a room you're not heating.

Through that lens, here are the three use cases that actually pay for themselves.

Churn / risk of inactivity. Output: probability the user will lapse in the next 30 / 60 / 90 days. Used to trigger save flows — messages designed to pull a user back before they go quiet — instead of win-back campaigns sent after they've already gone. Real ROI depends on whether your save flow actually saves anyone. A churn model feeding a save flow that doesn't work is just an expensive way to identify the problem you can't solve. Test the save flow first. Deploy the model only when the flow has proven incremental lift — meaning users who got it converted at a higher rate than a holdout (the random users you deliberately don't message, your control group) who didn't.

Conversion propensity. Output: probability the user will convert (purchase, upgrade, sign up) in a defined window. Used to suppress low-propensity users from heavy promotional pushes — saving deliverability (your reputation with mailbox providers) and user goodwill — or to time high-intent triggered programs. Most valuable for SaaS trial-to-paid programs and ecommerce cart abandonment, where the audience is heterogeneous and the cost of a wasted send is real.

Product / content recommendations. Output: a ranked list of items per user. Used in onboarding, post-purchase, browse abandonment, and newsletter content selection. The use case where AI personalisation pays for itself most clearly — once the catalog is large enough that hand-curation breaks down. Below ~200 SKUs (stock-keeping units, the unique products in your catalog) or content items, hand-curation by lifecycle stage usually outperforms.

Other predictive features exist — predicted LTV (lifetime value, the total revenue a user is forecast to generate), churn cause attribution, optimal discount level — but the three above carry most of the measurable revenue lift in lifecycle programs. Start there. Expand once each is proven in your context.

Your ESP (email service provider — the platform that sends your messages and stores your user data) probably ships predictive features already. Worth knowing what you're actually getting before you pay for anything bespoke.

Braze Predictive Suite. Out-of-the-box churn risk and conversion propensity scored against custom-defined events — you tell Braze what counts as "converted" or "churned" for your business and it scores users against that. Configurable target event and lookback window. Output is a per-user score available in segment filters. Strengths: zero build effort, integrates natively with Canvas (Braze's journey builder). Weaknesses: limited transparency into how the model decided what it decided, dependent on Braze having complete behavioural data on the user, scoring quality plateaus with audience size.

Iterable Brain. Send-time optimisation, frequency optimisation, channel selection. Less focused on score-based segmentation, more on per-message decisions — which channel, which time, how often. Best for programs running multi-channel and needing per-user channel selection.

Klaviyo Predictive Analytics. Predicted next-purchase date, predicted CLV (customer lifetime value), churn risk. Strong for ecommerce because the model is purpose-built for transactional data. Available as filterable user properties, like Braze. Strength: tight integration with Klaviyo's ecommerce-native data model. Weakness: harder to extend to non-ecommerce use cases.

Salesforce Einstein. Most extensive feature set — engagement scoring, send-time, content selection, journey decisions — but also the most setup, the steepest learning curve, and model quality meaningfully tied to how complete and clean your SFMC data extensions (Salesforce's term for the database tables it stores user data in) are.

The realistic answer: most of the time, for most programs, for most use cases. ESP-native predictive features are good enough when:

Generic use case — "score users by likelihood to churn in 30 days" rather than "score users by likelihood to churn for reason X given product feature usage pattern Y."

Large enough audience — typically 50K+ active users with 6+ months of clean event data (the stream of user actions the model trains on). Below that, ESP models fall back to weak defaults regardless of vendor. Models need examples to learn from; small audiences don't produce enough.

Activation stays inside the ESP — segment filters, Canvas branching, Liquid conditions (Liquid is the templating language most ESPs use to inject personalised values). Pulling the score out of the ESP for use elsewhere is where ESP-native starts to feel constraining.

No internal ML team to maintain a custom model. Hidden cost of custom is the ongoing retraining, drift monitoring, and on-call when the recommendation API breaks at 9pm on a Friday — the build itself is the easy part.

Custom models earn their cost in three patterns:

Domain-specific signal. Style-similarity recommendations for a fashion marketplace. Intent scoring tied to specific product feature usage for a B2B SaaS. Personalised content rankings for a publisher where the "catalog" is articles. The signals (the inputs the model learns from — clicks, purchases, dwell time, feature usage) that produce useful predictions are too domain-specific for a generic ESP model to learn from a generic event stream.

Multi-system activation. The score is needed in the ESP, on the website, in the app, in paid retargeting audiences, and in support tools. ESP-native scores can be exported but the architecture quickly tips toward "build the model in the warehouse, sync the score everywhere" when the activation surface is broad.

Audit and explainability. Regulated industries — finance, health, insurance — often need to explain why a specific user got a specific score. ESP-native black-box scores fail this test. Custom models with documented features (the named inputs the model uses) and feature importance (a ranking of which inputs mattered most for each prediction) pass it.

The defensible build pattern: model trained in the warehouse (BigQuery, Snowflake, Databricks — the cloud databases where your raw event data lives), output written nightly to user attributes via reverse-ETL (Census, Hightouch — tools that push warehouse data back into operational systems like your ESP), and consumed via standard segment filters. The ESP doesn't need to know it's a predictive model — it just sees a user attribute it can filter on.

Real-time variations of the same pattern use Connected Content (Braze) or Catalog Lookup (Iterable) — features that let your ESP call an external system at the moment a message is being assembled — to hit a model endpoint at send time. Adds latency and a runtime dependency, but keeps recommendations fresh. The architecture guide covers the trade-off.

Before deploying any predictive feature — built or bought — answer these. Most of the time at least one of the answers reveals that the model isn't the bottleneck.

1. What decision does the score change? If users in the top quintile (top 20% by score) get a different message, journey, or send than users in the bottom quintile, the score is doing work. If everyone gets the same treatment regardless, you're paying for a dashboard.

2. What does the score replace? The honest comparison isn't "model vs nothing" — it's "model vs the heuristic the team would use otherwise." A heuristic is a simple rule of thumb: "active in last 30 days = yes/no." A churn model often goes head-to-head with that exact heuristic. If the model can't beat it in a holdout test (where you score users with both methods and compare which one predicts the actual outcome better), it's expensive complexity.

3. How will it be measured? A predictive model needs a holdout. Some users get the predicted-action treatment; some get the previous heuristic-based treatment. Compare downstream metrics over 60+ days. Anything shorter is noise. Anything without a holdout is faith.

4. What happens when it's wrong? Models drift — their predictions get worse over time as the world changes underneath them. Data pipelines break. The score that was 0.92 last week is 0.31 this week, not because the user changed but because an upstream event stopped firing and the model lost half its inputs. Build the monitoring before the deployment, not after the first incident.

5. Who owns it? Predictive models without a clear owner go stale within months. The owner is responsible for retraining cadence (how often the model relearns from fresh data), drift monitoring, and the question "is this still earning its place?" Without an owner, the score becomes load-bearing infrastructure that nobody tests, updates, or trusts.

The AI Personalisation skill covers the rollout framework end-to-end, including the build vs buy decision matrix and the holdout design for each of the three primary use cases.

Predictive scores nobody filters on. A common pattern: turn on Predictive Suite, watch the scores populate, never actually use them in segment logic — because the existing program already segments on recency and tier and that's what the team trusts. The model trains. The dashboards trend. No decision changes. Either commit to using the score in segmentation or don't turn it on.

Predictive features sold as content selection. "The AI picks the best subject line per user." Most ESP implementations are picking from a small candidate set the marketer pre-defined, weighted by historical engagement on similar users. Useful, but closer to a multi-armed bandit (a class of algorithm that explores options and shifts traffic toward the winners) than per-user content generation. Set expectations accordingly.

Recommendations that override hand-curation. For small catalogs (200 SKUs or fewer), hand-curated recommendations by lifecycle stage usually outperform model-generated. Programs that switch to AI recommendations and lose curation often see flat or negative impact. Recommendations are a tool for catalog scale, not a replacement for category strategy.

The pattern that doesn't disappoint: a predictive feature deployed to one program, validated against a holdout for at least 30 days against a non-vanity metric, expanded only once the lift is real. Slow, careful, and accumulates more revenue than the "flip every switch" rollout.