How to Model LTV for a Marketplace Business
LTV for a marketplace is more complex than LTV for a SaaS business because a marketplace often has two customer sides --- buyers and suppliers --- and the value generated is a function of transaction volume, take rate, and retention on both sides. Modelling LTV correctly for a marketplace requires defining which side is the "customer" for LTV purposes, how transaction frequency evolves over time, and what gross profit is actually earned per transaction after fulfilment costs. Getting this wrong either overstates LTV significantly or misses the two-sided dynamic entirely.
Author: Yanni Papoutsi · Fractional VP of Finance and Strategy for early-stage startups · Author, *Raise Ready*
Published: 2025-03-08 · Last updated: 2025-03-08
Reading time: \~7 min
The Two-Sided LTV Problem
A SaaS business has one customer type. A marketplace has two: the demand side (buyers, employers, clients) and the supply side (workers, vendors, service providers). Both sides generate value, both sides can churn, and the economics of each differ.
The first modelling decision is which side to calculate LTV for. The answer depends on which side the marketplace monetises.
Monetisation-side LTV: Calculate LTV for whichever side pays the marketplace (demand side in most marketplace models). This is the LTV that maps directly to CAC, because CAC is typically the cost of acquiring the paying side.
Supply-side value: Even if the supply side does not pay, supply-side retention drives demand-side LTV. A marketplace where workers or vendors churn frequently forces the demand side to re-onboard new supply, reducing quality and driving demand-side churn. Model supply retention as a driver of demand-side LTV even if supply-side LTV is not calculated directly.
LTV Components for a Marketplace
**For a transaction-fee marketplace (e.g. staffing, freelance, logistics):**
LTV = Average Transaction Value × Take Rate × Gross Margin on Take Rate ×
Average Monthly Transactions × (1 ÷ Monthly Demand-Side Churn Rate) This is equivalent to:
LTV = Average Monthly Gross Profit per Customer ÷ Monthly Churn Rate \...where "gross profit" is the marketplace's net take after payment processing and direct fulfilment costs, not the full transaction GMV. **For a subscription marketplace (e.g. platforms where the buyer pays a subscription):**
The LTV model is closer to SaaS: monthly subscription revenue × gross margin ÷ churn rate. But transaction data should be layered in if the subscription price is linked to usage volume.
The GMV vs. Net Revenue Distinction
The most common LTV error for marketplaces: using GMV (gross merchandise value, the full transaction value passing through the platform) as the revenue basis for LTV rather than net revenue (the take rate portion the marketplace actually keeps).
A staffing marketplace that places a worker at £15/hour and charges the employer £18/hour has:
GMV: £18/hour × hours worked
Net revenue (take): £3/hour × hours worked
Gross profit on the take: £3/hour × hours worked × gross margin on
fulfilment
LTV should be calculated on gross profit from net revenue, not GMV. Using GMV as the LTV basis overstates LTV by the inverse of the take rate --- at a typical 15-20% take rate, this is a 5-7x overstatement.
Key insight: When a marketplace founder says their LTV is £X, the first clarifying question is always: is that gross profit on net revenue, or is it GMV? The answer changes the number dramatically and determines whether the LTV:CAC ratio reflects a viable business or an accounting artefact.
Modelling Transaction Frequency Over Time
One of the key differentiators in marketplace LTV is transaction frequency: how often does a demand-side customer transact, and does frequency grow or shrink over time?
Cohort analysis of transaction frequency is the most valuable input to marketplace LTV modelling:
In the first 1-3 months after acquisition, transaction frequency is
often low as the customer tests the platform
In months 3-12, frequency typically increases as trust and workflow
integration build
In months 12+, frequency stabilises at a steady state or continues
to grow for deeply embedded customers
Building LTV as a constant (average monthly transactions × take × margin) misses this ramp-up dynamic. A more accurate model uses cohort-observed frequency curves to build a lifetime transaction schedule.
For early-stage marketplaces without 12+ months of cohort data, use a conservative frequency assumption (no ramp-up, steady-state from month one) as the base case and model the ramp-up as upside.
Supply-Side Retention as a LTV Driver
Supply-side churn creates demand-side LTV risk that does not appear in a buyer-only LTV model. If the supply side churns and quality or availability on the platform deteriorates, demand-side churn follows. For marketplace models, include a supply-side retention assumption and model the feedback loop:
LTV
The exact relationship varies by marketplace type, but acknowledging this linkage in the model notes is important for any marketplace with operational supply-demand matching.
Worked Example: Staffing Marketplace LTV
Assumptions:
Average employer (demand-side customer) places 3 workers per month Each worker placed generates £250 in net revenue (take) to the
marketplace
Gross margin on fulfilment: 55%
Monthly gross profit per customer: 3 × £250 × 55% = £412.50 Monthly demand-side churn rate: 3%
LTV = £412.50 ÷ 0.03 = £13,750
If this were calculated on GMV instead (employer rate of, say, £1,500 per worker per month):
Incorrect LTV = (3 × £1,500 × 55%) ÷ 0.03 = £82,500
The GMV-based LTV is 6x the correct number. This is not an edge case --- it is the most common marketplace LTV error.
Frequently Asked Questions
Should marketplace LTV include both buyer and seller sides?
Only if you monetise both sides. If the marketplace charges workers or vendors a fee in addition to charging employers, model LTV for both sides. More commonly, two-sided LTV is calculated only for the monetised side, with supply-side retention modelled as a driver rather than a separate LTV component.
How do you handle seasonal transaction patterns in marketplace LTV?
Use annualised average transaction frequency rather than a specific month's data. If the marketplace is highly seasonal (e.g. retail staffing peaks at Christmas, summer festival staffing), the annualised average smooths the seasonality. Flag the seasonal pattern in the assumptions.
At what stage should a marketplace start tracking LTV by customer segment?
As soon as there are enough customers to create meaningful segments --- typically 50+ customers on the demand side. High-frequency, high-ACV buyers typically have very different LTV profiles from low-frequency, low-ACV buyers. Blending them into a single LTV hides the quality concentration that sophisticated investors will ask about.
Summary
Marketplace LTV is calculated on gross profit from net revenue (the take rate portion), not on GMV. Transaction frequency evolves over time and should be modelled using cohort data where available. Supply-side retention drives demand-side LTV and should be modelled as a linked assumption even if supply-side LTV is not calculated directly. The most common error --- using GMV as the LTV basis --- overstates LTV by the inverse of the take rate, which at typical marketplace take rates is a 5-7x error. Get the LTV denominator right before any investor conversation about unit economics.
Get the complete guide with all 16 chapters, exercises, and model templates.
Get Raise Ready - $9.99