Addy 
Addly 
Goalify 
Monet 
Reviso 
Key takeaways
- Most ecommerce recommendation systems are collaborative filtering over order history, not language models. Understanding which one you have tells you what it can and cannot do.
- Below a few hundred orders per product, a hand-picked complement beats a learned recommendation because the sample is too small to separate pattern from noise.
- The real advantage of a learned system is maintenance, not accuracy on any given day. It keeps working when your catalogue and seasons move and a static list does not.
- Every recommendation system needs guardrails - margin floors, stock checks and category exclusions - because the model optimises for clicks and not for your P&L.
"AI-powered recommendations" is now standard copy on almost every merchandising app, which makes it close to meaningless as a differentiator. Underneath the label there are two or three distinct techniques with genuinely different behaviour, and knowing which one you are running tells you a lot about what to expect.
What is actually running
Collaborative filtering
The workhorse, and the technique behind the large majority of ecommerce recommendation systems.
The idea is simple: find products that co-occur in orders more often than chance predicts. If customers who buy A disproportionately also buy B, then B is a good recommendation for A.
The key statistic is lift:
lift = P(B | A) ÷ P(B)
A lift of 1.0 means no relationship. A lift of 3.0 means B is three times more likely to appear when A is present. Raw co-occurrence would rank your bestseller first for everything, because your bestseller appears in a large share of all orders; lift corrects for that.
Strengths: captures relationships nobody would think to encode. Improves automatically with volume. Requires no product metadata.
Weaknesses: cold start on new products. Reinforces existing patterns, so it under-promotes items nobody has discovered yet. Vulnerable to artefacts from past promotions.
Content-based filtering
Recommends products similar to the anchor based on attributes — category, tags, title, price band, sometimes image embeddings.
Strengths: works from day one with no order history. Handles new products.
Weaknesses: produces substitutes by construction. Similar things are alternatives, not complements. Used alone on a product page, this is the system that recommends a second pair of the same shoes.
Hybrid
Most good systems combine the two: collaborative filtering where there is enough data, content-based as a fallback for new or low-volume products, with rules layered on top.
Large language models
Rare for the selection step and usually the wrong tool for it. LLMs are excellent at generating descriptions, normalising messy product data and interpreting natural-language queries. They are not a natural fit for ranking products by purchase likelihood, which is a well-solved statistical problem.
If an app claims LLM-powered recommendations, it is worth asking which part of the pipeline the model is in.
When rules beat models
Worth being direct about this, because it is the opposite of how these systems are marketed.
Below a few hundred orders per product. With thirty orders containing product A, any pattern you find is noise. A human who knows the catalogue will pick a better complement than a model working from a sample that small.
For brand-new products. No history exists. Use the closest analogue product's pairings, or your own judgement.
Where margin varies wildly. An unconstrained model optimising for conversion will recommend whatever converts, which is often your cheapest, lowest-margin item.
Where relationships are obvious and stable. If your printer takes exactly one cartridge model, that is a rule. It does not need a model, and a model can only get it wrong.
Where inventory is constrained. Never let a model promote its way into a stockout on a component you need elsewhere.
Where models genuinely win
Maintenance at scale. A human can pick excellent pairs for fifty products. Nobody maintains accurate pairings for two thousand products through a season change. This is the real argument and it has nothing to do with per-product accuracy.
Non-obvious relationships. Every catalogue has pairs that make no categorical sense and convert extremely well. Only the data finds those.
Seasonal drift. The right complement in December is not the right one in June. A learned system tracks this; a static list requires someone to remember.
Per-visitor personalisation. Adjusting recommendations based on what this specific visitor has browsed is not something a static list can do at all.
The guardrails you have to add
A recommendation model optimises the objective it was given, which is almost never your actual objective. These constraints are configuration, not emergent behaviour.
Margin floor. Exclude anything below a minimum contribution margin from recommendation slots. The best-converting suggestion is frequently not the most profitable one.
Stock availability. Never recommend out-of-stock or low-stock items. Obvious, and violated constantly.
Category exclusion. Prevent substitutes from appearing next to the buy button. This single rule fixes the most visible failure mode of an unconstrained system.
Already-owned suppression. Do not recommend something the customer bought last week. For repeat-purchase consumables, this needs a replenishment-cycle exception rather than a blanket rule.
Price band. Cap the recommendation at a percentage of the anchor price — 15–40% is the working range for accessories.
Manual overrides. Always keep a way to pin or block a specific pairing. Merchandising judgement should be able to beat the model when it needs to.
Placement matters as much as the algorithm
The same recommendation engine performs completely differently depending on where its output appears.
| Placement | Recommendation type | Why |
|---|---|---|
| Product page, below buy button | Complements | Shopper is deciding; additions help, alternatives distract |
| Collection page | Similar / popular | Shopper is browsing; substitutes are useful here |
| Cart drawer | Complements, low price ratio | Decision made; only additive offers work |
| Add-to-cart popup | Single strong complement | One offer, maximum attention |
| Exit intent | Alternatives or reminders | They are leaving; a substitute might be why |
| Order confirmation | Complements or replenishment | Warm buyer, zero risk |
| Empty search results | Similar / popular | Anything relevant beats nothing |
Note that substitutes are genuinely correct in two of those rows. The rule is not "never show substitutes" — it is "never show substitutes next to a buy button".
Measuring recommendation quality
The trap here is measuring click-through rate, which rewards clickbait pairings that do not convert.
Better metrics:
- Attach rate — orders containing a recommended item ÷ sessions where recommendations were shown.
- Incremental attach — attach rate minus the baseline co-occurrence rate for that pair before recommendations existed. This is the honest number and it is always lower than the headline.
- Revenue per recommendation impression.
- Gross profit per recommendation impression, which catches the margin problem.
- Anchor add-to-cart rate. The guardrail. If recommendations are pulling attention from the main product, this drops.
The incremental figure is the one to defend. A widget showing a 30% attach rate on a pair that already co-occurred in 24% of orders has produced six points of value, not thirty.
A sensible adoption path
- Start manual. Two hand-picked complements per top product. Establish a baseline.
- Move to data-derived static pairs once you have 90 days of meaningful volume. Compute lift, filter substitutes, refresh quarterly.
- Add a learned system when refreshing quarterly always feels out of date — that is the signal your catalogue is moving faster than your process.
- Layer guardrails immediately, not later. Margin floor, stock check, category exclusion, price band.
- Keep the manual override. There will always be a pairing the model gets wrong and you can see is wrong.
The order matters. Stores that start at step 3 usually cannot tell whether the system is working, because they never established what "working" looked like without it.
Frequently asked questions
What does AI actually mean in a product recommendation app?
In most cases, collaborative filtering or a similar statistical model trained on order history - finding which products co-occur more often than chance would predict. Some systems add content-based signals from titles, tags and images. Very few use large language models, and where they do it is usually for describing products rather than for choosing them.
How much data do I need for AI recommendations to work?
Enough that co-occurrence patterns rise above noise. A few hundred orders containing a given product is a reasonable floor for that product to receive sensible recommendations. Below that, a manually chosen complement based on product knowledge will usually outperform the model.
Are AI recommendations better than manual ones?
Not necessarily better on any single product, but far better at scale and over time. A human can pick an excellent complement for one product. A human cannot maintain accurate pairings for two thousand products through a season change, and that is where a learned system earns its place.
Do AI recommendations respect margin?
Only if you tell them to. A model trained to maximise clicks or conversions will happily recommend your lowest-margin product. Margin floors, stock availability checks and category exclusions are configuration you have to supply, not behaviour that emerges from the model.
Can recommendations hurt the customer experience?
Yes, in two specific ways. Recommending substitutes rather than complements reopens a decision the shopper had already made. And recommending something they have just bought or already own is the most common visible failure of an unconstrained system.
