Commerce·July 2024·11 min read

Predictive Analytics in E-Commerce: A Game Changer

Predictive analytics in commerce isn't one model, it's four different problems wearing the same name: who's about to churn, what a customer is worth over time, how much inventory to buy, and which transaction is fraudulent. Each needs its own signals and its own decision path, but all four run through the same lifecycle — data, features, model, decision, feedback.

"Predictive analytics" gets used as a single catch-all term, which hides how different the four common commerce applications actually are. Churn prediction, customer lifetime value, demand forecasting, and fraud detection all use the same underlying technique (learn a pattern from historical data, score new data against it) and almost nothing else in common.

They differ in the signals that feed them, the latency the decision needs, and what happens when the model is wrong. Treating them as one initiative with one team and one success metric is where most predictive analytics programs stall.

Four surfaces, four different jobs

Every commerce business runs some version of these four prediction problems, whether or not it has named them:

Churn prediction: which customers are about to stop buying, so retention spend goes where it can still change the outcome.
Customer lifetime value (LTV): how much a customer is worth over their full relationship, used to set acquisition spend and prioritize service investment.
Demand and inventory forecasting: how much of each SKU to buy, covered in depth in our practitioner's guide to AI demand forecasting for D2C brands, since it deserves its own full treatment.
Fraud detection: which transaction, account, or return request is illegitimate, scored in real time against a payment or account event.

The rest of this piece focuses on churn, LTV, and fraud, the three surfaces beyond demand forecasting, and on the lifecycle that all four (including forecasting) share.

The prediction lifecycle

Every one of the four surfaces above runs through the same five stages, whether the team building it realizes it or not. Naming the stages explicitly is what makes it possible to reuse infrastructure across all four instead of building four disconnected pipelines.

Data sources feed shared features, which train a versioned model, which produces a decision with a human override path. Actual outcomes feed back into the data layer for the next training cycle.

The stage most teams underbuild is features. Churn, LTV, and fraud models all want overlapping raw signals (order history, session behavior, support contact history), and building a shared feature layer once is cheaper than three teams independently extracting the same data three different ways.

Churn prediction

Churn prediction scores which customers are likely to stop buying, early enough that a retention action (a win-back offer, proactive support outreach) can still change the outcome. The hard part isn't the model, it's defining "churned" precisely enough for a model to learn from.

Google Analytics 4's built-in predictive metrics

GA4's predictive metrics include churn probability: the likelihood that a user active in the past 7 days won't be active again in the next 7 days. The same feature computes purchase probability and predicted revenue using the same underlying modeling approach, giving teams a baseline without building a model from scratch.

GA4 documents a real eligibility threshold for this to work: at least 1,000 returning users must have triggered the relevant condition (churned, or not) within a 7-day window over the trailing 28 days. Below that volume, the built-in model doesn't have enough signal, and a custom model built on smaller data faces the identical constraint.

What a custom model adds over the built-in metric

A brand-specific churn model can incorporate signals GA4 never sees: support ticket sentiment, subscription pause history, or a product-specific usage pattern that predicts disengagement before a purchase gap is even visible in transaction data. The trade is real engineering investment against a metric GA4 already computes for free.

Google Cloud's own worked example for this pattern trains a logistic regression model directly on GA4 export data using BigQuery ML, skipping a separate feature-engineering pipeline for teams that already export GA4 events to BigQuery. The CREATE MODEL statement handles the train/test split automatically:

CREATE OR REPLACE MODEL `project.dataset.churn_model`
OPTIONS(
  MODEL_TYPE = 'LOGISTIC_REG',
  INPUT_LABEL_COLS = ['churned']
) AS
SELECT
  days_since_last_order,
  order_count_90d,
  avg_order_value_90d,
  support_contacts_90d,
  churned
FROM `project.dataset.customer_features`;

This is a reasonable first custom model precisely because it's disposable: cheap to train, cheap to retrain weekly, and a clear baseline to beat before reaching for a more complex architecture.

Churn prediction only pays for itself if the retention action arrives before the customer has functionally already left. A model that flags churn risk after the customer's last realistic touchpoint is a very expensive way to confirm what already happened.

Customer lifetime value

LTV prediction estimates a customer's total future value, which reframes acquisition spend from a flat cost-per-acquisition target into a spend ceiling that varies by predicted customer quality. Two customers acquired through the same channel at the same cost can have wildly different predicted value, and treating them identically wastes the signal.

GA4's predicted revenue metric estimates expected revenue from a user's purchase conversions in the next 28 days, using the same predictive infrastructure as its churn probability metric. That's a 28-day window, not a full-lifetime estimate, so treat it as one input into a longer-horizon LTV model rather than the complete answer.

LTV drives decisions upstream of the purchase, not just after it

The highest-value application of LTV prediction is bidding: paying more to acquire a customer segment predicted to have high lifetime value, even at a higher upfront cost-per-acquisition than a "cheap" segment that churns fast. This only works if the LTV model is trustworthy enough to change a real budget allocation, which means it needs the same backtesting discipline as a demand forecast before anyone bets ad spend on it.

Fraud detection

Fraud detection is the one surface among the four where latency requirements are non-negotiable: a decision has to happen inside the payment authorization flow, in real time, not in a nightly batch job. That constraint shapes the entire architecture differently from churn or LTV, which can tolerate a daily or weekly refresh.

How a production fraud model actually scores a transaction

Stripe Radar evaluates hundreds of risk signals per payment (device signals, behavioral patterns, network-wide fraud data across Stripe's platform) and returns a risk score used to allow, block, or flag a transaction for review, all within the checkout flow's normal latency budget. Risk evaluations combine that global signal with rules specific to the merchant's own risk tolerance.

AWS offers a comparable managed path: Amazon Fraud Detector lets a team train a custom model on its own historical fraud labels while incorporating Amazon's own fraud-pattern models, for teams that need fraud scoring outside a payment processor's built-in tooling (account takeover, promo abuse, fake return requests).

Rules still belong alongside the model

Neither Stripe nor AWS treats rules as something the model replaces. Stripe's custom fraud models let a merchant feed business-specific signals (loyalty status, product catalog data, past dispute history) into a model built on top of Radar's network-wide data, while merchant-defined rules still handle cases the merchant knows about explicitly, like a shipping address pattern tied to a known abuse ring.

A pure rules engine misses novel fraud patterns; a pure ML model without rules can't act instantly on a pattern a fraud analyst just identified this morning. Running both together, with the model handling the general case and rules handling known specifics, outperforms either alone.

False positives are a real cost, not a rounding error

A fraud model tuned only to catch fraud, without weighing the cost of blocking legitimate customers, degrades conversion in a way that's easy to miss because it shows up as lost revenue, not as a fraud-loss line item anyone reviews. Every fraud model needs both numbers tracked together: fraud caught and legitimate transactions wrongly blocked, reviewed on the same cadence.

A fraud model has two failure modes, and only one of them gets measured by default. Fraud that slips through shows up on a chargeback report. A legitimate customer wrongly blocked just leaves and doesn't come back, and nothing flags that loss automatically.

The override path is the pattern that repeats across all four

A fraud analyst overriding a false-positive block, a retention manager overriding a churn score they know is wrong because of context the model doesn't have, a buyer overriding a demand forecast ahead of a canceled promotion: this is the same structural need showing up in four different surfaces. None of the four should be a black box a human can't correct.

The override only makes the system smarter if it's logged with a reason, not just silently overwritten. An unexplained override is noise the next model retraining has to average away; a logged one becomes a training signal for exactly the pattern the model missed.

Four separate teams building four separate override mechanisms, with no shared logging standard, is a common and avoidable failure. Build the override-and-log pattern once, as shared infrastructure, and every model that plugs into it gets smarter faster.

Operating four models without four separate messes

The infrastructure question that matters more than any single model's accuracy is whether a commerce team can run churn, LTV, forecasting, and fraud models without each one becoming its own bespoke pipeline maintained by whoever built it.

A shared feature store stops four teams from rebuilding the same signal

A feature store centralizes feature computation and serving, so "days since last order" or "average order value trailing 90 days" gets computed once and reused across the churn model, the LTV model, and the demand forecast, instead of three slightly different implementations drifting apart over time. That consistency matters more than it sounds: a churn model and an LTV model disagreeing on what "active customer" means will produce contradictory retention and acquisition decisions.

The same MLOps discipline applies across all four

Every one of these models needs the same operating rhythm: versioned retraining, backtesting against a holdout before shipping, and a champion-challenger comparison before a new model version replaces the one in production. Skipping this for a "simple" churn model because it feels lower-stakes than a fraud model is how a quietly degrading model keeps making decisions nobody's checked in months.

Surface	Primary signals	Decision latency	Cost of a wrong call
Churn prediction	Activity recency, engagement trend, support contacts	Batch — daily or weekly refresh is sufficient	Missed retention window; wasted retention spend on false positives
Customer LTV	Purchase history, category mix, acquisition channel	Batch — informs budget cycles, not real-time bids	Over- or under-investing in acquisition for a segment
Demand forecasting	Order history, pricing, promotions, marketing spend	Batch — feeds buying and allocation cycles	Stockouts or overstock; see our forecasting deep dive
Fraud detection	Device, behavioral, and network-wide risk signals	Real time — inside the payment authorization flow	Chargeback loss, or a wrongly blocked legitimate customer

Before building a fourth model, check these

Does a shared feature layer already exist, or will this model duplicate signals another team already computes?
Does the decision have a defined override path? Every one of these four surfaces needs a human who can override the model with a logged reason, not just a silent manual correction.
Is there a backtesting and versioning process, or will this model ship once and quietly drift with no one checking?
What's the cost of both failure directions, not just the failure the model was built to catch? A fraud model measured only on fraud caught, or a churn model measured only on churn predicted, is missing half its own scorecard.

FAQ

Do we need a data science team to start with predictive analytics, or can we use built-in tools first?

Start with what's already available: GA4's predictive metrics for churn and revenue, or a payment processor's built-in fraud scoring, both require no model-building. Move to a custom model once the built-in option's limitations (eligibility thresholds, generic signals) become the actual constraint.

How is customer lifetime value different from a simple average order value times purchase frequency calculation?

That calculation describes historical value, not predicted future value. An LTV model incorporates churn risk, category trends, and cohort behavior to estimate what a customer is likely to spend going forward, which is a materially different (and harder) problem than reporting what they've already spent.

Can one model handle churn and LTV together, since they seem related?

They can share a feature layer, but they should stay separate models with separate outputs, because they answer different questions (will this customer leave versus how much are they worth if they stay) and get used in different downstream decisions.

Why does fraud detection need real-time scoring when churn and LTV don't?

A fraud decision blocks or allows a transaction that's happening right now, inside the checkout flow; a churn or LTV score informs a retention or budget decision that can tolerate a day's delay. The latency requirement follows directly from when the decision actually needs to be acted on.

What's the biggest mistake teams make rolling out their first predictive model?

Skipping the override path and the ongoing evaluation cadence, treating the model as a one-time build instead of a system that needs monitoring, retraining, and a human who can correct it when it's visibly wrong.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.