Predicted LTV Models Compared: RFM, BG/NBD, and ML

If you're picking a predicted LTV model this quarter, start with the boring answer: for most marketing teams, a cohort-curve or a well-fit BG/NBD model will beat a fragile machine-learning pipeline you can't maintain. Machine learning wins when you have real feature richness and someone to retrain it. RFM isn't a prediction at all, and treating it like one is where a lot of budget goes to die.

That's the whole argument. The rest of this piece shows the math, names the assumptions, and gives you a table you can drop into a deck when someone on the growth team wants to "just build an LTV model" before you've checked whether the data can support one.

The three families, scored honestly

There are really three things people mean when they say "predicted LTV model." A scoring heuristic (RFM), a probabilistic model (BG/NBD and its cousins), and supervised machine learning (gradient-boosted trees, neural nets, the works). They answer different questions and they fail in different ways.

Here's how I score them for a marketing team that has to defend the number, not just publish it.

Model family	What it predicts	Data you need	Interpretability	Time to first usable number	Maintenance cost
RFM (recency, frequency, monetary)	Nothing, strictly. It ranks current value	A transaction log	Very high (it's three columns)	Days	Near zero
BG/NBD + Gamma-Gamma	Future transactions × future avg value	12–24 months of purchase history	High (named parameters)	A week or two	Low, refit quarterly
Supervised ML (XGBoost, etc.)	pLTV as a fitted target	History + behavioral/marketing features	Low without extra work	Weeks to months	High, retrain and monitor drift

A CFO I worked with had a rule I've never dropped: "I'll fund the model you can explain to me in one meeting." That instantly kills the "let's neural-net it" reflex for teams that can't yet describe why last quarter's cohort spent what it spent. If you can't explain the model, you can't defend the spend it drives.

RFM is a ruler, not a crystal ball

RFM scores each customer on how recently they bought, how often, and how much. You bucket each dimension into quintiles, and you get a tidy 555-is-best grid. It's genuinely useful for segmentation ("who do I email first"), and it takes an afternoon.

But RFM describes the past. A customer with a perfect RFM score today might be one bad delivery from churning, and RFM has no opinion about that because it has no model of dropout. When people say their "LTV model" is RFM, what they actually have is a present-value ranking they're hoping correlates with the future. Sometimes it does. It's not a prediction, and I'd never bid acquisition dollars against it.

Use RFM to prioritize. Don't use it to forecast.

BG/NBD, explained without the Greek

BG/NBD is the model most teams should reach for first when they want an actual forecast, and it's less scary than the name suggests. It comes from the "buy till you die" family, and the lifetimes Python library ships it alongside Pareto/NBD and the Gamma-Gamma monetary model, per the lifetimes documentation. You feed it a transaction log. It gives you, per customer, an expected number of future purchases and a probability they're still "alive."

The intuition is two coin flips running in the background of every customer:

• While a customer is active, their purchases arrive at some personal rate. Fast buyers and slow buyers differ, so the model lets that rate vary across your base.
• After any purchase, a customer might quietly go dormant forever. The model estimates that dropout probability too.

Multiply "expected future purchases" by "expected average order value" (that's the Gamma-Gamma half) and you have a predicted LTV per customer, built from four fitted parameters you can actually name. A 2025 arXiv study applied exactly this BG/NBD-plus-Gamma-Gamma pairing to a non-contractual purchasing setting and used it to estimate both future value and churn (arXiv, Jan 2025). Non-contractual just means your customers don't cancel a subscription when they leave; they just stop, which is most e-commerce and most apps.

Why I like it for marketing:

• It needs only what you already have: dates and amounts.
• The parameters are interpretable, so you can sanity-check them against reality.
• It's cheap to refit, so it doesn't rot the moment your intern leaves.

The catch: BG/NBD assumes purchase behavior is reasonably stationary and that customers act independently. Run a doorbuster promo, change your pricing tiers, or ship a referral loop, and those assumptions wobble. It also can't use features it doesn't see. It knows nothing about the acquisition channel, the device, or whether someone rage-quit your checkout. If those signals matter to your LTV, you've outgrown the probabilistic model.

Machine learning: powerful, hungry, and easy to fool yourself with

Supervised ML treats pLTV as a target you fit. You assemble features (RFM columns, sure, but also acquisition source, first-week engagement, category mix, discount sensitivity) and train a model, usually gradient-boosted trees before anything fancier, to predict a customer's value over some horizon.

When it works, it's the most accurate of the three, and the accuracy numbers in the literature look spectacular. A 2025 ScienceDirect study combining probabilistic and machine-learning models reported AUC of 0.99 and accuracy of 0.98 on e-commerce data, nudging past standalone XGBoost at 0.98 and LightGBM at 0.97 (ScienceDirect, 2025).

Now let me put on my "that benchmark is survivorship-biased" hat, because someone has to. Those figures are AUC on a classification framing (high-value vs not) on one cleaned dataset. They are not "we predicted every customer's dollar LTV within 2%." Published LTV benchmarks skew toward the datasets where models worked, and nobody writes the paper where the model shrugged. Treat 0.98-anything as an existence proof that ML can separate whales from tire-kickers, not as the number you'll hit on your messy production log next Tuesday.

Two failure modes I've watched eat quarters:

Accuracy at the wrong time is worthless. A model that nails 12-month LTV but only after nine months of data can't help you bid on acquisition today. A 2025 Finsi guide makes the point bluntly: an 85%-accurate prediction that arrives nine months in is nearly useless, while a rougher number available soon after acquisition actually moves decisions (Finsi, 2025). For paid-media bidding, a mediocre day-2 estimate beats a brilliant month-nine one. (This is the whole reason day-0 pLTV bucketing exists for privacy-constrained mobile UA, where day-0 pLTV buckets for SKAN apply the same idea under a harsher deadline.)

Models rot. A model trained on 2025 buyers predicts 2026 buyers worse every month as product mix, pricing, and competition shift. Coralogix's 2025 write-up on LTV model monitoring frames this as a continuous job: retrain and watch for drift, don't fit once and frame the notebook (Coralogix, 2025). If nobody owns retraining, your ML model is a depreciating asset with no line item.

I've seen this play out. At one company we shipped a gradient-boosted pLTV model that beat our cohort baseline by a comfortable margin in backtest, and everyone celebrated. Six months later the data engineer who built it moved teams, a feature pipeline changed silently, and the predictions drifted low for a full quarter before anyone caught it. We'd been under-bidding a whole acquisition channel the entire time. The cohort curve we'd kept running in parallel had stayed roughly right, because it has almost nothing to break. That's the tax nobody quotes you: an ML model isn't a number, it's a system, and systems need an owner and an alarm.

The checklist: data you need before ML is worth it

Before anyone builds the fancy thing, run down this list. If you can't check most of it, you're not ready, and BG/NBD or a cohort curve will serve you better for less.

• 12–24 months of clean transaction history. Fairing's 2025 e-commerce LTV guide puts the reliable range around 12–24 months (Fairing, 2025). Less than a year and you're mostly modeling seasonality.
• Enough customers per segment, not just in total. A million rows across five products can still be thin where it counts. If your smallest actionable segment has a few hundred converters, tree models will happily overfit it.
• Features that actually differ from RFM. If your only inputs are recency, frequency, and monetary, you don't need a neural net to relearn them. ML earns its keep when you feed it signals BG/NBD can't see: channel, first-session behavior, support tickets, device.
• A stable definition of a "customer" and a "purchase." Refunds, subscriptions, B2B multi-seat, guest checkouts. Pin these down first. Half the "our model is wrong" tickets I've triaged were a join, not a model.
• Someone who owns retraining. Not a hero notebook. A scheduled job, a monitoring dashboard, and a name attached to it.
• A backtest plan. Hold out a real time window and predict it. If you can't measure whether the model beats "assume this cohort behaves like the last one," you can't claim it does.

Why the cohort curve is the default I actually recommend

Here's the option most "which pLTV model" articles skip, because it isn't clever: fit a curve to your cohorts' cumulative revenue over time and extrapolate.

You group customers by acquisition month, plot cumulative revenue per customer at day 30, 60, 90, 180, and fit a curve (log or power usually) to the shape. New cohorts inherit the curve, scaled by their early signal. That's it. It's transparent, it updates itself as cohorts mature, and every finance person already thinks in cohorts, so you skip the translation fight.

A tiny worked example. Say three monthly cohorts show cumulative revenue per customer like this:

Days since acquisition	Jan cohort	Feb cohort	Mar cohort
30	$18	$19	$17
90	$31	$33	n/a
180	$44	n/a	n/a

The Jan cohort roughly doubled from day 30 to day 180 ($18 → $44, a 2.4× multiplier). If that shape holds, your March cohort's $17 at day 30 projects to about $41 by day 180. Crude? Yes. But it's a defensible, self-correcting predicted LTV you can compute in a spreadsheet, and it's your baseline: any BG/NBD or ML model has to beat this to justify its existence. If your $2M-in-ML-consulting model can't clear a curve fit, that tells you something.

The formula, spelled out, is just:

pLTV(cohort, horizon) = early_revenue(cohort) × maturity_multiplier(horizon)
maturity_multiplier(horizon) = avg( mature_cohort_revenue(horizon) / mature_cohort_revenue(early) )

Where you get the cohort curve matters less than that you're honest about the multiplier's uncertainty. Product analytics tools compute these cohort revenue curves out of the box, which is usually faster than exporting to a notebook. Amplitude, Mixpanel, and PostHog all do cohort revenue and retention curves, and each has its own trade-offs on cost and modeling depth (there's a fuller breakdown of category benchmarks worth reading before you trust any single tool's defaults). Kixo takes the same cohort-first approach and lets you ask for the curve in plain language and get the chart back, which lowers the barrier for a marketer who doesn't want to live in SQL. The honest caveat across all of them: a tool's built-in cohort curve is only as good as your event and revenue instrumentation, so fix the tracking before you trust the projection. For deciding what actually goes on the board, our unit-economics dashboard template covers the surrounding numbers.

So which predicted LTV model should you use?

Rough decision, the way I'd give it to a team lead in a hallway:

• You have a transaction log and a deadline: fit a cohort curve. Ship the baseline this week.
• You want per-customer forecasts and churn probability, and behavior is fairly stable: BG/NBD plus Gamma-Gamma. Interpretable, cheap, honest.
• You have rich features, real volume per segment, and someone to own retraining: build the ML model, and keep the cohort curve as your canary.
• You just need to prioritize outreach: RFM. But don't call it a forecast in the board deck.

The mistake isn't picking the "wrong" model. It's picking a model your team can't maintain and then quietly stopping trusting it — which is worse than the simple model you'd have believed. Match the model to the data you actually have and the meetings you actually have to survive.

FAQ

Is RFM a predicted LTV model? No. RFM ranks customers by past behavior; it doesn't model future purchases or dropout. It's a great segmentation tool and a poor forecast. If you need to predict value, use a cohort curve or BG/NBD.

How much data do I need before machine learning beats BG/NBD? Roughly 12–24 months of clean history, enough customers in each segment you care about (not just in aggregate), and features that go beyond recency/frequency/monetary. Without richer features, ML mostly relearns what BG/NBD gives you for free. See Fairing's 2025 range above.

Can I predict LTV in the first few days after acquisition? Directionally, yes, and for paid-media bidding you have to. Early estimates are rough but decision-useful; a precise number that arrives months later can't inform a bid you place today. That timing trade-off is the core point in Finsi's 2025 guide.

How often should I retrain an LTV model? Often enough that drift doesn't outrun you — quarterly is a reasonable floor for many teams, more for fast-changing businesses. Coralogix's 2025 monitoring write-up treats retraining and drift-watching as an ongoing job, not a one-time fit. A cohort curve sidesteps most of this by updating itself as cohorts mature.