Recommendation Systems: The Right Product for Each Shopper, Proven in Revenue
The right products for each shopper, and proof they add revenue
Career figures, not model results. What your own recommender adds is shown by the audit and a live test against a control.
The Three Approaches, and Where Each One Fails
Every recommendation system is a ranking problem: put the best items first for one shopper, on one surface. The approaches differ in what evidence they use, and each fails in a predictable way. The approach is chosen by benchmarking on your own data, then built with advanced data science and supervised and reviewed by me.
Learns from what similar shoppers did
Great at finding non-obvious pairings. Weak on new customers and new products, which have no history yet.
Ranks by attributes and descriptions
Handles new products from day one, but tends to recommend more of the same.
Combines both signals into one ranking
What most real systems use: behaviour where it's strong, similarity where it isn't.
What Shoppers Do Says More Than What They Rate
Ratings are rare. Most of what a recommender learns from is behaviour: views, cart adds and purchases. That evidence is plentiful but has to be read carefully.
Ratings and reviews
State preference directly, but they're rare, patchy and skewed toward people with strong opinions.
Views, cart adds, purchases
A purchase is strong evidence. A product someone didn't buy is ambiguous (maybe they never saw it), so each signal gets a confidence weight.
Products that are never shown look unpopular. A recommender trained only on its own past suggestions keeps narrowing what it shows, unless that's corrected deliberately.
Where Recommendations Actually Appear
One ranking engine can feed every surface, so the logic stays consistent across site, email and ads. Clean product and event data flow is covered under Signal Engineering.
On-site & in-app
Product pages, cart cross-sell, category re-ranking, homepage. Highest volume; speed matters.
Email & lifecycle
Product blocks in your email tool, computed before send.
Paid media
Dynamic product ads and catalogue feeds, usually delivered as a feed.
Search & merchandising
Re-ranking search and category results. Often the highest-value surface, and the last one reached.
A business-rules layer sits on every list
Whatever the model ranks, these rules are applied before anything is shown:
Why a recommender that tests well can still lose money
A short walkthrough of reading offline results (top-k hit rate, catalogue coverage) and why the live test against a control is the one that decides.
Cold Start Decides the Whole Design
A recommender that only learns from history can’t serve anyone new, and on any given day many visitors are new or unrecognised. Handling that gracefully is what separates a working system from a demo.
New shopper, no history
Start with what's popular in their context (category, campaign, device, market), then personalise as signal arrives.
New product, no sales yet
Ranked by similarity to products that already sell, so new items can be recommended on day one.
Thin interaction data
Confidence weighting stops one coincidental purchase from dominating a product's recommendations.
Anonymous visitors
Ranked by what they're viewing right now. Often beats a weak long-term profile.
How Recommendation Quality Is Actually Measured
Recommenders produce ranked lists, so “accuracy” is the wrong frame. Quality is checked in two layers: offline on past data first, then online against a control group, which is the one that decides.
Clicks on items people were going to buy anyway get counted as wins. Looks impressive, proves little.
The gap between the two is the only honest measure of what the recommender added. Shape only, not a promised result.
Offline: top-k hit rate
Of the top few items shown, how many did shoppers engage with, scored on a later period the model never saw.
Offline: position matters
A good item at position 1 counts for more than the same item at position 8.
Online: extra revenue
A live A/B test against a control. The decisive number is revenue per session, not widget clicks.
Coverage
How much of your catalogue the system ever recommends. Low coverage means a hidden bestseller list.
Diversity
How varied the items are within one list. Five near-identical products waste four slots.
Three Ways a Good-Looking Recommender Loses Money
All three look like success on a dashboard. All three are caught only by measuring against a control and watching coverage over time.
Cannibalisation
The widget recommends products shoppers were already buying. Clicks rise; revenue doesn't. Only a control group catches it.
Popularity bias
Popular items get recommended, which earns them more clicks, which gets them recommended more: an automated bestseller list.
The narrowing loop
Similar suggestions reinforce themselves and shrink discovery, so basket size quietly plateaus.
All three have one remedy: deliberately showing some less-certain recommendations so the system keeps learning. That costs a little revenue in the short term, so the budget for it is agreed explicitly, not hidden.
Store Apps, Cloud Services or a Custom Recommender?
For many stores, a platform app is the honest answer, and the audit will say so. A custom recommender, built on your raw data with advanced data science and supervised by me, earns its cost when margin or stock must sit inside the ranking, when the same logic must run across site, email and ads, when the catalogue is unusual, or when you need to explain every recommendation.
| Store recommendation apps | Managed cloud services | DIY with open-source tools | Custom model (Cognitive Intelligence) | |
|---|---|---|---|---|
| What you get | Working recommendations in days, at app pricing | Production APIs and cold-start handling, no infrastructure | Full control, if you have the team | Approaches benchmarked on your catalogue, coverage and diversity tracked, live revenue test |
| Margin & stock in ranking | Limited | Limited, logic largely hidden | Whatever you build | Built into the ranking itself |
| Same logic on site, email, ads | Storefront only | Partly | If you build it | Yes, one engine for every surface |
| Where it stops | Little control over ranking | Cost grows with traffic; opaque | You own speed, retraining, monitoring | Needs enough interaction volume |
| Model ownership | Vendor | Hosted | Yours | Yours: code, model and outputs |
| Who reviews it | Nobody | Nobody | Your data team | Me, at every retrain |
Segmentation Sits Underneath Recommendations, Not Inside
Customer segmentation and recommendations are often confused. They work together, but they answer different questions.
Where they connect
A shopper's segment can be an input to the recommender and a fallback when individual signal is thin. Segments also shape the campaign and offer around the recommendations.
Where they stay separate
Segments can't pick products for one person, and a recommender can't decide where retention budget goes.
What Data a Recommender Needs
Interaction volume matters more than the number of customers. A big audience that rarely clicks or buys gives the model little to learn from.
Interaction events
Views, cart adds and purchases, with a customer or session ID, product ID and timestamp.
Catalogue details
Category, brand, price, attributes and descriptions. Thin catalogue data is the most common blocker, and usually fixable.
Identity that persists
Recognising returning shoppers across sessions and devices. Guest checkout breaks repeat-behaviour signal.
A catalogue small enough to browse in full needs good merchandising, not a recommender. And if most buyers purchase only once, the first problem to solve is customer lifetime value.
Who Recommendation Systems Are Built For (and Not For)
It pays off where shoppers can’t easily find what they’d buy, and where you can prove the lift with a live test.
Good fit
- Large or fast-moving catalogues where discovery is the bottleneck
- Repeat-purchase categories: beauty, supplements, grocery, fashion
- Brands that outgrew store apps on ranking control or margin
- Multi-surface operations needing one logic across site, email and ads
- Teams willing to run a real A/B test
- Marketplaces and publishers, where new items arrive constantly
Not a fit yet
- A catalogue small enough to browse fully
- Mostly one-time buyers
- Too little traffic for a live test
- A store app already doing the job
Where AI Agents Fit Into Recommendations
A SaaS tool is someone else’s generic model. An AI agent is your own model, kept running: retraining on schedule, keeping stock in sync and catching the slow failures that turn a recommender into a bestseller list. The agents are autonomous, built from data science and marketing work, and every action is reviewed. More on the AI agents hub.
What the agents watch
- Flags coverage collapse, when recommendations quietly shrink to a few bestsellers
- Spots catalogue drift: new ranges, discontinued lines, price changes the model hasn't caught up with
- Watches offline vs live results, so a model that tests well but sells poorly is caught early
- Checks every retrain: evaluation, coverage and diversity floors, and business rules, before lists go live
What stays with a person
- Setting the exploration budget. How much short-term revenue to spend on learning.
- Deciding what the recommender may do. Exclusions, margin vs relevance, cross-sell limits.
- Judging whether a lift is real. Or just noise in a short test.
- Calling it off. If the extra revenue doesn't justify the system, someone has to say so.
Recommendation Systems: Frequently Asked Questions
What is a recommendation system?
A recommendation system ranks products for a specific shopper on a specific surface (product page, cart, email, ad feed) based on behaviour and product details.
What's the difference between the approaches?
Behaviour-based learns from what similar shoppers did but can’t serve new products or people; similarity-based handles new products but narrows. Blended systems combine both.
How is a recommender evaluated?
Offline on a later period it never saw (top-k hit rate, position, coverage, diversity), then online in an A/B test against a control on revenue per session.
Why measure extra revenue instead of clicks?
Because widgets get clicks on sales that would have happened anyway. Only a control group shows what the recommender actually added.
What is cold start?
New shoppers and new products have no history. It’s handled with product similarity, popularity in context and ranking by the current session.
Do you use a recommendation tool or platform?
No. Each recommender is custom-built on your raw data with advanced data science, benchmarked on your catalogue, and supervised and reviewed by me at every retrain. You own the model, the code and the outputs.
Will it just recommend the same popular products to everyone?
Left alone, yes. Coverage monitoring, diversity limits and an agreed exploration budget stop that.
How much data is needed?
Enough interactions and repeat behaviour, plus decent catalogue details and a way to recognise returning shoppers. Interaction volume matters more than customer count.
Do you work with brands outside Pakistan?
Yes. Delivery is remote from Lahore, for brands across Pakistan, the UK, USA, UAE, Canada and Turkey, with each model fitted per market.
AI-driven digital marketing intelligence consultant. 12+ years in digital marketing, 100+ clients across 15 industries and 6 markets, a Master's in Computer Science and MPhil / MS Data Science (AI). Every recommender is built, checked and reviewed by me personally, with no hand-off to an account manager.
Where to Go Next
Find Out Whether You Need a Custom Recommender at All
A data audit checks your catalogue, interaction volume and customer identity, and tells you plainly whether a custom model is justified, including when a store app is the better choice.