When you recommend an accessory, customers need to know whether it fits their variant and whether they need it at all. It may already be included, or it may be essential for the intended use. Your catalogue needs those relationships before the design can explain them; bundles also require quantities and pricing rules.
Required, complementary or an alternative?
You can represent that distinction in the catalogue: a required part is necessary for the intended use, a complementary accessory adds an option, and an alternative replaces the product under consideration. With the same heading for every relationship, customers have to work out whether you are suggesting an addition or a replacement.
Baymard’s cart-recommendation research emphasises relevance to the current purchase. For technical accessories, relevance cannot be established solely because other shoppers clicked both products.
Name the specific relationship, such as “Required for wall-mounting this version”, where the product information confirms it. Another version may need a different bracket.
Create a relationship table before designing
A small product group makes the relationship table manageable. For each recommendation, the main product, exact variant, accessory, relationship type and source of compatibility information show you what supports it.
Whether the accessory is already included belongs in the same mapping: a spare can fit without being needed for first use. Sets also need reliable supplied quantities. A photograph showing four screws does not establish how many are actually delivered.
Define what happens when the variant changes. If another size needs another bracket, a previously suitable recommendation must not remain labelled compatible. Without reliable data, the interface should not claim verified suitability.
Make bundle contents understandable
When adding a set, show which items and quantities enter the cart. An additional charge must be distinguishable from an included component. Adding accessories should remain a conscious action rather than an unnoticed purchase.
Implementation also needs rules for removal and editing. What happens to a required adapter when the main product is removed? Does a bundle price remain valid after a quantity changes? If the system only supports fixed sets, the interface needs to explain that constraint.
Check availability too. An available main product with an unavailable required part is different from a usable complete set. Recommendations must not hide that distinction.
Check the complete order
You can trace these rules with approved product data by adding a compatible combination, changing its variant and then removing the main product. Comparing the expected quantities, labels and prices with the cart reveals whether it responds to those changes as agreed.
Next, observe a task where the participant knows the intended use but not the parts required. Can they tell what is included, missing and optional? Record the exact point of uncertainty.
A purchase-friction review can investigate selection using the approved combinations. Separating data gaps from cart faults then shows whether the catalogue needs completing first or the cart’s behaviour needs changing. These become different tasks for CRO implementation.
