Frequently bought together, done right

Done right, "frequently bought together" is one named complement with a price and a reason, offered next to the item the buyer already chose. It is not a grid of six tiles, the pairing is chosen because the two objects genuinely work together rather than because a model scored them, and the label only claims what your data can support.

That last clause is the one nobody applies. Frequently bought together is a sentence about purchase behaviour in your shop. If it is really the output of a similarity model over a catalogue with no orders behind it, the heading is a claim you cannot back.

Why the grid of six loses

The buyer arrived to decide one thing. A grid of six alternatives at the moment of confirmation replaces a decision that was nearly finished with a browsing session that has just begun.

It also dilutes. Six tiles means six half-arguments, each with a thumbnail and a price and no reason attached to any of them. One tile means one sentence explaining why this object belongs with that object, which is the only content that has ever moved a complement.

And on a 390px screen, six tiles become a horizontal scroll. A horizontal scroll hides the item you actually wanted taken, which is the same failure as putting quantity tiers in a carousel, covered in quantity breaks that raise average order value.

One item. A name, a price, a reason, an unchecked box.

Where does the relevance come from?

There are three sources and they are not interchangeable, because each one entitles you to a different sentence.

Most shops have the first and think they need the third. The first is stronger. A fact about the object is verifiable by the buyer in one glance and does not depend on how many orders you have taken.

The second is available only if you measured it. Not "the app says so" but a number you can produce: of orders containing A, this share also contained B. If you have it, use the label and keep the figure somewhere you can find it again.

The third is the common case in installed apps, and it is where the label goes wrong. Presenting an algorithmic suggestion as a statement about what other customers do is a misleading claim about your shop, in the same family as an invented review. In the EU that falls under the unfair commercial practices rules. Elsewhere it is simply a statement you cannot defend if someone asks.

Declare the pairings by hand

For a catalogue under a few hundred SKUs, the honest and better version of this feature is a hand-written map. It takes an afternoon and it removes the labelling problem entirely.

type Complement = {
  sku: string
  reason: string        // a fact about the object, seven words
  maxShareOfCart: number // never more than half the cart
}

const COMPLEMENTS: Record<string, Complement> = {
  "tin-500g":  { sku: "scoop-steel", reason: "Measures one serving exactly.",   maxShareOfCart: 0.5 },
  "bottle-1l": { sku: "case-travel", reason: "Keeps the bottle upright in a bag.", maxShareOfCart: 0.5 },
}

Two properties fall out of writing it this way. Every pairing has an author, so a wrong one is a decision someone can revisit rather than a score nobody can inspect. And reason is required, which forces the question that a recommendation grid lets you skip: why these two, in one line.

If you cannot write the reason, there is no complement. Show nothing. An empty slot costs less than a suggestion that reads as filler.

The price ceiling, and why it is half

A complement priced near the item already chosen does not read as an addition, it reads as a second purchase, and a second purchase reopens the decision you were trying to confirm. The reference implementation in the commerce kit throws in development when the complement exceeds half the cart total, with the instruction to move it to a post-purchase offer instead.

Below that line the question is "do I also want this". Above it the question becomes "which of these two do I want", which is not a question you intended to ask.

The consent rule, since this one carries a price

If the complement is added by a checkbox, the checkbox starts unchecked. Article 22 of Directive 2011/83/EU requires the trader to obtain the consumer's express consent to any payment beyond the main obligation, and where consent was inferred from a default the consumer had to reject, the consumer is entitled to reimbursement of that payment.

This applies with particular force to the multi-tile version of the pattern, because several implementations pre-select the whole set and present a combined Add all three total. Three items the buyer never individually agreed to, bundled into one price, all of them pre-selected. In the EU that is a refundable charge on every order it touched. The full treatment is in order bump that is legal in Europe.

The same article is why the "bundle price" version needs care: a combined total is fine, a combined total with a struck-through figure you never charged for those items separately is a prior-price claim under the EU price-indication rules.

Where does it go on the page?

Below the add-to-cart button on the product page, or as a line in the cart above the totals. Never above the main button, and never as a screen the buyer must clear to continue. The three positions, and what each is for, are laid out in where to place an upsell on a product page.

One point from that page changes the ranking: a complement declined on the confirmation page, after payment, cannot cost you the original order. That is not true of either other position, and it is where anything failing the price ceiling belongs.

What the market ships

Search this term and you get app listings, most of them wrapping a recommendation API and rendering a three-tile row with all boxes pre-selected and a combined price. We are not naming specific products or repeating their self-reported conversion figures, which are unaudited and drawn from stores that are not yours. What is worth checking before installing one, on a European store, is a single setting: whether the boxes start ticked.

On the agent side, nothing in the tooling knows this rule. Our survey of what exists in the Model Context Protocol registry for commerce UI is in MCP server for ecommerce UI components, and the comparison of buying an app against building the block is in upsell apps for Shopify, or build it yourself.

The two mechanics that need no legal caveat at all are worth building first regardless: the quantity tier selector on the product page, and the free-shipping threshold bar in the cart.

FAQ

How many items should frequently bought together show?

One. A grid of six turns a confirmation into a browsing session, gives each item a half-argument with no reason attached, and on a phone it becomes a horizontal scroll that hides the item you wanted taken.

Can I label it "frequently bought together" if the pairing comes from an algorithm?

No. That label states that buyers in your shop pair the two items, which is a claim about your order data. If the pairing is a similarity score, say Goes with this and give the reason the two objects belong together. In the EU, dressing a model output as customer behaviour falls under the misleading practices rules.

Should the boxes be pre-selected?

Never. Article 22 of Directive 2011/83/EU makes a payment inferred from a default the consumer had to reject refundable. The multi-tile version with everything pre-ticked and a combined Add all three total is the most exposed form of this pattern in Europe.

How expensive should the complement be?

Well under half the cart. Above that it stops reading as an addition and starts reading as a second purchase, which reopens the decision instead of confirming it. An expensive complement belongs on the confirmation page after payment, where declining it cannot cost you the order.