Recommendation Systems

Metricuno
May 17, 2026
4 min read
Recommendation Systems — Recommendation systems power the "you might also like" carousel and post-purchase upsell. Learn the algorithms, benchmarks, and where they lift revenue.
Quick answer

Recommendation systems decide which products surface in the "you might also like" carousel and the cart upsell. Here's how the algorithms work and what lift to expect.

Definition
Personalization

Recommendation Systems

Algorithms that pick which products to surface to a shopper based on behaviour, item attributes, or popularity.

A recommendation system is the engine that decides which products fill slots like the product page "you might also like" carousel, the cart-drawer cross-sell, the post-purchase upsell, and the homepage "recommended for you" rail. It does this by scoring every product in the catalogue against a context — the current shopper, the current product, the current session — and returning the top N.

Three algorithm families dominate online retail: collaborative filtering (people who bought X also bought Y), content-based matching (this dress is similar to that dress on attributes), and popularity or rules-based fallbacks. Recommendation systems sit inside the broader discipline of personalization and are usually the highest-ROI personalization surface a store can ship.

Also known as
product recommendations
recommender systems
reco engine

Collaborative filtering is the workhorse. It builds a co-occurrence matrix from order and session data — every time two products appear in the same basket or browsing session, their similarity score nudges up. The PDP carousel then queries that matrix for the current product's nearest neighbours.

Content-based matching is the fallback for new SKUs that have no purchase history yet — a problem called cold start. It scores products on attributes you already have (category, colour, fabric, price band, brand) and recommends the closest matches. Most production systems run both and blend the scores.

Formula

similarity(A, B) = (A · B) / (||A|| × ||B||)

Variables

A

Item A vector

Vector of users (or sessions) who interacted with product A — 1 if they bought/viewed it, 0 otherwise.

B

Item B vector

Same vector for product B across the same user base.

A · B

Dot product

Count of users who interacted with both A and B.

||A||, ||B||

Vector magnitudes

Square root of the number of users who interacted with A and B respectively.

Worked example

A Shopify apparel store wants to find which products are most similar to a navy linen shirt, using last 90 days of order data.

Customers who bought the navy linen shirt (A): 400

Customers who bought beige chinos (B): 900

Customers who bought both: 180

similarity = 180 / (sqrt(400) × sqrt(900)) = 180 / (20 × 30) = 0.30

A cosine similarity of 0.30 is a strong co-purchase signal in apparel — beige chinos earn a top slot in the navy linen shirt's PDP carousel. Anything above ~0.20 in fashion is worth recommending; in narrower categories like supplements, the bar is higher because catalogues are smaller and co-occurrence is denser.

Lift varies enormously by placement and vertical. The cart-drawer cross-sell and post-purchase upsell tend to outperform the PDP carousel on revenue-per-session because intent is already high. The homepage rail is the lowest-converting slot but the highest-impression one.

Benchmark

Typical revenue lift from recommendation placements, by vertical

PlacementApparel & BeautyHome & LifestyleElectronics & Accessories
PDP "you might also like"+3-6% RPV+2-4% RPV+4-7% RPV
Cart-drawer cross-sell+5-9% AOV+4-7% AOV+6-11% AOV
Post-purchase upsell+8-15% AOV+6-10% AOV+10-18% AOV
Homepage "recommended for you"+1-3% RPV+1-2% RPV+2-4% RPV

Two practical notes before you ship. First, every recommendation surface should be A/B tested against a control — algorithm changes that look like wins in dashboards often shift revenue between placements rather than create new revenue. Second, watch your page-speed budget: heavy reco widgets that block the PDP from rendering can erase their own lift through bounce-rate damage.

Frequently asked

Recommendation systems FAQ

Personalization is the broader category — anything that adapts content to the individual shopper, including segmented email, dynamic banners, and localised pricing. A recommendation system is one specific tool inside personalization: the algorithm that ranks products for a given slot. Every recommendation engine is personalization; not all personalization is recommendations.

For stores under ~500 SKUs and ~5,000 orders per month, hand-curated rules and "bestsellers in this category" fallbacks often match collaborative filtering on revenue lift, because the data is too sparse for ML to find non-obvious patterns. Above that threshold, behavioural algorithms start to pull ahead, especially in the cart and post-purchase slots.

New products have no purchase history, so collaborative filtering can't score them. The standard fix is to fall back to content-based matching — recommend the new SKU alongside products with similar attributes (category, price band, tags) until it accumulates enough co-purchase data, usually 50-100 orders.

It can. Many reco apps inject a synchronous script that blocks PDP render until the API returns, adding 200-600ms to Largest Contentful Paint. Look for apps that load asynchronously, lazy-render below-the-fold carousels, and serve recommendations from an edge cache rather than a round-trip per page view.

The cart drawer and post-purchase upsell consistently win on revenue-per-session because the shopper has already decided to buy. PDP carousels lift AOV more modestly but at much higher impression volume. Homepage rails are the weakest revenue surface but useful for discovery and reducing bounce on returning visitors.

Four to eight products is the sweet spot. Below four looks empty; above eight, click-through drops because the carousel becomes a wall of options. On mobile, plan for two visible at a time with horizontal scroll — desktop layouts that look balanced often feel cramped on a 390px viewport.

No. The PDP carousel wants "similar to this product" (item-to-item). The cart cross-sell wants "complements what's in the basket" (frequently bought together). The homepage rail wants "matched to this shopper's history" (user-to-item). Using one model everywhere underperforms a context-appropriate model per slot.

Split traffic at the session level, hold the placement and design constant, and only vary the ranking algorithm. Measure revenue-per-session as the primary metric, not click-through on the widget — algorithms that get clicks can still cannibalise other placements. Run for at least two full purchase cycles to capture lagged effects.

Item-to-item collaborative filtering uses aggregated co-purchase data and generally doesn't require consent. User-to-item personalization that builds a profile of an identified shopper does fall under GDPR and ePrivacy — you need a lawful basis and, for non-essential personalization cookies, prior consent in the EU.

Revenue-per-session against a holdout group that sees a popularity-based or no-recommendation control. Surface-level metrics like widget click-through rate or attributed revenue are easily gamed by aggressive algorithms that pull clicks away from organic browsing without growing the basket.

Test ideas before you ship them

Run unlimited A/B tests, attach hypotheses to outcomes, and build a searchable archive of what works — and what doesn't.