AI product recommendations: the logic behind the widget, not just the widget.

The problem

A single "related products" widget reused identically on the product page and the cart page optimizes for neither: the product page shopper is still deciding, the cart shopper has already decided and is looking for an add-on.

How it's done manually

Merchandising sets one static "you may also like" rule, usually same category or best sellers, and applies it everywhere a recommendation slot exists on the site.

The AI solution

Separate logic runs on each surface: the product page surfaces items that help a still-deciding shopper (alternatives, complements, social proof), while the cart surfaces true add-ons calculated from what's actually bought together with the current cart contents.

Example workflow

A shopper adds a camera body to cart; the cart widget surfaces the lens and memory card combination other buyers actually purchased alongside it, while the product page they came from had shown comparable camera bodies at a similar price point.

Business impact

Product-page recommendations support the buying decision instead of distracting from it, while cart recommendations lift order value with genuinely complementary items instead of a generic "customers also bought" list.

Estimated ROI

The lift concentrates on categories with natural complementary products (electronics, apparel with accessories); categories with few natural add-ons see less upside from cart-specific logic.

Common mistakes

Running the exact same widget configuration on both surfaces because it's the default setup in most recommendation apps, missing the fact that the shopper's intent is different on each page.

Best practices

Configure product-page and cart widgets as two separate logics from the start, even if they're powered by the same underlying platform.

The problem

Email recommendation blocks often just mirror whatever the on-site widget shows, which ignores that timing and context are completely different: on-site is in-session browsing, email is a delayed touchpoint days or weeks later.

How it's done manually

A marketing team drops the same "recommended for you" dynamic block into every flow, powered by the same feed as the on-site widget, without adjusting for how much time has passed or why the email is being sent.

The AI solution

Recommendation logic in email accounts for elapsed time and purchase-cycle stage: a browse-abandonment email recommends the specific items viewed, while a replenishment email recommends based on typical reorder timing for consumable products, not generic browsing history.

Example workflow

A customer who bought a consumable product forty days ago, in a category where the typical reorder cycle is six weeks, gets a replenishment-focused recommendation email instead of a generic "new arrivals" block used for a different segment.

Business impact

Email recommendations feel timed and relevant instead of like a recycled on-site widget, which shows up in higher click and conversion rates on lifecycle sends specifically.

Estimated ROI

Brands with consumable or replenishable products see the clearest lift from cycle-timed recommendations; low-repeat-purchase categories see less benefit from this specific logic.

Common mistakes

Feeding email the same real-time browsing feed used on-site without adjusting for the time gap, which can recommend items a customer already bought or lost interest in by the time the email sends.

Best practices

Build separate recommendation logic per lifecycle email type (browse abandonment, post-purchase, replenishment, win-back) rather than one shared block across all of them.

The problem

These two recommendation types get used interchangeably even though they answer different questions, which leads to alternative products showing up where a complementary add-on would convert better, and vice versa.

How it's done manually

A single recommendation app setting gets applied everywhere by default, usually whichever the platform ships as its out-of-the-box "related products" logic, without distinguishing which pages call for which type.

The AI solution

Frequently-bought-together logic, built from actual co-purchase data, runs on pages where the goal is adding to an existing purchase decision (product page, cart). Also-viewed logic, built from co-browsing data, runs on pages where the shopper is still comparing (category, search results).

Example workflow

A shopper viewing a specific blender sees frequently-bought-together accessories (a replacement blade, a travel cup) on the product page, while the category page they arrived from showed also-viewed alternative blender models for comparison.

Business impact

Each recommendation type does the job it's actually good at: also-viewed helps comparison shopping convert, frequently-bought-together lifts order value on items shoppers have already decided to buy.

Estimated ROI

The distinction matters most on higher-consideration purchases where shoppers genuinely compare before buying; low-consideration, impulse categories see less difference between the two logics.

Common mistakes

Showing also-viewed alternatives on the cart page, which can talk a shopper into comparing away from a purchase they were already committed to making.

Best practices

Map each recommendation surface to the shopper's actual stage (comparing vs. decided) and choose the logic type that matches, rather than defaulting to whatever the platform ships first.

The problem

A recommendation model needs behavioral data to function, so every new product launches with none, and most setups either show nothing for it or fall back to unrelated bestsellers during exactly the window when visibility matters most.

How it's done manually

New products get left out of the recommendation rotation entirely until enough purchase or view data accumulates naturally, which can take weeks for a slower-traffic store.

The AI solution

An attribute-based fallback layer (category, price band, tags, shared collection) generates reasonable recommendations for a new product from day one, and automatically hands off to the learned, behavior-based model once enough data accumulates.

Example workflow

A new product launches and immediately gets recommended alongside others sharing its category and price band; after several weeks of accumulated view and purchase data, the system switches it over to behavior-based recommendations automatically.

Business impact

New products get reasonable recommendation visibility from launch day instead of an unexplained gap, and the transition to data-driven recommendations happens without anyone manually flipping a switch.

Estimated ROI

Brands launching new products frequently see the most benefit, since the cold-start gap otherwise recurs every single launch; brands with a stable, rarely-changing catalog have less need for this.

Common mistakes

Leaving new products out of recommendation slots entirely until data accumulates, which starves exactly the products that need visibility most during their launch window.

Best practices

Define the attribute-based fallback rules and the specific data threshold for handoff to the learned model before the next product launch, not reactively after noticing a new SKU has no recommendations.

The problem

Most upsell effort concentrates before the sale, on the product page and in cart, while the post-purchase window, when a customer has just demonstrated real buying intent, gets left to a generic order-confirmation page or nothing at all.

How it's done manually

A team sends the same order confirmation and shipping updates to every customer with no product recommendation attached, treating the post-purchase window as purely operational rather than a sales opportunity.

The AI solution

Post-purchase recommendation logic times a specific, complementary offer to the moment it's most relevant, immediately after purchase for a true add-on, or delayed to align with expected product usage for a natural next purchase.

Example workflow

A customer buys a coffee machine; the order confirmation surfaces a filter or descaling solution as an immediate add-on, while a separate recommendation for compatible pods sends roughly a week later, timed to when the machine has likely arrived and is in use.

Business impact

Post-purchase revenue increases from customers who've just proven they're ready to buy, without any additional acquisition spend, since the audience is already converted.

Estimated ROI

Products with a natural consumable or accessory relationship see the clearest post-purchase upsell revenue; standalone products with no natural follow-on purchase see less opportunity here.

Common mistakes

Sending the post-purchase upsell at the same moment as the order confirmation regardless of product type, which works for an immediate add-on but is too early for a usage-dependent follow-on purchase.

Best practices

Time post-purchase recommendations to the product's actual usage cycle, immediate for true accessories, delayed to match expected usage for consumables and next-step purchases.