Customer Lifetime Value Modeling for Consumption-Based Pricing

Customer lifetime value modeling built for subscription software does not work for consumption pricing, because the formula assumes a stability that usage-based billing eliminates by design. The standard shortcut looks like this: CLV equals (ARPU times gross margin times retention rate) divided by (1 plus discount rate minus retention rate), minus customer acquisition cost. That equation asks for three inputs that subscription SaaS happens to hold fixed by contract: revenue per period, the probability a customer churns, and the margin earned on what they spend. None of those three is wrong as a concept. All three are wrong as a prediction, once the thing being predicted is usage.

In subscription software, ARPU is a number set at the moment of signing and left alone until the next renewal conversation. Consumption pricing removes that floor and ceiling at the same time. Revenue moves because behavior moves, and behavior will not hold still the way a signature does.

Churn probability suffers the same fate. A static annual churn rate works reasonably well for subscription software because churn is observed at a single discrete moment, the renewal date, and historical rates are a fair proxy for what will happen at the next one. Consumption churn does not wait for a renewal date. Declining usage appears gradually in the billing data long before an account is formally lost, so a single churn probability applied across the customer base treats a customer whose usage is climbing and a customer whose usage is quietly draining away as the same risk. They are not the same risk, and a model that cannot tell them apart is already wrong before it produces a number.

Contribution margin is the third casualty, and the one most CLV models do not even think to question. In a subscription product, the cost to serve a given customer is roughly fixed, so margin per customer stays roughly stable. In a consumption product, margin depends on which features a customer happens to consume, and that mix can shift from month to month without any change in the customer's total spend or their contract.

If you put volatile inputs into a formula built for stable ones, the formula does not fail by giving a slightly-off answer. Averaging a number that is wrong on the high side with a number that is wrong on the low side does not produce a reliable center. It produces an average of two mistakes. Every section that follows exists to replace one of these three broken inputs, in order: ARPU, churn, and margin.

What makes consumption revenue structurally different from subscription revenue

Consumption revenue is not subscription revenue with a variable price tag attached to it. It behaves according to a different logic entirely, one built on what a customer's workload looks like in a given week rather than what they agreed to pay twelve months ago. None of that traces back to a commitment made when the contract was signed. The revenue time series for a single consumption customer can look nothing like the smooth, predictable annuity that CLV models were built to discount. It can spike, flatten, dip, and spike again, driven by nothing more than a product team shipping a new feature or a customer's own busy season.

Usage-based products add something subscription billing never had to deal with at all: a credit-and-token layer that introduces its own conversion-rate problem. Credits get purchased, then they get spent down at a pace that depends on what the customer is doing, and the gap between credits bought and credits burned is itself a signal that a pure dollar-based revenue figure hides.

Most consumption products that reach real scale end up hybrid rather than purely usage-based: a base fee covers a seat or a tier, and usage charges stack on top once a customer crosses an included allotment. Atlassian's own setup, as of June 2026, shows the shape clearly. Any single invoice under that structure carries two very different kinds of revenue stacked together: a seat-based component that is about as predictable as a subscription line, and a usage-based component that moves with whatever the customer actually did that month.

That split means a CLV model that blends the two into one ARPU figure is averaging a stable number with an unstable one and reporting a result that describes neither. The seat component should be modeled the way subscription ARPU has always been modeled. The usage component needs its own treatment, because it is carrying the volatility that the rest of the revenue line does not have. Before any CLV model can be rebuilt to handle consumption pricing, the revenue signal it is trying to predict has to be understood in these terms: a quiet, contract-driven piece and a loud, behavior-driven piece, layered into the same invoice but moving according to entirely different rules.

How consumption-based NRR creates an expansion dynamic that static CLV ignores

Static CLV models that treat churn as the main lever on customer value miss the thing that actually drives consumption-product economics: expansion that happens automatically, without a renewal conversation or a quota-carrying rep pushing for it. A subscription customer grows in value when someone convinces them to upgrade. A consumption customer grows in value the moment their own usage grows, because the billing system charges for what gets used, not for what got negotiated. That difference turns net revenue retention into something closer to a byproduct of product adoption than a sales outcome, and it means NRR on consumption products can run well past the levels that count as strong expansion on a subscription product, purely from existing customers using more of what they already have access to.

A CLV model that lumps all customers into one churn rate, regardless of how long they have been on the product, gets the shape of retention backward. Customers who make it through that early period have usually built the product into a real workflow, and workflows are hard to rip out. So a mature consumption customer is meaningfully harder to displace than a subscription customer who is simply going through a routine renewal. Averaging churn risk across a customer base that includes both brand-new accounts and years-old integrated ones overstates the risk on the mature accounts and understates it on the new ones, which is exactly backward from what a retention team needs to know.

The expansion dynamic also scrambles the signal that subscription CLV models are trained to look for first: initial spend level. On a consumption product, the customers who will eventually be worth the most often look like moderate spenders in their first few months, because the dollar volume has not caught up yet with the underlying behavior that predicts it. A model trained to chase high early spend will walk right past the accounts that are quietly building toward the largest long-run value.

This is the direction CLV modeling has to move for consumption products generally: treating the metric as a live, continuously updated read on customer behavior rather than a number computed once and left alone until the next planning cycle. A CLV estimate that only gets recalculated quarterly is already behind the behavior it is supposed to describe.

Rebuilding the ARPU input: from contractual average to usage-cohort distribution

Fixing the ARPU input starts by giving up on a single blended average and replacing it with a distribution organized by usage cohort. A single average ARPU figure fails for a reason that goes beyond ordinary volatility: it mixes together customers who are at completely different points in their usage journey and reports one number as if it describes all of them. A customer in month two of a consumption product behaves nothing like the same customer in month fourteen. The average describes neither phase accurately.

The fix is to segment customers by usage percentile within their own cohort age, then track how each percentile's spend evolves over the following quarters. A customer whose month-three spend is in the top quartile of their cohort is a different CLV segment than a customer at the median for that same cohort age, and that difference is visible in billing data well before it would ever appear in a quarterly NRR number. Building the model this way turns ARPU from a single snapshot into a trajectory, which is the shape consumption revenue actually takes.

Most consumption products settle into a hybrid structure, a base fee plus usage on top, and that forces a further split before you can model either component honestly. Blend the two components back into one ARPU number, and the model inherits all the volatility that lives in the usage component, with none of the tools needed to account for it.

None of this works without granular, timestamped usage data. Finance teams trying to build usage-cohort ARPU models from invoice totals alone are working from a monthly summary of behavior that actually happened continuously throughout the period, which throws away exactly the information the model needs. Teams stitching together usage data from a separate metering system, or reconciling multiple billing codepaths by hand, tend to spend the first week of every month just assembling the data that a CLV model needs on a continuous basis. Finance teams spending that first week reassembling data end up running CLV models that describe last quarter.

Rebuilding the churn input: usage-signal-driven retention probability instead of a static rate

Declining usage is visible in usage data weeks before any contractual signal does, and that gap is where churn risk actually lives in a consumption model. A static churn rate has no way to see it, and a CLV model built on that static rate will keep valuing a customer who is quietly disengaging as if they were an average customer, right up until the account is lost. Consumption churn does not announce itself that way. It builds up gradually, visible in usage data long before it becomes an account event, so the population-level churn rate is the wrong number to apply to any individual customer whose usage is already trending somewhere other than flat.

If a customer's API call volume has been dropping month over month, they carry a higher actual churn probability than the population average would suggest, no matter what the contract says about renewal dates. If a customer's usage is accelerating, they carry a lower near-term churn probability and a stronger expansion trajectory than that same population average implies. Treating both customers as draws from one churn distribution throws away the one piece of data that actually distinguishes them.

The signals worth tracking also change shape once pricing moves from subscription to consumption. Subscription SaaS leans on login frequency and feature adoption as its main engagement signals. Usage spread across several teams is closer to a switching-cost signal, the kind of stickiness an average churn rate has no variable for.

The modeling change that follows from this is straightforward to state: churn probability needs to be a function of recent usage trend, not a constant applied to a whole cohort. The payoff is that a team working from usage-signal churn data can act on an account that is already slipping, instead of finding out about the risk only when a renewal date arrives and it is too late to do much about it.

Rebuilding the margin input: contribution margin varies by feature mix, not just by customer

Contribution margin in a consumption model depends on which features a customer is actually using, not simply on how much they are spending in total, and a shift in that feature mix can change a customer's margin profile with no change at all in their revenue line. That makes margin the least-discussed input in consumption CLV and arguably the most consistently underestimated one.

Subscription software gets to treat gross margin as roughly stable per customer, because the cost of delivering the product to any given account is roughly fixed and does not move much with how actively that customer uses it. Consumption products break that assumption at the feature level. A customer who mostly runs cheap inference calls carries a very different gross margin than a customer who spends the exact same total dollar amount on a premium model endpoint that costs far more in GPU time per call. Two customers can generate identical revenue and produce very different profit, and a CLV model that only looks at total spend has no way to tell them apart.

That gap shows why margin needs to be modeled as a function of product mix rather than attached to the customer as a single fixed number the way subscription models have always done it. A customer who shifts from a lightweight feature set to a heavier, more compute-intensive one has not changed accounts, has not signed anything new, and may not even have changed their total spend. They have changed their margin profile, and if the CLV model is not tracking feature-level cost to serve alongside feature-level revenue, that change will go undetected until it appears as a surprise in quarterly profitability. Rebuilding this input means pricing and finance teams need cost-to-serve data broken out by feature or by endpoint, not just by customer, so that a shift in what a customer is using can be priced into their CLV estimate as soon as it happens rather than discovered months later in the aggregate numbers.