CLV Modelling for SaaS and E-commerce Growth Teams
A practical guide for SaaS and e-commerce data leaders on building customer lifetime value models that inform retention and acquisition spend. Covers data requirements, modelling approaches, and common pitfalls for teams scaling past product-market fit.

Once a SaaS or e-commerce business clears product-market fit, the conversation shifts from "can we get customers" to "which customers are worth getting, and how much should we spend to keep them." Customer lifetime value (CLV) modelling is the analytical backbone of that conversation. This guide walks through how growth-stage technical and data leaders can build CLV models that are accurate enough to trust and simple enough to maintain.
What is customer lifetime value modelling?
Customer lifetime value modelling is the practice of estimating the total revenue or profit a business can expect from a customer over the duration of their relationship, using historical transaction, engagement, and churn data. It converts a customer's past behaviour into a forward-looking number that can be used to guide acquisition budgets, retention investment, and pricing decisions. A CLV model is not a single formula — it is a pipeline of data, assumptions, and a chosen statistical or machine learning method, all of which need to be revisited as the business changes.
Why does CLV modelling matter past product-market fit?
Before product-market fit, most growth spend is exploratory and CLV estimates are too noisy to be useful. After product-market fit, cohorts are large enough and behaviour stable enough that CLV becomes a genuine planning input — it tells you which acquisition channels return customers worth keeping, and which retention interventions are worth the engineering effort.
At this stage, three things typically change: customer acquisition cost (CAC) starts rising as easy channels saturate, cohorts diverge in value based on plan tier, acquisition source, or product usage pattern, and the finance team starts asking for payback period and unit economics with more rigour than a spreadsheet can support. CLV modelling gives you a defensible answer to "how much can we afford to spend to acquire this type of customer," rather than a single blended CAC-to-LTV ratio that hides which segments are actually profitable.
What data do you need to build a reliable CLV model?
A usable CLV model needs three data categories: transactional or billing history (revenue events, subscription changes, order value), behavioural or engagement data (product usage, session frequency, feature adoption), and churn or cancellation events with timestamps. Without clean, joined data across these three areas, no model — however sophisticated — will produce trustworthy estimates.

For most growth-stage companies, the limiting factor is not modelling technique but data plumbing: billing data sitting in Stripe or a custom ledger, product usage sitting in an events warehouse, and support or cancellation reasons sitting in a CRM that never gets joined to the other two. Before investing in a CLV model, it is worth auditing whether these sources can be reliably joined on a customer or account ID, refreshed on a consistent cadence, and backfilled far enough to cover at least a few full customer lifecycles. This is squarely a data-infrastructure problem before it is a data science problem, and skipping it produces models that look sophisticated but rest on unreliable inputs.
Which CLV modelling approaches should you use?
The right approach depends on how much historical data you have, how homogeneous your customer base is, and how the outputs will be used. There is no single best method — heuristic, probabilistic, and machine learning approaches each trade off simplicity, data requirements, and accuracy differently.
| Approach | Best suited for | Data required | Trade-offs |
|---|---|---|---|
| Historical / heuristic CLV (average revenue × average lifespan) | Early growth stage, simple pricing | Minimal — aggregate billing data | Fast to build, but poor at segment-level or cohort-level accuracy |
| Probabilistic models (e.g. BG/NBD, Gamma-Gamma) | E-commerce with repeat, non-contractual purchases | Transaction-level order history | Well-suited to non-subscription buying patterns, but assumes purchase behaviour is reasonably stable over time |
| Survival analysis / cohort-based CLV | Subscription SaaS with defined churn events | Subscription start/end dates, plan changes | Handles censored data (customers who haven't churned yet) well, more statistically demanding to implement correctly |
| Machine learning regression or gradient-boosted models | Businesses with rich behavioural and firmographic features | Usage events, support tickets, firmographic data, plus transaction history | Can capture non-linear drivers of value, but requires more data engineering and ongoing monitoring for drift |
Many growth-stage teams start with a heuristic model to get directional numbers into the business quickly, then move to a probabilistic or survival-based model as retention and pricing complexity increase. Machine learning approaches are usually only worth the investment once you have enough labelled history and a team that can maintain a production pipeline — this is where ai-engineering practices around model monitoring and retraining become relevant, not just the initial model build.
How does CLV inform retention and acquisition spend?
A CLV model earns its keep when it changes a decision, not when it produces a number. Used well, CLV segments customers by predicted value so acquisition spend can be reallocated toward channels and campaigns that bring in high-value cohorts, and retention resources can be prioritised toward segments where a small increase in retention produces the largest lifetime value gain.
In practice this means comparing predicted CLV against CAC by channel, plan tier, or acquisition cohort — not just in aggregate — and setting payback period thresholds per segment rather than for the business as a whole. It also means treating retention interventions (onboarding improvements, proactive support outreach, win-back campaigns) as investments that should be sized against the CLV uplift they are expected to produce, evaluated with the same rigour as a paid acquisition channel.
What are common pitfalls in CLV modelling?
The most common failure mode is building a statistically sophisticated model on top of data that has not been validated — for example, mixing free-trial users with paying customers in the same cohort, or failing to account for refunds and downgrades in revenue calculations. The second most common failure mode is treating CLV as a static number rather than a distribution that should be recalculated as pricing, product, and market conditions change.
Other pitfalls worth naming plainly: CLV models trained on early, small cohorts tend to overstate the value of long-tenured "power users" and understate how a growing, more diverse customer base will actually behave; and models that ignore customer acquisition cost by channel can suggest an average CLV that looks healthy while individual channels are quietly unprofitable. Being honest about these limitations — and about how much historical data you actually have — is more valuable than a model that looks precise but rests on shaky assumptions.
Building the infrastructure: from spreadsheet to production model
Most CLV modelling efforts start in a spreadsheet or notebook, and that is a reasonable place to start — it forces clarity on what data exists and what the model needs to answer. The step that determines whether CLV modelling actually changes how the business spends money is moving from a one-off analysis to a pipeline that refreshes automatically, feeds dashboards finance and growth teams actually check, and gets revisited as a genuine part of planning cycles rather than a slide from a one-time project.

That step is an infrastructure and engineering problem as much as a modelling one: reliable data pipelines, a feature store or equivalent structure to keep training and scoring data consistent, and monitoring to catch when model accuracy degrades. If your team is earlier in this journey, our posts on data infrastructure for AI and taking models from notebook to production cover the foundational work in more depth. If CLV sits within a broader AI or analytics roadmap, ai-product-strategy is often the right starting point to sequence it against other priorities, and legacy platforms that make data hard to extract may need application-modernisation work first.
Getting started
CLV modelling rewards teams that get the data foundations right before reaching for a sophisticated technique. Start with a heuristic model to build organisational trust in the metric, invest in the data plumbing that any future model will depend on, and only move to probabilistic or machine learning approaches once you have the historical volume and engineering capacity to maintain them properly. You can browse more on related topics in our insights.
If you're exploring how to build or improve customer lifetime value modelling for your SaaS or e-commerce business, we can help — starting with an honest assessment of whether your data is ready for it.
Chris Kerr
Partner at Horizon Labs, an AI product consultancy and venture studio. A commercially focused product and technology leader with 20+ years building and scaling digital platforms, teams, and businesses across SaaS, travel, eCommerce, logistics and transport, and digital marketing — operating at the intersection of product, engineering, and data. Writes about platform strategy, AI transformation, modern data ecosystems, and the operational discipline that separates AI demos from AI products.


