Ecommerce Product Recommendations: The Complete Guide to Related Products, Cross-Sells, and Product Discovery

The direct answer

Product recommendations work when they reduce uncertainty, not when they add more products

The easiest recommendation to build is a row of product cards. The hardest part is deciding whether the row helps. More choices can create more browsing, but browsing is not the same as progress. A shopper who has to decode why six products are there has been handed a new search problem.

Start with the shopper’s current job. Someone viewing a hiking backpack may need a rain cover. Someone searching for a black office chair may want a comparable chair with adjustable arms. Someone with an empty query may need a category path, not a random best seller. The same recommendation engine can support all three, but the relationship and presentation should change.

This is why recommendation work belongs inside product discovery. The module sits between the shopper’s intent and the next action. It can help the shopper find the right product, find the missing accessory, recover from an unavailable item, or continue an exploration that began with search.

Chapter 1

Separate the four recommendation jobs before you build the module

The words “related products” are too broad to guide a real storefront. A related item can be a substitute, an accessory, a higher-priced option, a lower-priced option, or a piece of a larger project. Those relationships require different data, different copy, and different success criteria.

Shopify’s own recommendation tools distinguish related products from complementary products. Shopify describes related products as similar options and complementary products as additions that work with the selected product. That distinction is useful even if you use a different storefront or recommendation system because it gives your team a shared vocabulary. Read Shopify’s recommendation documentation.

Here is the practical rule: do not evaluate all recommendation jobs with one blended click rate. A complementary module may be judged by add-to-cart activity, while a related module may be judged by product-page continuation and purchase. A recovery module may be judged by whether the shopper returns to a useful product set after an unavailable or empty state.

The job also determines the label. “You may also like” is acceptable for open-ended exploration, but “Pair it with” sets a more specific expectation. “Similar options” tells the shopper to compare. “Complete the setup” tells the shopper that the products work together. Copy is part of the recommendation logic because it explains the relationship before the shopper inspects the card.

Chapter 2

Use context, confidence, friction, and guardrails to judge every recommendation

A recommendation can be technically related and still be commercially weak. The product may share a collection, but the shopper may not need it. The product may be popular, but it may be out of stock. The product may be a perfect add-on, but the module may appear before the shopper understands the primary item.

Use this four-part framework before changing a recommendation rule. It is deliberately simple. The goal is to create a review language that merchandising, design, engineering, and growth teams can use together.

The most important part is the guardrail. Recommendation systems are good at producing candidates. Your catalog and storefront rules decide which candidates are safe to show. A product that cannot be bought, does not ship to the shopper’s market, duplicates the selected item, or violates a category restriction should not be presented as a helpful next step.

For Shopify stores, the official documentation lists several requirements for product recommendations. Products need to be active and published to the Online Store channel. They also need to meet price and availability rules, and complementary products require inventory above zero. Treat those requirements as a baseline eligibility test, not as a complete relevance strategy. See the documented requirements.

Chapter 3

Choose the page and moment before choosing the product set

Placement changes meaning. A product recommendation on a product page says “consider this in relation to the item you are viewing.” The same card on a collection page says “this may be another path through the assortment.” In the cart, it says “you may want to add this before completing the order.”

Do not start with “where can we fit a carousel?” Start with “where does the shopper need help?” This changes the implementation conversation from adding a component to removing a decision bottleneck.

A useful placement has a visible relationship to the page content. On a product page, place related products after the shopper has seen the primary title, images, price, options, and availability. Place complementary products near the point where the shopper can understand why the add-on matters. On a search page, do not make recommendations look like organic results. Label recovery content so the shopper can tell what the system is doing.

On the cart page, the constraint is sharper. The buyer has already made a choice. A small, relevant add-on may help, but a second shopping mission can create uncertainty about whether the cart is ready. The module should be easy to ignore and easy to add. Never require the shopper to reject a recommendation to continue.

Chapter 4

Design the product page recommendation as a decision aid

The product page is the most natural home for recommendations because the shopper has supplied a strong anchor. The selected product gives you a relationship, a category, a price point, a set of attributes, and a likely use case. Your job is to use that context without taking attention away from the primary product.

The primary product must win the first decision. A recommendation module should not appear before the title, main media, price, options, shipping information, or add-to-cart action. If the shopper cannot understand the selected product, the module is asking for comparison too early.

A product card in a recommendation module does not need every detail from the product page. It does need the details that help the shopper judge the relationship. If the item is a shoe accessory, show compatibility or use. If the item is a substitute, show the differentiator such as width, material, price, or fit. If the item is a bundle component, show what role it plays.

Avoid vague cards that expose only an image and a title. The shopper should not have to open four tabs to compare the basic decision fields. A concise price, availability state, rating when reliable, and one useful attribute can turn a carousel from decoration into a comparison tool.

Chapter 5

Extend discovery beyond the product page without confusing the result set

Product-page recommendations are the obvious starting point, but product discovery also happens in collections, search results, empty states, and navigation. Those surfaces have weaker anchors. The shopper may have supplied a category, a query, a filter state, or nothing at all.

That means your confidence threshold should rise as context becomes weaker. A recommendation beside a known product can be specific. A recommendation below an empty search should first help the shopper recover the search or choose a relevant category. A generic bestseller row is rarely the best answer to an explicit query.

Baymard’s product-list research is useful here because it treats the product list as a path to product evaluation, not just a grid of inventory. Its benchmark reports that 36% of sites had severe product-list usability flaws. The specific fixes vary, but the underlying lesson is consistent: product discovery depends on the quality of the list, filters, sorting, and product-card information working together. See the Baymard product-list research.

If you place a recommendation inside a collection, explain the scope. “Complete your home office” is different from “More desk lamps.” The first is a project path. The second is a related category. Both can be useful, but they should not use the same heading, card count, or success metric.

Chapter 6

Protect cart and checkout intent when you introduce cross-sells

Cart recommendations are commercially attractive because the shopper has already shown commitment. That is also why they are easy to misuse. The cart is not a fresh collection page. It is a checkpoint where the shopper wants to confirm the order, shipping, price, and next action.

A useful cart recommendation is small, optional, and obviously related. If someone adds a camera, a memory card may be a helpful add-on. If someone adds a pair of jeans, a belt may be reasonable. If someone adds a gift, a random bestseller is not a relationship. It is an interruption.

Baymard’s cross-sell research highlights the danger of inserting a cross-sell step into checkout. In its testing, 66% of users who encountered a separate cross-sell step at Amazon showed extreme frustration. That does not mean every cart module fails. It means the interaction cost and placement matter enough to test directly. Read the Baymard cross-sell finding.

The safest implementation is progressive. Start with a compact cart module. Measure whether shoppers click, add, and complete the order. Watch for changes in checkout initiation, checkout completion, support contacts, and cart edits. A recommendation that adds units but creates more friction elsewhere is not automatically a win.

Keep the add action clear. If an accessory has required options, either let the shopper select them in the module or send them to a focused product page with the cart preserved. Do not add a product with an unknown size, color, or compatibility choice just to make the click path shorter.

Chapter 7

Prepare the catalog data that makes recommendations explainable

Recommendation quality starts in the catalog. Automatic logic can compare products, purchase patterns, descriptions, and collections, but it cannot reliably infer an attribute that is missing, contradictory, or buried in an inconsistent field. Manual rules have the same problem from another direction: the merchandiser can choose the right relationship, but the storefront still needs accurate price, inventory, title, image, and option data.

Think of each candidate as a claim. When you place a product beside another product, you are claiming that the shopper may find it useful in this context. The catalog fields should let your team and your system defend that claim.

Start with the fields that define the relationship. For apparel, that may be product type, fit, material, color, and size. For electronics, it may be compatibility, model, connector, capacity, and power. For parts, it may be manufacturer, model number, SKU, and application. The right fields are category-specific because the shopper’s decision is category-specific.

Then audit the fields that protect the transaction. A recommendation can be contextually perfect and still harm trust if it shows the wrong price or an unavailable item. The product page research from Baymard describes the product page as a central place where shoppers decide whether to purchase, which makes accuracy in the recommendation card part of the broader product experience. See Baymard’s product-page research.

Chapter 8

Understand how Shopify recommendations behave before you blame the theme

Shopify gives merchants several paths for product recommendations. A compatible theme can render product recommendations on product pages. Search & Discovery can customize related and complementary relationships. Automatic related recommendations can use purchase history, product descriptions, or related collections depending on the data available. Custom storefronts can use the Storefront API or the Ajax Product Recommendations API.

That flexibility creates a common diagnostic mistake: treating an empty or irrelevant module as one problem. The cause may be theme support, section configuration, product eligibility, missing data, manual selection, automatic relationship quality, API parameters, or the card renderer itself.

The Shopify Help Center documents requirements that are easy to overlook. A recommended product must be active, published to the Online Store channel, and priced above zero. Related products have one inventory exception when continue selling is enabled, while complementary products require stock above zero. The product cannot be a gift card, unlisted, or already in the visitor’s cart.

For developers, Shopify’s Ajax Product Recommendations API supports a product ID, a limit from 1 to 10, and an intent of related or complementary. The response URL can include tracking parameters for recommendation reports. Those parameters are useful only if the rendered card preserves the URL and your implementation does not replace it with an untracked link. Review the API reference.

For headless storefronts, the Storefront API exposes a productRecommendations query for a product identified by ID or handle. Shopify documents automatic related recommendations and manual configuration for complementary recommendations. The implementation detail changes, but the business question remains the same: what relationship is being requested, and how will the shopper recognize it? Read the Storefront API reference.

Chapter 9

Select recommendations with rules, behavior, and editorial judgment

There are three broad ways to choose recommendation candidates. Rules use explicit relationships. Behavior uses observed activity such as purchases or clicks. Editorial judgment uses merchandising knowledge about compatibility, seasonality, margin, inventory, or brand presentation. Strong programs combine all three instead of pretending one is sufficient.

Automatic selection is useful because the catalog and shopper behavior change. Manual selection is useful because some relationships are too important or too unusual to infer safely. Editorial review is useful because a store has constraints that are not always visible in historical transactions.

A simple operating model is to let automatic logic produce a starting set, use manual relationships for high-value or high-risk products, and add editorial rules for time-sensitive exceptions. The team should know which layer made the decision. Otherwise, a merchandiser may overwrite a useful automatic relationship without understanding why it was selected.

When you add manual relationships, do not fill every available slot. Add only products you would defend in a customer conversation. Shopify lets merchants select up to 10 complementary products and up to 10 related products in its Search & Discovery workflow, but the existence of a slot does not create a reason to use it. See the documented selection workflow.

Chapter 10

Design the module so the relationship is visible before the click

A recommendation module has two jobs. It must help the shopper choose a product, and it must explain why that product appeared. The first job depends on card content. The second depends on heading, placement, labels, ordering, and the relationship between the anchor and candidate.

Keep the component visually subordinate to the primary purchase area, but do not make it invisible. A subtle section heading and useful spacing can separate “the product you are considering” from “the next products you may want to explore.” The shopper should be able to skip the module without losing the main path.

Use consistent card geometry so shoppers can scan across candidates. Keep titles to a predictable number of lines, align prices, and make the entire card or a clearly labeled action tappable. On mobile, avoid a narrow horizontal carousel that hides the relationship after one swipe. If a carousel is appropriate, show a partial next card or another cue that more products exist, and ensure keyboard and screen-reader users can move through it.

Do not use urgency or discount language to compensate for a weak relationship. If the only reason the shopper should click is “limited time,” that is a promotion, not a recommendation. Promotions can be valid, but they should be labeled and measured as promotions so they are not confused with product discovery.

Accessibility is part of relevance. A screen-reader user should hear the section heading, the product name, the useful price or state, and the action. An image without a meaningful label is not a recommendation. A button that adds an item without explaining which variant was chosen is not a safe shortcut.

Chapter 11

Measure the recommendation funnel from visibility to value

Recommendation measurement fails when teams jump straight to revenue. Revenue matters, but it is the end of a sequence. First, the module must render. Then the shopper must notice it, understand it, click it, evaluate the product, add it, and complete the purchase. Each stage can fail for a different reason.

Shopify documents recommendation reporting through a funnel of sessions with recommendations, clicks, add-to-carts, and purchases. Its Search & Discovery reports include click rate, purchase rate, and low-engagement recommendations, while Shopify’s analytics fields reference adds recommendation conversion, performance gap, and session-level fields. See Shopify’s recommendation reports.

A low click rate can mean the relationship is weak, the heading is unclear, the module is below the fold, the cards lack decision data, or the recommendations are not visible on the device. A strong click rate with weak add-to-cart activity can mean the card created curiosity but the product page did not confirm fit, price, availability, or compatibility.

A strong add-to-cart rate with weak purchase activity can point to price shock, shipping, variant issues, stock changes, or checkout friction. Do not use one metric to diagnose the whole system. Pair the metric with a product sample and a live session review.

Segment before you compare. Recommendation behavior can vary by placement, anchor product, device, traffic source, new versus returning shopper, recommendation intent, and catalog maturity. A blended average can hide a high-performing product page and a broken cart module in the same number.

Also decide how you will attribute value. A click-assisted purchase is not identical to an incremental purchase caused by the recommendation. If you cannot run an experiment, use a transparent assisted-conversion definition, preserve the tracking parameters, compare against a baseline, and avoid claiming that every attributed order was created by the module.

Chapter 12

Run this 30-minute product recommendation audit

You do not need a new tool to find the first recommendation problems. You need a small judged sample, a live storefront, and a record of what you expected to happen. This audit is designed to produce a repair queue, not a perfect catalog model.

Use five anchor products. If your store has multiple departments, choose anchors from different categories. If your store sells one narrow product family, choose products with different price points, volumes, and variant complexity. The goal is to see whether the recommendation logic survives different contexts.

At the end of the audit, classify every problem into one of five owners: catalog data, eligibility, candidate selection, presentation, or measurement. This classification prevents the common response of asking engineering to fix a merchandising decision or asking merchandising to fix a missing theme section.

Chapter 13

Evaluate recommendation software against your operating reality

The commercial decision is not “which tool has the smartest recommendations?” It is “which system can produce useful, eligible, explainable recommendations on the surfaces my shoppers use, with the controls and measurement my team can operate?”

A demo can show a beautiful carousel. Your store needs reliable catalog sync, correct variants, appropriate prices, inventory behavior, mobile layout, theme compatibility, analytics, fallback behavior, and a workflow for exceptions. Evaluate the full path from product update to visible recommendation and attributed outcome.

Ask for a test plan, not only a product tour. Bring five real products, five intended relationships, two edge cases, and one mobile device. Require the evaluation to show what happens when the anchor is unavailable, the candidate is sold out, the product has variants, the recommendation set is empty, and the shopper has already added the candidate to the cart.

ParticleSearch is most relevant when the recommendation problem is connected to broader product discovery: search, filters, catalog signals, and the path from a shopper’s request to a useful product set. If your store only needs a small manually curated product-page block, start with native theme and Search & Discovery capabilities. If the problem spans search and discovery surfaces, evaluate the full operating workflow.

Chapter 14

Build the recommendation roadmap in four releases

Recommendation projects often fail because teams attempt to launch every placement, every category, and every strategy at once. A staged roadmap creates a cleaner baseline and makes each release easier to judge.

At every release, keep a rollback path. You should be able to remove a module, restore the prior candidate source, or disable a manual override without losing the measurement baseline. Commercial intent does not justify operational ambiguity. It makes clarity more important because the recommendation touches the path to purchase.

Set a review cadence that matches catalog change. A fashion store with frequent launches needs faster review than a stable parts catalog. A store with manual relationships needs an owner for stale mappings. A store with automatic recommendations needs a way to inspect low engagement and product eligibility.

Chapter 15

Apply the framework to four real store scenarios

The right recommendation strategy changes with the catalog and the shopper’s decision. Use these scenarios to see how the same framework produces different choices.

Notice what stays constant: start with the page job, define the relationship, enforce eligibility, expose the decision data, and measure the handoff. What changes is the evidence you need to call a product relevant.

Frequently asked questions