Recommendation Systems with Deep Learning: From Collaborative Filtering to Neural Recommenders

Introduction

Recommendation systems are the invisible engines driving user engagement across the internet. Netflix attributes 80% of viewer hours to recommendations, Amazon reports 35% of revenue comes from product suggestions, and YouTube's recommendation algorithm drives over 70% of watch time [1]. These systems have evolved from simple rule-based heuristics to sophisticated deep learning architectures that model user behavior at billion-user scales.

The shift from traditional collaborative filtering to neural recommenders has been transformative. In 2017, the introduction of Neural Collaborative Filtering (NCF) demonstrated that neural networks could significantly outperform matrix factorization on standard benchmarks [2]. Since then, the field has progressed through sequence-aware models (GRU4Rec, SASRec, BERT4Rec), two-tower architectures for large-scale retrieval, and multi-stage ranking pipelines that power systems serving billions of requests per day.

This guide provides a comprehensive technical overview of deep learning for recommendation systems. It covers the theoretical foundations, neural architectures, training strategies, production deployment patterns, and evaluation methodologies. We assume familiarity with deep learning fundamentals as covered in our transformer architecture guide and LLM embeddings guide.

Traditional Approaches

Before deep learning, recommendation systems relied on three primary approaches: collaborative filtering, content-based filtering, and matrix factorization. Understanding these foundations is essential because modern neural recommenders extend and generalise these ideas within a deep learning framework.

Collaborative Filtering

Collaborative filtering (CF) is based on the intuition that users who agreed in the past will agree in the future. User-based CF computes recommendations by finding similar users (nearest neighbours) and aggregating their item preferences. Item-based CF inverts this: it finds items that are similar based on co-occurrence patterns in user interaction data. The similarity metric is typically cosine similarity or Pearson correlation applied to the user-item interaction matrix.

While conceptually simple, pure CF suffers from three fundamental limitations. First, the cold start problem: new users and new items have no interaction history, so no recommendations can be computed. Second, sparsity: the user-item interaction matrix is typically 99.9% empty, making reliable similarity computation difficult. Third, scalability: computing pairwise similarities across millions of users or items is O(n^2) and becomes computationally prohibitive at scale.

Matrix Factorization: SVD and ALS

Matrix factorization addresses the sparsity and scalability limitations of pure CF by decomposing the user-item interaction matrix into lower-dimensional latent factor matrices. Given an m x n interaction matrix R (m users, n items), matrix factorization learns a user matrix U (m x k) and an item matrix V (n x k) such that R = UV^T, where k is the latent dimension (typically 20-200).

Funk SVD (Simon Funk's 2006 matrix factorization for the Netflix Prize) treats the problem as a regularised optimisation that minimises the squared error on observed interactions only. Alternating Least Squares (ALS) solves the same problem by alternately fixing U and solving for V, and vice versa. ALS is particularly attractive because it is embarrassingly parallel: each row of U and V can be computed independently given the fixed other matrix. Apache Spark's MLlib implementation of ALS remains widely used for batch recommendation in 2026, particularly for implicit feedback datasets [3].

The key limitation of matrix factorization is architectural: it is a linear factor model that cannot capture non-linear user-item interaction patterns. The dot product of latent factors assumes that user preferences are a linear combination of item attributes, which fails for complex, multi-modal preference structures. This limitation is what neural models were designed to overcome.

Content-Based Filtering

Content-based filtering recommends items similar to those a user has previously interacted with, based on item features rather than user co-occurrence. It constructs a user profile vector from the features of items the user liked and recommends items whose feature vectors are similar. TF-IDF vectors, genre labels, keywords, and categorical attributes are typical content features.

Content-based approaches excel at cold-start for items — new items with rich metadata can be recommended immediately — but they suffer from overspecialisation: recommendations tend to be too similar to past interactions, limiting discovery and reducing diversity. They also require high-quality, complete item metadata, which is expensive to produce and maintain at scale.

Neural Collaborative Filtering

Neural Collaborative Filtering (NCF), introduced by He et al. in 2017 [2], replaces the dot product in matrix factorization with a neural network that learns the user-item interaction function from data. The key insight is that the interaction function should be learned rather than fixed as a dot product, enabling the model to capture complex, non-linear patterns in user behaviour.

NCF Architecture: GMF, MLP, and NeuMF

NCF comprises three architectural variants. Generalised Matrix Factorization (GMF) extends classical matrix factorization by applying a non-linear activation to the element-wise product of user and item embeddings. GMF with a linear activation and weight constraint is equivalent to standard matrix factorization — a nice theoretical property that shows NCF subsumes the traditional approach.

The Multi-Layer Perceptron (MLP) variant concatenates user and item embeddings and passes them through a deep feed-forward network. Typical MLP architectures use 3-4 hidden layers with a tower structure (64, 32, 16, 8 neurons), where each layer learns progressively more abstract interactions. Dropout (0.2-0.5) and batch normalisation are essential for stabilising training.

NeuMF (Neural Matrix Factorization) combines GMF and MLP by concatenating their final representations before the output layer. This hybrid architecture captures both the linear factor structure (GMF) and non-linear interactions (MLP), consistently outperforming either component alone. The code below implements the full NeuMF architecture:

import torch
import torch.nn as nn

class NeuralCollaborativeFiltering(nn.Module):
    def __init__(self, num_users, num_items, embed_dim=64, layers=[64, 32, 16, 8]):
        super().__init__()
        self.user_embedding = nn.Embedding(num_users, embed_dim)
        self.item_embedding = nn.Embedding(num_items, embed_dim)
        # GMF branch
        self.gmf = nn.Linear(embed_dim, 1)
        # MLP branch
        mlp_layers = []
        in_dim = embed_dim * 2
        for out_dim in layers:
            mlp_layers.extend([
                nn.Linear(in_dim, out_dim),
                nn.ReLU(),
                nn.Dropout(0.2),
            ])
            in_dim = out_dim
        self.mlp = nn.Sequential(*mlp_layers)
        self.output = nn.Linear(layers[-1] + 1, 1)
        self.sigmoid = nn.Sigmoid()

    def forward(self, user_ids, item_ids):
        user_emb = self.user_embedding(user_ids)
        item_emb = self.item_embedding(item_ids)
        # GMF: element-wise product
        gmf_out = self.gmf(user_emb * item_emb)
        # MLP: concatenation
        mlp_out = self.mlp(torch.cat([user_emb, item_emb], dim=-1))
        # NeuMF: concat GMF and MLP
        out = self.output(torch.cat([gmf_out, mlp_out], dim=-1))
        return self.sigmoid(out).squeeze()

Embeddings and Training

NCF learns two embedding tables — one for users, one for items — each of dimension k (typically 32-128). These embeddings are the latent factors, analogous to the U and V matrices in matrix factorization but learned through backpropagation rather than alternating optimisation. The embeddings capture distributed representations of user preferences and item characteristics in a continuous vector space.

Training uses implicit feedback (clicks, views, purchases) formulated as a binary classification problem: predict whether user u will interact with item i. Negative sampling is critical — for each positive interaction, 4-20 negative items are sampled (items the user has not interacted with). The loss function is binary cross-entropy (log loss), and the model is optimised with Adam (learning rate 0.001, beta1=0.9, beta2=0.999) with early stopping based on validation Hit Ratio@K or NDCG@K [2].

Despite strong performance on benchmarks, NCF has a practical limitation: it is a pointwise model that scores one user-item pair at a time, making it expensive to rank millions of items at inference time. This gave rise to two-tower models that decompose the architecture for efficient retrieval.

Two-Tower Models

Two-tower models (also known as dual-encoder or Siamese networks) address the scalability challenge by decomposing the recommendation model into two independent encoders: a query tower (user-side features) and a candidate tower (item-side features). The query and candidate embeddings are learned such that their dot product (or cosine similarity) predicts relevance. At inference time, candidate embeddings can be pre-computed and indexed in a vector database for Approximate Nearest Neighbour (ANN) search, enabling retrieval from millions of candidates in milliseconds [4].

Architecture

The query tower encodes user features — user ID embedding, historical behaviour sequence embedding, demographic features, contextual features (time, device). The candidate tower encodes item features — item ID embedding, category embeddings, content features, popularity features. Both towers produce fixed-dimensional output embeddings (typically 64-256 dimensions). The similarity score is the dot product of the two embeddings:

import torch
import torch.nn as nn

class TwoTowerModel(nn.Module):
    def __init__(self, num_users, num_items, num_features, embed_dim=128):
        super().__init__()
        self.query_tower = nn.Sequential(
            nn.Linear(num_users + num_features, 256),
            nn.ReLU(),
            nn.BatchNorm1d(256),
            nn.Linear(256, embed_dim),
            nn.ReLU(),
        )
        self.candidate_tower = nn.Sequential(
            nn.Linear(num_items + num_features, 256),
            nn.ReLU(),
            nn.BatchNorm1d(256),
            nn.Linear(256, embed_dim),
            nn.ReLU(),
        )

    def forward(self, query_features, candidate_features):
        query_emb = self.query_tower(query_features)
        candidate_emb = self.candidate_tower(candidate_features)
        return query_emb, candidate_emb

The tower structure is critical: deeper, wider towers can learn more complex feature interactions but are more expensive to compute. In practice, the candidate tower is typically smaller than the query tower because candidate embeddings are computed offline and stored. A common configuration uses 3-4 hidden layers in the query tower (256, 128, 64, embed_dim) and 2-3 layers in the candidate tower (128, 64, embed_dim).

Loss Functions and Sampled Softmax

The standard loss function for two-tower models is sampled softmax with temperature scaling. For each positive (user, item) pair, we sample a set of negative items from the full item catalogue. The model computes the dot product between the query embedding and each candidate embedding, applies temperature scaling (typically 0.05-0.2), and trains with cross-entropy loss to identify the positive item among the negatives:

def sampled_softmax_loss(
    query_emb, pos_item_emb, neg_item_embs, temperature=0.05
):
    # Positive logit
    pos_logit = (query_emb * pos_item_emb).sum(dim=-1) / temperature
    # Negative logits (sampled candidates)
    neg_logits = torch.matmul(query_emb, neg_item_embs.T) / temperature
    # Full logits
    logits = torch.cat([pos_logit.unsqueeze(-1), neg_logits], dim=-1)
    labels = torch.zeros(len(query_emb), dtype=torch.long)
    return nn.CrossEntropyLoss()(logits, labels)

The choice of negative sampling strategy significantly impacts model quality. In-batch negatives (using other items in the same training batch as negatives) are computationally efficient but introduce sampling bias. Uniform random sampling from the full catalogue is unbiased but produces easy negatives that do not provide strong learning signal. The best practice is mixed negative sampling: combine in-batch negatives with uniform random negatives and hard negatives mined from top-ranked but non-interacted items [5].

Serving at Scale

The two-tower architecture enables a retrieval pipeline where candidate embeddings are pre-computed and indexed in an ANN vector index (typically HNSW). At serving time, the query tower computes the user embedding in real time, and ANN search retrieves the top-K nearest candidate embeddings. This decoupling means the candidate index can be rebuilt asynchronously (hourly or daily) while the query tower serves requests in 5-15 milliseconds. Pinterest's Pixie system, for example, serves 3 billion recommendation requests per day using a similar two-tower design with graph-based indexing [6].

For a detailed treatment of ANN search, HNSW indexing, and vector database deployment, see our guide on LLM embeddings and vector databases.

Feature Engineering

Feature engineering is often the highest-impact activity in production recommendation systems. ID features (user ID, item ID) are the most important single features — learned embeddings for each user and item capture collaborative signal. However, at large scales, storing user embeddings for billions of users becomes impractical. The trend in 2024-2026 has been toward feature-rich models that reduce reliance on pure ID features in favour of content and context features [7].

Key feature categories include: categorical features (item category, language, country) with learned embeddings, numerical features (price, popularity score, recency) with normalisation and bucketing, sequential features (last N items viewed) encoded via pooling or attention, cross features (user demographics x item category), and real-time context features (time of day, session length, device type). Feature management at scale requires a feature store infrastructure — see our MLOps production guide for details.

Sequence-Aware Recommendation

User behaviour is inherently sequential: the order in which users interact with items carries significant signal about their current intent. Sequence-aware recommendation models capture this temporal dynamics by modelling user behaviour as a sequence of item interactions rather than a static set.

GRU4Rec

GRU4Rec, introduced by Hidasi et al. in 2016 [8], was the first successful application of recurrent neural networks to session-based recommendation. It uses Gated Recurrent Units (GRUs) to model the sequence of user clicks within a session. At each time step, the GRU takes the current item embedding and the previous hidden state as input, producing a new hidden state that encodes the session context. The model scores all items by computing the dot product between the GRU hidden state and item embeddings, then ranks by score.

GRU4Rec achieves 15-25% improvement in Recall@20 over classical session-based kNN baselines on e-commerce datasets [8]. The key architectural decisions are the GRU hidden size (100-200 units), the embedding dimension (50-200), and the negative sampling strategy during training. GRU4Rec is still widely used in production due to its simplicity and low inference latency (sub-millisecond per session).

SASRec: Self-Attention for Sequential Recommendation

SASRec (Self-Attention based Sequential Recommendation), proposed by Kang and McAuley in 2018 [9], replaces the GRU with a Transformer decoder layer using causal (masked) self-attention. Each position in the user's item sequence attends to all previous positions, allowing the model to capture long-range dependencies that RNNs struggle with. The self-attention mechanism computes a weighted sum of previous item embeddings, where the weights depend on the similarity between the current query and all previous keys.

SASRec consistently outperforms GRU4Rec by 5-15% in Recall@10 on benchmark datasets, particularly when user sequences are long (20+ interactions). The Transformer architecture naturally parallelises over the sequence dimension during training, making SASRec significantly faster to train than GRU4Rec despite more parameters [9]. The standard SASRec configuration uses 2-4 attention layers, 8-16 attention heads, and embedding dimensions of 64-256.

The self-attention mechanism underlying SASRec is the same one used in modern LLMs. For a detailed explanation, see our guide on transformer architecture explained.

BERT4Rec: Bidirectional Encoding

BERT4Rec, introduced by Sun et al. in 2019 [10], applies the masked language modelling approach from BERT to sequential recommendation. Unlike SASRec's causal (left-to-right) attention, BERT4Rec uses bidirectional attention where each position can attend to all other positions in the sequence. During training, some items in the sequence are randomly masked (typically 20%), and the model learns to predict the masked items from their bidirectional context.

BERT4Rec achieves state-of-the-art performance on sequential recommendation benchmarks, outperforming SASRec by 2-8% on Amazon and Yelp datasets [10]. The trade-off is that bidirectional attention cannot be used for autoregressive generation at inference time — BERT4Rec requires the full sequence context, making it suitable for next-item prediction but not for generating long recommendation lists incrementally. In production, BERT4Rec is typically used as a feature encoder that feeds into a larger ranking model.

Session-Based Recommendation

Session-based recommendation is a special case of sequential recommendation where user identity is unknown — only the current session's click stream is available. This is the dominant scenario in e-commerce (anonymous browsing), news (no login required), and video streaming (guest users). GRU4Rec was originally designed for this setting and remains competitive. More recent approaches use graph neural networks to model item-to-item transitions across sessions — see our graph neural networks guide for details.

Multi-Stage Ranking

Production recommendation systems at scale operate in multiple stages — retrieval, ranking, and re-ranking — each with different model complexity and latency budgets. The total candidate pool may be 10^7-10^9 items, but a user will only see 10-50 recommendations. The multi-stage funnel efficiently narrows this gap.

Retrieval: Candidate Generation

The retrieval stage reduces the full item catalogue (millions to billions) to a candidate set of hundreds to thousands of items. The retrieval model must be fast enough to evaluate billions of items — typically using ANN search on two-tower embeddings, inverted index lookup on item metadata, or a combination of both (multi-channel retrieval). YouTube's candidate generation system, for example, uses a deep neural network with hundreds of millions of parameters trained on user watch history, then retrieves the top-N items via ANN search on the learned embeddings [11].

Multi-channel retrieval is standard practice: different retrieval strategies capture different signals and ensembles of strategies improve recall. Common channels include: collaborative filtering (two-tower ANN search), content-based (category preferences, trending items), social (friend activity, group recommendations), geographic (items near the user), and contextual (seasonal, time-of-day patterns). Each channel retrieves 100-500 candidates, and the union is deduplicated before ranking.

Ranking: Deep Scoring Models

The ranking stage applies a deep neural network to score each candidate item for the given user. Unlike the retrieval model, the ranking model can use rich cross features between user and item — embeddings that interact deeply rather than the shallow dot product of two-tower models. Deep ranking models typically use 5-10 fully connected layers with batch normalisation, dropout, and skip connections, processing hundreds of features from user, item, context, and cross-feature transformations.

The ranking model is trained to predict a target metric like click-through rate (CTR), conversion rate (CVR), or watch time. Multi-task learning is standard: a single shared bottom predicts multiple objectives (click, add-to-cart, purchase, share, watch time) with task-specific towers on top. This shared representation improves data efficiency and generalisation. Google's YouTube ranking system, for instance, jointly predicts expected watch time and engagement in a multi-task architecture [11].

Re-Ranking: Diversity and MMR

The final stage re-ranks the scored candidate list to satisfy business constraints beyond relevance: diversity, freshness, fairness, and business rules. Without re-ranking, top-N recommendations tend to be overly homogenous — all items are close variants of the same category or genre. The Maximum Marginal Relevance (MMR) algorithm addresses this by iteratively selecting items that are both relevant and diverse with respect to already selected items:

MMR computes a linear combination of relevance score and diversity penalty: MMR = score(item) - lambda * max_similarity(item, already_selected), where lambda controls the diversity-relevance trade-off. Typical lambda values range from 0.3 to 0.7 depending on the vertical. Other re-ranking techniques include: Business Rule Filtering (remove blocked categories, enforce minimum spacing between same-brand items), Fairness Constraints (ensure balanced representation across groups), and Exposure Allocation (reserve slots for new or exploration items).

Cold Start Problem

The cold start problem is the fundamental challenge of recommending items for which no interaction data exists. It manifests in two forms: user cold start (new user with no history) and item cold start (new item with no interactions). Cold start is the most cited practical challenge in production recommendation systems, affecting user retention and new item promotion.

Content-Based Bridging

The most effective cold start strategy is content-based bridging: use item content features (title, description, category, image embeddings, metadata) as a bridge between existing items (with interaction data) and new items (without). The system learns a mapping from item content features to collaborative embedding space. For a new item, the content-based embedding is computed from its features and used for retrieval and ranking alongside collaborative embeddings.

LLM-generated item descriptions and embeddings have become standard for cold start in 2026. An item's title and description are embedded using a model like text-embedding-3-small, and this semantic embedding serves as the initial representation for new items. As interactions accumulate, the collaborative embedding is blended with the content embedding using a mixing weight that shifts from content-dominant to collaborative-dominant over time. See our guide to LLM embeddings for embedding generation details.

Exploration Strategies

Beyond content bridging, active exploration is necessary to gather interaction data for new items. Epsilon-greedy exploration selects a random item with probability epsilon (typically 0.01-0.1) instead of the top-ranked recommendation. Upper Confidence Bound (UCB) algorithms select items with the highest uncertainty, naturally exploring items with few interactions. Thompson Sampling, which samples from the posterior distribution of expected relevance, provides the theoretically optimal exploration-exploitation trade-off.

In practice, production systems use hybrid strategies: a dedicated exploration channel reserves 5-15% of recommendation slots for new items, with allocation determined by a bandit algorithm. YouTube, for instance, reserves a fixed percentage of browse recommendations for recently uploaded content, ensuring new creators receive initial exposure [11].

Meta-Learning for Cold Start

Meta-learning (learning to learn) has emerged as a promising approach for cold start. Model-Agnostic Meta-Learning (MAML) trains a model initialisation that can quickly adapt to new users or items with a few gradient steps. For recommendation, the meta-learner is trained across thousands of users/items, each with a small support set of interactions. At deployment, a new user with limited interactions gets a customised model by fine-tuning from the meta-learned initialisation using their few observed interactions [12].

Meta-learned cold start models have been deployed at Pinterest (PinSage with inductive learning) and Alibaba, achieving 10-25% improvement in cold-start recommendation accuracy over content-based baselines [12]. The main limitation is training complexity: meta-learning requires careful episode construction and is sensitive to the distribution of meta-training tasks. For a broader discussion of inductive learning and its applications, see our graph neural networks guide.

Production Considerations

Deploying a recommendation system in production involves infrastructure decisions that can determine success or failure. Model accuracy is necessary but not sufficient — latency, scalability, freshness, and reliability are equally important.

Feature Stores

Recommendation systems consume hundreds of features per request: user embedding, recent interaction sequence, item metadata, real-time context. Feature stores (Feast, Tecton) provide a central repository for feature definitions with consistent serving across training and inference. The critical requirement is point-in-time consistency: training features must reflect the state of the world at the time of the interaction, not the present state (which would leak future information and cause train-serve skew) [13]. For a complete treatment of feature infrastructure, see our MLOps production guide.

Real-Time vs Batch Inference

Recommendation latency budgets are tight — typically under 200ms total for retrieval, ranking, and re-ranking. Real-time inference (compute user embedding on demand, query ANN index) is required for most applications. However, some stages can be pre-computed: candidate embeddings are computed offline, popularity-based recommendations are refreshed hourly, and personalised home pages can be pre-generated for active users.

The industry trend is toward near-real-time personalisation: model updates happen continuously (streaming), not in daily batch jobs. Google's YouTube uses a continuous training pipeline that updates the recommendation model every 30 minutes, while Spotify updates session-based models in near-real-time as users interact with the app. Streaming infrastructure for real-time features requires robust event processing — see our AI infrastructure guide for the underlying architecture.

A/B Testing and Online Metrics

Offline metrics (NDCG, Recall@K) are imperfect proxies for business outcomes. The ultimate validation of a recommendation model is an online A/B test measuring user engagement metrics. Key online metrics include: click-through rate (CTR), session length, watch/read time, conversion rate, revenue per user, retention (D1, D7, D30), and diversity metrics (catalogue coverage, category distribution entropy).

A/B testing for recommendation systems is complicated by network effects: a change that improves recommendations for one user may impact other users due to supply constraints (e.g., limited inventory of viral content). Swaminathan et al. (2017) propose interleaved experiments where each user sees an interleaving of recommendations from control and treatment models, providing more sensitive and robust comparisons [14]. Interleaving requires 10-100x less traffic than traditional A/B tests to achieve the same statistical power.

Key Offline Metrics: NDCG, Recall@K, MAP

Normalised Discounted Cumulative Gain (NDCG) is the standard offline ranking metric. It measures the quality of the ranked list by accumulating gains (relevance) at each position, discounted logarithmically by position. NDCG@10 of 0.85 means the top 10 recommendations are on average 85% as good as the perfect ranking. Recall@K measures the fraction of relevant items retrieved in the top K. Mean Average Precision (MAP) averages precision across recall levels, capturing both ranking quality and completeness.

In production, teams typically track NDCG@K for ranking quality (evaluated on held-out user interactions), Recall@K for retrieval coverage (how many relevant items are captured in the candidate set), and a business-specific metric (e.g., revenue-weighted NDCG for e-commerce, watch-time-weighted NDCG for video). Diversity metrics like intra-list similarity, category coverage, and entropy of recommended item distribution are increasingly tracked to prevent filter bubble effects.

Evaluation Metrics

Rigorous evaluation is essential for developing and maintaining recommendation systems. The evaluation strategy combines offline metrics for rapid iteration and online (A/B) metrics for business impact validation.

Offline vs Online Evaluation

Offline evaluation measures model performance on historical data by holding out a subset of user interactions. The standard protocol is leave-one-out: for each user, hold out one interaction as the test item, train on the rest, and measure how highly the test item is ranked among all items (or among a sampled set of negatives). The leave-one-out protocol with 100-1000 randomly sampled negatives has been the standard since the Netflix Prize [2][3].

Offline metrics are useful for model selection but have well-known limitations. They evaluate on historical data while deployment is in a non-stationary environment. They cannot capture user reactions to recommendations (a recommended item that the user did not previously interact with may be valuable). They cannot measure long-term effects like user retention or discovery of new interests. Hence, offline evaluation is a gate but not a substitute for online A/B testing.

NDCG, Recall@K, MAP, and HR@K

Hit Ratio@K (HR@K) is the most commonly reported metric in academic recommendation research: it measures whether the held-out test item appears in the top-K recommendation list. NDCG@K is the most informative single metric because it accounts for both relevance and ranking position. Recall@K is most relevant for retrieval stage evaluation — it measures whether the candidate set contains all relevant items, regardless of rank.

Diversity and Beyond-Accuracy Metrics

Accuracy-only optimisation creates filter bubbles and reduces user satisfaction over time. Beyond-accuracy metrics include: Intra-List Similarity (ILS) measures the average pairwise similarity of items in a recommendation list — lower ILS indicates higher diversity. Catalogue Coverage measures the fraction of items that ever appear in recommendation lists — low coverage concentrates traffic on popular items. Serendipity measures whether recommendations are both relevant and unexpected. A 2024 study by Spotify found that optimising for diversity alongside accuracy increased user retention by 8% over accuracy-only optimisation at the same engagement level [15].