Product recommendation models fall into three families: collaborative filtering, content-based filtering and hybrids of the two. Deep learning architectures such as two-tower networks and graph neural networks now sit on top of all three. The right choice rarely depends on which algorithm is newest. It depends on how much behavioural data you have, how large and varied your catalogue is, and whether you can measure the model’s effect on revenue instead of on a lab metric.
This guide is for ecommerce operators, marketing leaders and revenue teams who have to pick, build or buy a recommendation engine. We cover how each model works, where it breaks, how to test it, and how to keep it trustworthy once it is live.
TL;DR
- Collaborative filtering learns from similar shoppers, content-based filtering learns from product attributes, and hybrids combine both to cope with thin data.
- Production systems usually split the job into candidate generation, scoring and re-ranking, rather than relying on one model.
- Offline metrics alone mislead. Filter offline, iterate with multi-armed bandits, and confirm with an A/B test.
- The bottleneck is usually data sparsity, cold start and popularity bias, not the algorithm.
- Recommendations are a socio-technical system: design for explainability, and govern them like any other AI that influences customers.
Table of Contents
- What a product recommendation model actually does
- The main types of recommendation models
- Comparing the models side by side
- Why production systems use stages, not one model
- The pitfalls that matter more than the algorithm
- How to test a recommendation model honestly
- Make recommendations explainable and trustworthy
- Our perspective: start with the decision, not the algorithm
- Choosing the right model for your situation
- Where Brainiac fits
- A practical first 90 days
- FAQ
- Sources
What a product recommendation model actually does
A recommendation model answers one question for each visitor: out of thousands of products, which few should this person see next? It takes signals such as past purchases, views, searches, item attributes and context, and returns a ranked list.
A recent survey of deep learning in recommender systems groups modern engines into collaborative filtering, which predicts interest from similar users, content-based filtering, which predicts it from item and user attributes, and hybrids that combine both to improve accuracy and overcome data limits. The same survey notes that state-of-the-art models commonly use Multi-Layer Perceptrons, Two-Tower neural networks and Graph Neural Networks for richer feature extraction.
Think of the model as a map, not a verdict. It shows likely routes through your catalogue, and your job is to check that the map matches the territory your customers actually walk.
The main types of recommendation models
Collaborative filtering
Collaborative filtering assumes that people who behaved alike in the past will want similar things. If shoppers who bought a trail running vest also bought a hydration flask, the next vest buyer sees the flask.
Strengths: it needs no product metadata, and it surfaces surprising, cross-category links that no merchandiser would write by hand.
Weaknesses: it needs a lot of interaction data. New products and new visitors have no history, which is the cold-start problem. It also tends to favour what is already popular.
Content-based filtering
Content-based models match products to a shopper’s profile using attributes: category, price band, brand, colour, text descriptions, image embeddings. If someone keeps viewing waterproof shells, the model recommends other waterproof shells.
Strengths: it works for new items the moment they have clean attributes, and it is easy to explain.
Weaknesses: it can trap shoppers in a narrow band of similar items, and it is only as good as your catalogue data.
Hybrid models
Hybrids blend behaviour and attributes. A typical setup uses attributes to place new items, then shifts weight toward behavioural signals as data accumulates. For most stores with a mixed catalogue, a hybrid is the practical default, because it covers the weak spot of each parent approach.
Context-aware and sequential models
Sequential models treat a session as an ordered story rather than a bag of clicks. A survey of sequential recommender systems for ecommerce frames recommendation as tailoring suggestions to an individual customer’s need, which is why session order, device and time of day increasingly feed the models. They shine for fast-moving categories like fashion or consumables, where what someone did five minutes ago matters more than what they did last year.
Deep learning and graph models
Two-tower networks learn one representation for users and another for items, so that matching becomes a fast similarity search across a huge catalogue. Graph neural networks go further by treating customers, products, orders and attributes as a connected graph. According to NVIDIA’s documentation on graph-based personalization, pairing graph models with large language models helps ingest unstructured data such as text descriptions and image embeddings, so relevant recommendations remain possible even when interaction history is minimal.
Comparing the models side by side
| Model | Needs | Handles cold start | Explainability | Best for |
|---|---|---|---|---|
| Collaborative filtering | Large interaction history | Poorly | Moderate (“shoppers like you”) | Mature stores with steady traffic |
| Content-based | Clean product attributes | Well for new items | High | Small or new catalogues |
| Hybrid | Both, in moderate amounts | Well | Moderate | Most mid-market stores |
| Sequential / context-aware | Session-level event data | Moderate | Lower | Fast-moving categories |
| Two-tower and graph models | Engineering capacity, rich data | Good, especially with LLM features | Lower, needs deliberate design | Large or complex catalogues |
No row wins everywhere. If your store sees a few hundred orders a month, a simple, well-tuned hybrid will usually beat a sophisticated deep model that has too little data to learn from.
Why production systems use stages, not one model
It is tempting to train a single model that takes every product and returns the ideal list. At scale that is too slow and too brittle. Google’s machine learning guidance describes a three-stage architecture of candidate generation, scoring and re-ranking.
- Candidate generation narrows the full catalogue to a few hundred plausible items.
- Scoring ranks those candidates with a richer, more expensive model.
- Re-ranking applies business rules and corrections: freshness, diversity, stock, margin, exclusions.
The same guidance advises separating candidate generation from scoring and using several specialized generators, each drawing on a different source such as historical behaviour, social signals or trending items. The result is a more relevant and more varied pool before the final model ranks it. Google’s overview of candidate generation describes the two core approaches, content-based similarity between items and collaborative similarity between users.
For a retailer, the staged design has a practical benefit: the re-ranking stage is where merchandising judgment lives. You can push in-stock, high-margin or seasonal items without retraining the whole model.
The pitfalls that matter more than the algorithm
Popularity bias
Many off-the-shelf engines rely on simple dot-product similarity, and under that measure popular items dominate. Google’s scoring guidance explains this effect and notes that practitioners use other similarity measures or explicit re-ranking to restore diversity. If your margin sits in the long tail, an engine that only loops shoppers through your top sellers is quietly working against you.
Data sparsity and cold start
For most businesses with complex data, the model is not the bottleneck. Sparse interactions and new items are. Practical fixes include richer product attributes, image and text embeddings, and graph or LLM-based features that let new products inherit meaning from similar ones. Before you commission a new algorithm, audit your event tracking and catalogue data. Missing variants, inconsistent categories and untracked add-to-cart events cost more accuracy than any model swap can recover.
Positional bias
Shoppers click the first items in a list regardless of relevance. If you train on clicks without correcting for position, the model learns where it placed things, not what people wanted. The NIST AI Risk Management Framework is the reference point for treating this kind of bias as a managed risk rather than a technical footnote.
How to test a recommendation model honestly
Teams often fall into one of two traps. They test only online, which is slow and costly, or they trust only offline metrics, which are biased. Research from Expedia Group describes a hybrid evaluation approach: use offline metrics to filter, multi-armed bandits for fast iterative testing, and A/B tests for final confirmation. In their experience this compressed a six-month development cycle into five weeks.
The case against offline-only evaluation is stronger for smaller stores. A study comparing offline and online evaluation in small ecommerce found that low traffic volume makes recommending on small shops especially challenging, and offline scores such as precision or recall often fail to track real-world A/B results. They cannot capture the full user experience, your interface or position effects.
A workable testing sequence:
- Offline screen. Replay historical sessions and discard models that clearly underperform. Do not use the survivors’ scores to predict revenue.
- Bandit stage. Let a multi-armed bandit shift traffic toward better-performing variants while you iterate quickly.
- A/B confirmation. Run the finalist against your current experience, with revenue per session, conversion and average order value as primary measures.
- Watch for leakage. Check whether gains come from cannibalizing items shoppers would have bought anyway.
- Re-test on a schedule. Catalogues, seasons and interfaces change, and so does model performance.
If you want a framework for judging whether an analytics or AI system is accurate enough to trust, our guide on how to evaluate AI analytics platform accuracy applies the same discipline.
Make recommendations explainable and trustworthy
NIST frames recommendation engines as socio-technical systems. They are not only mathematical models. They shape what people see, buy and believe. Its framework describes trustworthy AI as valid and reliable, safe, secure, resilient, accountable, transparent, explainable, interpretable, privacy-enhanced and fair. For a store, that translates into plain commitments:
- Be able to say why a product was recommended (“because you viewed…”, “popular in your area”).
- Measure fairness across segments and categories, not only overall lift.
- Give shoppers and your own team controls to exclude items or reset a profile.
- Keep an audit trail of model versions and the data they used.
There is a second audience now: AI shopping assistants that recommend your products on a customer’s behalf. Clear, structured listings feed both your own engine and those assistants, and the product description fixes for AI recommendations show how listing quality changes whether a product gets picked. If this is on your radar, our overview of agentic commerce readiness covers whether an AI agent can find, trust and buy from you.
Our perspective: start with the decision, not the algorithm
We see the same pattern in many ecommerce and go-to-market projects. A team picks a model first, then goes looking for a business problem it can solve. We reverse that order.
First, name the revenue decision the recommendation supports: cross-sell at cart, replenishment emails, homepage merchandising, or sales-rep product suggestions in the CRM. Second, check the data that decision depends on, because that is where projects stall. Third, choose the simplest model that clears the bar, and prove it with one pilot before widening the scope. That is the logic behind our pilot-first approach to AI agent strategy.
We also build in the open. Our work favours open-source components and integrations with the platforms you already run, such as Salesforce and HubSpot, so you can see how every recommendation is produced and change it without asking a vendor. A black box that lifts click-through today is a liability the first time someone asks why it recommended what it did.
Finally, treat attribution as a map rather than a courtroom verdict. A recommendation widget rarely deserves all the credit for a sale or all the blame for a miss. Measure incremental revenue through controlled tests, and use attribution models to understand the wider tapestry of touchpoints around it.
— Don
Choosing the right model for your situation
Use these criteria in order.
- Traffic and order volume. Under a few thousand monthly orders, start with content-based or hybrid models and strong merchandising rules. Collaborative signals will be noisy.
- Catalogue churn. If new products arrive weekly, prioritize cold-start strength: attribute quality, embeddings and graph features.
- Catalogue breadth. A narrow catalogue needs less machinery. A very wide one benefits from staged architecture and two-tower retrieval.
- Margin structure. If margin lives in niche items, plan the re-ranking stage to protect discovery from popularity bias.
- Team capacity. A model nobody can monitor will decay. Count the people who will own it, or buy managed operations.
- Governance needs. Regulated categories, or any need to explain decisions, push you toward interpretable approaches and documented controls.
Build, buy or co-build
Off-the-shelf engines are fast to launch, but you inherit their defaults, including their similarity measures and bias handling. Fully custom builds give control but demand data engineering and testing capacity. A middle path is a co-built system: an established framework, tuned to your catalogue and wired into your CRM and analytics stack, with testing and monitoring included from the start.
Where Brainiac fits
If you are weighing these options, we can help at whichever stage you are. Our AI strategy and readiness work assesses your data, maps and prioritizes use cases, and builds the roadmap and business case. When you are ready to build, custom agent deployment puts production-grade agents inside your own environment, and the Atlas AI operations platform supports ongoing operations. To talk through a recommendation or personalization project, start from brainiacconsulting.io.
A practical first 90 days
- Weeks 1 to 2: audit event tracking, catalogue attributes and identity resolution. Fix gaps before modelling.
- Weeks 3 to 4: choose one placement and one decision, such as cart cross-sell. Set a baseline for revenue per session.
- Weeks 5 to 8: build candidate generators and a scoring model, add a re-ranking layer for stock and margin, and screen offline.
- Weeks 9 to 12: run bandit and A/B stages, review fairness and explainability, and document the controls.
The schedule is a guide, not a promise: your data quality will set the real pace.
FAQ
Which AI model is commonly used in product recommendation systems?
Hybrid systems are the most common, combining collaborative and content-based signals. Deep learning variants such as two-tower networks and graph neural networks are increasingly used for larger catalogues. The best fit depends on your data volume and catalogue complexity, not on popularity of the technique.
What is the most popular recommendation algorithm?
Collaborative filtering is the best-known approach, built on the idea that similar shoppers want similar products. In practice it is usually paired with content-based features and a re-ranking stage. On its own it struggles with new products and new visitors.
Which AI is best for product recommendations?
There is no single best model. For small catalogues or thin data, a tuned hybrid usually performs best. For large or complex catalogues, graph models combined with LLM-derived features help with cold start, provided you can test them properly with A/B experiments.
What is the difference between a recommendation model and a recommendation engine?
The model is the algorithm that scores items. The engine is the whole system around it: data pipelines, candidate generation, re-ranking rules, serving, testing and monitoring. Most business results come from how well the engine is built, not from the model alone.
Sources
- In-depth survey: deep learning in recommender systems (Neural Computing and Applications)
- A Survey and Taxonomy of Sequential Recommender Systems for E-commerce
- NVIDIA Structured Data and Graph Models: Personalization
- Google for Developers: Recommendation systems overview
- Google for Developers: Candidate generation overview
- Google for Developers: Scoring
- NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- Expedia Group: hybrid evaluation of recommendation algorithms
- Off-line vs. On-line Evaluation of Recommender Systems in Small E-commerce
