Marketplaces can report substantial transaction value while earning very little operating profit. To decide whether a marketplace deserves further investment, track what the platform earns, what it costs to serve a request and how often an actual paid purchase follows.
The numerical example below is completely hypothetical. It illustrates a decision method rather than industry performance, a pricing recommendation or a forecast.
Start with clear definitions
GMV (gross merchandise value) is the value of completed transactions under a stated counting policy; it is not automatically platform revenue. Take rate is platform revenue divided by relevant GMV under the same policy. Contribution after variable cost is revenue minus transaction-dependent costs. Operating result then subtracts the included fixed expenses.
For a private-offer marketplace, track requests across separate stages. A buyer submitting a request is not a merchant responding, a buyer selecting an offer is not a captured payment, and a captured payment is not necessarily an irrevocably fulfilled sale. Refunds and cancellations require a documented treatment.
Hypothetical monthly assumptions
Assume the platform has 1,000 eligible buyer requests in a month and routes them to a controlled set of merchants. Forty-five percent receive at least one valid proposal. Twenty percent of those answered requests result in a paid purchase. Assume an average order value of $620 and an effective platform fee of 4% of paid transaction value.
| Input | Illustrative value |
|---|---|
| Eligible requests | 1,000 |
| Answered-request rate | 45% |
| Paid conversion among answered requests | 20% |
| Average paid order value | $620 |
| Effective platform take rate | 4% |
| Variable handling cost per eligible request | $0.45 |
| Platform-borne extra processing cost per paid purchase | $1.20 |
| Additional support cost per paid purchase | $3.00 |
| Included fixed operating costs per month | $1,250 |
Model boundary: this example assumes the platform earns a transaction-based fee and, for illustration, bears the extra processing and support costs shown. A real payment or seller-of-record structure might shift, add or eliminate individual fees. Merchant product costs are not modeled as platform costs because this scenario assumes the merchant remains responsible for the merchandise.
Reproduce the calculations
- Answered requests: 1,000 × 45% = 450.
- Paid purchases: 450 × 20% = 90.
- Paid GMV: 90 × $620 = $55,800.
- Platform fee revenue: $55,800 × 4% = $2,232.
- Request handling: 1,000 × $0.45 = $450.
- Additional payment processing: 90 × $1.20 = $108.
- Purchase support: 90 × $3.00 = $270.
- Contribution after these variable costs: $2,232 − $450 − $108 − $270 = $1,404.
- Result after the included fixed costs: $1,404 − $1,250 = $154.
That $154 is not net profit. The simplified model excludes acquisition, refunds, chargebacks, taxes, salaries, insurance, and other costs not included in the stated assumptions.
Add acquisition and see what changes
Suppose every one of the 90 paid purchases came from a different newly acquired buyer and acquisition averaged $10 per buyer. That adds $900 to the month. The result becomes $154 − $900 = −$746.
This is why request volume and GMV can be misleading headline metrics. A model can appear positive until the cost of obtaining genuine customers is included. For repeat purchasers, distinguish newly acquired buyers from returning buyers and avoid assigning CAC to every transaction without a deliberate allocation rule.
Stress-test liquidity, not just take rate
The economics depend on merchant response capacity. If the answered-request rate falls from 45% to 25%, while every other stated assumption stays unchanged:
- Answered requests: 1,000 × 25% = 250.
- Paid purchases: 250 × 20% = 50.
- Fee revenue: 50 × $620 × 4% = $1,240.
- Request handling: $450, processing: $60, purchase support: $150.
- Contribution: $1,240 − $450 − $60 − $150 = $580.
- After $1,250 of included fixed costs: −$670, before acquisition and other omissions.
Revenue falls faster than request-handling expense because every eligible request still needs to be examined. Monitoring only completed orders conceals this risk.
What to measure in a pilot
Record merchant response rates by product category and geography; seller minutes per request; eligible versus ineligible requests; offer expiry; offer selection; paid completion; refunds; cancellation reasons; repeat buyer rates; acquisition cost; and the platform's real fee income. Make the definition of a “valid proposal” stable over time.
Before operating live payments, separately verify legal, tax, payments and customer-service responsibilities in each market. A spreadsheet is not a substitute for operational and legal design.
The goal of the exercise is a business decision: which assumption is both most uncertain and most capable of changing the result? Often that is merchant participation, paid conversion or acquisition—not just the listed take rate. Read the validation framework and private-offer mechanics to connect the model to an actual pilot.