Recommender systems
User-Based Collaborative Filtering
Understand user-neighborhood recommendation, similarity construction, support, sparsity, and the limits of “people like you.”
By the end you can
- Explain the mechanics of user-based collaborative filtering
- Compare cosine, Pearson, and overlap-based similarity for preference histories
- Identify weak-support, popularity, privacy, and manipulation risks
- Design neighborhood diagnostics and baseline comparisons
Key idea
The neighbor test
Ranking from similar users' histories is worth it only when those histories are dense, stable, and relevant to the decision being made. One company decided not to release its own. Netflix had planned a sequel contest, Netflix Prize 2, built on another release of its user-preference matrix. It cancelled the contest on 12 March 2010, the same day it settled a federal Video Privacy Protection Act suit.
FTC staff had raised Section 5 concerns in a letter of 3 November 2009. Netflix then told staff it intended to suspend Prize 2. Any future data set would go only to researchers who contractually agree to specific limitations on its use, with operational safeguards and prior discussion with FTC staff. The staff closing letter, signed by Maneesha Mithal, states the rule that closed it: “Due to advances in technology that allow for vast amounts of data to be collected, stored, accessed, and combined, staff encourages companies to be cautious when releasing data presumed to be "anonymous" or "not personally identifiable," especially when those representations are made to consumers.”
A user-preference matrix was the thing being released, and the reason for stopping was privacy rather than quality. The lesson's point is narrower: a neighbourhood is only as good as the shared history under it, and sometimes the right move is not to use it.
Where the shared history is thin or stale, the honest move is to fall back, not to serve a neighborhood the team could not defend out loud.
Example
A user-neighborhood recommender beaten by recommending the most popular items
On one dataset, recommending the same chart to everybody beat a recommender that studies each person. On Epinions, in Ferrari Dacrema, Cremonesi and Jannach's 2019 measurements, the non-personalised TopPopular baseline — which knows nothing about any individual — scored HR@10 = 0.6644 and NDCG@10 = 0.4547. UserKNN, a user-neighborhood recommender of exactly the kind described here, scored HR@10 = 0.3922 and NDCG@10 = 0.3117 on the same data.
The comparison comes from a 2019 reproducibility study. It put user neighborhoods and the methods that were supposed to have superseded them on the same footing. Its authors could reproduce only 7 of 18 published neural recommenders, and 6 of those 7 could often be outperformed by simple nearest-neighbour or graph-based heuristics. They state the result without hedging: “In one case, even a non-personalized method that recommends the most popular items to everyone was the best one in terms of certain accuracy measures.”
Epinions is also where the catalogue is most lopsided. Its popularity distribution had a Gini index of 0.69, against 0.37 for CiteULike-a. The neighborhoods there were mathematically well-formed. They were built on co-ratings of the items nearly everyone touches. That is why the policy that skipped the neighborhood entirely did better.
- Reproducibility first: Of 18 published neural recommenders, only 7 could be reproduced at all. That is what made the baseline comparison possible.
- The baselines won: 6 of those 7 could often be outperformed by simple nearest-neighbour or graph-based heuristics — the comparison most published tables never ran.
- The Epinions result: TopPopular scored HR@10 = 0.6644 and NDCG@10 = 0.4547. UserKNN scored HR@10 = 0.3922 and NDCG@10 = 0.3117 on the same data.
- The condition that produced it: Epinions' popularity distribution had a Gini index of 0.69, against 0.37 for CiteULike-a. Concentration is the variable, not the algorithm's cleverness.
- What the similarity was made of: Where popularity concentrates that hard, the co-ratings available to compute user similarity are largely head items. The neighborhood is recruited by what everyone consumes, not by what distinguishes anyone.
The similarity rule decides the recommendation before aggregation
The method compares a target user's interaction pattern with other users, selects a neighborhood, and aggregates the neighbors' preferences for unseen items. It can be intuitive and effective when the overlap is meaningful. The difficulty is defining comparable histories. The field's own benchmark shows how little material there is to compare.
MovieLens publishes the density of every rating matrix it has released. ML-100K — 943 users, 1,682 movies, 100,000 ratings, collected 9/1997-4/1998 — stands at 6.30%. ML-1M is at 4.47%. ML-10M at 1.34%. ML-20M — 138,493 users, 27,278 movies, 20,000,263 ratings, 1/1995-3/2015 — at 0.54%. Harper and Konstan define exactly what that column is: “The sole computed column, Density, represents the percentage of cells in the full user-item matrix that contain rating values.”
Density falls by more than an order of magnitude as the population grows. Two users sharing a handful of titles is the ordinary case, not the pathological one. Raw cosine similarity, Pearson correlation, centered ratings, implicit overlap, significance weighting, time windows: six answers to the question of what to do with that 0.54%. They select different neighborhoods from it.
Pick the comparison rule and you have already picked the neighborhood, which settles most of the recommendation before any aggregation runs.
Case
Why Amazon moved from customers to products
The user-oriented form came first and was largely displaced. A 2008 paper by Hu, Koren and Volinsky records the shift plainly: “Its original form, which was shared by virtually all earlier CF systems, is user-oriented”. Then the verdict: “Better scalability and improved accuracy make the item-oriented approach more favorable in many cases”.
The arithmetic under that verdict had been published five years earlier, by the people who had to run it. In 2003 Amazon's own engineers set out the cost directly: “Using collaborative filtering to generate recommendations is computationally expensive. It is O(MN) in the worst case, where M is the number of customers and N is the number of product catalog items, since it examines M customers and up to N items for each customer.” Their M and N were not research-scale. Amazon.com then had “more than 29 million customers and several million catalog items”. The datasets the published literature was tuned on were of another order entirely: MovieLens at 35,000 customers and 3,000 items, EachMovie at 4,000 customers and 1,600 items. The item-to-item alternative moves the expensive similar-items table offline. The online step then “scales independently of the catalog size or the total number of customers”.
Amazon's own published history tells the same fact in words. Its recommender came to “base product recommendations not on similarities between customers but on correlations between products”, because “a given product sold on the Amazo[n] Store [was] purchased by only a tiny subset of the site's customers”. That made it “computationally feasible to produce an updated list of related items for every product on the Amazon site on a daily basis”. The evidence behind any one product-product correlation is bounded by how few customers touch that product. Neighbourhoods over users do not shrink that way. They grow with M.
Visual
The neighborhood recommendation process
Neighborhood methods spend most of their effort before any item is proposed. Four of the five steps decide how histories are represented, where overlap may be measured, and how much a thin overlap deserves to be trusted. Only the last step, aggregate items, produces something to show.
Measure overlap is the step the MovieLens densities describe. At ML-20M scale only 0.54% of the cells of the user-item matrix carry a rating. Two histories are nearly always compared on a handful of co-rated titles. Control confidence is the step that decides what to do about that, and Koren gives it a published form rather than a preference. The similarity actually used is scaled down in proportion to how few users rated both items, so a coefficient with almost no support contributes almost nothing. Represent histories and select neighbors sit on top of that thin evidence rather than repairing it.
The whole arrangement costs what Amazon's engineers named: O(MN) in the worst case, with M the number of customers and N the number of catalog items.
- 1
Represent histories
Choose ratings, binary interactions, centered scores, or time-weighted events.
- 2
Measure overlap
Compute similarity only on comparable observed evidence.
- 3
Control confidence
Shrink or downweight similarities supported by few co-interactions.
- 4
Select neighbors
Balance similarity, support, freshness, and computational budget.
- 5
Aggregate items
Combine neighbor evidence with normalization, eligibility, and fallback rules.
Predict first
Eight obscure films, no dates
Netflix released its Prize ratings with the names removed. Narayanan and Shmatikov then asked how much an outsider must know about one subscriber to find that subscriber's row. With eight ratings and approximate dates, almost everyone could be found. Take the dates away entirely, and suppose the outsider knows eight films the person rated, all outside the 500 most-rated, and two of the eight may be wrong.
Make a prediction before reading on. Without any dates, what share of subscribers can still be singled out: a few percent, around a third, or most of them?
Settle on an answer, then read on — the next section is the reveal
Example
Neighborhood failure modes
Tiny-overlap certainty is the failure that looks like a result: two shared items produce a perfect correlation and outrank a neighbor with real support. Scale collapse is the failure that looks like an engineering problem and is really a modeling one. The failure teams almost never measure is what the preference matrix discloses about the people in it.
Netflix released the Prize ratings matrix with the names taken off. Narayanan and Shmatikov ran a de-anonymisation algorithm against it. Eight movie ratings, of which 2 may be completely wrong, with dates carrying up to a 14-day error, uniquely identify 99% of the records. Two ratings and dates within 3 days suffice for 68%. With no dates at all, 84% of subscribers are uniquely identified from 8 known titles outside the 500 most-rated movies, 2 of which may be wrong. What they did with that: “Using the Internet Movie Database as the source of background knowledge, we successfully identified the Netflix records of known users, uncovering their apparent political preferences and other potentially sensitive information.” The FTC staff closing letter later cited the paper as demonstrating re-identification within the Prize 1 data set of over 480,000 customers.
The same distribution is at work in both directions. The popular titles that carry the overlap say little about anyone. The obscure ones that say almost nothing about taste identify people.
- Tiny-overlap certainty: A perfect correlation from two items outranks a stable moderate neighbor. It stops doing so under Koren's shrinkage: with lambda2 typically 100, those 2 co-ratings retain about 2 percent of the coefficient.
- Head-item domination: Popular items create apparent similarity across many users while carrying almost no distinguishing information. The titles outside the 500 most-rated are the ones that separate people: 8 of them, 2 possibly wrong, identify 84% of Netflix Prize subscribers with no dates at all.
- Shilling vulnerability: Coordinated fake users manipulate neighborhoods and promoted items. A similarity rule that trusts thin overlap is the cheapest surface to attack.
- Changing taste: Old interactions overwhelm recent intent, and the horizon is long — the ML-20M ratings span 1/1995 to 3/2015 in a single matrix.
- Scale collapse: Computing all user pairs is O(MN) in the worst case. At 29 million customers and several million catalog items, that is the cost Amazon's engineers set against user-based filtering in 2003.
Steps
Build and audit a user-neighborhood model
Comparable events have to be defined before two users can be called similar. Normalization and support shrinkage follow. Then somebody reads the neighbor lists by hand. The baselines settle whether any of it earned its place.
Step 3 does not have to be improvised. Koren stated the problem in 2008: “Since many ratings are unknown, it is expected that some items share only a handful of common raters. Computation of the correlation coefficient is based only on the common user support. Accordingly, similarities based on a greater user support are more reliable.” The similarity he then uses is s_ij = (n_ij / (n_ij + lambda2)) * rho_ij, where n_ij is the number of users who rated both items and lambda2 is typically 100. Put support through it and the vague instruction becomes arithmetic. A correlation resting on 2 co-ratings keeps about 2 percent of its value. One resting on 400 co-ratings keeps 80 percent. That is what downweighting by the amount of evidence means once it is written down.
Step 5 decides whether the model ships, and the Epinions result is the reason it cannot be a formality. Popularity, item-item and matrix-factorization policies all have to be measured under the same protocol. A user-neighborhood policy can look reasonable in isolation and still be the wrong thing to serve. UserKNN's HR@10 = 0.3922 sat well below the TopPopular baseline's 0.6644. And the item-oriented family is the one credited with “Better scalability and improved accuracy”. A margin that has only been measured against nothing is not a margin.
1. Define comparable events
Choose rating, interaction, time, and context windows.
2. Normalize carefully
Center or weight histories only when the semantics justify it.
3. Add support shrinkage
Reduce confidence in similarities with weak overlap.
4. Inspect neighbors
Review their shared evidence, context, and stability.
5. Compare with baselines
Measure gains against popularity, item-item, and matrix-factorization policies.
Example
The film service’s neighbours, built and audited
Star ratings were all a film service's nearest neighbours shared: they lived in different markets, spoke different languages, watched for different households and purposes, rated only blockbusters, used the scale differently, and one perfect correlation rested on two co-rated titles; small profile changes replaced most of the selected neighbours from one week to the next. The service is invented, and the quiz below asks about it. Here is the routine run on it. All numbers are invented for the exercise.
- Define comparable events: star ratings from the last three years, from users in the same market, on titles available in both users' catalogues. A rating of a film one neighbour could not have streamed is not shared evidence.
- Normalize carefully: some users rate nearly everything four or five stars, so subtract each user's mean before comparing. A user whose average is 4.6 stars and one whose average is 3.1 now agree only where they depart from their own habits in the same direction. Skip the step and raw cosine takes no account of how each user uses the scale: two people who give everything four or five stars come out as close neighbours even when they love different films.
- Add support shrinkage: with Koren's weight n/(n + 100), neighbour A, a correlation of 1.0 on 2 co-rated blockbusters, drops to about 0.02; neighbour B, a correlation of 0.45 on 150 co-rated films, keeps 0.27. B now outranks A.
- Inspect neighbors: a reviewer reads 20 users' top-10 neighbour lists. In 14 of the 20, the strongest neighbours share only titles from the 100 most-rated films, so the lists are flagged as overlap on popularity, not on taste.
- Compare with baselines: on the same held-out month, hit rate at 10 is 0.21 for user neighbours, 0.24 for popularity and 0.26 for item-item. The user-neighbour model loses to both and does not ship.
Key idea
“Users like you” is a claim that needs defending
“Users like you” is a modeling claim. It requires enough shared evidence and a relevant context. Item-oriented neighbourhoods are “more amenable to explaining the reasoning behind predictions”, the 2008 paper notes, and the contrast is instructive. The user-oriented explanation is the harder one to stand behind. What sits under it is a set of co-rated titles from a matrix that is 0.54% full at ML-20M scale. They were chosen by a similarity rule nobody on the receiving end can see.
The Netflix Prize numbers show how little those titles carry about taste and how much they carry about identity. The head items that supply most of the overlap distinguish almost nobody. Eight known titles outside the 500 most-rated movies, two of them possibly wrong, pin down 84% of subscribers. An overlap can be too weak to justify the sentence on the screen and strong enough to name the person it was computed from.
A shared interaction pattern shows that two histories overlapped; it never shows why, and the on-screen explanation quietly supplies a reason nobody verified.
Key takeaways
- Neighborhood methods are interpretable only when the neighborhood itself can be defended. Netflix told FTC staff in writing that it intended to suspend Netflix Prize 2, and on 12 March 2010 it cancelled the sequel contest rather than release another user-preference matrix.
- The method compares a target user's interaction pattern with other users, selects a neighborhood, and aggregates the neighbors' preferences for unseen items. It does that over a matrix that carries ratings in 0.54% of its cells at MovieLens ML-20M scale (138,493 users, 27,278 movies, 20,000,263 ratings).
- “Users like you” is a modeling claim that requires enough shared evidence and a relevant context. With no dates at all, 84% of Netflix Prize subscribers are uniquely identified from 8 known titles outside the 500 most-rated movies, 2 of which may be wrong. An overlap of popular titles is weak evidence about taste and strong evidence about identity.
- Represent histories is a decision, not a default. Ratings, binary interactions, centered scores or time-weighted events decide which part of a history speaks, and the horizon is long enough to matter — ML-20M spans 1/1995 to 3/2015.
- Tiny-overlap certainty remains a practical risk. A perfect correlation from two items outranks a stable moderate neighbor until Koren's shrinkage s_ij = (n_ij / (n_ij + lambda2)) * rho_ij is applied, with lambda2 typically 100. At that point 2 co-ratings keep about 2 percent of the coefficient and 400 co-ratings keep 80 percent.
- Gains from user-based neighborhoods count only when they hold against popularity, item-item and matrix-factorization policies evaluated under the same protocol. On Epinions the non-personalised TopPopular baseline scored HR@10 = 0.6644 against UserKNN's 0.3922.