Product recommendations: the right logic for each slot

A marketer asks for "product recommendations". A developer installs one widget and puts it on every page. That is where the money leaks.

This page is a brief you can hand to a developer: for each slot, the logic, the commercial reason and the failure mode. It sits under our conversion rate optimisation guide. Personalisation strategy lives in our post on personalisation in marketing, and store-wide conversion work in the ecommerce CRO guide. Here we only do slots and logic.

Substitutes or complements: the distinction that decides everything

Every recommendation is one of two things.

• A substitute replaces what the shopper is looking at. Another kurta. A different 1.5-ton split AC.
• A complement goes with it. The dupatta. The stabiliser and the installation kit.

Google's own commerce documentation makes the same split, describing its Frequently Bought Together model as the choice when "you are looking to recommend complements (as opposed to substitutes)".

The rule is timing. Both kinds are useful, at different moments.

• Before choice: substitutes help. The shopper is still comparing, so widening the set is a service.
• After choice: substitutes cannibalise. The shopper has decided, and you are reopening a closed question.

Get that wrong and the widget is not neutral. It costs you the order you had.

The cart is the flip point.

Where each recommendation slot belongs

Six slots, six jobs.

Model names follow Google Cloud's recommendation model types, updated 6 October 2026.

Google's documentation is explicit about placement. "Recommended for you" is "typically used on the home page". Frequently Bought Together is "commonly displayed on the add-to-cart page, or on the shopping cart or registry pages". Placement is part of the design, not an afterthought.

Why the cart slot is the one you must not get wrong

At the cart the shopper has already done the hard thing: they chose. A substitute there invites them to start again, and restarting usually means leaving.

Baymard Institute's cart research, published 12 January 2021, found that 52% of the desktop sites it benchmarked showed cart cross-sells that were either completely irrelevant or based only on what other customers bought. Its sharper finding is the one to quote at your developer: "even 1 questionable recommendation was observed to cause users to lose faith in all of the product suggestions."

So the cart rules are strict, and all subtractive:

1. Complements only. No alternatives to anything in the cart.
2. Compatibility first. Batteries, cables, fitting kits, refills. Things the main item genuinely needs.
3. Show fewer, not a fixed number. If only one item is clearly relevant, show one. Do not fill the row.
4. Label the slot. "Frequently bought together" explains itself. "You may also like" explains nothing.
5. Never above the total. Nothing should sit between the cart contents and the amount payable.

If the cart is already losing people, fix that first. Our guide to cart abandonment covers it: no widget rescues a cart with hidden delivery charges.

The cold-start problem, in plain English

Cold start is simple: an engine needs behaviour to learn from, and on a first visit you have none. Most Indian stores with modest traffic are in that state for most of their visitors, most of the time.

There is a second cold start, for items. A product launched yesterday has no interaction data, so a behavioural model almost never surfaces it. Amazon Personalize handles that with an exploration weight, which determines "how frequently recommendations include items with less item interaction data or relevance", defaulting to 0.3. Even the big platforms deliberately show items they are unsure about, or new stock would never be seen.

What to serve when you know nothing about the visitor, in order of preference:

• Catalogue similarity. Google's Similar Items model "requires only information from the product catalog; no user events are required", which makes attribute matching the natural cold-start answer, provided your attributes are populated.
• Popularity, scoped tightly. Popular in this category, size range or price band. Google's Buy it Again model itself falls back to "globally popular items" when it has no personalised result, a fallback the docs say "can't be controlled or disabled".
• Session behaviour. Three product views in one session is enough to narrow a slot, with no login and no stored profile.

Never serve an empty or random slot: a blank row looks broken, a random row teaches shoppers to ignore the area.

Rules-based, behavioural or model-driven

That is our view, and not the convenient one for an agency to hold. Amazon Personalize's User-Personalization recipe states you "must create an Item interactions dataset and import at minimum 1000 item interactions" before it works at all. A minimum is not a comfortable operating level. Near a floor like that, a model mostly learns noise.

Step up when all three are true: your catalogue is large enough that hand-mapped rules go out of date, you have months of clean event data rather than weeks, and someone owns the pipeline when it breaks. Until then, better attributes beat a better model.

Two prerequisites sit underneath all of it: first-party data you control, and customer segments to anchor the rules to.

One design consideration, not legal advice: personalisation means profiling, and profiling means consent under India's data law. Decide at build time how consent state reaches the recommendation layer, so a slot can fall back to non-personalised logic for a visitor who never agreed. See our DPDP guide for marketers.

How to measure recommendations honestly

You will see figures claiming recommendations drive some large share of ecommerce revenue. We do not quote them: they trace back to vendor marketing material rather than published research.

The problem is attribution. Every recommendation platform reports "revenue from recommendations", counted as orders where someone clicked a recommended item. That number is almost always overstated: some of those shoppers would have bought the product anyway. Clicking the widget is not proof the widget caused the sale.

A holdout fixes it. The design:

1. Split by visitor, not session. Google's experiment guidance warns users should not move between groups, within or across sessions.
2. Hold back 10% to 20% and show them no recommendations at all, or the pre-existing logic.
3. Keep everything else identical. Google's wording is blunt: "Both versions of your application must be the same." Same layout, same latency, same image quality.
4. Compare revenue per visitor across the whole group, not clicks on the widget. It is the only number that cannot be gamed by moving a click around.
5. Run it past one full business cycle so a payday week or a festive spike does not decide the result.

The gap between the platform's attributed revenue and your holdout difference is the overstatement. The same logic applies to paid media, in our post on incrementality testing.

The slot we change first on an inherited store (DH's own view)

This is our own working order, not a benchmark. When we inherit a store that already runs recommendations, we do three things before adding anything.

1. Count the slots and read what each is actually serving, not what the setting says. We open four product pages and the cart and write the items down. On most inherited stores, every slot runs the same substitute logic.
2. Strip substitutes out of the cart. That one change is subtractive, needs no new data, and removes the only recommendation that can cost you a sale you had already won.
3. Split the product page into two labelled slots. Alternatives high, "goes with it" low. The second slot usually does not exist, which is why basket size never moves.

Only then do we discuss engines. The constraint is almost never the algorithm. It is that nobody populated the product attributes the logic needs, so a good engine has nothing to reason with.

What goes wrong when a developer builds it the obvious way

Recommendations are a marketing request with technical consequences. Four to specify up front.

• Links that are not links. If the widget renders items as click handlers, search engines get nothing. Google states it "can only crawl your link if it's an <a> HTML element" with an href attribute, and lists onclick-based links as not recommended. Ask for real anchors.
• Tracking parameters on every recommendation link. One product then exists at dozens of URLs. Keep the href clean and put the tracking in the analytics event.
• A slot that blocks rendering. Recommendations should never delay the price, the image or the add-to-cart button. Lazy-load below the fold, with a fixed container height so nothing jumps.
• Out-of-stock items left in the pool. Exclude them at serving time, not by hiding them with CSS afterwards.

Four lines in a ticket, and much harder to retrofit after launch than to specify now. Put them in the same sprint as the rest of your ecommerce marketing plan.

Fewer slots, better logic, more basket

The upgrade most stores need is not a smarter engine. It is deciding what each slot is for, then deleting the ones that cannot answer that question.

Start with the cart, where a wrong recommendation costs money rather than merely wasting space. Then give the product page its missing complement slot. Then run the holdout, so the next person who tells you recommendations drive a third of your revenue gets answered with your own number. Repeat orders lift customer lifetime value, and the slot doing most of that work is usually a well-timed ecommerce email.