How do you handle cold start for a brand new user and a brand new item?

They are two different problems

Collaborative filtering learns from co-occurrence: it recommends to you what people similar to you engaged with. Both cold-start cases break that, but they break different halves of it and the remedies are not symmetric.

A new user has no history, so there is nothing to match them against. The information you do have is contextual and arrives free with the request: device, locale, referring source, time of day, and whatever the signup flow captured. The deficit closes quickly, because a user generates signal within their first session, and it closes on its own.

A new item has no interactions, so it appears nowhere in the co-occurrence data and cannot be retrieved by any collaborative index. The information you have is the item's own content: text, category, price, creator, tags, embeddings of its description or thumbnail. Critically, this deficit does not close on its own, because the item only accumulates interactions if the system shows it, and the system has no reason to show it. That asymmetry is the whole substance of the question.

The new user

Serve something reasonable immediately and improve within the session. Segment popularity is the honest baseline: the best-performing items for people in this country, on this device, arriving from this source. It is unpersonalised and it substantially outperforms nothing, and it costs a query.

Any explicit signal the product can collect cheaply beats it. An onboarding step that asks for two or three interests, or a first-run screen that offers a choice of starting categories, converts a cold user into a warm one before the first recommendation. That is a product decision as much as a modelling one, and raising it is worth credit because it acknowledges the cheapest fix is often not a model.

Then use the session itself. Two views and a search query give you a content-similarity target that is far more informative than a demographic prior. A sequence model over the current session is the natural formulation, since it needs no user identity at all — it predicts the next item from the items so far, which means it works on the first visit and on anonymous traffic.

The new item

Content features get the item into the candidate set at all. If you embed items from their text and imagery, a brand-new item has a vector on the day it is created and can be retrieved by similarity to what a user is looking at. This is the argument for hybrid retrieval: keep a content index alongside the collaborative one so that an item with zero interactions is still reachable.

Content features also transfer through their attributes. A new item from a creator whose other work performs well, in a category the user engages with, at a familiar price point, inherits a usable prior even though the item itself is unknown. This is where a model that learns from item attributes rather than item identifiers earns its keep, because the attribute weights are already trained and the new item simply presents its attributes.

But content signal is a weaker predictor of engagement than behaviour, so the item will rank below established items on any score the ranker produces, which brings you to the part that has to be deliberate.

Exploration has to be budgeted, not hoped for

If every impression goes to whatever currently scores highest, new items receive essentially none. No impressions means no interactions, no interactions means no collaborative signal, and the item stays cold permanently while the items that were popular last month keep collecting the traffic that confirms they are popular. The loop is self-reinforcing and it is caused by the system's own logging, because the ranker is trained on impressions the ranker chose.

The remedy is a reserved allocation rather than a preference. Give new items a guaranteed share of impressions — a fixed slot in the slate, or a fixed percentage of traffic — until they have accumulated enough interactions for their score to mean something. Frame it in the interview as a cost with a return: you are spending a small, measurable amount of engagement now to buy the information that tells you whether the item is good, and without that purchase you never find out.

The principled version is a bandit formulation, where an item's score carries an uncertainty estimate and the selection favours items whose upside is uncertain. Thompson sampling or an upper-confidence-bound rule both do this, and either turns "explore new items" into a rule that automatically stops exploring an item once its estimate is confident, in either direction. That last property is why it beats a fixed quota: a genuinely bad new item stops consuming exploration budget quickly.

Two guardrails make it survivable in production. Cap the exposure any single exploring item can get, so an item that is offensive or broken does not reach millions before a human sees it. And exclude exploration slots from the metrics you compare model variants on, otherwise a variant that explores more looks worse purely because it is doing the work.

Blend rather than switch

The naive implementation has a rule: fewer than N interactions, use the content model; more than N, use collaborative. It behaves badly at the boundary, because the recommendation set changes discontinuously and a single extra interaction can reshuffle everything a user sees.

Weight the two by the evidence instead. With few interactions the content-based score dominates; as interactions accumulate the collaborative score takes over, with the weight moving smoothly as a function of the interaction count. The cleanest version of this is not a blend of two systems at all but a single model that takes both identifier embeddings and content features as inputs — the identifier embedding is near its initialisation for a new item and contributes little, and the content features carry the prediction until it is trained. The transition then happens inside the model, driven by the data, rather than by a threshold someone has to maintain.

Whichever construction you use, measure it directly. Report the metric separately for cold and warm traffic, because an aggregate that is ninety per cent warm will not move when your cold-start handling gets worse. Track the share of impressions going to items created in the last week, and the time from item creation to its tenth interaction — those two numbers tell you whether new supply is reaching anyone, which is the thing the whole mechanism exists to guarantee.