You have 180 products and about 40 orders a month. Somewhere in your admin there is a switch labelled "related products", and turning it on fills the bottom of every page with things nobody is going to buy. The recommendations are not wrong exactly. They are just arbitrary, and shoppers can tell.
This is the ordinary situation for a small shop, and almost everything written about recommendation engines assumes the opposite one. The techniques that made recommendations famous were built at a scale where every product has thousands of purchase records behind it. At 40 orders a month you are not running a small version of that. You are running a different problem.
- Collaborative filtering needs purchase overlap between items. Below a few hundred orders per product, there is nothing for it to find.
- The item to item method Amazon published in 2003 works on a relative measure, not raw popularity, which is why bestsellers do not swallow every slot.
- Research testing a general chat model as a recommender found it strong at re ranking and cold start, weaker than specialised systems at general top N recommendation.
- McKinsey puts personalisation revenue lift at 5 to 15 percent, a figure drawn from large programmes and not a promise for a 180 product catalogue.
- Manual rules on a curated catalogue beat a weak model, and you should measure against showing nothing at all.
So the useful question is not which algorithm to pick. It is what you already know about your own products that a shopper does not, and how to put that in front of them at the moment it helps.
What does a recommender actually need to work?
Overlap. Specifically, enough customers who bought both item A and item B for the pair to mean something rather than being a coincidence between two people.
The method that made this famous is worth understanding precisely, because its logic explains the limit. Amazon's item to item collaborative filtering, described in Amazon Science's own account of the algorithm, treats item B as related to item A if purchasers of A are more likely to buy B than the average customer is. The greater that probability difference, the stronger the link. That relative framing is the clever part: it stops the bestseller appearing beside everything, because the bestseller is already likely for everyone.
Now apply it to your shop. If a product has six purchases, the "customers who bought this also bought" set is six people's baskets. One person buying two unrelated things creates a permanent, confident, wrong recommendation. The maths has not failed. You simply asked it a question your data cannot answer.
What works at each size of shop
The honest answer changes with your order volume, and the change is not gradual. There are roughly four stages, and each one unlocks a different technique rather than a better version of the last.
| Where you are | What actually works | What to avoid |
|---|---|---|
| Under 100 orders total | Hand written pairs on your top 20 products | Anything automatic, it is noise |
| A few hundred orders | Category and attribute rules, plus complements you define | Collaborative filtering on purchase pairs |
| Steady traffic, thin purchase data | Session behaviour, what this visitor viewed in this visit | Cross customer personalisation |
| Thousands of orders per year | Co purchase signals start to hold, tested against a rule baseline | Assuming the model beat the rules without checking |
The first row is the one people skip because it feels unsophisticated. It is also the row where the return on an hour of work is highest. You know that the small jug goes with the teapot and that nobody has ever bought the replacement filter without the machine. Writing twenty of those pairs down takes an afternoon and beats any model you could train on 40 orders.
Can you just ask a language model instead?
For some jobs, yes, and the research is more specific than the marketing. A rigorous evaluation of a general chat model as a recommender, published as Evaluating ChatGPT as a Recommender System, tested it across movies, music and books and found it excels at re ranking and in cold start situations while underperforming established systems on general top N recommendation.
Read that as a job description rather than a verdict. A model given your catalogue text is good at answering "given these forty candidates, which three suit somebody looking at this item" and good at the case where you have no history at all. It is not the thing that decides what the forty candidates should be, and the same study noted the need for post processing to handle invented or duplicated suggestions.
The practical shape that falls out of this: use rules or attributes to fetch candidates from your own catalogue, then let a model order them and write the reason line. That keeps every recommendation inside products you actually stock, which is the failure mode that embarrasses shops who let a model generate the list directly.
Where should a recommendation appear?
In three places, and they want three different things. The product page wants complements, the basket wants small additions, and the post purchase email wants the next purchase rather than this one.
On the product page, similar items compete with the thing the shopper is already looking at. If somebody is reading about a specific chair, five other chairs is a way of restarting their decision. Complements move the basket up without reopening the choice. This is the same reasoning behind writing product pages that answer a question rather than listing attributes, which we covered in how assistants and shoppers read a product page differently.
In the basket, the constraint is price. An addition worth roughly a tenth of the basket total gets added without new deliberation. Something worth half of it becomes a second decision, and second decisions are where carts get abandoned.
After purchase, you finally have the one signal that is reliable at small scale: this person bought this thing. Consumables have a refill interval, complements have an obvious next step, and both are better handled in an email than on a page. That timing question is the whole subject of which stage of an email programme AI actually improves.
Recommend from stock you want to move, not only from stock that sells itself. A recommendation slot is inventory management with a nicer name, and pointing it at slow moving items with healthy margin is usually worth more than a marginal accuracy gain.
How do you know whether it worked?
By comparing against showing nothing, not by counting clicks on the widget. A recommendation that gets clicked and replaces a purchase the customer would have made anyway has added zero and cost you the margin difference.
The measurement most shops run is attribution: revenue from sessions that touched a recommendation. It flatters every system ever installed, because the customers most likely to buy are also the most likely to browse. The comparison that means something is a holdout, where some visitors see the block and some do not, and you compare revenue per session across the two groups.
A holdout test is simpler to run than it sounds. Split visitors by a stable hash of their session identifier, show the block to one group, hide it from the other, and record revenue per session for each. No statistical machinery is needed to see a difference of any size worth acting on, and the split costs you nothing except the recommendations you did not show to half your traffic.
At 40 orders a month a holdout takes months to say anything, which is a real constraint rather than an excuse to skip it. In that case measure something coarser and honest: average order value and units per order, tracked before and after, with a note of everything else you changed that month. It is weak evidence. It is still evidence, and it beats a dashboard that only reports its own success.
Your site search is a recommender you already run
Every query typed into your search box is a customer telling you what they expected to find. Most shops treat that log as a debugging tool and never read it, which wastes the cleanest intent signal in the building and hides the fact that most ecommerce search boxes fail the queries people actually type.
Two things fall out of it immediately. Searches that return nothing are either a gap in your catalogue or a gap in your vocabulary, and the difference is usually obvious when you read fifty of them. Somebody searching for a term you do not use for a product you do sell is a naming problem you can fix in an afternoon, and fixing it improves ecommerce product recommendations everywhere else too, because the same words feed attribute matching.
Searches that return results but no clicks are the more interesting category. They mean your listing text did not convince at the point of comparison, and no recommendation block will rescue a product whose own page does not land.
Feed the search log back into your pairs. If people who search for one term frequently end up buying a product filed under a different one, that is a relationship your category tree does not encode and your recommendations should.
What personalisation is actually worth
The widely quoted numbers come from large programmes, and they are worth reading with the source attached. McKinsey's explainer on personalisation states that it can lift revenues by 5 to 15 percent, increase marketing return on investment by 10 to 30 percent, and cut customer acquisition cost by as much as half, and reports that faster growing companies derive 40 percent more of their revenue from personalisation than slower growing ones.
Those are averages across organisations running personalisation as a programme, with data teams and testing infrastructure behind them. The mechanism that produces a 5 to 15 percent lift at that scale is not available to a shop with 180 products, and quoting it in a business plan is how a small seller ends up disappointed by a perfectly functional widget.
What does transfer is the direction. Showing a shopper something relevant to what they are already doing beats showing them a static block, and the effect is real even when it is small. Take the direction, leave the percentage.
What happens when the recommender is not yours?
Increasingly the first recommendation a shopper sees is made somewhere you do not control, inside an assistant that read your product page and decided whether to mention you. That shifts part of the job from ranking your own catalogue to being legible to something else's ranking.
The practical consequence is unglamorous. Structured attributes, plain descriptions of who a product is for, explicit statements of what it works with, and a clear price and availability. A model summarising a category cannot infer a complement relationship from a lifestyle photograph, so anything you know about what goes with what should exist as text somewhere on the page rather than only in your own recommendation database.
This does not replace on site recommendations. It changes what they are competing with. A shopper who arrives already told what to buy is further down the decision than one browsing, and the useful block for them is confirmation and accessories rather than alternatives.
The mistakes that cost the most
Four, in rough order of how often they happen.
Recommending things you cannot ship. Out of stock items in a recommendation block are worse than an empty block, because they create a want you then refuse. Filter on availability before anything else, every time.
Recommending near duplicates. Five variants of the same product read as a system that has not understood the question. If your catalogue has deep variants, deduplicate at the parent product level before ranking.
Letting a model invent products. If a model writes the list rather than ordering a list you supplied, it will eventually recommend something you have never sold. Constrain it to identifiers from your own catalogue and validate the output against your database before rendering.
Leaving it on forever without looking. Recommendations drift as your catalogue changes, and nobody notices because the block always looks populated. Put a monthly reminder to read what it is actually showing on your five most visited products. Reading what your customers say about those products, which we went into in what review analysis picks up and what it misses, will usually explain any pairing that looks wrong.
A worked example on twenty pairs
Suppose you sell kitchen equipment: 180 products, a handful of categories, 40 orders a month. Here is the whole exercise, start to finish, in about two hours.
Pull your twenty best selling products. For each, write down what a person who bought it needs next, using nothing but your own knowledge of the goods. The teapot takes the strainer. The grinder takes the brush and the spare burr. The pan takes the lid that fits it, and only that lid, which is precisely the fact your attribute matching cannot work out on its own.
Now check each pair against your order history. Some will be confirmed, some will surprise you, and a few will be flatly contradicted, which is the most valuable outcome because it means your assumption about how the product is used is wrong. That is worth more than the recommendation itself.
Add a fallback for the other 160 products: same category, in stock, closest price tier. It will be mediocre and it will be better than an empty block. Then set a reminder for three months, when you will have another 120 orders and a slightly better picture.
The reason this beats installing something is not cost. It is that the twenty pairs encode why, and a similarity score does not. When one stops working you will know which assumption changed.
Where to start on Monday
Open your order history and sort by items that appear in the same basket. If a pair appears three or more times, write it down. That list, however short, is your first recommendation set, and it is built from evidence about your own customers rather than an average of somebody else's.
Then fill the gaps with attributes: same collection, same material, same use, one price tier up. Add availability and margin as filters. Only when a product has enough purchase history for co purchase counts to be stable should you consider letting something automatic take over, and even then, keep the manual pairs for your top sellers because they encode knowledge no model has. Working from your own order table this way also sits on the easier side of the line between personalisation that needs consent and personalisation that does not.
All of this lives in your storefront code rather than in a vendor's settings screen, which matters the day you want to change the ranking rule or add a margin filter. Building on a store whose code and data stay in your own hands is what keeps a recommendation rule a fifteen minute edit instead of a support ticket. The engine is not the hard part. Knowing your own catalogue is, and you already do.