∴ Use case · Marketplaces
Experiment on ranking, fees, incentives, and liquidity — not just UI.
The important marketplace levers are usually rules, not pixels: ranking, take rate, incentives, and matching. Trevo writes those variants in server code and sends each one through your normal pull-request review.
export function rankListings(listings, ctx) { return sortBy(listings, "recency"); // exp: blend recency with response rate return variant === "responsive-first" ? sortByBlend(listings, ["responseRate", "recency"]) : sortBy(listings, "recency");}
How do you A/B test a marketplace?
Marketplace experiments change the rules that move liquidity — ranking and matching logic, fee and take-rate rules, incentives, badges, and supply-side nudges — and measure transaction outcomes rather than clicks. With Trevo, each rule change is a pull request in your repository behind a feature flag, so both arms of a ranking or fee experiment are explicit and reviewable before they run. Assignment can hold per buyer so search feels stable, results use always-valid sequential statistics on metrics like completed transactions and take-rate revenue, and the losing rule is removed by an automatic cleanup pull request.
How it works
From a marketplace hypothesis — ranking, fees, incentives — to a decided rule change.
Trevo reads the marketplace logic
The scan finds where matching, ranking, pricing, and fees are decided, and where the two sides of the market see them. Proposals cite those exact files.
Rules become explicit variants
A blended ranking, a threshold fee, an earlier incentive — each expressed as code behind a flag, with the current rule preserved as control.
Assignment respects the market
Bucketing is consistent per user so search results do not reshuffle between visits, and both sides of a transaction get a coherent experience.
Transaction metrics decide
Completed transactions, take-rate revenue, time to first match — with guardrails for the other side of the market. mSPRT keeps every peek valid; cleanup is automatic.
Ranking is an experiment, not an argument
Every marketplace has the ranking debate: recency vs quality vs responsiveness vs margin. Trevo ends the meeting by running it — the competing sort orders are two arms of one experiment, decided on transactions rather than opinions.
- ✓Both sort rules explicit in one reviewable diff
- ✓Per-buyer consistency — results do not reshuffle
- ✓Guardrails for supply-side fairness metrics
control recency sortvariant blend: response rate × recencyprimary booking_completedguard new-seller exposure share
Fees and incentives, tested where they are computed
Take rates and promotions are code paths with real revenue attached — exactly where teams fear to touch. Trevo makes the change reviewable and reversible: both fee rules visible in the diff, the flag as the rollback, the cleanup PR as the eraser.
- ✓Fee thresholds and take-rate rules as experiments
- ✓Incentive timing and eligibility testable server-side
- ✓Revenue per transaction with always-valid stats
hypothesis first-booking coupon fires too latechange offer at first search, not at cartsurface full-stackmetric first_booking → 90-day GMV
What this looks like in practice
Illustrative marketplace proposals of the kind Trevo writes — yours come from your own matching and fee logic.
Δ ranking
Blend response rate into ranking
Rank responsive suppliers higher and measure completed transactions, with new-supplier exposure as the guardrail.
measures → search → booking_completed
Δ fees
Waive the buyer fee at a basket threshold
Turn the flat buyer fee into a threshold rule and state what unlocks it at checkout.
measures → checkout → revenue per order
Δ liquidity
Scarcity honestly, from inventory
Show real remaining capacity on listings — read from the same table that enforces it — and measure urgency effects without dark patterns.
measures → listing_view → booking_started
Frequently asked questions
Which side of the marketplace should experiments run on?
Bucket on the side whose behavior you want to change — usually the buyer for ranking and fees, the supplier for incentives and onboarding — and put guardrail metrics on the other side so a win for one is not a loss for the market. Trevo wires both kinds of events in the experiment PR.
How do you A/B test ranking without destabilizing search?
Assignment is consistent per user, so each buyer sees one ranking rule throughout the test rather than results reshuffling between sessions. The competing rule runs for its own cohort, and the comparison happens in the stats, not in front of a confused user.
Can network effects contaminate a marketplace experiment?
They can — two arms share one pool of supply, so strong interference is a real design concern. Guardrail metrics on the untested side surface it, and rules with mostly-local effects (fees, incentives, presentation, matching thresholds) test cleanly. For levers with heavy cross-arm interference, treat results as directional and confirm with a staged rollout — which is one merge away, since the variant is already code.
What metrics matter for marketplace tests?
Completed transactions and revenue per transaction beat clicks and views; time-to-first-match and repeat rate capture liquidity. Trevo evaluates the primary metric with always-valid sequential statistics, so checking daily is safe.
Our marketplace logic is tangled legacy code. Will the proposals be nonsense?
Proposals cite the code they read, so you can judge each one against the file it points at before approving. Messy codebases are normal input — the scan reads what is there, and anything it gets wrong dies in review rather than in production.
Keep reading: Pricing experiments · Trevo for growth teams · Trevo for startups · PostHog + Trevo · Trevo vs Eppo
Bring Trevo one real funnel problem.
Connect the repo and the first proposals arrive in under fifteen minutes, each one naming the exact files a full-stack experiment would change. Not ready? A free scan previews the ideas on your domain first.