Two-sided marketplace analytics means simultaneously tracking supply-side and demand-side health — not just GMV — to measure liquidity, match rate, and take rate as a connected system. When these metrics are siloed or poorly modelled, a marketplace can appear to be growing while its core matching engine is quietly breaking down.
If you run a two-sided marketplace — whether that is a B2B services platform, a payments or lending marketplace, a gig economy product, or a consumer commerce platform — the most dangerous moment is when your dashboard looks healthy and your business is not. GMV is growing. Registered users are up. Conversion looks fine. But underneath, supply quality is degrading, buyer repeat rates are collapsing, and your take rate is being quietly eroded by subsidised transactions you cannot see in aggregate.
This is the core problem with how most growth-stage marketplace companies are built: their analytics stack was designed for a single-sided business. And a single-sided analytics stack will always lie to you about a two-sided business.
Why Standard Analytics Tools Fail Two-Sided Marketplaces
The fundamental issue is structural. Standard analytics tools — and the BI dashboards built on top of them — are designed for linear funnels. A user arrives, they convert, they churn or return. That model works for SaaS, for e-commerce, even for lending. It does not work for marketplaces.
As the research makes clear, in a marketplace the funnel is a loop, not a line. Supply joins, creates inventory, demand searches, finds supply, a transaction occurs, a review is left, and the loop repeats. If you try to measure this with a standard e-commerce dashboard, you miss the most critical signal: whether buyers and sellers are actually finding each other at a rate that sustains the business.
A pattern we see repeatedly when working with marketplace clients at Fintel Analytics: they have solid product analytics in Mixpanel or Amplitude tracking buyer behaviour, a Stripe dashboard tracking revenue, and a BI tool pulling registered user counts from their production database — but no model that connects supply-side listing behaviour with demand-side search behaviour at the match level. The result is that when buyer conversion drops, nobody can answer the most basic question: is this a demand-side problem, or is supply quality degrading? Those two root causes require completely different responses.
To make things worse, most marketplace companies inherit a data model from their engineering team that was designed for operational purposes — recording transactions, not analysing them. This means the tables exist, but the relationships between buyer events, seller events, and transaction outcomes are either not modelled at all, or are modelled at a grain that makes analytics almost impossible to run efficiently.
📺 Watch: How To Do User Acquisition For A Two-Sided Marketplace
The Metrics That Actually Matter — And How to Model Them
The core error most marketplace founders make is treating GMV as the headline health metric. GMV measures economic activity on the platform, not the value captured by the marketplace business. Companies that optimise for GMV often inflate transaction volume through subsidies and promotions that destroy unit economics — the growth looks real until it suddenly is not.
The metrics that actually matter for marketplace health exist at three levels:
Level 1 — Liquidity
Liquidity is the probability that a buyer can find what they need and a seller can get a transaction. It is the single most important indicator of marketplace health, but it is extraordinarily hard to measure because it requires connecting supply-side listing behaviour with demand-side search and purchase behaviour across the entire platform.
The core liquidity metrics to build into your data model are:
- Search-to-fill rate: the percentage of buyer searches that result in a transaction. A falling search-to-fill rate is often the earliest warning sign of supply degradation or quality problems — it will show up here weeks before it appears in revenue.
- Time-to-fill: how long a listing sits before it is booked or sold. Rising time-to-fill, particularly concentrated in specific categories or geographies, signals local supply-demand imbalance.
- Buyer-to-seller ratio by segment: not globally — segmented by category, region, and cohort. A global ratio of 3:1 can mask a category that is running 15:1 (catastrophically oversupplied) alongside another running at 0.5:1 (no supply to serve demand).
To model these correctly, you need a transaction-level event table that joins buyer session data with supply listing data at the search event grain — not just at the transaction grain. This is where most marketplace data models fall short. They record what happened (a transaction), not what failed (a search that found nothing).
Level 2 — Match Quality
Match quality metrics measure whether the connections your platform makes between buyers and sellers are good ones. This matters because a marketplace can have high liquidity — lots of transactions occurring — but consistently poor match quality, which destroys retention on both sides.
Key match quality signals include:
- Repeat buyer rate by acquisition cohort: buyers who transact well on their first match will come back; buyers who have a poor first experience rarely do. Tracking this at the cohort level, not just in aggregate, is essential.
- Seller churn by transaction volume band: sellers who are not getting enough transactions will leave. A sudden increase in churn among mid-tier sellers — those generating 10–50 transactions per month — is a structural signal that demand routing is broken, not that sellers have lost interest.
- Review score distribution by category and geography: average review scores are vanity; distributions tell the truth. A category with 4.3 average stars can be hiding a bimodal distribution — a cluster of excellent sellers and a cluster of terrible ones — that is about to collapse trust on one side of the market.
Level 3 — Take Rate and Unit Economics
Take rate — the percentage of GMV that flows through to marketplace net revenue — is where the business model either works or does not. A falling take rate often indicates that incentive spend or promotional subsidies are being applied without visibility into their actual effect on liquidity or retention.
Building take rate analytics properly requires a transaction-level revenue model that separates gross transaction value, seller fees, buyer fees, promotional discounts applied, and refunds — at the individual transaction level, not rolled up monthly. Without this, you cannot identify which sub-segments of your marketplace are profitable and which are loss-making at scale.
If you are looking to understand how to build exactly this kind of analytics layer for your marketplace, explore how Fintel Analytics approaches this — we work with growth-stage marketplace businesses globally to design and deliver the data infrastructure that makes these metrics actually computable.
How to Build the Data Engineering Foundation
Good marketplace analytics is not a BI problem. It is a data engineering problem that a BI layer sits on top of. The quality of your metrics is determined almost entirely by the quality of your underlying data models — and most marketplace companies get the foundation wrong.
Here is the architecture we typically recommend for Series A or Series B marketplace businesses:
1. Source layer: Raw event and transactional data ingested from your product database (typically Postgres or MySQL), your payments provider (Stripe, Adyen, or a custom PSP), and your product analytics tool (Mixpanel or Amplitude). This should land in BigQuery or a comparable cloud warehouse. Do not do transformation here — bring the raw data in first.
2. Staging layer (dbt): Clean and standardise the raw source tables. This is where you handle null values, cast data types correctly, and deduplicate records. This layer should have tests on every critical column — null checks, uniqueness checks, referential integrity between buyer events and transaction IDs. The most common mistake is skipping this layer and building analytics models directly on raw tables, which means a schema change upstream silently breaks your reporting.
3. Intermediate layer (dbt): This is where the marketplace-specific modelling happens. Build separate grain models for:
- Supply events (listing created, listing updated, listing deactivated)
- Demand events (search, search with zero results, listing viewed, transaction initiated)
- Transaction events (transaction completed, transaction failed, refund, dispute)
- Seller lifecycle (onboarded, first transaction, active, at-risk, churned)
- Buyer lifecycle (registered, first transaction, repeat, dormant, churned)
Each of these should be a separate dbt model at the correct grain. Joining them prematurely into a single "master table" is the single most common mistake — it creates a model so wide and so query-intensive that it cannot run in reasonable time, and it obscures the analytical flexibility you need to answer questions at different levels of granularity.
4. Mart layer: Build business-oriented aggregate models on top of the intermediate layer — a liquidity mart, a take rate mart, a seller health mart, a buyer cohort mart. These are the tables your BI tool queries. They should be pre-aggregated at the right grain for your most common analyses, so your dashboards are fast and your analysts are not running full table scans every time a stakeholder refreshes a chart.
5. BI layer: For most marketplace businesses at Series A/B scale, Holistics BI or Looker are the right choices — tools that enforce a semantic layer so that take rate, liquidity ratio, and match rate have exactly one definition across the entire organisation. The scenario where finance is calculating take rate one way and the product team is calculating it another way, with leadership not knowing who to trust, is a direct consequence of not having a governed semantic layer. It is also one of the most common problems we encounter in new client engagements.
For more on how to build the testing and validation layer that keeps this infrastructure honest, see our guide on dbt Testing Strategy for Startups: Stop Shipping Bad Data.
The Siloed Dashboard Problem — And What It Actually Costs
One of the most consequential and least discussed problems in marketplace analytics is what happens when supply-side analytics and demand-side analytics are owned by different teams, built on different tools, and never formally reconciled.
In our experience working with growth-stage marketplace companies, this is not an edge case — it is the default. The product team owns buyer funnel analytics in Mixpanel. The operations team has a seller dashboard they built in Google Sheets from a weekly data export. Finance has a revenue model in Excel. None of these three sources have a common grain, a common definition of "active", or a common date logic. When leadership asks "why is our conversion rate falling?", each team produces a different answer — and they are all technically correct from within their own model.
A Salesforce research report published in late 2025 found that data and analytics leaders estimate 19% of their company's data is siloed, inaccessible, or otherwise unusable — and 70% of them believe their most valuable business insights reside in exactly that inaccessible portion. For a marketplace company, siloed supply and demand data is not an inconvenience. It is an existential risk.
We rebuilt the analytics infrastructure for a Series A marketplace business operating across multiple geographies. Prior to the engagement, the team had separate dashboards for buyer activity (Mixpanel), seller performance (a Google Sheet maintained by the operations manager), and financial take rate (a monthly Excel model). When GMV growth stalled, they could not identify whether the problem was on the supply side, the demand side, or the matching layer — because no single model joined these three views together.
After rebuilding the data models in dbt on BigQuery and surfacing a unified liquidity dashboard in Holistics BI, the team identified that search-to-fill rate had been declining steadily for 11 weeks in one geography — masked in the aggregate numbers by strong performance in another region. The root cause was a supplier quality issue that had gone entirely undetected. Weekly reporting that had previously required manual consolidation across three tools was replaced by a live dashboard that updated automatically — and the team had the answer to that question within 72 hours of the new infrastructure going live.
The Investor Lens: Why Your Metrics Are Failing Due Diligence
For marketplace founders approaching a Series A or B raise, analytics quality is increasingly a diligence issue — not just a nice-to-have. Investors evaluating two-sided marketplaces are not just looking at GMV growth. They are looking for evidence that the marketplace has durable liquidity, that take rate is defensible, and that unit economics are improving as the platform scales.
If your data infrastructure cannot produce clean, auditable, reproducible answers to questions like "what is our repeat buyer rate by acquisition cohort?" or "what is our seller churn rate by transaction volume band?", that is a red flag in a diligence process — regardless of how good the headline numbers look.
A pattern we see consistently: marketplace founders present investor decks with compelling GMV growth, but when the data room is opened, the underlying metrics are either unavailable at the required grain or computed differently in different documents. The investor's data team notices the discrepancy. The deal slows down. In some cases, it falls apart.
Building the right analytics foundation is not just an operational improvement. For a marketplace raising capital, it is a directly value-accretive activity — it reduces diligence friction, builds investor confidence, and often surfaces operational insights that improve the business before the round closes. For more on how to structure your data stack for investor scrutiny, see our guide on Investor Due Diligence Analytics: Build a Data Stack That Survives the Process.
Frequently Asked Questions
Q: What is the most important metric for a two-sided marketplace?
A: Liquidity is the single most critical marketplace health indicator — specifically the probability that a buyer can find what they want and a seller can secure a transaction. Liquidity is best measured through search-to-fill rate, time-to-fill by category and geography, and buyer-to-seller ratio at a segmented level. GMV is the most commonly cited marketplace metric but is also the most commonly misused — it measures economic activity, not the health or profitability of the platform.
Q: Why do marketplace analytics dashboards show different numbers across teams?
A: This is almost always a semantic layer problem. When supply-side analytics, demand-side analytics, and financial reporting are built on separate tools by different teams, there is no single agreed definition of metrics like "active seller", "conversion rate", or "take rate". The fix is to build a governed semantic layer — in a tool like Holistics BI or Looker — that enforces a single, documented metric definition across the entire organisation.
Q: How should a Series A marketplace company structure its data stack?
A: A typical Series A marketplace stack should include: a cloud data warehouse (BigQuery or Snowflake) ingesting raw data from your product database, payments provider, and product analytics tool; a dbt transformation layer with staging, intermediate, and mart models; and a BI tool with a semantic layer. The key is separating supply-side event models from demand-side event models in the intermediate layer, rather than joining them prematurely into a single wide table.
Q: What is take rate in a marketplace, and how should it be tracked?
A: Take rate is the percentage of Gross Merchandise Value (GMV) that flows through to the marketplace's net revenue. It should be tracked at the individual transaction level — not rolled up monthly — so that promotional discounts, seller fees, buyer fees, and refunds can each be analysed separately. A blended monthly take rate masks significant variation by category, geography, and customer segment, which is where the real unit economics story lives.
Q: How do I know if my marketplace liquidity is deteriorating before it shows up in revenue?
A: The leading indicators of liquidity deterioration appear in search and listing behaviour before they appear in revenue. Watch for: falling search-to-fill rate (more searches, fewer transactions), rising time-to-fill on listings, increasing proportion of zero-result searches, and declining repeat buyer rate in recent acquisition cohorts. These signals typically lead revenue decline by 6–12 weeks in most marketplace models — which gives you a window to act, if you are measuring them.
Two-sided marketplace analytics is genuinely one of the hardest data problems a growth-stage company can face — not because the metrics are conceptually complex, but because the data engineering required to make them computable is almost always underestimated. At Fintel Analytics, we have designed and delivered analytics infrastructure for marketplace businesses across fintech, payments, and e-commerce — from the raw data model through to the executive dashboard — and the single most consistent finding is that the businesses who invest in getting the foundation right outperform their peers at every subsequent stage of growth. If your current setup cannot answer "where exactly is our liquidity degrading, and why?", that is a solvable problem — and the window to fix it before your next fundraise is shorter than most founders realise.