Recommendation Engine Development
A recommender tuned to the objective you actually care about, with cold start and business rules handled properly, and every offline improvement confirmed by an online test before anyone claims it.
Recommendation is the area of machine learning where offline metrics most reliably mislead. A model can win convincingly on historical data and lose money in production, because the historical data records what your current system showed people, not what they would have chosen from anything else.
Recommendation engine development is the building of a system that selects and ranks items for a specific user and context: learning from interaction history, handling users and items without history, applying business rules and diversity constraints, serving results within a latency budget, and being evaluated by online experiment rather than by offline score alone.
Decide what you are optimising before you build
Recommenders optimise what you tell them to, faithfully and sometimes destructively. The objective has to be chosen deliberately:
| Objective | What it produces | The failure mode |
|---|---|---|
| Click-through | Attention-grabbing items | Clickbait, and revenue that does not follow |
| Immediate conversion | Safe, popular, cheap items | The catalogue narrows to the same few products |
| Revenue or margin | Commercially sensible ranking | Can suppress discovery and long-tail sales |
| Retention or repeat visit | Genuinely useful recommendations | Slow to measure, needs patience |
| Blended with constraints | The usual practical answer | Requires explicit weights and periodic review |
Most production systems end up blending an engagement objective with a commercial one and applying hard business rules on top. Making those weights explicit and reviewable is part of the engagement, because they will need to change.
How we build a recommender
Popularity is the baseline, and it is a strong one
A well-constructed popularity or recency baseline, segmented sensibly, is harder to beat than most teams expect. It is the bar every model is measured against, and it is also the fallback when personalisation is unavailable.
Retrieve then rank
A fast candidate generation stage narrows thousands of items to a few hundred, then a ranking model orders them with richer features. This two-stage design is what makes personalisation possible inside a latency budget, and it separates the recall problem from the precision problem cleanly.
Solve cold start explicitly
New users, new items and new sessions are the majority of traffic in many businesses, and a model trained on interaction history has nothing to say about them. Content-based features, attribute similarity and sensible defaults are designed in from the start rather than bolted on when the launch reveals the gap.
Enforce business rules as constraints
Stock availability, margin floors, contractual placements, regional restrictions, age gating and brand adjacency rules belong in the serving layer, not in the model's objective. Attempting to teach a model your commercial policy produces neither good recommendations nor reliable compliance.
Design for diversity and feedback loops
A recommender trained on its own outputs narrows relentlessly: it shows popular items, which get more interactions, which makes them more popular. Diversity constraints and a small share of exploration traffic keep the catalogue alive and keep the training data from collapsing in on itself.
Prove it online
Every change ships behind an A/B test measured on the business objective, with a guardrail on the metrics you are not optimising. Offline evaluation is used to decide what is worth testing, never to declare a win.
Log what was shown, not just what was clicked
Without impression logs there is no way to know what a user chose not to click, which cripples both training and evaluation. If you are not logging impressions with position and context today, starting immediately is the highest-return change available, regardless of who builds the recommender.
Where recommenders earn their place
- E-commerce. Product discovery, complementary items at basket, and personalised category ordering.
- Media and publishing. Next-item and feed ranking where catalogue depth exceeds what anyone can browse.
- Marketplaces. Matching supply and demand, where diversity and fairness across sellers matter commercially.
- B2B and services. Next best action and cross-sell, usually with a small catalogue and rich account features.
- Internal. Content, learning or task recommendations inside your own product.
The economics differ sharply: a large catalogue with sparse interactions needs different design from a small catalogue with dense ones, and we establish which you have before choosing an approach.
How the engagement runs
Offline work decides what to test; the online test decides what ships.
Objective and data audit
Objective and guardrail metrics agreed, interaction and impression logging assessed, popularity baseline measured.
Candidate generation
Retrieval stage built and evaluated on recall, with cold-start paths designed for new users and items.
Ranking and constraints
Ranking model trained, business rules and diversity applied in the serving layer, latency budget met.
Online experiment
A/B test against the current system on the business objective with guardrails, run to significance.
Rollout and handover
Staged rollout, exploration traffic configured, monitoring and retraining handed over.
What you receive
A recommender proven online, with the levers to keep steering it commercially.
Serving system
Candidate generation and ranking within your latency budget, deployed as infrastructure as code.
Cold-start handling
Defined behaviour for new users, new items and anonymous sessions, with measured quality.
Business rules layer
Availability, margin, contractual and compliance constraints enforced at serving time.
Experiment results
A/B test on the business objective with guardrail metrics and the decision rationale.
Diversity and exploration
Constraints and exploration share configured, with the effect on catalogue coverage measured.
Monitoring and retraining
Coverage, latency, objective drift and the retraining schedule, handed over with runbooks.
Is this the right engagement?
Worth being direct. Recommendation Engine Development is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Your catalogue is larger than a customer can reasonably browse.
- You log interactions, and ideally impressions with position.
- You can run an A/B test and wait for it to reach significance.
- There is a clear business objective and someone to own the trade-offs.
- Commercial rules exist and can be written down.
Choose something else if
- The catalogue is small enough that a curated ordering is better and cheaper.
- Traffic is too low for an online test to conclude anything.
- No interaction history exists and cold start is the entire problem.
- Nobody can decide what the system should optimise for.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How much interaction data do we need for a recommendation engine?
Enough that users and items have repeat interactions, which matters more than raw volume. Sparse data with millions of one-time visitors and no repeat behaviour is a cold-start problem in disguise, and it is better solved with content and attribute features than with collaborative methods.
Why do offline improvements not always show up in production?
Because your historical data records what your current system showed people, not what they would have chosen from a different set. Offline evaluation is biased by that exposure, which is why we use it to decide what is worth testing and rely on online experiments to decide what ships.
How do you handle new products with no history?
With content and attribute-based similarity, sensible defaults and a share of exploration traffic so new items get an opportunity to be seen. Cold start is designed in from the beginning because in most catalogues it is a permanent condition rather than a launch problem.
Can we enforce commercial rules like margin or availability?
Yes, and they belong in the serving layer as hard constraints rather than in the model's objective. Trying to teach a model your commercial policy produces neither reliable compliance nor good recommendations.
Will it just keep showing the same popular items?
That is the default failure and we design against it with diversity constraints and exploration traffic. A recommender trained purely on its own outputs narrows the catalogue over time, and the effect is gradual enough that it is often noticed only in the long-tail sales figures months later.
Often paired with this
Most clients combine two or three engagements from the Machine Learning & Predictive Analytics pillar. These are the ones that most often run immediately before or after.
Customer Segmentation and Propensity Scoring
Segments that map to actions and propensity scores per offer, activated in your marketing platform.
Read more →Predictive Analytics
Predictions embedded in the decisions they are meant to improve, measured on the business outcome rather than on AUC.
Read more →Dynamic Pricing Optimisation
Prices moved on measured elasticity, inside guardrails, proven by controlled experiment rather than by simulation.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.