Cold Start: New Users, New Items

The Blank Screen Problem

Priya gets a new phone and downloads a music streaming app (the kind you've probably used yourself, whether it's JioSaavn, Spotify, or Gaana). She signs up with her phone number, and before she has played a single song, the app stops her with a screen: "Pick at least 3 genres or artists you enjoy." She taps a few: Bollywood romantic, some Punjabi pop, a couple of Sufi singers. Only then does the home screen fill up with songs.

Her cousin Ananya, who has used the same app for three years, never sees a screen like that. Ananya opens the app and it already seems to know her: the top row is full of songs that feel picked for her mood that week, no genre picklist required.

Why the difference? Ananya's account carries three years of listening history: thousands of songs played, skipped, replayed, and shared. Priya's account carries nothing at all. The app cannot recommend "songs like the ones you've enjoyed before" to someone who hasn't enjoyed anything on the app yet, because there is no "before." This is called the cold start problem: the difficulty of making good recommendations when there isn't enough interaction history to learn from, either because the user is new, or because the item itself is new and nobody has interacted with it yet.

Every platform you use daily runs into this constantly. Flipkart lists a product with zero reviews the day a new seller joins. Swiggy adds a restaurant to your city with zero past orders. YouTube uploads a video that has zero watch time in its first second of existence. In each case, the system that normally relies on "what did people like this do before" has nothing to work with. And yet, somehow, that Flipkart product still gets shown to someone, that restaurant still gets its first few orders, and Priya still ends up with a home screen full of music she actually likes. The fix is a clean piece of applied mathematics you can compute by hand in a few lines, and it's exactly what that genre-picker screen is quietly doing behind the scenes.

How Recommenders Learn: The User-Item Matrix

To see exactly where cold start breaks things, it helps to know how a recommender system behaves when it does have data. The most common technique is called collaborative filtering, and its core idea is simple: people who agreed in the past will probably agree again. If Amit and Riya have both loved the same five songs, and Amit just discovered a sixth song he loves, there's a good chance Riya will love it too, even though she has never heard it.

To make this computable, the system organizes everything it knows into a user-item interaction matrix: a table where every row is a user, every column is an item, and each cell records a signal of interest such as a star rating, a play count, or a purchase. Below is a small slice of one from our music app. Ratings run from 1 (disliked) to 5 (loved), and a question mark means the user has never interacted with that song at all.

              Tum Hi Ho   Kesariya   Vande Mataram   Nagada Sang Dhol   Naya Safar
Amit          5           4          2               1                  ?
Riya          4           5          1               2                  ?
Farhan        1           2          5               4                  ?
Sneha         2           1          4               5                  ?
Priya (NEW)   ?           ?          ?               ?                  ?

Look closely at the pattern. Amit and Riya both rate the romantic songs ("Tum Hi Ho," "Kesariya") high and the patriotic or party songs low, so they behave like similar listeners. Farhan and Sneha show the opposite pattern. A collaborative filter notices this by computing a similarity score between rows, and uses it to fill in the blanks: since Amit and Riya agree closely, whatever high rating Riya would give a new song is a decent guess for what Amit would give it too.

Now look at Priya's row. Every cell is a question mark. There is nothing to compare her ratings against, because she has no ratings: no shared songs, no pattern, no signal at all. Look also at the "Naya Safar" column: every cell in it is a question mark too, since that song was uploaded minutes ago and nobody has played it yet. Similarity calculations like the ones collaborative filtering depends on need at least some overlapping, non-empty values to compare. A row or column that is entirely empty gives the formula nothing to work with, so the similarity is and the system has no basis to rank one song above another for Priya, or to decide who might enjoy "Naya Safar." That is the cold start problem laid bare in a single table.

Three Kinds of Cold Start

It helps to separate the problem into three distinct cases, because each has a slightly different fix:

• New-user cold start: a person joins the platform with no interaction history at all, like Priya above.
• New-item cold start: a product, video, song, or restaurant is added to the catalogue with no interaction history, like "Naya Safar" above.
• New-system cold start: an entire platform launches for the first time, with no users and no items and therefore no data whatsoever. This is the hardest version, and it's why brand-new apps often lean on content and editorial curation before any real personalization becomes possible.

New-user and new-item cold start are the ones every growing platform faces every single day: thousands of new signups and thousands of new listings, all needing a first recommendation before any interaction data exists for them. As it turns out, both are solved the same way.

Solving New-User Cold Start: Ask, Then Compute

If a system cannot learn from what Priya has done, the next best option is to learn from what Priya says. This is why the genre-picker screen exists. It collects data the app doesn't have yet. For the worked example ahead, her picks simplify down to two tags that our small catalogue actually uses: Romantic and Classical.

This is the idea behind content-based filtering, the second major family of recommendation techniques alongside collaborative filtering. Instead of comparing users to other users, content-based filtering compares the features of items to the stated or inferred preferences of a user. Both get represented the same way: as a list of numbers called a feature vector.

Suppose our music app tags every song against four genre categories: Romantic, Patriotic, Party, and Classical. A song gets a 1 in a category if it belongs to that genre and a 0 if it doesn't, and a song can belong to more than one. Here are the tags for five songs in the catalogue, including the brand-new "Naya Safar," tagged by its uploader the moment it was published, no plays required:

Tum Hi Ho          [1, 0, 0, 0]   Romantic
Kesariya           [1, 0, 0, 0]   Romantic
Vande Mataram      [0, 1, 0, 1]   Patriotic, Classical style
Nagada Sang Dhol   [0, 0, 1, 0]   Party
Naya Safar (NEW)   [1, 0, 0, 0]   Romantic -- zero plays so far

This table needed zero listening history to build. Every value comes from metadata, from facts about the song itself, not from what anyone did with it. That is precisely what makes content-based filtering immune to the cold start problem: it doesn't ask who has interacted with this item, it asks what this item is, and that question can be answered on day one.

Priya's picks translate into a feature vector the same way. She selected Romantic and Classical, so her preference vector is [1, 0, 0, 1], a 1 in the two categories she chose and a 0 everywhere else. The system now has two things it can compare directly: Priya's preference vector, and every song's feature vector. All that remains is a way to measure how close two vectors are.

The Math: Cosine Similarity, Step by Step

The standard way to measure how similar two feature vectors are is cosine similarity. The name sounds intimidating, but the idea behind it is geometric and fairly simple: treat each vector as an arrow pointing in some direction in space, and measure the angle between the two arrows. Two arrows pointing in nearly the same direction are very similar. Two arrows at right angles share nothing in common, and two arrows pointing in opposite directions are opposites. Cosine similarity turns this into a single number between -1 and 1, and for non-negative feature vectors like ours, built entirely from 0s and 1s, it will always land between 0 (completely unrelated) and 1 (pointing in exactly the same direction).

The formula has two ingredients, calculated separately and then combined:

cosine similarity(A, B) = (A · B) / (|A| × |B|)

A · B is the dot product: multiply the vectors' matching positions together and add up the results. |A| and |B| are the magnitudes, or lengths, of each vector: square every entry, add the squares, and take the square root. Compute this by hand for Priya's profile P = [1, 0, 0, 1] against every song in the catalogue.

First, the magnitude of Priya's own vector, since it gets reused in every comparison:

|P| = sqrt(1² + 0² + 0² + 1²) = sqrt(1 + 0 + 0 + 1) = sqrt(2) ≈ 1.41

Now "Tum Hi Ho," with feature vector A = [1, 0, 0, 0]:

A · P = (1×1) + (0×0) + (0×0) + (0×1) = 1
|A| = sqrt(1² + 0² + 0² + 0²) = sqrt(1) = 1
cosine similarity = 1 / (1.41 × 1) = 0.71

"Kesariya" carries the identical feature vector [1, 0, 0, 0], so by the same arithmetic it also scores 0.71.

Next, "Vande Mataram," with feature vector C = [0, 1, 0, 1]:

C · P = (0×1) + (1×0) + (0×0) + (1×1) = 1
|C| = sqrt(0² + 1² + 0² + 1²) = sqrt(2) ≈ 1.41
cosine similarity = 1 / (1.41 × 1.41) = 1 / 2 = 0.50

Then "Nagada Sang Dhol," with feature vector D = [0, 0, 1, 0]:

D · P = (0×1) + (0×0) + (1×0) + (0×1) = 0
cosine similarity = 0 / (anything) = 0.00

And finally, the brand-new "Naya Safar," with feature vector E = [1, 0, 0, 0], the same tag as "Tum Hi Ho," despite never having been played:

E · P = (1×1) + (0×0) + (0×0) + (0×1) = 1
|E| = sqrt(1² + 0² + 0² + 0²) = 1
cosine similarity = 1 / (1.41 × 1) = 0.71

Lining up every score gives Priya's ranked recommendation list, computed before she has listened to a single track:

Tum Hi Ho          0.71
Kesariya           0.71
Naya Safar (NEW)   0.71
Vande Mataram      0.50
Nagada Sang Dhol   0.00

Priya gets a sensible, personal-feeling list from two taps on an onboarding screen, without anything about her having to be learned from behavior. And "Naya Safar" ties for first place despite having zero plays: it didn't need a single listener before it could be recommended to the right person, because its genre tag alone was enough to match Priya's stated taste. One calculation just solved new-user cold start and new-item cold start at the same time.

Coding It: A Content-Based Recommender in Python

The hand calculation above is exactly what a recommender system automates in code. Here is a complete, runnable implementation using nothing beyond Python's standard math module, so every step stays visible:

import math

# Genre feature vectors: [Romantic, Patriotic, Party, Classical]
songs = {
    "Tum Hi Ho":         [1, 0, 0, 0],
    "Kesariya":          [1, 0, 0, 0],
    "Vande Mataram":     [0, 1, 0, 1],
    "Nagada Sang Dhol":  [0, 0, 1, 0],
    "Naya Safar (NEW)":  [1, 0, 0, 0],   # just uploaded, zero plays
}

def cosine_similarity(v1, v2):
    dot_product = sum(a * b for a, b in zip(v1, v2))
    magnitude1 = math.sqrt(sum(a * a for a in v1))
    magnitude2 = math.sqrt(sum(b * b for b in v2))
    if magnitude1 == 0 or magnitude2 == 0:
        return 0
    return dot_product / (magnitude1 * magnitude2)

# Priya's onboarding picks: Romantic and Classical
priya_profile = [1, 0, 0, 1]

recommendations = []
for title, features in songs.items():
    score = cosine_similarity(priya_profile, features)
    recommendations.append((title, round(score, 2)))

recommendations.sort(key=lambda pair: pair[1], reverse=True)

for title, score in recommendations:
    print(f"{title}: {score}")

Running this prints:

Tum Hi Ho: 0.71
Kesariya: 0.71
Naya Safar (NEW): 0.71
Vande Mataram: 0.5
Nagada Sang Dhol: 0.0

which matches the by-hand arithmetic exactly. The cosine_similarity function never needs a play count, a rating, a purchase history, or any record of past behavior anywhere in its body; it only ever looks at the two vectors it is handed. Swap priya_profile for any brand-new user's onboarding picks, or add any brand-new song's genre tags to the songs dictionary, and the function produces a ranked, personalized list immediately, which is exactly the guarantee a cold-start solution needs to provide.

One line deserves a closer look: if magnitude1 == 0 or magnitude2 == 0. If a song had no genre tags at all, an empty vector [0, 0, 0, 0], its magnitude would be zero, and dividing by zero would crash the program. This isn't a corner case you can skip past: real catalogues genuinely contain items with missing or incomplete metadata, and a recommender that crashes on them is worse than one that simply scores them as unrelated to everyone.

Solving New-Item Cold Start When Metadata Isn't Enough

"Naya Safar" was rescued from cold start almost for free, because a music app always collects clean, reliable metadata: an uploader must supply a genre, an artist, a language, and a duration before a song can even be published. Not every new item comes with metadata that good. A brand-new restaurant on Swiggy might list its cuisine type but say nothing about portion size, spice level, or how fast it actually cooks, which are exactly the things that predict whether people reorder from it. A newly listed product on Flipkart from a first-time seller might have a thin or overly generous description. When content features are weak or untrustworthy, platforms fall back on two further techniques.

The first is popularity-based recommendation: when there is genuinely nothing personal to go on, show the item, or show the new user, whatever is doing best across the whole platform right now. This is why a brand-new user's very first home screen is often a "Trending Today" or "Most Ordered Near You" row rather than anything personalized. It isn't tailored to any one person, but it's unlikely to be actively bad, since it reflects what large numbers of other people are already choosing.

The second is deliberate exploration. Instead of waiting passively for interaction data to appear, the platform manufactures some: it shows the new restaurant or the new product to a small, random slice of users who look like a reasonable fit, watches what happens next (do they click, order, buy, return), and uses that early signal to decide how widely to promote it. This trades a little short-term recommendation quality, since some of those first users might get a middling suggestion, for the information needed to make much better recommendations soon after. Balancing "show things we already know are good," called exploitation, against "try things we're still uncertain about, to learn more," called exploration, is formally known as the multi-armed bandit problem, a topic properly covered in more advanced machine learning courses. The underlying intuition, giving the new arrival a fair, limited trial before deciding how much to trust it, is one you already understand from ordinary life.

Hybrid Systems: Shifting the Blend Over Time

No real platform picks exactly one of these techniques and stops there. Production recommender systems are almost always hybrid recommender systems, blending collaborative filtering, content-based filtering, popularity, and exploration together, and shifting that blend continuously as data accumulates. A practical way to picture the blend is as a sliding weight:

• On day one for a new user, the system leans almost entirely on content-based filtering and popularity, because collaborative filtering has nothing to work with yet.
• After the user has ten or fifteen genuine interactions (songs played to completion, products clicked, restaurants ordered from), collaborative filtering finally has enough signal to start contributing, and the system quietly raises its weight.
• After hundreds of interactions, collaborative filtering usually takes over, sometimes paired with richer techniques built on the same idea (matrix factorization is the classic example, and more advanced courses explore it in depth), because "people with taste like yours enjoyed this" becomes a far sharper signal than genre tags alone once there is enough history to compute it from.

The same sliding blend applies to items. "Naya Safar" gets recommended purely by content match on day one. If, over the following week, the specific people it was recommended to actually play it all the way through and come back for a replay, that behavior becomes real interaction data: new, non-empty entries in its column of the user-item matrix. From that point on, collaborative filtering can start recommending it too, layered on top of the content match that got it noticed in the first place. Cold start is a permanent, ongoing condition at the edge of the system, not a hurdle a platform clears once and forgets. There is always a next new user signing up and a next new item being added.

Back to the Blank Screen

Priya's genre-picker screen was never a formality. It was the fastest way to convert her into a set of numbers a similarity formula could use, standing in for the play history she doesn't have yet. The moment she taps "Romantic" and "Classical," she becomes the vector [1, 0, 0, 1], and every song in the catalogue, even one uploaded five minutes ago with zero plays, can be scored against her instantly.

That is the whole trick. When the data a recommender normally relies on doesn't exist yet, swap in a different kind of data that does exist: declared preferences, item metadata, platform-wide popularity, or a small deliberate experiment. Given enough time, real interaction history builds up on its own, and the substitute is no longer needed. A few weeks from now, Priya's own listening pattern will start doing the heavy lifting, the genre tags will fade into the background, and her home screen will look as effortlessly personal as Ananya's. The system will have quietly solved her cold start, just in time for the next new user to walk through the same blank screen.

Think About It

Think about this: How would you explain cold start: new users, new items to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where cold start: new users, new items is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting cold start: new users, new items to at least 3 other topics you have studied.

Key Takeaways — Summary and Recap

Let us recap what we covered: the core ideas behind cold start: new users, new items, how they connect to real-world applications, and why they matter for your journey in computer science. Remember these key points as you move forward. For competitive exam preparation (CBSE, JEE, BITSAT), focus on understanding the WHY behind each concept, not just the WHAT.