Why Cold Start Is Structural in Two-Sided Markets
Cold start is usually described as a nuisance, the awkward first weeks before data accumulates. In a two-sided marketplace it is closer to a structural condition, because the recommender's raw material is interaction history, and a young marketplace has none. New buyers browse inventory with no signals attached; new suppliers list into a void where nothing they offer is ever surfaced. Both sides read the silence as evidence the platform is empty, and the recommendation system, by having nothing to say, confirms it.
The churn math is unforgiving. A buyer's first two or three sessions decide whether the app earns a place on the home screen, and those sessions are exactly the ones a behavioral recommender cannot inform, because the buyer has no history and, if the marketplace is young, the items around them may have none either. Suppliers meanwhile judge the platform by whether their listings earn impressions in week one. The recommendation layer is therefore not a growth feature bolted on later; it is the marketplace's answer to both sides' first impressions.
This is also why porting a mature recommender's architecture to a young marketplace fails. The techniques that shine at scale, matrix factorization, deep retrieval, sequence models, all consume interactions, and there are not enough interactions to consume. The correct sequence is to start with systems that need no history at all, instrument them so they generate training data, and graduate to learned models when the data justifies them. The rest of this post is that sequence, in the order we actually run it for marketplace clients.
Baselines That Need No History
The first working recommender for a new marketplace is not a model; it is policy. Popularity within category, recency-weighted so the newest supply gets a window, and editorial slots the operations team can pin for launches or seasonal pushes, these need zero interaction data and immediately solve the empty-shelf problem. They feel unsophisticated to teams excited about machine learning, and they are precisely what keeps early buyers from staring at nothing. Sophistication is earned with data; relevance theater is not.
Content and attribute matching extends the same idea. A new item can be recommended through what it is, category, price band, location, attributes, long before anyone has interacted with it, and a new user can be served by context: what they searched, their city, the time of day. Co-occurrence, users who engaged with X often engaged with Y, builds useful signals from a modest number of sessions and refreshes cheaply. None of this requires embeddings, which matters more than it sounds: a baseline you fully understand and can debug beats an opaque model that is merely fashionable.
Keep the baseline forever, for two reasons. First, as fallback: when a learned model's inputs are missing, degraded or stale, the baseline is what the surface renders instead, and users should not perceive the difference as a broken app. Second, as challenger: the simple system is the yardstick every complex system must beat, measured rather than assumed. Teams that skip the baseline lose the ability to prove their model works, which is how organizations end up paying inference costs for a system indistinguishable from sorting by popularity.
Match Supply to Demand, Not Items to Users
A recommendation objective copied from retail, maximize click-through, quietly damages a two-sided marketplace. Pure engagement ranking concentrates demand on whatever already converts, starving new suppliers of the impressions they joined to receive, until they churn off the platform and supply thins. The marketplace's real objective is matching efficiency on both sides: buyers find something worth transacting quickly, and supply gets enough exposure to justify listing. Those goals overlap but are not the same, and the recommender is where the tension gets resolved, well or badly.
The mechanisms are practical. Give new listings an explicit exploration budget, a guaranteed number of impressions across relevant queries and surfaces, after which they compete on merit. Cap the share of any surface that one supplier or one item can occupy. Weight the ranking objective with utilization, not just engagement, so a well-reviewed supplier with open capacity is not buried beneath a saturated one. None of these require machine learning; all of them require deciding that the recommender serves the marketplace's health and not only the session's next click.
The two-sided view also changes what you measure. A ranker that lifts buyer click-through while depressing supplier retention is a failure that looks like a success for a quarter. Track supplier-side health, new-supplier activation, impression fairness, repeat-listing rates, with the same seriousness as buyer conversion, and treat sharp divergence between the two as a defect in the objective rather than a trade-off to accept. A marketplace that starves either side is temporarily optimizing its way out of business.
Evaluation Discipline Before Sophistication
Offline metrics mislead in two-sided settings more than anywhere else. Precision and recall against held-out interactions measure how well you re-predict the past, including all the popularity bias your own previous ranking created. A model that recommends whatever was already winning scores beautifully offline and accelerates exactly the supply concentration you are trying to prevent. Treat offline scores as a sanity filter, never as the decision, and be suspicious when a candidate's offline gains concentrate entirely on the most popular items.
The decisions that matter come from online experiments with guardrails on both sides. Roll a candidate ranking against the baseline on a small traffic slice and watch buyer conversion and repeat engagement alongside supplier activation and impression distribution. Pre-commit the guardrail thresholds before the experiment starts, because deciding them after seeing the numbers is how teams rationalize shipping a winner that quietly taxes supply. Log every exposure and outcome from day one, the impressions, the rankings, the results, because that log is the training set every future model will need.
There is a compounding effect worth naming: the discipline of evaluating simple systems well is the same muscle that evaluates complex ones. Teams that A/B their popularity baseline honestly, with pre-registered metrics and supply-side guardrails, deploy their first learned retriever safely. Teams that ship models on intuition, because the demo looked good, carry that habit into every subsequent generation and eventually ship something expensive and broken at scale. The sophistication of the system matters less than the honesty of the evaluation around it.
The Upgrade Path to Learned Models
Graduate to learned models when the data says so, not the roadmap. The signal is volume: enough interactions per category that co-occurrence matrices are dense enough to trust, enough supplier history to model, enough traffic to measure a difference in an experiment. Before that line, embeddings and collaborative filtering mostly re-derive what the baselines already do, at higher cost and opacity. We have reviewed marketplaces running learned retrieval on interaction volumes where a tuned popularity heuristic matched it, and the team could not tell because it had never run the comparison.
The shape of a healthy progression: content-based ranking and explicit exploration budgets at launch, co-occurrence and simple behavioral signals as sessions accumulate, then retrieval models and learned rankers layered over a baseline that never retires. New items and new users always ride the content path, because cold start never fully disappears, it becomes a routing decision instead of a crisis. Each generation runs as a challenger against the last, with the supply-side guardrails from the evaluation discipline still armed.
Where teams stall is not the algorithm but the infrastructure underneath: exposure logs that were never written, experiment tooling that cannot split traffic fairly across both sides, feedback loops where the recommender's own past outputs contaminate the training data. Those are engineering problems, solvable in weeks if addressed early and painful to retrofit if not. Building the instrumentation and evaluation loop alongside the product from day one is the difference between a marketplace whose recommendations compound and one that restarts its recommender every eighteen months. Our AI development services build that foundation in from the first sprint.