Every store has a version of recommendations, even if it is only a row of “you may also like” products chosen by a theme. The question is whether a better version would earn more, and at what cost. The answer depends on your traffic, your catalogue and your patience for testing, and it is rarely the one a vendor’s demonstration implies.
This guide explains the main approaches in plain language, what each needs from your data, where recommendations are most useful, and how to test them honestly. It connects to our guides on AI in ecommerce examples and RFM segmentation, which provide the customer side of the picture.
The main approaches
| Approach | How it chooses | Data needed | Best for |
|---|---|---|---|
| Manual rules | You pick related products or set rules by category | Product knowledge | Small catalogues, launch |
| Same collection or tag | Shows products that share attributes | Clean tags and collections | Browsing within a range |
| Bought together | Counts products often in the same order | Order history | Cart and product page add-ons |
| Best sellers by segment | Shows what sells for a group | Orders plus customer segments | Homepage and emails |
| Collaborative filtering | People like you bought these | Many users and orders | Larger catalogues with traffic |
| Content-based models | Compares product text, images and attributes | Rich product data | New products with little history |
| Hybrid and learning-to-rank | Combines signals and learns from clicks and purchases | High volume | Large stores |
The last rows sound more impressive, and they can be, but they are data hungry. A model learns from patterns across many shoppers. A store with a few hundred orders a month has too little to find reliable patterns for most products, and the model will fall back on popularity, which you could have done in an afternoon.
Where recommendations earn money
| Placement | Goal | Good approach |
|---|---|---|
| Product page | Alternatives and add-ons | Same collection plus bought together |
| Cart | Small, low-friction add-ons | Bought together, filtered by price |
| Post-purchase page and email | Second order | Complements to what was bought; see post-purchase flow |
| Homepage | Discovery | Best sellers, or by segment for returning visitors |
| Search no-results page | Rescue | Popular products and related categories |
| Abandoned-cart and browse emails | Bring back | Viewed or similar items; see browse abandonment |
Cart and post-purchase placements tend to be the most dependable for add-ons, because the shopper has already decided to buy. The homepage is the hardest to get right, because you know little about the visitor. A product page recommendation should answer a different question from the cart: “is there something better for me” rather than “what goes with this”.
Rules that always apply
Whatever method chooses candidates, a layer of rules should filter them. Many bad recommendations are not bad models; they are missing rules.
- Exclude out-of-stock items, or at least variants the shopper cannot buy.
- Exclude what is already in the cart or was just bought, except for consumables.
- Respect margin. Do not push products that lose money after discounts and shipping.
- Respect compatibility. A phone case for another model is a negative experience.
- Mind price jumps. Recommend items near the original price band unless trading up is intended.
- Avoid sensitive suggestions. Related items should not reveal personal information to others in a household or on a shared device.
- Add diversity. Five near-identical products waste the placement.
A realistic path for a small store
- Hand-pick related products for your twenty best sellers.
- Use bought-together counts from the last year for the cart, filtered by price and stock.
- Add segment-based best sellers to emails using RFM or a simple new and returning split.
- Test each placement against a control for four weeks.
- Consider a model only when you have the order volume and a clear placement that might benefit.
This stepwise route costs little, teaches you what your customers respond to and produces data for any later model. Our AI product recommendation engine service follows the same order: rules and co-purchase first, models where volume justifies them.
What a model needs
If you do move to a model, make sure the foundations are in place. Without them, the best algorithm learns the wrong lessons.
| Foundation | Why |
|---|---|
| Clean product data | Titles, categories, attributes and images drive content-based models |
| Reliable events | Views, add-to-carts and purchases tracked per user or session |
| Enough volume | Patterns need many examples per product |
| Inventory feed | So it does not recommend what is unavailable |
| A control group | To measure real lift, not just clicks |
| A way to override | So you can pin or exclude products |
The cold-start problem
New products and new visitors have no history. A model cannot recommend a product nobody has bought, and it knows nothing about a first-time visitor. Solutions are straightforward: use content-based similarity for new products, popularity and context, such as the page being viewed, for new visitors, and let manual rules cover launches. If your catalogue changes often, this problem is permanent, which is another reason rules stay in the mix.
Testing recommendations
The danger with recommendation widgets is measuring the wrong thing. Clicks on a widget are not revenue; shoppers who would have found the product anyway may click it. A fair test splits visitors randomly between the new recommendations and the old or none, and compares revenue per visitor, average order value and margin over several weeks. Keep other changes constant, and avoid promotions that distort the period.
- Choose one placement and one change.
- Split traffic evenly at random.
- Run for at least four weeks, covering full weekly cycles.
- Compare revenue per visitor, order value and margin, not just clicks.
- Check for harm, such as lower conversion on the main product.
- Roll out if the result is clearly positive; otherwise keep the control.
What about large language models?
Language models can help in two limited ways: describing why two products go together, and matching a shopper’s natural-language request to your catalogue in a chat or search interface. They are less suitable as the engine that chooses recommendations at scale for every page view, where speed, cost and consistency matter. A sound design uses structured data and rules to choose candidates and a language model, if at all, to explain or converse. See AI shopping assistants explained.
Privacy and consent
Personalised recommendations use behaviour data, so the privacy rules of your market apply. Say in your privacy policy what you track and why, honour cookie choices and avoid keeping identifiable histories longer than you need. Session-based recommendations that do not follow a person across visits are lower risk than profiles built over months. If you use a third-party recommendation service, check where the data goes, whether it is used to train models for other customers and what your agreement says. A simple, well-explained approach is usually enough, and it avoids surprises for customers who dislike being followed around a site.
How often to review
Recommendations drift as your catalogue, prices and seasons change. Set a monthly review: look at the top recommended products for your ten best sellers, check for out-of-stock or discontinued items, look at the widgets on mobile, and compare revenue per visitor with the previous month. A fifteen-minute review catches the kind of errors that quietly cost sales, such as a discontinued item recommended on every product page.
A worked example
A store with 40,000 monthly visitors and 1,000 orders adds a cart add-on strip using bought-together counts, filtered by stock and a price cap of a quarter of the cart value. Over four weeks, a random half of visitors see it. In the test group, 7 percent of carts add a recommended item at an average of $14, and the average order value rises by about $1. Across 500 test orders that is roughly $500 of extra revenue in four weeks, or about $1,000 for the full store, at a margin of perhaps 40 percent. It is a respectable return on a configuration done in a day. A large machine-learning build would need to beat it by enough to cover its cost. The figures are illustrative.
Mistakes to avoid
- Buying a model before fixing the data.
- Measuring clicks, not revenue and margin.
- No stock filter, sending shoppers to sold-out pages.
- Recommending low-margin items because they sell.
- Placing widgets everywhere, making pages slow and cluttered.
- Set and forget. Review what is shown at least monthly.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Google Cloud: recommendations system overview, an introduction to recommendation approaches
- Shopify Help Center: Search & Discovery app, built-in product recommendations on Shopify
- Baymard Institute: product page UX research, usability research on product pages and related products