Skip to content
mlmentorship

Content-based filtering

Content-based filtering scores item features against a user profile. It handles item cold-start and often complements collaborative filtering.

Published · 5 min read ·Role-specific ·Intermediate

Visual quick review

Visual first · depth when needed

Trace how liked-item feature vectors become a user profile, then explain why that profile can score a brand-new item without any interaction history.

Preparing the visual…

Summary

Content-based filtering recommends items whose features (genre, text, tags, embeddings) match a profile built from the items a user already engaged with: it scores item–profile similarity, using no other users’ behavior.

Content-based filtering is the standard answer to the item cold-start problem: a brand-new item with zero interactions has no collaborative signal, but it does have features, so a content model can recommend it on day one. It also drives explainability (“because you watched X”) and works for niche users with unique tastes. Every recsys interview expects you to contrast it with collaborative filtering and explain why production systems combine them.

The mechanism

  1. Item representation. Turn each item into a feature vector: structured attributes (genre, brand, price), TF-IDF / embeddings of text, image/audio embeddings, or learned content encoders.
  2. User profile. Aggregate the representations of items the user engaged with, e.g. the (weighted) average of liked-item vectors, or a learned user encoder.
  3. Score and rank. Recommend items with the highest similarity (cosine / dot product) to the profile, excluding already-seen items.

This is structurally a two-tower idea (a user/profile tower and an item/content tower) when both sides are learned, which is why content features feed naturally into modern retrieval models.

Learning objective

Why can a content model rank a brand-new item?

Building a user profile and scoring a new item in the same feature space Two liked items have binary vectors over science, drama, and short features. Averaging them gives the user profile one, one half, one half. A brand-new telescope guide has zero interactions but a cosine similarity of 0.87 to that profile, so it ranks above a popular drama with 12,000 interactions and a similarity of 0.41. The content score never uses other users' interaction counts. 1 · REPRESENT LIKED ITEMS features = [science, drama, short] Liked · Space 101 x₁ = [1, 0, 1] Liked · Lab Story x₂ = [1, 1, 0] 2 · AVERAGE INTO ONE PROFILE user profile p = [1, 0.5, 0.5] 3 · SCORE CANDIDATE FEATURES #1 · Telescope guide new · 0 interactions x = [1, 0, 1] cos(p, x) = 0.87 #2 · Popular drama 12k interactions x = [0, 1, 0] cos(p, x) = 0.41 OTHER USERS' COUNTS ARE NOT INPUTS TO THIS SCORE
Read it this way: average the two liked-item vectors to build the profile, then compare that profile only with each candidate's features. The telescope guide can rank first on day one because its feature vector already exists; the 0 and 12k interaction counts are shown only to emphasize that this content score does not use them. The vectors and layout are original; mechanism checked against Google's recommendation-systems documentation.

Content-based vs collaborative filtering

Content-basedCollaborative filtering
Signalitem features + this user’s historythe user–item interaction matrix
New item (item cold-start)works (has features)fails (no interactions)
New userneeds a little historyfails (no interactions)
Serendipity / discoveryweak (stays near known tastes → filter bubble)strong (finds non-obvious patterns)
Niche usersstrongweak
Needs other users?noyes
Quality ceilinglimited by feature qualitylearns latent taste it can’t name

The crisp summary: content-based asks “what is this item like?”; collaborative asks “who else behaved like you?” They fail in opposite situations, which is exactly why they’re combined.

Strengths and weaknesses

Strengths: handles item cold-start, needs no other users, recommendations are explainable, works for unique tastes.

Weaknesses:

  • Limited serendipity: recommendations cluster around what the user already likes (the filter-bubble / over-specialization problem).
  • Feature-bound: quality is capped by how good your item features are; it can’t discover preferences your features don’t encode.
  • Still has user cold-start: a brand-new user with no history has no profile.

Hybrid systems (what’s actually deployed)

Production recommenders blend both:

  • Cold-start handoff: content-based for new items/users, sliding to collaborative as interactions accumulate.
  • Feature-rich two-tower / wide-and-deep models that take both content features and collaborative IDs as input, learning a single ranker.
  • Knowledge-graph and embedding side-information layered onto collaborative factors.

So “content-based vs collaborative” is rarely a real either/or in 2026: the design question is how to fuse them.

What an interviewer expects you to say

  1. Define it as profile (from the user’s items) × item features, with no reliance on other users.
  2. Lead with its killer use case: item cold-start and explainability.
  3. Contrast cleanly with collaborative filtering on the cold-start and serendipity axes (“what is this item like” vs “who behaves like you”).
  4. Name its weaknesses: over-specialization / filter bubble, feature-quality ceiling, and remaining user cold-start.
  5. Conclude with hybrid systems and feature-rich two-tower models as the production reality.

Common confusions

  • “Content-based solves all cold-start.” It solves item cold-start; a brand-new user still has no profile.
  • “It’s just collaborative filtering with features.” It uses no cross-user signal; that’s the defining difference and the source of both its cold-start strength and its serendipity weakness.
  • “It’s more accurate than collaborative filtering.” Usually the opposite once interaction data exists: collaborative filtering learns latent preferences content features can’t capture. Content shines specifically when behavioral data is sparse.
  • “Two-tower retrieval is collaborative filtering.” Two-tower can be either or both: with content features in the item tower it’s content-based; with pure ID embeddings it’s collaborative.

Related: Matrix factorization for recsys, Two-tower retrieval, How would you do cold-start for a new user?, Knowledge-graph embeddings, TF-IDF and BM25.