Machine Learning for Marketplaces and Platforms

Every marketplace becomes a ranking problem

At 200 listings, a marketplace can sort by newest and nobody minds. At 40,000 listings, the order of search results decides who sells, who churns and whether buyers find anything at all. That is the point at which machine learning stops being a nice idea and becomes part of how the platform works.

Consider a B2B marketplace matching 3,000 suppliers of industrial services with buyers posting 500 requests a month. Early on, the founders matched by hand. Now the volume makes that impossible, response rates are falling, and a few fake supplier profiles have started appearing. Those three problems, matching, engagement and trust, are where machine learning for marketplaces earns its keep.

Marketplace machine learning use cases, in rough order of need

1. Fraud, spam and fake listing detection. Scoring new accounts, listings and messages for risk, so moderators review the right few rather than everything.
2. Search ranking. Ordering results by likelihood of a useful outcome, such as a contact, booking or purchase, rather than just keyword match.
3. Matching and recommendations. Suggesting suppliers for a request, or listings for a buyer, based on what similar users engaged with.
4. Pricing suggestions for sellers. Helping sellers set prices that sell, based on comparable listings and outcomes.
5. Seller and buyer churn prediction. Spotting sellers whose listings are going stale and buyers whose activity is dropping.
6. Listing quality scoring. Nudging sellers to add photos, detail and accurate categories, which improves everything else.
7. Dispute and refund prediction. Flagging transactions likely to end in a dispute so they get attention early.

Fraud comes first because a marketplace that loses trust loses both sides at once. The methods overlap heavily with AI fraud detection in financial services, adapted to accounts, listings and messages rather than card payments.

Cold start and feedback loops

Two problems are specific to platforms and catch teams out.

• Cold start. New listings and new sellers have no engagement history, so a ranking model trained on clicks buries them. Give new listings deliberate exposure and use listing content to estimate quality until behaviour data exists.
• Feedback loops. Listings ranked highly get more clicks, which the model reads as proof they deserve ranking highly. Without correction, a small set of sellers ends up dominating and the rest leave.
• Position bias. Buyers click the top result partly because it is at the top. Training data needs adjusting for this, or the model learns to copy the old ranking.

A marketplace ranking model is shaping the market it learns from. Treat that as a design constraint, not an afterthought.

Holding back a small share of traffic with some randomisation in ranking is the standard remedy. It costs a little short-term relevance and buys you honest data.

How much data is enough?

Being early is not a failure. Plenty of successful platforms ran on good filters, simple rules and manual moderation well past their first year. Building machine learning before there is data to train it is one of the more common ways a start-up burns runway.

Regulation: ranking transparency and trust

In the EU, platforms must explain the main parameters that determine ranking, under the Platform to Business Regulation for business users and the Digital Services Act for online platforms' recommender systems. Very large platforms carry heavier duties, but even small ones need a clear, plain explanation of how results are ordered.

• Document the signals your ranking uses and keep the explanation current
• Be explicit if paid placement affects ranking
• Keep an appeals path for sellers whose listings or accounts are removed by automated moderation
• Log moderation decisions so they can be reviewed

Costs and sequencing

Indicative ranges: a fraud and spam scoring service with a moderation queue, eight to twelve weeks; learning-to-rank search on an existing search engine, ten to fourteen weeks including offline and live testing; recommendation features, eight to twelve weeks; pricing suggestions, six to ten weeks where comparable sales exist.

Budget for evaluation infrastructure alongside the models. Every ranking change should be tested against the current version on live traffic, with the result measured on transactions rather than clicks. Without that, you will not know whether a change helped, and neither will anyone else in the company.

How we would start

SpiderHunts usually begins by instrumenting the platform properly: logging searches, impressions, clicks, contacts and transactions in a form a model can use. Many platforms record only the transaction, which makes ranking impossible to learn. If you are still building the platform itself, our notes on Django for marketplaces and platforms and our SaaS development work cover designing that data in from day one.

Frequently asked questions