How would you launch a recommender for a new marketplace with no interaction history at all?

## What is actually missing In new-system cold start there is no interaction matrix. Not sparse — absent. Every collaborative method, latent-factor or neighbourhood, is unavailable by definition, and so is every offline evaluation that scores a ranking against historical behaviour. The problem is therefore not "which model" but **what to ship, in what order, and how you will know when to move on**. That is why this is a strategy question rather than an algorithms question. ## Sequence the launch **1. Instrumentation before ranking.** Log impressions, positions, and outcomes, joined to the item and the session context. Interaction data is the input to every later stage, and the months you fail to log are permanently lost. Teams routinely ship a ranking first and discover a quarter later that they logged clicks without impressions, which makes every rate uninterpretable because the denominator is missing. **2. A defensible non-personalised baseline.** Recency, category-scoped popularity once any traffic exists, availability and quality filters, and explicit business rules. Editorial or manual curation is entirely legitimate at this stage and often better than anything automated on a thin catalogue; the mistake is treating it as beneath the team rather than as the correct tool for the data volume. **3. Content-based personalisation.** This is the first genuinely personalised layer that a new system can support, because it needs only item metadata and one user's own session history — no cross-user data, no matrix. In a new regional marketplace it typically arrives within weeks, driven by category and attribute affinity from what the user has browsed in the current session. **4. Collaborative signal, on evidence.** Only when density supports it. Which brings up the part interviewers actually probe. ## Define the switch criteria before you need them Say in advance what "enough data" means, or the decision becomes a matter of who argues hardest: - **Interactions per active user** and **per servable item** — medians, not means, because a few hot items hide an empty tail. - **Item coverage** — the share of the servable catalogue that would have a vector fitted from real interactions. If it is 12%, a collaborative model is a good ranker for a catalogue you do not have. - **A held-out offline comparison** against the incumbent baseline, using item-level and time-based splits rather than a random one. - **An online test** as the actual gate. Offline lift on thin data is fragile, and the baseline is a real competitor rather than a straw man. Naming these numbers early converts an emotive argument into a checkable condition, and it is often the substance of the answer an interviewer is listening for. ## Transfer from an adjacent market, carefully If the company already runs the product elsewhere, reusing that market's model is tempting. The parts that transfer reasonably are the *structure*: feature definitions, the metadata schema, the pipeline, sensible defaults. The parts that transfer badly are the *fitted preferences*: inventory mix, seasonality, price bands and taste differ by region, and a confidently wrong prior is harder to spot than no prior at all, because the outputs look plausible. Transfer the engineering, re-fit the preferences, and hold the imported version to the same online comparison you would demand of any candidate. ## The trap: your baseline writes your training data Everything the system learns from is filtered through what the baseline chose to show. If launch ranking is pure recency, you will accumulate months of data about how recent items perform and almost none about anything else, and the first collaborative model trained on it inherits that blind spot as if it were preference. Two defensive habits: keep the launch ranking diverse enough that different parts of the catalogue get real exposure, and log enough context that you can later reason about what was shown and not merely what was clicked. Deciding how much short-term relevance to trade for that future data quality is a leadership call, not a modelling one, because the cost lands this quarter and the benefit lands next year. ## Set expectations about the timeline The last part of the answer is organisational. Stakeholders arrive expecting personalisation on day one, and the honest position is that a recommender is a data product whose quality is bounded by data volume that only usage produces. Communicating that as a staged plan with named milestones and criteria — baseline now, content-based at week six, collaborative when coverage passes the agreed level — is what stops the team from being pushed into shipping a collaborative model on a matrix too thin to support it, which produces a worse experience than the baseline it replaced and burns the credibility needed for the real version.