An AI recommendation system selects and ranks products, services or content for a particular person or situation. In an online shop, it can suggest similar, complementary or otherwise relevant products based on observed interest. Its central function is choosing from an existing catalogue. For a business owner, the project starts with where the recommendation appears, which data is available and how its usefulness will be evaluated.
Recommendations need a precise commercial question
“Which products should appear beside this item?” and “which products should this user see on the homepage?” are different tasks. The first can use features of the viewed item, including within an anonymous session. The second can use available history and the person's preferences. This choice affects required data, behaviour for new visitors and application response time.
For a small catalogue, a team-maintained list of complementary products can be an appropriate starting point. Evaluate a model against this option and other simple references, such as category popularity. Complexity is justified through improvements measured where recommendations are used, under the same display and evaluation conditions.
Two important families: content and collective behaviour
Content-based filtering compares product features with known preferences: category, material, dimensions, use or other relevant attributes. It can recommend a new product when its description is available, even before the product has interactions. Quality depends on how these features are defined and populated.
Collaborative filtering uses relationships within users' interactions with products. Declared ratings are explicit feedback; views or purchases are implicit signals that require contextual interpretation. A missing interaction does not automatically mean rejection: the person may not have seen the product, or it may have been unavailable at the time.
| Option | Main data | Situation to address |
|---|---|---|
| Content-based | Attributes and preferences | Incomplete descriptions or overly narrow similarities |
| Collaborative | Interaction history | Users and items without history |
| Hybrid | Multiple candidate sources | Comparable scores and consistent filtering |
Reading a user–item matrix
In the demonstrative example, user u1 has interacted with products A and B. User u2 has interacted with A, B and C. Modelling can use these similarities to propose C as a candidate for u1. The question mark in the matrix represents an unobserved interaction, rather than a negative rating.
Shared interactions suggest a candidate
The drawing explains the collaborative idea and does not calculate a purchase probability. Two shared preferences in such a small example are insufficient to claim that C is the best real recommendation. In a project, the model is trained and evaluated on representative data, and the candidate must also pass the shop's operational conditions.
From candidates to the list displayed on the page
A practical architecture separates candidate generation, scoring and final re-ranking. The first stage narrows the catalogue to a relevant set. The second compares candidates for the chosen objective. The last can remove unavailable products and address diversity, freshness or other experience requirements. Rules and the model have distinct responsibilities within this chain.
Three stages before a recommendation is displayed
- 1. Candidates
Gather relevant catalogue items from content similarity, interactions or a managed list.
- 2. Scores and ordering
Compare items for the chosen objective. Treat scores from different sources consistently before ranking.
- 3. Eligibility and diversity
Check availability and compatibility; apply variety rules and the number of interface positions.
Stock and compatibility can be mandatory conditions, rather than merely signals that slightly adjust a score. An accessory incompatible with the viewed product, for example, must be removed from an accessory list even if it received many clicks in other contexts. Identifiers, variants and catalogue updates need to be synchronised before evaluating a new algorithm's effect.
If the interface explains a recommendation with “compatible with the selected product” or “frequently bought together”, that reason must be supported by the catalogue relationship or interactions actually used. The AI recommendation’s explanation should be checked separately from the list’s ranking. Persuasive commercial wording does not correct a mistaken product association.
Handling customers or products without history
The problem of starting without data, called cold start, is addressed explicitly. A new visitor can receive recommendations based on the current page, selected preferences or relevant popularity. A new product can enter through its attributes and eligibility rules. The interface should not display an empty list simply because a learned profile does not yet exist.
The history being used needs defined events and clear retention periods. Viewing, adding to a basket, purchasing and returning have different meanings. Also separate actual recommendation impressions from the page merely loading. This enables correct click-through-rate calculations and investigation of the position in which each product was seen.
Click-through rate, or CTR, is calculated by dividing clicks on recommendations by the recorded impressions of those recommendations and expressing the result as a percentage. Keep the impression definition identical when comparing variants: a product visible on screen is a different event from a recommendation loaded farther down a page that the person never reached.
What to measure before extending recommendations
Offline evaluation checks ranking against held-out interactions and respects time order, so future data does not enter training. In production, an experiment can compare the new list with the existing version. Track clicks, orders, business-relevant value and subsequent behaviours specified in the evaluation plan for the same period.
Evaluating the shop module
- Reference
Retain the current list or a simple rule. Define the same display area and events for comparison.
- Measurement
Record actual impressions, clicks and orders as defined in the plan. Separate results by test period and population.
- Commercial checks
Check unavailable items, variety, catalogue coverage and the fallback list. Also measure response time.
Click-through rate alone can favour attention-grabbing products that do not adequately meet the need. Catalogue coverage describes how many eligible products reach recommendations, while diversity describes list variety according to the selected criteria. Report these measurements together with response time and situations in which a fallback list was used.
WebHat can integrate a recommendation engine into custom applications with AI integration, connecting the catalogue, events and display rules. Consultancy can define a first module — for example, complementary products in one shop area — with a reference version, measurable events and an owner responsible for product administration.
Questions about recommendation systems
Does a recommendation system generate new products?
The function described here selects existing items. Generative models can have additional roles, such as describing the list, while product eligibility remains checked separately.
Is a user account required?
Recommendations can use the current page or session. History-based personalisation requires identifiers and data available under the conditions established for the application.
Is grouping customers the same thing?
Segmentation forms groups; recommendation selects and ranks items for a context. Segments can serve as a signal within a recommendation system.
What should happen when the model does not respond?
Provide a valid fallback list containing eligible, available products and record the event. The list and waiting time are established within the project.
