Frequently bought together: basket analysis that powers the recommendation rail

The most clicked module on most product pages runs on a simple question: what do people actually buy with this? Answering it well is basket analysis; answering it badly is random accessories.

What basket analysis actually measures

At its core, frequently-bought-together is association mining on order history: which products appear in the same basket more often than chance predicts. The raw co-occurrence count is the starting point, but the useful metrics are lift and confidence. Lift tells you the pairing is real rather than just two popular products coinciding.

Time windows matter. Co-purchases within the same session reflect genuine complementarity; products bought months apart by the same customer reflect the customer's taste, not a bundle. Session-level baskets are the right unit of analysis for the rail.

Category structure shapes the results. The strongest pairs are usually complements, not substitutes: the camera and the memory card, the dress and the belt, the grill and the cover. Substitute pairs, two similar dresses, rarely get bought together, and a good algorithm learns the difference instead of recommending near-duplicates.

The cold-start problem for new products

New products have no order history, which means no co-purchase data, which means the best-performing module on the site ignores them exactly when they need exposure. Cold start is the central engineering challenge of the bought-together rail.

Attribute-based pairing is the standard fallback. Match the new product to established products on category, price tier, style tags, and use case, then borrow the established product's pairings. A new leather tote inherits the pairing patterns of similar totes until its own data arrives.

Content-based signals help too. Products frequently viewed together, added to wishlists together, or compared side by side predict future co-purchases. These signals arrive weeks before order data, giving new products a head start on the rail.

Ranking pairs for the rail, not the report

The rail shows three or four pairs, so ranking matters more than recall. The ranking should blend the statistical strength of the pairing with business value: margin on the bundle, inventory availability, and strategic priorities like new product exposure.

Availability is a hard filter, not a soft preference. Recommending a frequently-bought-together item that is out of stock trains shoppers to ignore the module. The rail should check inventory in real time and substitute the next-best available pair.

Price psychology plays a role. Pairs with a natural bundle price, where the combined total feels like a deal, convert better than pairs that just happen to co-occur. Some teams add small bundle discounts on the top pairs; the discount is funded by the conversion lift it creates.

Where the module belongs on the page

Placement decides most of the module's performance. Below the add-to-cart button and above the fold on desktop captures the shopper at peak intent: they have decided on the main product and are open to additions. Buried below reviews, the same module gets a fraction of the clicks.

Mobile placement needs separate thought. The product page is a long scroll, and the bought-together module competes with image galleries, variant selectors, and sticky add-to-cart bars. Testing usually favors a position right after the variant selection, where the shopper has configured their product and is mentally checking out.

The cart page is the second home for bundle logic. 'Complete your purchase' modules in the cart catch the pairs the product page missed, with the advantage that the cart's contents are known. Cart-page bundles convert at high rates because the commitment is already made.

Measuring bundle performance honestly

Click-through on the module is a vanity metric. The measures that matter are attach rate, the share of orders containing a recommended pair, and incremental revenue: would the second item have sold anyway? A holdout that suppresses the module for a control group answers the incrementality question cleanly.

Watch for cannibalization. A bought-together module that mostly shifts purchases from one product to another is rearranging revenue, not creating it. The incrementality test catches this; click metrics never do.

Refresh the pairings on a schedule. Co-purchase patterns drift with seasons, trends, and catalog changes. Stale pairings decay in performance gradually enough that nobody notices until the quarterly review. Monthly recomputation keeps the rail honest.

Frequently asked questions

How is frequently-bought-together different from related products?

Bought-together uses real co-purchase data; related products use attribute similarity. Different signals, different jobs.

What do I do about new products with no order history?

Borrow pairings from similar products and use view-together signals until order data arrives.

Should I discount the bundle?

Test small pair-level discounts; they typically fund themselves through lift.

How often should pairings be recomputed?

Monthly at minimum; automate it so stale pairings never linger.