When we talk about Netflix or Amazon recommendations, the conversation usually stops at “AI knows what I like”. The real story is simpler and more interesting: a sparse matrix, one similarity formula and a heap.

Recommendations drive a large share of what people watch on Netflix and buy on Amazon, yet the core idea fits in a few dozen lines of code. This post walks through the data structure, the maths and the flow, with a small example you can run.

Let’s break this down.

The Core Idea: “People Who Liked This Also Liked…”

This is collaborative filtering. The system never needs to know what a movie is about. It only looks at behaviour: who rated, watched or bought what.

Consider five users rating movies from 1 to 5 (- = not watched):

User   | Inception | Interstellar | Matrix | Titanic | Notebook
-------+-----------+--------------+--------+---------+---------
Alice  |     5     |      4       |   5    |    -    |    -
Bob    |     4     |      5       |   -    |    1    |    -
Carol  |     5     |      -       |   4    |    -    |    1
Dave   |     -     |      -       |   -    |    5    |    5
Eve    |     4     |      5       |   5    |    -    |    2

Alice loves sci-fi, and so do Bob, Carol and Eve. They disliked the romance films Alice hasn’t seen, so the system won’t push romance to her. Nobody told it what “sci-fi” means; the pattern comes from the ratings alone.

Two Flavours

• User-based: find people like you, recommend what they liked. (This post.)
• Item-based: find items liked by the same people as this item. This is Amazon’s “Customers who bought this also bought”.

Storing It: The Sparse User-Item Matrix

Every recommender starts with a matrix: one row per user, one column per item. The catch is that it is almost entirely empty. In the public Netflix Prize dataset, about 99% of the cells had no rating.

Why This Matters

A full matrix for millions of users and items would be billions of cells of mostly zeros. Storing them wastes memory and slows every calculation.

How to Store It

• Dictionary of dictionaries: each user maps to only the items they rated. Fast inserts and lookups, ideal for collecting live data.
• CSR (Compressed Sparse Row): three flat arrays (data, indices, indptr) that make bulk maths fast. Used by SciPy and most ML pipelines.

ratings = {
    "alice": {"inception": 5, "interstellar": 4, "matrix": 5},
    "bob":   {"inception": 4, "interstellar": 5, "titanic": 1},
    "carol": {"inception": 5, "matrix": 4, "notebook": 1},
    "dave":  {"titanic": 5, "notebook": 5},
    "eve":   {"inception": 4, "interstellar": 5, "matrix": 5, "notebook": 2},
}

The same data in CSR, with items numbered 0 to 4:

data    = [5, 4, 5,  4, 5, 1,  5, 4, 1,  5, 5,  4, 5, 5, 2]
indices = [0, 1, 2,  0, 1, 3,  0, 2, 4,  3, 4,  0, 1, 2, 4]
indptr  = [0, 3, 6, 9, 11, 15]   # where each user's row starts

Memory now grows with the number of ratings, not with users × items.

Measuring Taste: Cosine Similarity

Treat each user as an arrow pointing through “movie space”. Cosine similarity measures the angle between two arrows: 1 means identical taste, 0 means nothing in common.

cos(a, b) = Σ aᵢ·bᵢ / ( √Σ aᵢ²  ×  √Σ bᵢ² )

from math import sqrt

def cosine(a, b):
    dot = sum(r * b[i] for i, r in a.items() if i in b)
    if not dot:
        return 0.0
    norm = lambda v: sqrt(sum(x * x for x in v.values()))
    return dot / (norm(a) * norm(b))

cosine(ratings["alice"], ratings["eve"])   # 0.956

Why Angle, Not Distance?

Some people rate everything a 5; others never go above a 3. They might still love the same films. Distance would call them different because their numbers differ. Cosine only cares about direction, so a generous rater and a strict rater with the same taste still match.

For star ratings, go one step further: subtract each user’s average rating first (Pearson / adjusted cosine). Then “below my usual” becomes a negative signal instead of a weak positive one.

Finding Taste Twins: k-Nearest Neighbours with a Heap

We don’t want every user’s opinion, only the k most similar (often 20 to 100). Fewer, closer neighbours means less noise.

Why a Heap?

Sorting all n users costs O(n log n), but we only need the top k. A min-heap of size k does it in O(n log k) with only k slots of memory.

Think of the heap’s root as a bouncer: it holds the weakest of the current top-k. A new candidate gets in only if they beat the bouncer; otherwise they’re turned away in one comparison.

import heapq

def neighbours(user, ratings, k=20):
    scored = ((cosine(ratings[user], ratings[v]), v) for v in ratings if v != user)
    return [(s, v) for s, v in heapq.nlargest(k, scored) if s > 0]

neighbours("alice", ratings, k=3)
# [(0.956, 'eve'), (0.855, 'carol'), (0.760, 'bob')]

At 100 million users with k = 50, that’s roughly 5× fewer comparisons than a full sort.

The Flow: From Ratings to Recommendations

The one new piece is scoring unseen items: each neighbour votes with their rating, and closer neighbours get louder votes.

predicted(u, i) = Σ sim(u, v) × rating(v, i)  /  Σ sim(u, v)

from collections import defaultdict

def recommend(user, ratings, k=20, n=10):
    if user not in ratings:
        return popular(ratings, n)
    seen = ratings[user]
    num, den = defaultdict(float), defaultdict(float)
    for sim, v in neighbours(user, ratings, k):
        for item, r in ratings[v].items():
            if item not in seen:
                num[item] += sim * r
                den[item] += sim
    scores = ((num[i] / den[i], i) for i in num)
    return heapq.nlargest(n, scores) or popular(ratings, n, seen)

def popular(ratings, n, exclude=()):
    counts = defaultdict(int)
    for row in ratings.values():
        for item in row:
            counts[item] += 1
    return heapq.nlargest(n, ((c, i) for i, c in counts.items() if i not in exclude))

recommend("alice", ratings, k=3)
# [(1.53, 'notebook'), (1.0, 'titanic')]  -> both low: don't recommend romance

Alice’s taste twins disliked both romance films, so their predicted scores are low. In a real catalogue, the sci-fi her neighbours loved would rise to the top instead.

5 Principles for Good Recommendations

1. Never Store the Zeros

A library doesn’t keep a shelf for every book it doesn’t own. Store only the ratings that exist: dict of dicts for live data, CSR for heavy maths.

2. Compare Direction, Not Size

Two friends can love the same films while one rates everything higher. Cosine (or Pearson for star ratings) matches taste, not enthusiasm.

3. Keep Only the Top-k

You don’t ask the whole city for a restaurant tip, just the few friends whose taste you trust. A heap keeps exactly those k, cheaply.

4. Don’t Trust Weak Neighbours

A user who shares one movie with you isn’t really your taste twin. Set a minimum similarity and a minimum number of votes per item, or a few weak opinions will produce confident-looking nonsense.

5. Always Have a Fallback

A brand-new user has no ratings, so collaborative filtering has nothing to work with (the cold start problem). Fall back to popular or trending items, or ask a few onboarding questions, rather than showing an empty screen.

How Netflix and Amazon Scale It

• Item-to-item CF (Amazon): item relationships change slowly, so “similar items” lists are precomputed offline and looked up in milliseconds.
• Matrix factorization (Netflix Prize): compress the giant matrix into short dense vectors per user and item, so similarity becomes a fast dot product.
• Approximate nearest neighbours: libraries like FAISS or ScaNN find the top-k among hundreds of millions of vectors without checking them all.
• Two stages: cheap candidate generation picks a few hundred items, then a richer ranking model orders them using context like time and device.

Recommendations go beyond clever AI. They are about storing data sparsely, measuring similarity honestly and keeping only the signals that matter. Get these basics right, and “people who liked this also liked…” stops being magic and becomes something you can build.