Choosing marketplace models tools: the four records liquidity actually needs

What to take away

• The record most marketplaces do not keep is the request that never got a response. It predicts churn.
• Naming marketplace models tools does not settle the records question. The records decide whether liquidity is measurable.
• Liquidity must be computable per segment. A system that only aggregates cannot answer the question the business runs on.
• Ask any candidate system for fill rate by segment with a time bound. Most cannot produce it.

The four records

1. Every request, including the ones that went nowhere. Most systems record transactions. The requests that failed show the market shape, and they are usually discarded.
2. The response chain with timestamps. Who was shown the request, who responded, and when. Without timestamps there is no time to first response. Without that you cannot see quality degrading.
3. Segment attributes on both sides. Geography, category, price band, urgency. Liquidity is a property of a segment. A schema that cannot express segments cannot express liquidity.
4. The money, with deductions. What was charged, what was credited back, what was refunded, and what settled off the platform.

The join that breaks

Fill rate needs the request log and the transaction ledger to agree on what a request is. They usually do not. The request log was built by the product team as event data. The ledger was built by finance as records of completed sales.

The symptom is a fill rate nobody trusts but everyone quotes. The fix is a written definition of a genuine request, agreed by both teams, applied consistently and dated.

That is a definition exercise before a software one. Skipping it installs a system that produces confident numbers on an unresolved question. The wider measures this feeds are in marketplace models.

When a spreadsheet is enough

Early on, and on three conditions:

A spreadsheet cannot hold a request log of any size. That is the point at which most marketplaces need something else. Recognize that moment by the size of the log, not by the size of the company.

What to require before buying, and named marketplace model tools to compare

Requirement	Why	How to test it
Failed requests retained	This is where churn is visible first	Ask for requests with no response last month
Timestamps on every step	Time to first response is the product	Ask for the distribution, not the average
Segment dimensions	Liquidity is per segment	Ask for fill rate in one narrow category
Deductions joined to fees	Otherwise the realized fee is unknown	Ask what was actually kept, by segment
Full export	You will move eventually	Ask for the export and open it

Run the export test first. A system whose data cannot be retrieved will quietly make your next strategic decision for you.

Publicly documented marketplace model tools include the following. None is ranked here. Prices are public list prices or labeled typical ranges.

Tool	What it does	Public facts to check
Sharetribe	Hosted marketplace software	No-code Go plan and developer Flex; supports Stripe Connect payouts; hosted plans historically start below $100 per month.
Arcadier	No-code marketplace builder	Templates for goods, rentals, and services; payment gateway integrations; starter plans commonly start under $100 per month.
Mirakl	Enterprise marketplace platform	Seller onboarding, catalog management, and Mirakl Connect; used by large retailers; pricing is quoted by scope.
Marketplacer	SaaS marketplace platform	Seller onboarding, catalog, and order routing; used by retailers to add third-party sellers; enterprise pricing.
CS-Cart Multi-Vendor	Self-hosted marketplace software	Publicly listed one-time license around $1,450; hosting and add-ons extra.
Stripe Connect	Payments for marketplaces	Seller onboarding, split charges, and payouts; publicly listed US card pricing is 2.9% plus 30 cents per successful charge, plus Connect fees.
Adyen for Platforms	Payments for marketplaces	Split payments, onboarding, and local payment methods; interchange-plus or custom pricing.
Mangopay	Payments and e-wallets	E-wallets, escrow, and payout APIs; pricing is custom and typically per transaction.

These tools store or move marketplace records. They do not define a genuine request, and they do not choose your segment. That work stays with you.

What no tool decides

None of them decide which side pays, how narrow your first segment should be, or what your fee buys. Those are the questions in pricing architecture and the classification work in business model types.

A tool also cannot tell you whether the matching is working. Repeat rate on the requesting side does that. It can be computed from records you already have. Where matching works and volume is flat, you have an acquisition problem. Where matching is weak and volume is growing, you are buying transactions.

The two situations need opposite responses. The cost arithmetic that separates them is in unit economics. The underlying economics of search and matching in electronic markets is treated in MIT's course on economics and e-commerce.

Common questions

Build or buy?

Buy the generic parts and build the request log. The definition of a request is specific to your market. Nobody else's schema will fit it.

We are pre-launch. What should we set up now?

The request log with timestamps and segment attributes. Everything else can be backfilled. That cannot. A request that was never recorded did not happen as far as any later analysis is concerned.

How long should we retain failed requests?

Long enough to see a full cohort mature. For most markets that means at least a year. Storage is cheap. The alternative is having no way to answer why growth stalled.

Can analytics tools already do this?

They can hold the events. What they usually cannot do is join those events to money. That is exactly the join the business runs on. Managerial accounting draws the same line between an event and its financial record, and MIT's financial and managerial accounting course sets out why the two are kept in different systems.