Personalization for Marketplaces: Why Two-Sided Is Twice as Hard

TL;DR.

• Personalization for marketplaces is two cold-start problems wedged into one product: every new buyer is cold, and every new listing is cold, every day.
• Supply-side personalization is harder than demand-side because the supply has finite capacity, latent quality, and its own preferences about which buyers it wants.
• A two-sided marketplace recommendation engine has to optimize four axes at once: buyer intent, buyer ability-to-pay, seller capacity, and seller fit.
• The matching problem is not symmetric. Airbnb, Etsy, Upwork, and food delivery each hide a different axis in their ranker because their constraints differ.
• The cleanest mental model: a knowledge graph that stores buyer state, supply state, and their interaction history as first-class edges, then ranks against all four axes per request.

A friend who runs growth at a vertical labor marketplace told us last month that their conversion-rate test, the one designed to lift "buyer personalization," shipped a 4% lift to gross merchandise volume and a 9% drop in seller retention. They had personalized the experience for the demand side and quietly starved their best suppliers. That is what personalization for marketplaces actually looks like at scale: every demand-side win has a supply-side bill, and most rankers do not balance the books. This post walks through why two-sided marketplace personalization is twice as hard as e-commerce personalization, what the four matching axes of a marketplace recommendation engine are, and how four different categories of marketplace solve (or fail to solve) them.

Why personalization for marketplaces breaks the e-commerce playbook

The standard e-commerce personalization stack treats inventory as a static, infinite, fungible catalog. You have ten thousand SKUs of detergent and ten million sessions, and your job is to pick the right SKU per session. The ranker only needs to learn buyer preferences. Inventory does not push back.

A two-sided marketplace breaks every one of those assumptions. Inventory is not infinite — each Airbnb host has one calendar, each Upwork freelancer has one set of working hours, each restaurant on a food-delivery app has one kitchen. Inventory is not fungible — a Manhattan apartment for two on October 12 is not substitutable with a Brooklyn apartment for four on October 15, even though the catalog calls them both "listings." And inventory is not silent — it observes the platform, gets demoted in rankings, and either re-invests effort or churns to a competitor. The personalization for marketplaces problem is therefore three coupled problems: who is the buyer, what is the live state of supply, and how does the platform allocate scarce supply across competing buyers without burning either side?

We have written about cold-start and day-zero personalization before; in a marketplace, you face the cold-start problem twice over, in opposite directions, on every request. New buyers arrive with zero history. New listings arrive with zero proof. Neither side has the signal a collaborative-filtering ranker needs.

The four axes of personalization for marketplaces

A useful frame: the marketplace recommendation engine is not ranking items, it is solving a four-axis matching problem on every search. Get any axis wrong and the match fails for one of the two sides.

1. Buyer intent. What is the buyer actually trying to do this session? Is the query "a one-night stay" or "a six-month relocation"? Is it "a one-off logo" or "a long-term design partner"? Intent windows differ from search to purchase, and the signal is thin until the buyer has done a few sessions.
2. Buyer ability-to-pay. Two buyers with identical intent can have wildly different price tolerances. Showing a $4,000/night villa to a backpacker wastes both sides' attention; showing a $80/night hostel to a corporate traveler wastes a high-value session.
3. Seller capacity. Can the seller actually fulfill? Is the calendar open, the inventory in stock, the freelancer accepting clients this month? Capacity is the axis that most demand-led rankers under-weight, and it is the axis that destroys seller retention when ignored.
4. Seller fit. Will this buyer be a good buyer for this seller? Will they pay, show up, leave a review, not chargeback, fit the seller's preferred client profile? Sellers have implicit and explicit preferences and they will leave the platform if you keep matching them to bad customers.

The naive approach is to optimize only the first two axes and call the result "personalization for marketplaces." That is what the friend at the labor marketplace did, and it is what most marketplace personalization vendors ship by default. A real two-sided marketplace personalization system has to rank on all four axes simultaneously, with the relative weights tuned per vertical.

Why supply-side personalization is harder than demand-side

Demand-side personalization is hard but well-understood. The session is the buyer, the query is the goal, the inventory is the catalog, and the ranker learns from clicks and purchases. The literature is decades deep, and the algorithms — collaborative filtering, two-tower retrieval, contextual bandits — port reasonably well from e-commerce.

Supply-side personalization is genuinely new territory. The supply side is not a passive catalog; it is a population of economic agents with preferences, capacity, and a churn risk. That changes the problem in three structural ways:

• The reward function is delayed and indirect. When you rank a seller in front of a buyer, the right outcome is not "the buyer clicked." It is "the buyer transacted, the seller fulfilled, both parties were happy enough not to leave a one-star review or churn." That signal arrives weeks later, if at all. Demand-side ranking has the comfort of a same-session reward.
• The training data is highly censored. You only see outcomes for matches you actually made. If the ranker systematically buries category-C sellers, you have no data on whether they would have converted. The supplier-side research gap is exactly this censorship problem — Spotify Research has flagged it as an open area where demand-side techniques do not transfer (Spotify Research).
• Fairness and supply health become objectives. A demand-side ranker that always shows the top 5% of items is "personalized." A supply-side ranker that always shows the top 5% of sellers will lose the bottom 95%, and eventually the top 5% will be poached by a competitor with a larger funnel. You have to actively distribute opportunity, which means deliberately mis-optimizing for short-term GMV.

This is also why collaborative filtering ages badly in marketplace settings — it has no native way to express seller capacity, seller fit, or supply-health fairness. You can bolt them on, but the moment you do, you have left the world of pure CF and entered the world of constraint-aware ranking. At which point a graph representation usually wins.

Four marketplaces, four different hidden axes

The same four-axis problem has very different shapes depending on the marketplace vertical. Look at how the major categories solve it.

Airbnb: capacity and trust are the binding constraints

Airbnb's catalog is fundamentally bounded by calendar. The same listing has zero inventory on a booked date and one unit on an open one. Their search has to integrate availability as a first-class signal, not a post-rank filter. Their public engineering posts on listing embeddings describe how they train representations to reflect not just listing similarity but host-side outcomes — bookings, not clicks. That is supply-side personalization in production. Trust is the other axis: the platform has to weight a host's response rate, cancellation rate, and review count alongside buyer intent, because a buyer matched to an unreliable host churns harder than a buyer matched to no host at all.

Etsy: ability-to-pay and seller fit collide

Etsy's catalog is closer to e-commerce — millions of SKUs, no calendar — but the supply is overwhelmingly small-volume sellers who care intensely about who buys from them. A $400 custom wedding piece needs a buyer who can pay, will communicate, and will not return. Etsy's search has historically weighted ability-to-pay through price segmentation and personalized price ranges. Seller fit is messier: a sticker shop and a fine-art shop both serve the "personalized gift" query, but mismatched intent ruins reviews. The challenge here is that Etsy's supply is high-variance in price tolerance, much higher than a typical e-commerce vertical.

Upwork: seller capacity is invisible until you ask

Upwork has the hardest version of seller capacity because it is not in any database — a freelancer is "available" until they say they are not. Their ranker uses response-rate signals as a capacity proxy. They also have a fit problem: once a buyer finds a freelancer they trust, the marketplace risks being disintermediated. The platform's incentive is to preserve enough switching cost that the buyer comes back. That is a personalization problem with a structural conflict baked in. Public commentary from marketplace operators has noted this dynamic across labor marketplaces — Thumbtack faces it too.

Food delivery: real-time capacity is the entire game

For DoorDash, Uber Eats, and Instacart, the supply axis is literally a real-time kitchen utilization and courier-availability function. A restaurant that is at 100% throughput should be demoted in search even if it is the highest-conversion match — promising a 25-minute ETA that becomes 65 minutes destroys the buyer. Food delivery rankers are effectively scheduling systems with a personalization layer on top. They are the closest production example of all four axes being live at once, on a per-request basis, with sub-second latency budgets.

What a marketplace recommendation engine should actually do

If you are building a marketplace recommendation engine for personalization in 2026, the design constraints are clear enough to write down:

• Represent both sides as first-class entities. Buyers have intent histories, price tolerance, location, and lifecycle stage. Sellers have capacity, quality scores, category fit, and their own preferences over buyers. Both deserve persistent state, not just session features.
• Treat every interaction as a typed edge, not a click. A query is an edge. A view is an edge. A purchase is an edge with a value. A review is an edge with a sentiment. A cancellation is an edge with a sign. The ranker learns from edge types, not just from a flat session log.
• Rank against all four axes per request. Even if three of the four weights are tiny in your vertical, expose them. A change in market conditions (an Airbnb host strike, a freelancer talent shortage) will shift the weights, and you need the knobs already wired.
• Build observability for both sides. A 4% GMV lift that costs you 9% seller retention is a regression, but you will never see it if your dashboards only track demand-side metrics. Instrument both sides from day one.

This is the design space our reference architecture for real-time personalization was written against, and it is why graph-based representations have been outcompeting flat-feature stores in marketplace use cases. The four-axis problem is exactly the shape a knowledge graph can express natively. For the strategic frame on which side of the marketplace to invest first, the canonical operator write-up is Reforge's marketplace cold-start guide.

How ×marble fits in

We built ×marble to be the personalization layer that does not assume your catalog is e-commerce. The graph treats buyers and sellers as separate node types with their own state, supports typed edges for every interaction (view, query, purchase, cancellation, review), and ranks against configurable axes so you can weight capacity and seller-fit alongside buyer intent. Vivo, our consumer-facing product at vivo.timesmarble.com, is itself a two-sided personalization for marketplaces problem — the supply is human creators with finite output, the demand is viewers with finite attention, and the matching is exactly the four-axis problem above. If you are building a marketplace and would rather not write a constraint-aware ranker from scratch, the engine at timesmarble.com is the same one we run for Vivo.

FAQ

What is personalization for marketplaces?

Personalization for marketplaces is the practice of ranking, recommending, and matching items on a platform where both buyers and sellers are first-class users. Unlike e-commerce personalization, it has to optimize for buyer intent, buyer ability-to-pay, seller capacity, and seller fit at the same time. The goal is a match that both sides are happy with, not just a click.

Why is supply-side personalization harder than demand-side?

Supply-side personalization is harder because supply is not a passive catalog. Sellers have finite capacity, latent quality, and preferences over which buyers they want. The reward signal is delayed (you do not know if a match worked until the transaction completes), the data is heavily censored (you only see outcomes for matches you actually made), and fairness across sellers is an explicit objective, not just a side constraint.

How do you solve cold-start in a two-sided marketplace?

You solve cold-start in a two-sided marketplace by treating it as two problems at once. For new buyers, use day-zero signals — referrer, geo, device, declared intent — to bootstrap a session-level profile. For new listings, use content-based features (category, price, attributes), social proof from any external source the seller can verify, and a small budget of exploration impressions to gather real demand signal. See our deeper write-up on the cold-start problem and day-zero personalization.

What is a marketplace recommendation engine?

A marketplace recommendation engine is a ranking system designed for two-sided platforms where both demand and supply have to be modeled. It differs from a standard e-commerce recommender by representing sellers as first-class entities with capacity and preferences, modeling interactions as typed edges (view, query, transact, review), and optimizing on four axes — buyer intent, buyer ability-to-pay, seller capacity, seller fit — instead of one.

Should I personalize for the buyer or the seller side first?

You should personalize for whichever side is the constrained side of your marketplace. In supply-constrained marketplaces (Airbnb in a new city, Upwork in a new skill category) the seller side comes first, because losing a seller is worse than losing a buyer. In demand-constrained marketplaces (most niche verticals at launch) the buyer side comes first. The trap is treating it as symmetric and personalizing equally for both — you will end up with neither side trusting the platform.

Further reading

• Cold-start problem and day-zero personalization — the half of the problem most teams underestimate
• Why collaborative filtering is aging — why CF struggles in marketplace settings specifically
• Reference architecture for real-time personalization — the shape of a system that supports all four axes
• Recommendation engine vs personalization layer — why marketplaces tend to need both, not one
• Spotify Research: Recommendations in a Marketplace — Mehrotra and Carterette on the supplier-side research gap
• Reforge: beat the cold-start problem in a marketplace — operator-level strategic frame