Recommender Systems

Recommender System · Recommendation Engine · RecSys

Definition

A recommender system is an algorithmic system that selects the products most relevant to a user from the catalogue, based on their behaviour, product attributes and session context. It is not a single model but a pipeline: candidate generation, ranking and merchandising rules are separate stages, each of which can be changed independently.

What a recommender system is

The job of a recommender system states simply: out of a catalogue of tens or hundreds of thousands
of SKUs, pick the 4–12 items worth showing to a specific shopper in a specific slot on the page.
Everything else is implementation detail around that selection.

Formally, the system evaluates a relevance function:

score(user, item, context) → a real number

user    — the profile: view and purchase history, affinity to brands and price bands
item    — the product: feed attributes, interaction statistics, stock status
context — the placement, the current category, the device, the anchor product

Candidates are then sorted by score, unavailable items and anything excluded by rules are removed,
and the top N go into the recommendation widget.

One consequence matters more than the rest: a recommender system is a pipeline, not a model.
Swapping the algorithm moves quality by a few percent; fixing the product feed or adding a stock
filter moves it by tens of percent.

Algorithm classes

Class	What it is built on	Strength	Limitation
Collaborative filtering	The user × item interaction matrix	Finds non-obvious links between products	Does not work for new products or new users
Content-based filtering	Product attributes and text descriptions	Works from the first day of a SKU’s life	Narrows the output to near-identical items
Matrix factorization	Decomposing the interaction matrix into latent factors	Compact, tolerant of sparsity	Ignores context and sequence
Embedding models	Item vectors trained on interaction sequences	Similarity by real behaviour, not by description	Needs data volume and regular retraining
Two-tower	Separate encoders for the user and the item	Fast candidate retrieval by vector	Training and infrastructure complexity
Hybrid	A weighted combination of several sources	Holds up across every traffic segment	Harder to debug and to explain

Collaborative filtering remains the default class for stores with accumulated history.
Content-based filtering is mandatory wherever the assortment turns over quickly — fashion,
books, seasonal categories. Matrix factorization and Item2Vec give a compact vector
representation of products, while a two-tower model encodes the user and the item separately,
which makes it possible to retrieve candidates by approximate nearest-neighbour search.

Architecture: candidates and re-ranking

Running a heavy model over every product in the catalogue on every request is not possible — the
response budget is usually measured in tens of milliseconds. That is why production systems are
split into two stages.

Catalogue (100,000+ SKUs)
        │
        ▼  Stage 1: candidate generation   (~5–15 ms)
   lightweight sources: co-visitation, vector retrieval, category bestsellers,
   user history, category manager rules
        │
        ▼  200–500 candidates
        ▼  Stage 2: re-ranking              (~10–30 ms)
   heavier model + business logic:
   margin, stock status, brand de-duplication, diversity
        │
        ▼  Stage 3: post-processing
   merchandising rules, pinned positions, exclusions
        │
        ▼  4–12 products in the widget

Re-ranking is where algorithmic relevance meets business requirements. This is the stage that caps
the share of any single brand in the output, lifts high-margin products and strips out items that
are not in stock.

ℹ

The split into stages also pays off organisationally: changing the re-ranking model does not require
rebuilding the candidate sources, and adding a new source does not break the existing ranking. That
is what makes incremental improvement possible.

Metrics: offline and online

Offline metrics are calculated on historical data: the model predicts what the user interacted with
in a held-out period, and the prediction is compared against what actually happened.

Metric	What it measures	Why it is needed
Precision@k	Share of relevant items among the k returned	Accuracy of a short output
Recall@k	Share of relevant items found out of all relevant ones	Coverage of the user’s interests
NDCG	Quality of ordering, weighted by position	Accounts for top positions mattering more
Coverage	Share of the catalogue that appears in recommendations	Guards against collapsing into the top-100 bestsellers
Diversity	Variety inside a single block	Guards against ten nearly identical t-shirts
Novelty	Share of items the user has not seen before	Balances the familiar against the new

Online metrics are calculated in an A/B test on live traffic and take priority in any disagreement:

Metric	How it is calculated	Comment
Widget CTR	Clicks / widget impressions	Fast, but not directly tied to money
CR from the widget	Orders containing a widget item / impressions	Closer to the result, sensitive to attribution
RPV	Revenue / unique visitors	The primary metric for comparing strategies
Attributed revenue	Revenue from products that interacted with recommendations	Depends on the attribution window — fix it in advance

A good offline metric alongside a poor online result is a routine outcome. Offline evaluation
rewards predicting what the shopper would have found anyway; the business needs increment, and
increment is only visible against a control group. NDCG, precision and recall help screen out models
that are clearly weak, but the decision is made on the A/B test.

Cold start and fallbacks

Cold start is not a rare failure — it is the permanent state of part of your traffic. In a typical
online store, a noticeable share of sessions comes from visitors with no history.

Type of cold start	Solution
New user	Session-based recommendations from the current visit, popular items in the entry category, trends
New product	Content features: brand, category, price band, text description
New project	Non-personal strategies plus implicit feedback from the first days of collection
Rare category	Aggregating statistics up to the parent category level

One requirement is non-negotiable in production: a deterministic fallback. If the personal strategy
returns fewer items than the widget needs, the block must top itself up with bestsellers rather than
collapse into nothing.

Placement map: what goes where

Placement	Typical strategy	Primary metric
Homepage	Personal recommendations, trends, recently viewed	Session RPV
Category listing	Personalized sorting, promo blocks	Category CR
Product page	Similar items, accessories	CTR, browsing depth
Cart	Frequently bought together	AOV
Post-purchase screen	Companion items and consumables	Repeat orders
Zero-result search	Content-based similar items	Sessions saved

Adjacent terms: a recommendation strategy describes the algorithm configuration for one specific
placement, personalized recommendations are the special case where the individual profile drives the
selection, and embeddings together with approximate nearest-neighbour search are the technical basis
of vector strategies.

Common mistakes

Optimising CTR instead of revenue. A “recently viewed” block almost always wins on CTR and
almost never on incremental revenue: the shopper would have come back to that product anyway.
No stock filter. Recommending an item that cannot be bought costs more than showing no
recommendation at all.
Comparing strategies without an A/B test. Switching strategies on week by week mixes the
effect with seasonality.
Ignoring diversity. Ten variants of the same model are formally relevant and practically useless.
One algorithm for every placement. The selection logic in the cart and on the homepage differ
in kind, not in degree.
No retraining. A model trained on last year’s assortment degrades invisibly — monitor
catalogue coverage and the share of recommendations coming from new arrivals.

Frequently asked questions

How is collaborative filtering different from content-based filtering?

Collaborative filtering works from user behaviour: if people with a similar history bought item X, X gets recommended. It needs no knowledge of product attributes, but it performs poorly for new items with no interaction history. Content-based filtering compares the products themselves — brand, category, price, description — so it works from the first day a SKU exists, but it tends to lock the shopper into a narrow band of near-identical items. Production systems almost always run a hybrid.

What is the cold start problem?

It is the situation where the system does not have enough data for personal selection. Cold start comes in three types: a new user with no history, a new product with no interactions, and a new project with no data at all. The fixes are content features, session-based recommendations built from the current visit, and clear non-personal fallbacks such as bestsellers and category trends.

Which metrics should be used to evaluate recommendations?

Offline metrics (precision@k, recall@k, NDCG, catalogue coverage, diversity, novelty) are calculated on historical data and are used to screen models before release. Online metrics (widget CTR, conversion from the widget, revenue per visitor, attributed revenue) are calculated in an A/B test and are the ones that decide. A gap between offline and online results is normal: an offline metric scores the prediction of past behaviour, not a change in future behaviour.

Does a recommender system replace the work of a category manager?

No. The algorithm optimises relevance on historical data and knows nothing about supplier contracts, a collection being cleared out, or a new line being introduced. That is why production systems support merchandising rules — pinned positions, boosts and exclusions — applied on top of algorithmic ranking.

How much data is needed to launch recommendations?

Session-based and content-based scenarios — similar items, recently viewed, bought together — start from the data of a single visit plus a correct product feed. Collaborative models need accumulated interaction history: in typical projects that is several weeks of event collection. The exact threshold depends on traffic and on how sparse the interaction matrix is, not on the calendar.

Gravity Field

Recommender Systems in Gravity Field

Gravity Field covers the whole recommendation pipeline — from candidate generation to re-ranking and merchandising rules on top of the algorithm. Strategies are compared against each other in A/B tests, so what ships to production is the variant with a confirmed effect on revenue. Client cases include +20% revenue in DIY and +15.1% accessory sales in electronics.

✦Collaborative, content-based and hybrid strategies for different placements

✦Session-based recommendations for anonymous traffic with no history

✦Merchandising rules — boost, pinned positions and exclusions over the ML output

✦Filtering by stock status and current attributes from the product feed

✦A/B testing of strategies with Bayesian statistics and revenue attribution

Explore the platform →