Marketplace Liquidity: What to Measure and What to Fix

A growing marketplace can still leave buyers without a usable match and suppliers without work. Liquidity measures how reliably those two sides reach a useful outcome. Start with one market segment and trace where requests stall—from discovery to acceptance to completion.

The useful question is where a relevant request stops becoming a completed transaction. Sharetribe's metrics guide covers buyer and supplier liquidity measures. Below, we define an operational version of each rate so your team can calculate it consistently. These definitions are choices to document, not universal industry benchmarks.

Defining Core Liquidity Metrics

To accurately diagnose failure points, you must define the outcome, unit of measurement, eligibility criteria, observation window, attribution rule, and data source for each metric. Track users in a cohort—a group sharing a stated starting event and time window.

Choose the same market segment and observation window for each numerator and denominator. Divide the numerator by the denominator and multiply by 100. A zero or missing denominator makes a rate unavailable, not zero.

Supplier participation and capacity utilization answer different questions. One completed job makes a supplier count as participating even if most of their available time goes unused.

Time and Concentration

Time-to-First-Transaction: This metric evaluates how long a user waits for their first success. You must show the elapsed-time distribution among completed outcomes alongside the unresolved count and age of waiting members. Dropping the still-waiting members can make time-to-success look artificially fast. Conversely, treating them as failed before the observation window closes is a separate error.

Supplier Concentration: This measures how much volume flows to your largest suppliers. Formula: Chosen top-N supplier GMV / all eligible supplier GMV in the same period. Use a disclosed "Top-N" selection (e.g., top 10 suppliers). This is an operational diagnostic tool to monitor platform reliance, not a fairness verdict.

The Request-Cohort Funnel

To see where transactions fail, track a specific cohort of requests from intent to completion over a stated observation window long enough for that service to complete. In the example below, each request has had its full seven-day window; seven days is an assumption, not a recommended default. Use one outcome per request so the denominator remains coherent.

Hypothetical arithmetic with a seven-day observation window:

• Eligible Requests: 80 unique request intents in the cohort.
• Matches Accepted: 50 accepted matches from those requests.
• Completed Transactions: 40 successful completions.

Resulting rates:

• Request-to-Match: 62.5% (50/80)
• Match-to-Completion: 80% (40/50)
• Request-to-Completion: 50% (40/80)

These percentages are illustrative math, not universal target benchmarks.

Diagnosing Symptoms and Interventions

Instead of reacting to a numerical symptom with a platform overhaul, pair the symptom with competing hypotheses, inspect the individual records, and deploy a small intervention.

Compare the next cohort on the same definitions. Record changes in category, geography, acquisition source or season so you do not attribute every movement to your intervention.

For structural approaches to platform design, review our marketplace business model selection and marketplace pricing strategy guide.

The Manual Operations Dashboard

To log these events before investing in automated tracking, use our manual starting log: Marketplace Operations Metrics Dashboard.

This is a manual Excel workbook containing four tabs:

1. Read Me: Instructions for manual entry.
2. Weekly Dashboard: Columns for Week, Active supply, Active demand, Searches, Requests, Matches, Completed transactions, Support tickets, Disputes, and Notes, with space for 12 weeks of manual entries.
3. Liquidity Metrics: Contains textual formula descriptions to guide your calculations (not live automated analytics).
4. Ops Queue: A log to track failures with columns for Issue, User Side, Severity, Root Cause, Owner, Resolution, and Prevent Next Time.

Because same-week aggregate counts are not a matched funnel, compute your rates only from linked eligible cohorts with sufficient observation time. Use separate copies of the file for different segments.

Inline Metric Definition Template

This hypothetical example shows the definitions to record alongside each rate. Replace the dates, windows and counts with your own:

• Metric Name: Search-to-Fill (Urban Services)
• Eligibility & Cohort: Distinct search sessions by registered users between Oct 1 - Oct 7.
• Observation Window: 14 days from the search session.
• Numerator: Distinct eligible search sessions attributed to at least one completed fulfillment within 14 days.
• Denominator: All eligible search sessions in the Oct 1 - Oct 7 window.
• Attribution Rule: Assign a booking to the last eligible search session by that user within 24 hours before the request. Count each successful session once; these windows are example choices.
• Unresolved Cases: Record the number and age still awaiting outcomes. Do not present an immature cohort as a completed observation window. Report genuinely unknown outcomes separately.
• Source: Search sessions linked to request and operational fulfillment records. Payment success alone does not establish that a job or delivery was completed.

Next Steps

Directorism designs and builds custom marketplaces and directories, including the workflows needed to record these events.

Before automating your tracking, establish a baseline:

1. Define a single operational cohort and time window.
2. Fill the Weekly Dashboard tab with your aggregate totals for that period.
3. Use the Ops Queue tab to log and inspect one specific failure from intent to completion.
4. Assign the next smallest intervention to test on your next cohort.

For further checks on your platform's operational model, consult the marketplace validation checklist.