The cold start problem

What cold start means

Collaborative filtering recommends things to you because people like you liked them. That works brilliantly at scale and fails completely at the edges. The classic definition comes from Schein, Popescul, Ungar and Pennock (2002), who framed the hardest case as recommending items "that no one in the community has yet rated".

There are two versions of the problem, and Affinity Atlas has both:

• New users. Someone signs up and the system knows nothing about their preferences. Lika, Kolomvatsos and Hadjiefthymiades (2014) describe exactly this: a new user arrives and there is simply no history to learn from.
• New or rare items. An artist, game or beer style seen by two people. Is it niche, or just new to our population? Niche weighting needs a rarity estimate, and rarity estimated from tiny counts is noise.

Why dating makes it harder

Recommending a film only has to satisfy you. Recommending a person has to satisfy two people. Researchers call these reciprocal recommender systems: people are both the subject and the object of the recommendation, and a suggestion only succeeds if both accept. Palomares and colleagues (2021) surveyed the field and made that mutual-acceptance constraint the defining feature.

The payoff for taking reciprocity seriously is large. In RECON (Pizzato et al., 2010), a reciprocal recommender evaluated on real online dating data, accounting for both sides' preferences raised success in the top ten recommendations from 23% to 42%. For new users it still reached 26%. Those numbers are from one dataset in 2010, not a universal benchmark, but the direction is clear: one-sided "who would you like?" models leave a lot on the table.

How others have handled it

The most public example of reciprocal thinking in a mainstream app is Hinge's "Most Compatible" feature. When it launched in 2018, Hinge told TechCrunch it learned from likes and passes and used a pairing approach inspired by the Gale-Shapley stable matching algorithm. CEO Justin McLeod's summary: "the person that you're seeing is also seeing you". The Verge reported that both people received the same recommendation, which expired after 24 hours. Hinge's current explanation describes a newer system, so treat the 2018 description as history rather than how it works today.

The catch is that behaviour-based systems need behaviour. On day one there are no likes or passes to learn from. The usual answer is to collect some explicit signal up front. Affinity Atlas starts somewhere different.

1. Borrow data that already exists

Recommender surveys group cold start solutions into explicit ones (ask the user) and implicit ones (infer from other data), with hybrids in between. Gope and Jain (2017) use that split; Burke (2002) surveyed the hybrid designs that combine them.

Affinity Atlas is, at its core, an implicit cold start strategy. A new user who connects Spotify, Steam and Goodreads is not a blank profile. They arrive with years of real listening, playing and reading. That is the whole premise of matching on data you are already creating: day one is not empty, it is just elsewhere.

2. Ask fewer, better questions

For interests without a good integration (pets, plants, astrology, parkrun), we have to ask. How you ask matters. Rashid and colleagues (2002) compared six strategies for choosing which items to ask new users to rate and found the choice significantly affected both how much effort users had to put in and how accurate predictions became.

That is why Interest Q&A branches. "Are you a pet person?" only leads to breeds, routines and dealbreakers if the answer is yes. Each answer is chosen to separate people, not to fill a form. Frequency answers feed engagement; preference strength feeds sentiment; answer rarity across users feeds niche weight.

3. Shrink small numbers

Here is the trap niche weighting has to avoid. Say an artist appears in 2 of the first 40 profiles. Taken literally, 5% of people like them, so a shared listen would earn a NicheWeight of 0.95. But with 40 people we have no idea whether that artist is genuinely obscure or just under-sampled.

Statisticians have a standard fix: pull small-sample estimates towards a prior until there is enough data to trust them. IMDb publishes one version for its Top 250, a weighted rating that blends a title's own average with the global average according to how many votes it has (IMDb help). Applied to popularity it looks like this:

With n = 40, an observed share of 5%, a prior of 50% and m = 20, the estimate is (40 x 0.05 + 20 x 0.5) / 60 = 0.20. The shared listen earns a NicheWeight of 0.80 instead of 0.95: still clearly niche, but not yet treated as a once-in-a-lifetime overlap. As the population grows, n swamps m and the estimate converges on the real share.

The same instinct shows up elsewhere. Evan Miller's well-known "How Not To Sort By Average Rating" shows how two positive ratings out of two can wrongly outrank 100 out of 101, and recommends the lower bound of the Wilson score interval. Search engines add pseudo-counts for the same reason, a trick known as add-one or Laplace smoothing. The details differ; the principle is identical: do not let tiny samples make extreme claims.

4. Say how sure you are

A new user's first match scores are less certain than they will be later. Most apps hide this. We think it should be on the card.

Recommender research supports showing uncertainty. Coscrato and Bridge (2023) argue that uncertainty estimates can be displayed alongside recommendations, used to trigger explanations, or used to mix safe suggestions with exploratory ones. Much earlier, Herlocker, Konstan and Riedl (2000) described recommenders as black boxes and found that explanations could improve acceptance.

Every Affinity Atlas match card carries a confidence level (High, Medium or Low) based on how many shared signals and shared sources the score rests on. A 61% built on three shared sources and six signals is labelled differently from a 61% built on nine sources and thirty signals, because they are different claims.

5. Explore in the open

Recommender systems learn faster when they sometimes show something uncertain to find out. McInerney and colleagues (2018) framed this as explore, exploit, and explain, with exploration especially valuable for new users and items. The usual way to explore is silently: slip uncertain items into your feed and watch what happens.

We would rather ask. In the demo, when someone has a source connected that you do not, the match card says so and shows the effect before you choose: "connecting Untappd would move this score from 48% to 55%". Because scores only use sources you both share, the number can go down as well as up, and the card says that too. Exploration becomes a decision you make, not an experiment run on you.

What we will not do

• No temporary visibility boost. We will not make your first week feel artificially busy so the second week feels like failure.
• No hiding thin data. If a score rests on very little, the confidence label says so.
• No pretending rare means meaningful. Small-sample rarity is shrunk until the population is big enough to trust it.
• No one-sided suggestions. Compatibility is pairwise and symmetric: you both always see the same number.

Cold start never fully goes away. Every new interest, new platform and new user brings a little of it back. The honest response is not to hide the uncertainty but to design for it, and to tell people where it is.