The Cold Start Problem
6 min read · updated August 3, 2026
“Cold start” names three unrelated problems that happen to share a symptom. Fixing the wrong one is the usual reason a solution does not work.
Three cold starts, not one
| Which cold start | Description |
|---|---|
| new item | The item exists, the system does not. No interactions, so collaborative signal is undefined. Fixable from attributes, because an item's metadata exists before its behaviour does. This is the easy one and it is the one most people mean. |
| new user | The user exists, their history does not. Fixable by asking, by using context (device, locale, referrer, the page they landed on), or by deferring personalisation entirely until evidence arrives. |
| new system | Nobody has interacted with anything. No collaborative structure exists at all, and no amount of modelling creates it. The only answers are content-based ranking, an imported prior, or buying the data with exploration. |
The distinction matters because the fixes do not transfer. Content features solve the new-item problem completely and the new-user problem not at all. Onboarding questions solve the new-user problem and do nothing for a new item. And the new-system problem is a chicken-and-egg that only exploration breaks.
Why one click out of ten is not a 10% rate
The most common cold-start bug is not a missing model, it is arithmetic done too eagerly. An item shown ten times and clicked once is not a 10% click-through rate; it is almost no evidence at all. Ranking by raw rate hands the top of the list to whichever new item got lucky, and then the position bias makes the luck look real.
The fix is an empirical-Bayes shrinkage estimator: pull the estimate towards a prior whose strength you choose. With a Beta prior over the rate:
p_hat = (clicks + alpha) / (impressions + alpha + beta) alpha, beta pseudo-counts encoding the prior alpha / (alpha + beta) is the prior mean alpha + beta is how many observations the prior is "worth"
Set the prior from the item’s category rather than from nothing — that is what makes it empirical Bayes. Suppose the category’s historical click rate is 0.04 and you decide the prior should carry the weight of 100 impressions. Then alpha + beta = 100 and alpha = 4, beta = 96. For the new item with 1 click in 10:
p_hat = (1 + 4) / (10 + 100) = 5 / 110 = 0.0455 raw rate: 0.100 shrunk estimate: 0.0455 prior mean: 0.040 after 1,000 impressions with 100 clicks: p_hat = (100 + 4) / (1000 + 100) = 104 / 1100 = 0.0945
The estimate starts near the prior and migrates to the data as evidence accumulates, at a rate set by the single number you chose. That number is the honest expression of how much you trust the category to predict a new item, and it is a much better thing to argue about in a design review than a model architecture.
Buying information deliberately
Shrinkage stops you overreacting to thin data. It does not get you more data — an item ranked low by a shrunk estimate stays low, gets no impressions, and never accumulates the evidence that would move it. Breaking that requires spending impressions on purpose.
UCB1 gives a principled amount to spend. Rank by the estimated rate plus a bonus that grows with total time and shrinks with the number of times this item has been tried:
index_i = mean_i + sqrt( 2 * ln(t) / n_i ) mean_i observed reward rate for item i n_i times item i has been shown t total impressions across all items
Work it at t = 1000, where ln(1000) = 6.908. Item A is established: 500 impressions, mean 0.10. Item B is brand new: 5 impressions, mean 0.
A: 0.100 + sqrt(2 * 6.908 / 500) = 0.100 + sqrt(0.0276) = 0.100 + 0.166 = 0.266 B: 0.000 + sqrt(2 * 6.908 / 5) = 0.000 + sqrt(2.7631) = 0.000 + 1.662 = 1.662 B is shown, despite having zero observed reward.
The bonus falls as 1/sqrt(n_i), so B’s advantage evaporates quickly: by 500 impressions its bonus equals A’s, and from then on it is judged on its record. That decay is what makes the exploration cost bounded rather than open-ended, and it is why UCB is a better answer than a fixed “show new items 5% of the time” rule — the fixed rule spends the same budget forever regardless of how much it has already learned.
Thompson sampling is the alternative worth knowing: keep a Beta(alpha + clicks, beta + misses) posterior per item, draw one sample from each, rank by the draws. An item with 1 click in 5 under a uniform prior has posterior Beta(2, 5), mean 2/7 = 0.286, and a wide enough distribution that it will sometimes draw high and get shown. It tends to be gentler than UCB in practice and it composes naturally with the shrinkage prior above, because they are the same Beta.
One caveat that costs people real money: both indices above assume the reward you observe is caused by the item, and in a ranked interface it is partly caused by the slot. An item explored into position 1 collects clicks that an equally good item explored into position 8 does not, so the bandit learns the slot and calls it the item. Either explore within a fixed position — swap the candidate into the same slot every time — or divide the observed reward by the position propensity before it reaches the estimator. It is the correction from the metrics page again, and skipping it turns an exploration budget into a slot-popularity measurement.
Four strategies and what each costs
- Content bootstrapping. Represent the new item from its attributes or text and place it in the same space as items that have history. Requires: an item encoder and populated metadata. Costs: nothing at serving time. Fails when your metadata is thin or written by whoever uploaded the item, which is more often than product teams expect. Practically this means the item embedding is only as good as your catalogue hygiene.
- Contextual priors. Before you know the user, you know the referrer, the locale, the device, the time and the entry page. Segment popularity by those and you have a defensible default that is not a global bestseller list. Requires: nothing you do not already log. Costs: nothing. This is the highest return per hour of work on the list and it is routinely skipped.
- Explicit elicitation. Ask during onboarding — pick three topics, follow five accounts. Requires: a UI and a reason for the user to bother. Costs: friction, measurable as drop-off at that step. Worth it when the alternative is several sessions of bad recommendations, and not worth it when the user can get value without answering.
- Exploration. Spend impressions to buy information, with UCB or Thompson sampling deciding where. Requires: the machinery above, and a willingness to serve a knowingly suboptimal result some of the time. Costs: exactly the exploration budget, which is the one cost on this list you can compute in advance. It is also the only strategy that solves the new-system case, and the only one that produces the counterfactual data a personalisation model needs to escape its own feedback loop.