Recommendation Engines for Products and Content

When a company needs its own recommendations

Recommendations solve a discovery problem: nobody browses ten thousand products or an entire article archive. A custom engine makes sense for online shops and B2B wholesalers with large catalogues, marketplaces matching buyers and sellers, content and course platforms, classifieds sites and comparison services. In B2B the goal is often suggesting reorder items based on a customer's history.

To be candid: with a small catalogue and modest traffic, an off-the-shelf add-on for your shop platform or a few hand-set rules will do better. A custom solution starts paying off when event volume is high enough to measure impact, when recommendations must respect specific rules (margin, availability, supplier agreements), when data has to stay on your infrastructure, or when ready-made tools do not fit the business model, such as two-sided matching.

Recommendation types and where they appear

• similar items on the product page – based on attributes, descriptions and images;
• frequently bought together in the basket – based on co-occurrence in orders;
• personalised ranking of the home page or category – based on the user's history;
• session-based recommendations for anonymous visitors – based on their last few clicks;
• search result re-ranking that takes preferences into account;
• next best offer in email or CRM;
• two-sided matching on a marketplace – buyers to sellers, jobs to contractors.

The first version usually covers one or two placements where impact is easiest to measure.

Data: events, catalogue and consent

Recommendation quality depends on behavioural data: impressions, clicks, add-to-basket events, purchases, returns, reading time. We design an event schema with session and user identifiers, context (page, list position) and a flag showing whether the item was a recommendation – without it, impact cannot be measured later. From the catalogue we need attributes, categories, prices, stock levels and dates added.

Part of discovery is checking whether the data is usable: bot traffic, duplicate products, tracking gaps after a cookie banner change. Historical data can come from a data warehouse, an analytics tool or the shop database, with ETL pipelines handling the flow.

Algorithms and architecture

We start with a baseline: category popularity, order co-occurrence, simple rules. A more complex model has to beat it in testing, or it is not worth the maintenance cost. Depending on the data, next steps include matrix factorisation for interaction data, product embeddings from descriptions and images (useful for new items), session-based models and, finally, a gradient-boosted ranker that combines many signals.

The architecture typically has two stages – candidate generation and ranking – plus a business rules layer. Recommendations for fixed placements are computed in batches and cached (e.g. in Redis), while real-time personalisation runs through an API with a latency budget written into the specification. The shop integrates through a REST API or a front-end component; the service itself is usually written in Python, regardless of the platform's own stack.

Business rules and control over results

Your commercial team needs a say in what customers see. The admin panel lets them:

• exclude unavailable, discontinued or restricted products;
• boost or pin selected items for a campaign;
• factor in margin, stock levels and supplier agreements;
• enforce diversity so a list is not five variants of the same thing;
• preview recommendations as a chosen user would see them, with an explanation such as “because you viewed…”.

Offline evaluation and A/B testing

Before launch the model is evaluated on historical data with a time-based split: it learns from an earlier period and is tested on a later one. We measure precision@k, NDCG, catalogue coverage and diversity, among others. The offline result is only a filter, though – the decision comes from an A/B test on live traffic with a business metric agreed up front (conversion, revenue per session, basket value) and guardrail metrics such as return rate. We also watch for the feedback loop in which popular products keep getting more popular at the expense of the rest of the catalogue.

Mistakes we rule out in the specification

• recommending a product the customer has just bought, or an article they have already read;
• showing items that are out of stock or have long delivery times;
• the same products in every placement on the page, which teaches users to ignore recommendations;
• no record of what the user actually saw – without it, impact cannot be counted fairly;
• optimising for clicks alone, which promotes eye-catching but rarely purchased items.

Each of these points is reflected in the rules, the event schema or the metrics set out in the specification.

Profiling, consent and transparency

Personalisation based on user behaviour is profiling under the GDPR. Browser tracking generally requires consent under EU ePrivacy rules, and users should be able to object. We design for a minimal data set, exclusion of sensitive categories and a non-personalised fallback for users who have not consented. The Digital Services Act requires online platforms to set out the main parameters of their recommender systems in their terms and conditions. If recommendations affect employment, credit or access to essential services, a separate legal assessment is needed, including under the AI Act – we do not give legal advice, but we flag such points in the specification.

Project flow and budget

The project moves through data and objective analysis, specification (placements, metrics, rules, test plan), component design, iterative build, offline evaluation, A/B testing, launch and maintenance with quality monitoring. A pilot for one placement on existing data starts from $2,900. Costs rise when event tracking must be built first, when there are more placements and channels, or when real-time personalisation or an extensive rules panel is needed. Compute resources and A/B testing tools are billed separately. Pricing principles are on the pricing page, and other services in the AI software development category.

Client inputs

• an export of event and order history from recent months;
• a catalogue feed or product API access;
• merchandising rules and exclusion lists;
• a metric owner and agreement to A/B test on part of the traffic.

Recommendations often work hand in hand with search – see search and comparison platforms and e-commerce platforms. Send a description of your goal and available data via the contact page.

Related services

Frequently asked questions