Recommendation systems

Recommendation engines

What a recommendation engine is, the approaches available, how the good ones are told apart from the rest, and what to check before you commit to one.

What is a recommendation engine?

A recommendation engine is a software system that selects and orders items from a catalogue for a particular person or context. It learns from interaction data - views, clicks, plays, purchases, dwell time - and usually from the content of the items themselves, then returns a ranked slate for a specific surface: a homepage rail, a product detail page, a feed, an email.

The term is used loosely for three different things: a single model, a pipeline of models with business rules on top, and a whole platform that operates those pipelines. Most buying decisions go wrong at that distinction, because a product that is excellent as the first can be a poor answer if you needed the third.

Where NeuronSearchLab fits

NeuronSearchLab is an API-first recommendation platform for building, evaluating and operating personalised recommendations.

A single recommendation model gives you one fixed way of ranking. NeuronSearchLab trains and compares several architectures on your own data, keeps the winner behind one unchanging API, and gives you evaluation, experimentation, explainability and editorial control over whatever is serving.

Concretely: NSL is a recommendation system in the ordinary sense - you send a catalogue and an event stream, you call an API, you get a ranked slate. What it adds on top of a single fixed recommender is the layer that decides which recommender is serving and proves it is the right one: several architectures trained on your own data and compared like for like, shadow and canary releases with automatic rollback, per-result explanations, and editorial rules applied at request time. The application integration does not change when the model underneath it does.

If you want one model chosen for you and never revisited, a simpler product in this category will serve you well and this page names several. If choosing, measuring and governing the model is part of the job, that is the gap NSL is built for.

The approaches, and what each is good at

“Recommendation engine” covers several families of model that behave very differently on different catalogues. These are the families you will meet.

Collaborative filtering

Ranks from co-occurrence in behaviour: people who interacted with this also interacted with that. Strong when interaction data is dense, weak on items nobody has touched yet. Includes neighbourhood models, matrix factorisation and linear autoencoders.

Content-based

Ranks from what the item is - text, metadata, images, audio, video - usually through embeddings. Places a brand-new item on its first day, because it needs no interaction history. Weaker at surprise, because it recommends more of the same.

Sequential

Treats a user's history as an ordered sequence and predicts the next item. Built for regimes with long, repetitive histories - music, short video, reading. Transformer-based sequence models are the standard form.

Graph

Propagates signal over a user-item graph, so a recommendation can be reached through several hops rather than direct co-occurrence. Useful on sparse data where direct overlap between users is rare.

Generative

Generates item identifiers directly - semantic-ID decoders and autoregressive user models - rather than scoring a candidate set. The newest family, and the one where the gap between a published result and a deployable system is widest.

Multi-stage

Most production systems: something cheap narrows the catalogue to a few hundred candidates, something careful orders what is left, and business rules apply on top. The retrieval and ranking stages can come from different families.

The NSL Recommender Leaderboard measures 27 complete systems from these families on 10 public datasets, with quality, cost and latency reported separately. It is free and ungated, and the per-scenario boards show the winner changing between cold users, long-tail items and dense histories - which is the evidence behind the claim that no single architecture wins everywhere.

What to check before you choose one

Seven questions that separate products in this category. They are worth asking of every vendor, including us.

Which approaches it supports

Ask which recommender families the product can actually run, and whether you can pick between them. Many hosted products name their models by merchandising job - 'related items', 'trending' - rather than by architecture, which means the architecture is not yours to choose.

Whether you can bring your own representations

If you already produce embeddings - from a multimodal model, a text encoder, or a model your own team trained - can they be attached to items and used for retrieval and ranking? This is the difference between a recommendation layer that composes with your ML work and one that replaces it.

What evaluation it gives you

Per-model-version offline metrics, not just a revenue chart per placement. Relevance, coverage, diversity, novelty and cold-start performance reported separately, so a model that wins on relevance by collapsing onto the head of the catalogue is visible as such.

How a model is promoted and rolled back

Shadow mode, canary traffic, conditional promotion against agreed metrics, automatic rollback. A recommendation change is a production change, and the question is whether the product treats it like one.

What editorial control exists

Whether a non-engineer can boost, suppress, exclude, pin or guarantee an item on one surface without a retrain, a deploy or a release - and whether they can preview the effect before publishing it.

Whether a result can be explained

For one item in one slate, can you get back why it was placed there? This matters for debugging, for editorial trust, and increasingly for regulators asking how content reached a user.

Where it runs and what it costs

Region, tenancy, whether a private deployment is possible, what the meter is, and whether the price is published at all. Half of this category quotes rather than publishes.

Products in this category

A neutral summary of six products teams commonly evaluate, on four of the dimensions above. Each cell is sourced from the vendor’s own public documentation and links to it from that product’s page.

ProductRecommendation APIBring your own embeddingsModel selectionExperimentationPricing model
NeuronSearchLabRecommendation platform: build, evaluate, operateDocumentedDocumentedDocumentedDocumentedDocumented
RecombeeRecommendation-as-a-service APIDocumentedNot documentedPartlyDocumentedDocumented
Amazon PersonalizeManaged recommendation service on AWSDocumentedNot documentedPartlyOut of scopeDocumented
Algolia RecommendRecommendation add-on to a hosted search indexDocumentedNot documentedPartlyPartlyDocumented
Dynamic YieldPersonalisation and experimentation suiteDocumentedNot documentedPartlyDocumentedOut of scope
BloomreachCommerce search, merchandising and marketing suiteDocumentedNot documentedPartlyDocumentedOut of scope
NostoCommerce experience platformDocumentedNot documentedPartlyDocumentedOut of scope

How to read this table

  • Documented - the vendor’s own public documentation describes this as a capability.
  • Partly - documented, with a material limit named in the cell.
  • Not documented - we could not find it in the public documentation. That is not the same as it not existing. Ask the vendor.
  • Out of scope - the documentation says it is not part of the product.

Compiled from public documentation on 19 September 2026. Products change; every claim links to the page it came from, so check the source before you rely on it. Nothing here is scored, ranked or totalled.

Building one yourself

Building a recommender is not the hard part. A competent team gets a collaborative filtering model beating a popularity baseline in a couple of weeks. The cost is everything after that: the event pipeline, the feature store, the retraining schedule, the offline evaluation harness, the online experiment framework, the rules engine merchandisers ask for within a month of launch, the on-call rota for a service that now sits in the request path of every page.

The honest test is whether the ranking itself is a source of advantage for your business. If it is - if you have signals nobody else has and the catalogue is the product - building is defensible. If the ranking is table stakes and the advantage is elsewhere, the build is a permanent tax on the team that could have been spending that time on the thing that does differentiate you.

By industry

What a recommendation engine has to be good at changes with the catalogue. Three common cases, each with its own page.

Frequently asked questions

What is a recommendation engine?

A recommendation engine is a software system that selects and orders items from a catalogue for a particular person or context. It learns from interaction data - views, clicks, plays, purchases, dwell time - and usually from the content of the items themselves, then returns a ranked slate for a specific surface such as a homepage rail, a product detail page or a feed.

What is the difference between a recommendation engine and a recommendation platform?

A recommendation engine is one model or pipeline that produces a ranking. A recommendation platform is the layer around it: ingestion, model training and selection, evaluation, experimentation, editorial control, explainability and serving. NeuronSearchLab is a platform in this sense - it operates recommenders rather than being a single fixed one.

Which recommendation approach is best?

None of them is best on every catalogue. Published benchmarks, including the NSL Recommender Leaderboard, consistently show the winning architecture changing with the shape of the data: sequence length, catalogue turnover, how long-tailed the catalogue is, and whether impressions are logged. This is the main practical argument for evaluating several architectures on your own data rather than adopting one.

Do I need machine learning engineers to run a recommendation engine?

Not to run a hosted one. You need engineering to send a catalogue and an event stream, and to call an API. You need more than that if you intend to train, compare and govern models yourself. Platforms differ in how much of that second category they take on.

How is recommendation quality measured?

Offline, with ranking metrics computed on held-out interactions - NDCG@K, recall@K, MRR, hit rate - alongside catalogue coverage, novelty, diversity and cold-start performance. Online, with an A/B test measuring the business outcome the recommendations exist to move. Offline metrics narrow the field; only an online test settles it.

How much does a recommendation engine cost?

Hosted recommendation APIs generally meter on recommendation requests, catalogue size or a combination. Published entry pricing in this category ranges from free developer tiers into four figures per month; enterprise suites are usually quoted rather than published. NeuronSearchLab publishes its tiers, starting at a free tier of 1,000 requests a month and £150 a month for the first paid tier.

Related reading

See it on your own catalogue

Send a catalogue and an event stream and get ranked results back the same day. The free tier needs no card.