A recommender system is the part of a platform that selects products for a specific person: from their own views and purchases and from the choices of people with similar behaviour. It is rolled out in ascending order: first selection by catalogue attributes, then event collection, then a behavioural model. The result is checked by comparison with an ordinary storefront rather than by gut feel.
Key takeaways
It is a module that decides, for every user, which products to show and in which order. The decision rests on two sets of data: the catalogue and the events people leave on the platform.
It is worth agreeing separately on what counts as success. A page view and a purchase are different events with different value, and a model trained on views will optimise attention rather than revenue.
There are many algorithms, but three ways of linking a person to a product sit underneath them. The choice depends on what you have more of: a described catalogue or accumulated events.
| Approach | How it works | What a start requires | Where it breaks |
|---|---|---|---|
| Collaborative filtering | Finds people with similar behaviour and offers what they chose | Event history across many users | New products and new users are left without recommendations |
| Content-based approach | Compares product attributes and descriptions and offers items similar to those viewed | A catalogue filled with attributes | The selection turns monotonous: the same thing in different wrappers |
| Hybrid model | Combines both and switches between them by situation | Both a catalogue and events | Harder to tune and harder to explain why an item is shown |
| Popular in category | Shows what everyone buys most often | Order history alone | No personalisation, but a working fallback |
In practice several run in one interface at once: a personal selection on the home page, similar items on the product page, complementary items in the cart. Each block solves its own task and is measured separately.
Personal models need accumulated history, and the order of magnitude is visible in the published requirements of large services. For its commerce recommendation models Google names these thresholds.
These are the requirements of one specific service rather than a universal law, but they show the scale: thousands of events and months of observation, not a week after launch. The same page notes that initial model training and tuning takes two to five days and that a working model cannot be built on synthetic data. Different tasks are handled by different model types: similar items, frequently bought together, a personal selection, repeat purchase.
The practical conclusion for a mid-sized business: start with content-based recommendations, which work on catalogue attributes from day one, and collect events in parallel. Once enough history has accumulated, a behavioural model is added on top rather than instead.
Cold start is the situation where there is no history yet but something still has to be shown. It comes in three forms, each with its own answer.
Tip Every recommendation block needs a fallback for when the model returns nothing: popular in category, new arrivals or a manual selection. An empty block on a storefront looks like a platform failure and undermines trust in the other selections.
Blocks go where a person is already choosing, not where space happens to be left on the page.
Guided selection is a neighbouring mechanic: a person describes their task in their own words and the system translates that description into catalogue parameters and offers options. It helps in complex catalogues — equipment, components, medical services — where a customer does not know the terminology or which filters they need. How the catalogue and the storefront work as a whole is covered in our articles on building a marketplace and launching an online store.
The order matters: each next step relies on data gathered in the previous one.
The sixth step is skipped most often, and it is the one that answers whether the work paid off. Without a comparison any growth in sales can be put down to the season or to advertising.
Recommendations have metrics of their own, and looking at revenue alone is not enough: it moves for many reasons at once.
Catalogue coverage deserves separate attention. If the model keeps cycling through the same hundred items, sales on them will grow while the rest of the catalogue becomes dead weight, along with the money frozen in it.
Most failures come not from the algorithm but from the absence of rules around it.
As soon as behaviour is tied to an account, it is personal data with all the duties of an operator attached.
Important The Law on Personal Data No. ZRU-547 treats collection, storage and use of such information as processing and allows it on one of the grounds in Article 18. Under Article 22 a person is entitled to know the purposes and methods of processing, retention periods and whether the data was transferred abroad. If user profiles travel to an external service outside the country, that is a cross-border transfer, and its conditions are set out in Article 27-1 as amended by Law No. ZRU-1125 of 26 March 2026.
The technical answer is usually simple: events accumulate under an anonymised identifier, while name, phone number and address never reach the model at all — product selection does not need them. That lowers both the legal exposure and the damage from a leak.
The personal nature of a selection is also disclosed. A person should understand why they see these particular products and be able to browse the catalogue without personalisation.
We have no separate service called "recommender system" with a fixed price: it is part of a platform, and the cost depends on what has already been built. The nearest items from our service pages look like this.
The strongest influence on cost is the state of the catalogue: if attributes are empty and some products differ only by photograph, the work starts with putting the data in order. What each scope includes is described on our website development page, and the process review formats on our AI and automation page.
Syntra Systems starts with the catalogue and the events rather than with the choice of algorithm: we look at how products are described, what already reaches analytics and where a person gets lost while choosing. Content-based recommendations and fallbacks go first, while event collection is configured in parallel.
A behavioural model is added once there is enough accumulated history, and every block is compared with a storefront without personalisation. In the Syntra Health health marketplace the selection is built around a person's own indicators — the same principle: data and rules first, personalisation after. How similar mechanics work inside a mobile app is covered in our article on AI features in a mobile app.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
To start, a catalogue with well-defined attributes is enough: content-based recommendations work from product characteristics on day one. Behavioural models need accumulated history — thousands of events and months of observation — and are added on top of blocks that already run.
No. The same mechanics work in online stores, booking services, education platforms and B2B portals — anywhere with a catalogue and a choice among many options. The more items there are and the harder the choice, the more noticeable the effect.
It takes on the standard selection questions: it answers instantly and does not depend on working hours. A consultant stays for complex, unusual and contentious cases, and the share of enquiries reaching them is measured after launch as the marker of the effect.
What is popular in the category they landed in, plus new arrivals. After the first two or three actions the selection is refined from the current session even if the person is not signed in. Personal blocks are switched on later, once history has accumulated.
Split the traffic and compare a personalised storefront with a plain one on the same metrics: share of orders with a recommended product, average order value, catalogue coverage. Without that comparison, growth in sales can be explained equally well by the season or by advertising.
Bestsellers are the same for everyone and are counted from overall order statistics. Recommendations are assembled for a specific person or a specific product, so two users see different selections. Bestsellers remain a useful fallback all the same.
A name, phone number and address aren't needed at all to select products. Events are accumulated under an anonymised identifier and tied to an account only where order history requires it. That cuts down both the legal obligations and the damage if the data ever leaks.
