Customer lifetime value (CLV), also called lifetime value or LTV, estimates the value associated with a customer relationship. A basic revenue estimate is average revenue per customer per period multiplied by expected customer lifespan in the same period units. For example, $500 in average annual revenue and a three-year lifespan gives $1,500 in revenue CLV. That is not automatically profit or a prediction for an individual customer.
Choose the decision first: compare acquisition channels, prioritize retention work, or forecast revenue. Then define the customer group, time period, revenue basis, currency policy, and transaction rules. These choices determine which CLV formula is useful and whether two reported results can be compared.
This guide explains the formulas, shows why two valid averaging methods can disagree, and turns the calculation into a documented process that can be reviewed before it reaches a CRM or reporting system.
What customer lifetime value measures
CLV is an estimate of the value associated with a customer relationship over time. A historical CLV summarizes observed activity using a declared method. A predictive CLV estimates a future outcome using historical and other customer data.
A simple revenue-based CLV describes revenue, not net profit, discounted cash flow, or a guaranteed customer-level outcome. It may omit gross margin, refunds, service costs, acquisition costs, and the time value of money. Before calculating, decide whether the result will describe revenue, gross profit, or another explicitly defined measure.
For an introductory explanation of the simplified calculation, see HubSpot’s customer retention metrics guide. Treat that formula as an estimate, not a financial accounting standard.
Choose the CLV formula that matches the decision
For a transactional business, a common first-pass formula is:
Revenue CLV = average purchase value × purchase frequency per period × average customer lifespan
Average purchase value is eligible revenue divided by eligible purchases. Purchase frequency is purchases divided by unique purchasing customers in the same period. Make the period and denominator explicit. If purchase frequency is four purchases per customer per week, lifespan must be measured in weeks or converted to weeks before multiplying.
When the decision concerns customer economics rather than top-line revenue, calculate a gross-profit variant:
Gross-profit CLV = revenue CLV × gross-margin rate
State how gross margin is defined. Depending on the decision and the reliability of the data, profitability analysis may also account separately for refunds, discounts, service and retention costs, acquisition cost, and discounting. Customer acquisition cost (CAC) is commonly compared with CLV. It is not automatically subtracted in every CLV formula. HubSpot’s SaaS customer success guidance discusses margin and relationship length as considerations in SaaS-oriented CLV.
For subscriptions, define the revenue measure and billing event before calculating. Specify how renewals, upgrades, downgrades, cancellations, and churn are treated. A billing event is not necessarily equivalent to a new customer purchase.
A CLV result is comparable only when its revenue basis, time unit, customer grain, currency, and inclusion rules are explicit.
Calculate CLV without mixing units or averages
Start with one fixed observation period and a documented rule for eligible transactions. For example, a retailer might count completed, paid orders, subtract recorded refunds, and exclude cancelled orders. Aggregate revenue and purchase count at a consistent customer and period grain before calculating the chosen formula.
Two averaging methods can produce different results when customer purchase values and purchase frequencies vary:
- Product of population averages: multiply average purchase value by average purchase frequency, then by lifespan. This is a segment-level estimate using two separate averages.
- Average of customer-level values: calculate each customer’s purchase value and frequency together, derive each customer’s value, then average those results. This retains the relationship between value and frequency within each customer.
The HubSpot educational article’s fictional Jitterbug coffee-shop example makes the difference visible. It reports five weekly customer values of $25.36, $58.68, $10.42, $73.85, and $7.89. Their average is $35.24 per week. Multiplying by 52 weeks and 2.3 years gives $4,214.70. The article also gives an average purchase value of $7.954 and average frequency of four visits per week. Multiplying those population averages, then applying the same lifespan, gives about $3,805.19.
Both figures can be reproduced from the source inputs, but they use different averaging methods. The $4,214.70 result is the average of individual weekly customer values multiplied by the lifespan. It is not the product-of-averages result. See the original CLV example and document which method you use.
Report the method, currency, period, eligible transaction rules, lifespan assumption, and formula version alongside the result. If many customers are still active at the end of the observation window, their observed relationship length is incomplete. Define a churn or inactivity rule and treat estimated lifespan accordingly rather than treating an active customer as a completed relationship.
Worked example: revenue CLV versus gross-profit CLV
Suppose a hypothetical subscription business has $500,000 in net annual revenue across 1,000 unique active customers. Its average annual revenue per customer is $500. If the declared average lifespan is three years:
- Revenue CLV: $500 × 3 = $1,500.
- Gross-profit CLV: $1,500 × 80% gross margin = $1,200.
These are aggregate estimates, not predictions that each customer will generate exactly $1,500 in revenue or $1,200 in gross profit. The example assumes revenue and customer counts use compatible definitions. State how active customers and incomplete lifespans are handled.
Build an auditable calculation before automating it
Keep transaction evidence separate from customer-period results. One source row should represent one transaction or billing event. One aggregate row should represent one customer, calculation period, currency, formula version, and run or input watermark. Do not store a segment-wide average as though it were an individual customer observation.
A proposed result record might include:
{
"customer_id": "CUST-1042",
"calculation_period_start": "2025-10-01",
"calculation_period_end": "2026-09-30",
"currency": "USD",
"revenue_basis": "net_paid_revenue",
"eligible_transaction_count": 12,
"eligible_revenue": 1440,
"lifespan_value": 3,
"lifespan_unit": "year",
"clv_value": 4320,
"formula_version": "revenue-clv-v1",
"source_record_count": 12,
"input_watermark": "transactions-2026-10-14T11:45:00Z",
"calculated_at": "2026-10-14T12:00:00Z",
"run_id": "clv-2026-10-14-01"
}The values are illustrative, not a vendor schema. The row grain is one customer, period, currency, formula version, and calculation run. A practical sequence is to select eligible paid transactions, normalize currency under a documented policy, aggregate by customer and period, calculate the chosen formula, validate the result, and retain source IDs, formula version, calculation time, input watermark, and run identity.
Finance or revenue operations owns the metric definition. Data engineering owns reliable extraction and aggregation. Keep detailed calculation history in a system designed for it, and use the CRM as a destination only when field ownership, permissions, and update behavior are agreed.
For repeat runs, define a uniqueness key using the customer, period, currency, formula version, and run or input watermark when multiple calculations can exist for the same period. A lookup followed by create is not sufficient protection against concurrent duplicate writes. Where concurrent writers are possible, use a database-enforced unique constraint or transactional upsert. Route invalid IDs, unknown currencies, ambiguous payment status, and failed validations to an owner for review instead of silently replacing a prior result.
For help reviewing customer identity, data ownership, and CRM write-back rules, see CRM systems consulting.
What HubSpot’s CLV card does and when to calculate externally
HubSpot documents a Customer lifetime value card for contact and company records on Professional or Enterprise subscriptions. The card is based on associated Closed Won deals and uses broad purchase-value, lifespan, and purchase-frequency inputs. It is a historical, deal-based estimate, not a documented gross-margin or full profitability model.
Before relying on the card, check deal associations, amounts, consistent Closed Won stage usage, and how migrated history, refunds, cancellations, credits, and renewals are represented. The official HubSpot record-card documentation describes the feature and its subscription condition.
Use the native card when that historical deal-based view answers the question. Calculate separately when the required definition depends on net paid revenue, refund handling, gross margin, or another measure not represented by the card.
A historical deal-based card can be useful without matching a custom net-revenue or gross-profit calculation. Compare the card’s deal inputs with the approved metric definition before using its value for customer economics.
HubSpot developer guidance documents CRM searching, requested properties, filters, and pagination, but does not provide a complete CLV aggregation and write-back workflow. Any external extraction needs appropriate authentication and scopes, retrieval of the required records, pagination handling, external aggregation and validation, and a separately approved write-back policy. Reporting and export availability also varies with subscription and reporting setup.
For a configuration review, see HubSpot systems support.
When predictive CLV is worth the added complexity
Use a deterministic historical calculation for descriptive reporting and clear thresholds. Consider predictive CLV only when the decision requires a forecast and the business has stable customer identities, consistent transaction and churn definitions, enough completed lifecycle examples, a declared future outcome window, and a process for evaluating predictions against holdout data.
Keep a predictive result separate from source events. A scoring row should identify the customer, scoring date or period, model name, model version, run, predicted outcome, currency where relevant, and confidence or review status. If multiple models or runs can score the same customer in one period, include those dimensions in the uniqueness key.
Rules are preferable when a transparent condition answers the question, such as “at least three paid purchases in 12 months.” A model may help estimate future value. Bounded AI tasks may include summarizing churn themes or proposing an action from structured evidence. Keep financial eligibility rules explicit and route low-confidence or policy-sensitive cases to a named human owner.
Use CLV to guide action, then measure the result
Use CLV alongside margin, churn risk, service burden, and customer need. A high historical spend does not guarantee future value. Choose one action the result can inform, such as investigating onboarding friction, reviewing an account, or comparing acquisition cohorts.
Measure the outcome the action is intended to change, such as repeat purchase, retention, expansion, or gross profit, against a defined baseline and time window. Assign owners for the formula, source data, calculation changes, and follow-up.
Customer-value segmentation can help focus investigation and investment, as discussed in this Deloitte customer-experience framework. It does not establish that a particular intervention will improve CLV. Judge the action by its measured outcome, not by a change in the CLV label alone.
Before publishing a CLV result
- Confirm whether the result is revenue CLV or gross-profit CLV.
- Check that the currency, period, customer grain, and lifespan units align.
- Document eligible transactions, refund treatment, cancellation rules, and purchase-count logic.
- Choose either the product of population averages or the average of customer-level values, and label the method.
- Store source IDs, formula version, input watermark or run ID, calculation time, and review status.
- Use a database-enforced unique constraint or transactional upsert when concurrent writes are possible.
- Send invalid or ambiguous records to a named owner instead of silently overwriting a prior result.