Which recommendation approach fits your website?

Start with the decision, not the model.

A recommender selects items to suggest: an article, product, video or course. The useful question is not “Which model is best?” It is “What should this person find next, and what evidence can help us choose?”

If you have useful articles but little interaction data, start by comparing editor-selected links, topic matching and content similarity. If you already run recommendations, first identify what fails and how you will measure a better result.

A system is more than one algorithm.

Google’s developer guide describes three common stages: find possible items, score them, then adjust the final list. Its 2016 YouTube paper documents separate candidate-generation and ranking models. These are useful architectural examples, not a requirement to copy a large platform. [1] [4]

1. Set eligibility rules. Decide what can be shown. Respect publication state, access rights, content quality and any exclusions.
2. Retrieve candidates. Find a manageable set of possible recommendations from the catalogue.
3. Rank them. Put the more promising choices first for the task you care about.
4. Check the final list. Remove invalid items and excessive repetition. Apply diversity, freshness and editorial rules.

The eligibility checks above are our design recommendation. Enforce access rules when results are served, even if retrieval or ranking has already checked them. A good similarity score is not permission to show restricted or withdrawn material.

COMPARE THE TECHNIQUES

1. Editorial rules and popularity.

How it works: editors choose links, or rules select items by topic, date or aggregate popularity. These are useful starting points against which to compare more complex methods.

What it needs: reliable categories, dates and content status; an editor’s time for manual links. Popularity needs a defined measure and time window, using appropriately collected data.

Suggested use: a publisher adds three editor-selected links to a guide. This is an illustrative starting point, not a customer result.

Watch for: maintenance effort, stale links and popular items taking nearly all the space. “Most clicked” is not the same as “most useful”. Start here when the task is narrow or you need a clear baseline.

2. Content-based and semantic recommendations.

How it works: match item features, such as topics, descriptions or text. A semantic approach represents meaning as a list of numbers, called an embedding, so it can find related material even when wording differs. Google’s content-based tutorial explains feature matching and matching items to preferences. [2]

What it needs: usable content, stable item IDs, metadata and a way to update the catalogue. A contextual “related articles” placement can compare the current article with other articles without a personal reader profile. Individual personalisation is a separate choice.

Suggested use: help readers find related guides across different editorial categories. New items can be considered from their content before they have interaction history.

Watch for: similar wording without a useful next step, repetitive results and obsolete advice. Compare semantic matching with simpler topic matching. More meaningful vectors do not remove the need for editorial checks.

3. Collaborative filtering.

How it works: learn from patterns across people and items. Item-to-item methods look for related interaction patterns; matrix factorisation learns compact representations of users and items from a feedback matrix. The relationship can reveal choices that are not obviously similar in content. [3]

What it needs: reliable interaction data and consistent item identities. Views, purchases and ratings mean different things; a view is not proof of satisfaction. Data collection and use need an appropriate privacy basis and controls.

Suggested use: a service with repeated interactions tests whether collective patterns improve recommendations beyond content similarity.

Watch for: sparse data, popularity bias and the cold-start problem: a new user or item has little history. Keep a content-based or editorial fallback. There is no universal traffic threshold at which this method becomes worthwhile.

4. Hybrid systems and learned ranking.

How it works: combine several signals or candidate sources. A hybrid might blend topic matching with interaction patterns, then use rules or a trained model to order the results. A two-tower retrieval model encodes a user or request and an item separately into a shared space for efficient matching; it is not the same thing as a complete recommendation system.

What it needs: for a simple blend, clear rules and comparable signals. For learned ranking or retrieval, suitable training examples, evaluation data and model maintenance. A hybrid does not have to use deep learning.

Documented architectural example: YouTube’s 2016 paper describes deep candidate generation followed by a separate ranking model. It is a historical account, not a verified description of YouTube’s full current stack. [4]

Watch for: more moving parts, inconsistent scores and objectives that reward clicks at the expense of usefulness. Add complexity only when a simpler comparison leaves a measured gap.

5. Session and sequence models.

How it works: use the order of recent actions to estimate a useful next item. A session model focuses on a visit; a longer-history model can use actions across time when that use is appropriate.

Research examples: SASRec uses self-attention to select useful signals from action history. BERT4Rec learns by predicting hidden items in sequences using bidirectional context during training. Neither cited benchmark paper establishes a deployment on your type of website. [5] [6]

Suggested use: a learning or content service investigates whether the order of actions helps more than a general preference profile.

Watch for: short or noisy sessions, changing intent and accidentally training with information that would not have existed at recommendation time. Session data is not automatically anonymous or exempt from privacy requirements.

6. Graph-based recommendations.

How it works: represent relationships as a network of nodes and links. In LightGCN, the network connects users with items they interacted with, and the model learns from those connections. Other graph designs may represent different relationships; they are not interchangeable. [7]

What it needs: reliable relationships, clear meanings for links and a way to maintain the network.

Research example: LightGCN simplifies graph convolution for collaborative filtering. Its reported experiments are evidence for that research setting, not proof that adding a graph will improve a publisher’s results.

Watch for: extra training and maintenance work, weak relationships and complexity that adds little beyond simpler collaborative methods. A graph-shaped database alone is not a recommendation strategy.

7. Contextual bandits.

How it works: balance showing options that currently look promising with trying other eligible options to learn from feedback. This is often called exploration versus exploitation.

What it needs: timely feedback, a carefully chosen reward, safe exploration rules and logs that record how choices were made.

Documented study: a 2010 paper evaluated a contextual-bandit method using logged random traffic from Yahoo!’s news module. This was an offline evaluation on a real-service dataset, not evidence that any ordinary click log can support an unbiased comparison. [8]

Watch for: exposing readers to poor choices while exploring, a narrow click objective and incorrect offline evaluation. This is not our default first step for a small publisher.

8. Generative retrieval and semantic IDs.

How it works: a model can generate codes that identify candidate items instead of only searching for nearby vectors. A semantic ID is a sequence of codes derived from item representations; it is not a title or a public URL.

Research example: the 2023 paper Recommender Systems with Generative Retrieval predicts semantic IDs for the next item from a sequence. It reports benchmark results, not a deployment promise. [9]

Reported industry use: Snap’s 2026 paper describes semantic IDs as additional ranking features and explores them as retrieval sources. The authors report SID variants launched in production models. This does not establish that every described retrieval experiment was deployed. [10]

What it needs: a way to create and update codes, suitable training data, candidate resolution and checks against the live catalogue. Generated codes must resolve to real, eligible items; they must not bypass access rules.

Watch for: model and catalogue maintenance, ambiguous code-to-item mappings, invalid candidates and cost. Semantic IDs can also be used without generative retrieval. This is not the same as asking a chatbot to invent a list of links.

Where do language models fit?

Our suggested roles include extracting content features, interpreting a stated interest, supporting semantic retrieval and explaining a recommendation. These are design possibilities to evaluate, not documented Smarter BI deployments.

A language model is not automatically a good ranker. Check its outputs, latency, costs and handling of confidential inputs. If it explains why an item was selected, the explanation should reflect the actual selection process rather than a plausible story.

Keep the distinction clear: a language model that writes text, a model that creates embeddings and a model that generates item codes can play different roles. None replaces a reliable catalogue, an evaluation set or editorial control.

What the real examples establish.

• YouTube, 2016: a company-authored account of a large recommendation system with separate retrieval and ranking models. Useful architecture evidence; not a current platform audit. [4]
• Yahoo! news study, 2010: an offline bandit evaluation using real-service random-traffic data. Not a new live A/B test performed by Smarter BI. [8]
• Snapchat, 2026: authors report production launches of semantic-ID variants, alongside experiments. Their results have not been independently reproduced by Smarter BI. [10]
• SASRec, BERT4Rec, LightGCN and generative retrieval: research examples of sequence, graph and generative techniques. Benchmark performance does not establish commercial value on a different catalogue.

Do not transfer a headline uplift from another company or paper into a business case for your site. The audience, catalogue, baseline and success measure may all differ.

Choose the simplest credible starting point.

These are Smarter BI’s starting hypotheses, not a validated decision rule.

• Useful content, little behavioural data: compare editorial links, tags and content-based matching.
• Reliable repeated interactions: test collaborative or hybrid methods against the content baseline.
• Order of actions matters: investigate a sequence model after checking data quality and privacy constraints.
• Good candidates, poor final choices: review ranking, exclusions and variety before changing retrieval.
• A mature system with a specific limitation: investigate graph, bandit or generative methods only when the limitation and evaluation plan justify the extra work.

For a publisher, a useful first experiment may still be three editor-approved links on a small group of pages. Review five representative pages to identify the reader problem first.

Test usefulness, not just prediction scores.

Start with a representative set of reader tasks and candidate recommendations. Ask editors or other qualified reviewers whether each suggestion is relevant, current, allowed and useful as a next step.

• Compare fairly: use the same eligible catalogue and tasks for simple and complex approaches. Where time matters, train on earlier data and test on later data.
• Check retrieval: recall@k asks how many known relevant items appear among the first k candidates. Missing feedback is not proof that an item is irrelevant.
• Check order: NDCG rewards placing more relevant results nearer the top. Its meaning depends on the relevance labels and evaluation design.
• Check the catalogue: look at coverage, repetition, freshness, unavailable items and new-item handling—not one average score.
• Check real use: when appropriate, run a controlled test with guardrails. Track task completion, useful engagement or another agreed outcome alongside complaints and errors.
• Check total cost: include content preparation, training or embedding updates, serving latency, hosting/API costs, monitoring and editorial maintenance.

Choose one primary outcome before the test. Click-through rate can help diagnose a placement, but more clicks or longer visits alone do not establish a better experience. Low traffic may leave a test inconclusive; use reader research and editorial evaluation without presenting them as causal revenue evidence.

Agree what data you may collect and use. Content-only recommendations can avoid individual profiles, but do not automatically make the whole website privacy-compliant. Do not send private reader data to external models without the necessary assessment and agreement.

Turn the survey into a decision brief.

Copy these prompts into your own document. This page does not collect your answers.

1. What should users find or do, and where will suggestions appear?
2. What content, metadata and permitted interaction data exist?
3. What do you do now, and what specifically fails?
4. What must never be recommended?
5. Which simple baseline and alternative should you compare?
6. What evidence would justify a change?
7. Who owns the decision, and what are the platform, cost, privacy and timing constraints?

Illustrative brief: “We publish professional guides. Readers of introductory articles struggle to find deeper explanations. We will compare editor-selected links with topic and semantic matching on a small page sample. Editors will check relevance and access labels. Our digital lead owns the decision; we have not established an engagement uplift.”

RESEARCH AND UPDATES

Read and share the guide.
No signup needed.

The full guide is free to read without giving us your email address.

Prefer an email copy of the link? Ask us to email you the guide. You can also choose optional research updates about recommender systems and content discovery. Updates require separate email confirmation, and you can unsubscribe at any time.

Sources and limits.

Selected primary documentation, author abstracts and publication records were checked on 28 October 2026. This is an editorial synthesis, not a systematic literature review, full-paper replication or exhaustive survey of every current method. Publication dates below describe the sources, not a verified current deployment.

1. Google: Recommendation systems overview (updated 2025). Candidate generation, scoring and re-ranking.
2. Google: Content-based filtering (updated 2025). Feature matching and preferences.
3. Google: Collaborative filtering (updated 2025). Interaction patterns and learned representations.
4. Covington, Adams and Sargin: Deep Neural Networks for YouTube Recommendations (2016). Google Research publication record and abstract.
5. Kang and McAuley: Self-Attentive Sequential Recommendation (2018, v1). SASRec.
6. Sun and colleagues: BERT4Rec (2019, v2). Masked-item sequence learning.
7. He and colleagues: LightGCN (2020, v4). Graph-based collaborative filtering.
8. Li and colleagues: A Contextual-Bandit Approach to Personalized News Article Recommendation (WWW 2010; arXiv v2, 2012). Offline evaluation on Yahoo! data.
9. Rajput and colleagues: Recommender Systems with Generative Retrieval (2023, v3). Semantic-ID retrieval research.
10. Ju and colleagues: Semantic IDs for Recommender Systems at Snapchat (2026, v1). Reported industry applications and experiments.

Suggested starting points, evaluation advice, cost considerations and the decision brief are Smarter BI’s interpretation. Company and benchmark results have not been independently reproduced. AI assisted source organisation and drafting.

For a shorter introduction, read seven reasons publishers can benefit from recommendations. Explore our software services. Our ForYou example is an illustrative use case, not a deployed or tested product.