Marketplace Metrics: Liquidity, GMV and the Data Behind Them

Marketplace metrics should show whether buyers find suitable supply, whether sellers receive worthwhile demand, and what the platform earns after the costs of serving both sides. Start with a defined local market and transaction window. Then connect search, availability, booking and payment records so liquidity, take rate and acquisition cost describe the same business activity.

Jafrin Akter AloLast updated 25 October 202618 min read

On this page

Which marketplace metrics should drive the weekly decision?

Choose measures that identify the next constraint: missing supply, failed matching, poor completion, weak repeat use or insufficient contribution. Registered users and listing totals help size the system, but they cannot identify which of those problems requires work.

A marketplace for appointment bookings needs different capacity measures from a marketplace selling unique secondhand items. Its basic event design also differs from conventional SaaS activation. The industry stack guide puts those business-model differences into the wider tracking, CRM and reporting architecture.

Start with one buyer-side outcome, one supply-side outcome, completion quality, repeat transactions and contribution. Add a diagnostic when it changes a decision. The following are proposed operating definitions; choose and version the window and counting unit before implementing them.

Sharetribe distinguishes seller sell-through, buyer purchase behavior and search-to-fill, and changes the supply measure for goods, rentals and services. Keep these definitions explicit when comparing reports. A booked hour and a listing that sold are different counting units. Sharetribe's marketplace metrics

Show the unmatched population beside time to match. A ten-minute median among the successful 10% leaves 90% of attempts unexplained. Similarly, a zero-result response is a search outcome; a failed request that never returned results is a delivery error. Report failure rate beside match rate so an outage stays visible when failed requests are excluded from the match denominator.

For a multi-capacity service, use consistent units. If a provider offers ten one-hour slots with capacity for three participants each, the offered capacity is thirty participant-hours. Counting the ten slots against twenty booked seats would produce a meaningless utilization rate.

Once a listing enters an eligible cohort, retain a withdrawal or pause as an outcome with a reason. Dropping unsuccessful listings from the historical denominator can improve sell-through without creating another sale. Calculate capacity from availability history rather than today's inventory snapshot.

Use stage conversion to locate the loss after discovery:

Choose the confirmation, fulfillment and response rules for the actual service. A booking for next month has not failed today's fulfillment check merely because it is still pending.

How can a healthy overall fill rate hide a failing market?

Calculate liquidity inside the geography, category and time range where supply can actually satisfy demand. Buyers searching for a morning appointment in one city cannot use evening capacity in another.

Consider a hypothetical booking marketplace with 4,000 eligible searches, all old enough to have a full seven-day confirmation window. Each successful search produces exactly one booking in this example. The operational records contain these counts:

The combined rate is 920 / 4,000, not the unweighted average of 28% and 8%, which is 18%. More demand in North could raise the company-wide rate without improving either location.

Suppose North has 150 zero-result searches and South has 300. Their zero-result rates are 5% and 30%. Inspect South's actual query filters, available slots, prices and returned results before spending more to acquire buyers there. A high zero-result rate may come from unavailable supply, an overly restrictive filter or an indexing problem. The appropriate intervention depends on that diagnosis.

Calculate the buyer-to-seller ratio as distinct active buyers divided by distinct active seller organizations in the same market window. Define active buyers as people making eligible requests and active sellers as organizations offering eligible capacity. Pair the result with capacity: one hotel and one single-room host count as two sellers but offer very different capacity. There is no generally useful target ratio without that context.

a16z's marketplace framework connects matching, concentration and economics at the market level. Use the share of transaction value contributed by the largest suppliers to see whether an apparently healthy market depends on a few relationships. A growing seller count does little to reduce that dependency if the new sellers receive no business.

How do GMV, take rate and contribution reconcile?

GMV measures transaction value under a written inclusion policy; platform revenue measures what the business earns; contribution deducts the specified variable costs. Keep the transaction basis, fee basis and refund treatment visible beside every take-rate calculation. As a16z puts it, “GMV does not equal revenue.” Marketplace take-rate guidance

Extend the hypothetical example: all 920 bookings complete at USD 200 each. The platform earns a 12% commission. Assume no taxes, tips, currency conversion, advertising revenue or subscription revenue. Subsequently, USD 10,000 of buyer payments is refunded, and the corresponding USD 1,200 of platform fees is reversed.

Subtracting the full USD 10,000 buyer refund from the platform's USD 22,080 fee revenue would mix two different balances. The fee reversal is USD 1,200 here. Actual refund policies can allocate the cost differently, so retain the buyer refund, seller adjustment and platform fee reversal as separate records.

Label the USD 20,880 figure “net platform fee revenue” in this example. The broader label “net revenue” needs its deductions stated, especially when a business also earns subscriptions, advertising or service fees.

The realized fee take rate is 20,880 / 174,000 = 12% on the after-refund GMV basis. Using before-refund GMV gives 20,880 / 184,000 = 11.35%. Either calculation can answer a defined question; its denominator must accompany the label. A blended take rate should use summed fees divided by corresponding summed GMV, rather than averaging each seller's percentage.

Now assume the platform incurs USD 4,800 in payment-related costs, USD 2,200 in variable support costs and USD 1,000 in transaction incentives. Contribution under this stated policy is 20,880 − 4,800 − 2,200 − 1,000 = USD 12,880, or USD 14 per original completed booking. This excludes acquisition expenditure and remaining fixed costs. It is neither the bank payout nor the company's net profit.

Have finance approve the revenue recognition and cost policy for your operating model. A commission marketplace, reseller and subscription directory should not inherit the same revenue definition. Keep reporting currency and original transaction currency, and never add different currencies before applying the agreed conversion method.

At Martechdevs, the implementation task is to connect these records without multiplying amounts through one-to-many joins. Our warehouse and data modelling work brings product outcomes, fee adjustments and payment records into a model that finance and growth can reproduce.

How should one person with several marketplace roles be modelled?

Keep the person, their role on an event, their organization membership and the transaction parties as separate entities. A person can buy on Monday and manage a seller's listings on Tuesday without becoming a new person or rewriting Monday's activity.

Record actor_person_id and actor_role on actions where a person acts. Record the buyer and seller identifiers on the booking itself. A payment webhook has a system actor; do not invent a person to fill every event field.

Keep membership start and end times where organizational changes affect historical reporting. A current profile field such as role = seller cannot safely classify every earlier search. Apply identity rules that survive role changes, then build a customer view with several roles around the shared person identity.

Segment's Group call associates a user with an organization or similar entity. A user can belong to several groups, but destination support differs. Segment also has no native group-removal method, so membership removal requires destination-specific handling. A Group call therefore complements your membership records; it does not replace their history. Segment Group specification

Count unique people across both roles only when the question is about people. Buyer count plus seller count can exceed unique people because the populations overlap. For seller onboarding, count seller organizations if several staff members collectively complete the process.

Which events make marketplace metrics computable?

Instrument durable state transitions and the demand attempts that failed, with stable links between the relevant records. Use the backend to establish committed commercial and financial outcomes, while client events explain interaction and abandonment.

These are proposed business event names, not Stripe webhook names. Map each provider event to the appropriate business transition. Keep event_id, schema version, occurrence time, receipt time and source system in the common envelope. Include identifiers only when they exist at that stage; a search has no booking identifier yet.

A separate search_no_results event is optional when the canonical search record already carries result_count = 0. If both are emitted, they refer to the same search attempt and contribute one denominator row. Retries of a network request keep the attempt identifier; a new deliberate search gets a new one. Do not count each keystroke as an independent search unless that is the explicitly chosen metric.

Store normalized filters and an appropriate location bucket rather than indiscriminately copying raw searches, addresses or payment details into every analytics destination. Keep restricted operational records and consent-governed analytics collection distinct. Describe missing coverage when a client-side funnel observes only part of the operational population.

Document these rules in the tracking plan and apply a shared event naming convention. A funnel assembled from browser clicks and backend outcomes needs an explicit identity and coverage bridge.

How can you calculate search-to-booking without inflating it?

Count each eligible search once, wait for its full outcome window, and count it as filled when at least one qualifying confirmation is linked to it. The following contract measures confirmation within seven elapsed days. Completion, cancellation and refunds remain separate outcome measures.

metric: search_to_confirmed_booking_7d_v1
unit: canonical search attempt
denominator: eligible searches with a complete seven-day window
eligibility: human buyer intent, supported market, valid search response
zero_results: included
failed_search_response: separate error metric
success: at least one first booking confirmation linked to the attempt
window_start: search occurrence, inclusive
window_end: search occurrence plus 604800 seconds, exclusive
attribution: one frozen origin search per booking, or explicitly unknown
deduplication: one search row per search_id; one booking row per booking_id
segmentation: geography and category requested at search time
coverage: confirmed complete-through timestamp plus ingestion allowance
late_data: restate the affected cohort and retain the previous result

For this example, the origin search is the last eligible search from which the buyer selected the listing before confirmation. Freeze that link on confirmation. Bookings from direct links can remain unattributed to a search; report that coverage separately. This product-navigation rule is independent of marketing-channel attribution.

The query below runs in SQLite with UTC timestamps stored as integer seconds. searches contains one canonical row per search_id, including created_at, market and is_eligible. bookings contains one row per booking_id, with origin_search_id and first_confirmed_at. Adapt timestamp syntax for your warehouse while preserving the boundaries.

WITH mature_searches AS (
    SELECT search_id, created_at, market
    FROM searches
    WHERE is_eligible = 1
      AND created_at >= :cohort_start
      AND created_at < :cohort_end
      AND created_at + :window_seconds <= :complete_through
), filled AS (
    SELECT DISTINCT s.search_id
    FROM mature_searches AS s
    JOIN bookings AS b ON b.origin_search_id = s.search_id
    WHERE b.first_confirmed_at >= s.created_at
      AND b.first_confirmed_at < s.created_at + :window_seconds
)
SELECT s.market,
       COUNT(*) AS eligible_searches,
       COUNT(f.search_id) AS filled_searches,
       100.0 * COUNT(f.search_id) / COUNT(*) AS fill_percent
FROM mature_searches AS s
LEFT JOIN filled AS f ON f.search_id = s.search_id
GROUP BY s.market;

Bind window_seconds to 604800, with cohort_start < cohort_end. Set complete_through to the time through which the required source data is complete after the ingestion allowance. It is not automatically the current wall clock. All bound values use the same seconds unit.

The DISTINCT prevents two bookings from making one search count twice. A confirmation exactly at the excluded seventh-day boundary does not qualify. Markets with no mature eligible searches produce no row; show “no eligible observations” instead of inventing a 0% rate. This query relies on canonical source rows and does not deduplicate raw webhook deliveries or repair ambiguous attribution.

How do retention and acquisition costs stay separate by side?

Measure repeat behavior within a fixed buyer or seller cohort, and keep acquisition cost aligned to that cohort's counting unit. A buyer returning to search is different from a buyer completing another booking; a seller logging in is different from a seller earning another sale.

The cohort retention guide explains fixed starting populations and incomplete windows. In a hypothetical buyer cohort of 100 people, 40 may return while their spending rises from USD 10,000 to USD 12,000. That is 40% buyer retention and 120% GMV retention. Both should remain visible.

Do not credit the same transaction contribution in full to both a buyer-acquisition ROI report and a seller-acquisition ROI report, then add them together as a company return. They are overlapping views of the same transaction. Use an explicit allocation for additive reporting, or keep each view labelled and reconcile both to a transaction-level total.

For example, USD 6,000 of buyer acquisition and USD 4,000 of seller acquisition cost USD 10,000 together. If the resulting transactions contribute USD 8,000 before acquisition expense, the combined shortfall is USD 2,000. Assigning the entire USD 8,000 independently to each side does not create USD 16,000 of company contribution.

Use CAC payback to measure when allocated contribution recovers the relevant acquisition pool. Assess a new market by its combined cost as well as each side's funnel. Buying cheaper demand can still reduce value when the available supply cannot serve it.

Which analytics tools fit these records?

Keep commercial and financial records authoritative, then choose an exploration tool that preserves the person, role and organization dimensions. A product analytics tool explains behavior; a CRM can manage seller onboarding; a warehouse becomes useful when repeated reconciliation requires all three plus support data.

Sources: Mixpanel plan availability, Amplitude account-level reporting, PostHog group semantics and billing.

With Segment's Mixpanel Actions destination, verify the Track action's Group ID mapping. Its default reads context.groupId; a custom group key must be present on the Track event. Sending organization traits alone does not establish that every event is attributed correctly. Segment's Mixpanel mapping guidance

Before changing tools, run a small acceptance fixture: one person acts as buyer, two staff members act for the same seller, and another booking has two sellers on separate lines. The expected outputs are distinct person counts, one seller-organization funnel where appropriate, and transaction totals that do not double. Choose the tool and edition that can reproduce the required view, with the warehouse handling unsupported relational analysis.

How should lifecycle messages respect both roles?

Trigger messages from the recipient's current role and transaction state, with shared contact-level controls across roles. A seller reminder about unanswered requests and a buyer reminder about an abandoned booking solve different problems.

Build lifecycle journeys around transaction events: remind sellers about expiring availability, explain a buyer's payment failure, and request feedback after confirmed fulfillment. Keep required service notifications distinct from optional promotional messages and apply the relevant delivery and consent rules.

Suppress ordinary promotional nudges when a related cancellation, refund or dispute needs resolution. A delayed event must not restart an old campaign after the case closes. Use frequency caps for dual-role users so separate buyer and seller campaigns do not each consume an independent allowance for the same person.

How do you reconcile bookings, payments and payouts?

Reconcile each commercial record to the relevant financial objects, then explain timing and amount differences before aggregating. A confirmed booking, a captured payment, a completed service, a transfer to a seller balance and a bank payout are separate events.

Stripe Connect's charge type changes where charges appear and which account is debited for refunds or disputes. Direct charges belong to connected accounts; destination charges and separate charges and transfers involve the platform balance. Retain the provider account context with every identifier and use the charge-type-specific financial records. Stripe Connect charge types

Use this reconciliation sequence for a closed reporting window:

1. Start with canonical bookings and lines. Separate confirmed, fulfilled and canceled outcomes and retain their transition times.
2. Map each line or allocation to payments and captured amounts. Explain split payments, partial captures, unpaid bookings and one payment covering several items.
3. Aggregate refunds, fee reversals, disputes and transfer adjustments to their own unique object identifiers before joining. Joining two refunds to three transfers can otherwise turn one booking into six rows and multiply its value.
4. Reconcile seller balances and bank settlement separately. Explain outstanding transfers, settlement delays, reserves and failed payouts under the actual provider configuration.
5. Produce an exception list with the booking, discrepancy amount, currency, reason and owner. Keep unexplained differences visible until resolved; repeat the check after corrections.

Stripe's payout reconciliation report maps automatic payout batches to their underlying balance transactions. Manual payouts generally need the Balance report, with a documented exception for platforms whose connected accounts have automatic payouts. Instant payouts require your own reconciliation because Stripe cannot identify their constituent transactions. A payout date is therefore a settlement dimension, not a substitute for the booking's completion date. Stripe payout reconciliation

Verify webhook signatures before accepting provider events, using the endpoint secret and unmodified payload. Stripe can deliver duplicates and does not guarantee event order. Deduplicate receipts by event ID, preserve business-object identities, and reconcile current source state when transitions arrive late. Never sum every received “success” notification as another sale. Stripe webhook handling

Run reconciliation more frequently where financial exposure requires it, and review the accumulated exceptions at least weekly for the reporting process. This operational cadence does not replace accounting close or change the original occurrence time of an event.

How should the team act on the marketplace dashboard?

Use reconciled evidence to choose a bounded change in one market, then compare matching, completion and economics together. The diagram shows a practical triage path; the thresholds come from the particular business and intervention, not a universal marketplace benchmark.

Read diagram as text

• Select one market category and observation window to Records and metric windows reconcile?.
• Records and metric windows reconcile? to Repair coverage identity or financial mapping: No.
• Repair coverage identity or financial mapping to Select one market category and observation window.
• Records and metric windows reconcile? to Suitable supply reaches eligible searches?: Yes.
• Suitable supply reaches eligible searches? to Test availability relevance or supply acquisition: No.
• Suitable supply reaches eligible searches? to Test acceptance checkout and fulfillment losses: Yes.
• Test availability relevance or supply acquisition to Compare completed outcomes and contribution.
• Test acceptance checkout and fulfillment losses to Compare completed outcomes and contribution.
• Compare completed outcomes and contribution to Repeat use and economics support expansion?.
• Repeat use and economics support expansion? to Keep scope bounded and investigate the remaining loss: No.
• Keep scope bounded and investigate the remaining loss to Select one market category and observation window.
• Repeat use and economics support expansion? to Expand one market with explicit guardrails: Yes

Open full diagram

Bring one market, one complete cohort and its payment exceptions to the $99 martech audit. That gives the implementation work a concrete starting point: the records needed to explain a decision, the gaps preventing it, and the next calculation the team should be able to reproduce.

Written by

Jafrin Akter Alo

Data Engineer and Co-founder at Martechdevs and Growth and Analytics Partners

Jafrin writes practical guides to marketing technology, customer data, analytics and AI workflows. Martechdevs is a Growth and Analytics Partners company.

View LinkedIn profile