Complementary vs. Additional Products: Why the Distinction Matters in E-commerce

In e-commerce, terms such as cross-sell, complementary product, accessory and additional product are often used to describe more or less the same thing.

But not all recommendations serve the same purpose.

When a customer is looking at a product, some items have a genuine relationship with how that product is used. Others are simply interesting additions to the basket. The difference may seem subtle, but it matters when the goal is to build recommendations that are genuinely relevant.

This is especially important for a product recommendation engine. Recommending a product simply because it is close to the product being viewed is not the same as understanding why that product is useful with it.

What Is a Complementary Product?

A complementary product is a product that has a functional or usage relationship with the main product.

It may be essential for the product to work, necessary in certain situations, or simply strongly recommended to get the most out of it.

Some simple examples:

• Camera → SD card
• Chainsaw → chain oil
• Printer → ink cartridge
• Aquarium → filter
• Drill → drill bits

In each case, the relationship does not necessarily come from the products being similar.

An SD card does not look anything like a camera. An ink cartridge does not look anything like a printer. Yet both have an obvious relationship with the way the main product is used.

This is precisely what makes complementary product recommendations more difficult than simply finding similar products.

The Role of a Complementary Recommendation

A good complementary recommendation answers a very simple question:

"What do I need with this product?"

The goal is therefore not simply to increase the number of items in the basket. It is also to help the customer buy what they will actually need.

This can prevent an incomplete purchase, frustration after delivery, or the need to place another order a few days later.

What Is an Additional Product?

An additional product is different.

It is not necessarily related to the operation of the main product. It may simply improve its use, provide greater comfort, or address a secondary need.

For example:

• a protective case for an electronic device;
• a maintenance product;
• a comfort accessory;
• a more complete version of a piece of equipment;
• an accessory that enables a different use of the product.

These products can be very useful in a cross-sell strategy, but their relationship with the main product is generally less direct.

The question becomes:

"What else might I want to buy with this product?"

This is a different logic from:

"What goes with this product?"

That distinction matters when building a recommendation engine.

The Problem with Recommendations Based Only on Similarity

A common approach is to look for products that are most similar to the one the customer is viewing.

Embeddings are particularly useful for this.

The product page is transformed into a vector representation, and the system searches for the products that are closest in that semantic space.

This works very well for identifying similar products.

A drill can easily be matched with other drills. A pair of shoes can be matched with other similar pairs of shoes.

But this is not enough to identify complementary products.

A drill and a drill bit may be very different from a semantic point of view. Yet they have an obvious relationship in terms of usage.

This leads to a fundamental distinction:

Similarity: "What looks like this product?"

Complementarity: "What goes with this product?"

These are two different problems.

How Can Complementary Products Be Identified?

There is no single source of truth.

When a catalogue has enough historical data, actual customer behaviour is obviously an important signal. Products that are frequently purchased together can reveal real complementary relationships.

But this signal is not always available.

This is particularly relevant to the cold-start problem. A new product may need recommendations as soon as it is added to the catalogue, even though no customer has purchased it yet.

This is where several sources of information can be combined.

1. Behavioural Data

Purchases, add-to-cart events and other interactions can progressively reveal relationships that actually occur in the catalogue.

With enough data, these relationships become a particularly valuable signal.

2. Semantic Similarity

Embeddings can be used to find similar products and transfer some relationships that are already known.

If product A has a known complementary relationship with product C, and a new product A' is very similar to A, C can become a candidate for A'.

But this transfer needs to be handled carefully.

Two products can be very similar in their descriptions while having different technical characteristics. When necessary, a transferred relationship therefore needs to be checked against compatibility constraints.

3. Product Knowledge

Some relationships simply cannot be inferred from the purchase history of a catalogue.

A drill needs drill bits. A printer uses ink cartridges. An aquarium may need a filtration system.

These relationships come from knowledge about the product and how it is used.

LLMs can help bring some of this general knowledge into the recommendation process, even when no purchase history is available.

This is particularly useful when a new catalogue or a new product has just been launched.

RecoKit Is Not Simply Looking for the Closest Products

This is an important distinction in the way a recommendation engine is designed.

A system based only on similarity can answer:

"Here are the products that look most like the one you are viewing."

A recommendation engine focused on complementarity is trying to answer:

"Here are the products that have a reason to be recommended with the one you are viewing."

That difference changes the way recommendations are built.

RecoKit can combine several types of information: relationships observed in behavioural data, product similarity, relationships transferred by analogy, compatibility constraints, and general knowledge about products and their uses.

The goal is not to force every product into a "complementary" or "additional" category.

The goal is to identify the most relevant relationships between products.

Why Does This Distinction Matter in E-commerce?

Because a list of additional products is not necessarily a good recommendation.

Take a customer looking at a drill.

Showing three other drills may make sense if the goal is to help the customer compare different models.

But if the customer has just bought the drill, the products they actually need may be drill bits, a set of screwdriver bits, an additional battery or certain safety equipment.

The right recommendation therefore depends on the type of relationship being considered, but also on the context.

On a product page, the goal may be to help the customer complete their equipment.

In the cart, the goal may be to prevent an incomplete purchase.

After the purchase, recommendations may focus on products that extend or enhance the use of the product that was bought.

A relevant recommendation is therefore not simply the one that maximises similarity between two product pages.

It is the one that matches the shopping context and the actual relationship between the products.

Conclusion

The distinction between complementary and additional products is mainly about asking the right question.

An additional product is something the customer might want to add.

A complementary product is something that has a real reason to be used with the main product.

For a recommendation engine, this distinction matters.

Traditional approaches can identify products that are frequently purchased together when enough data is available. Embeddings make it possible to get started without historical data by understanding product similarity. Relationships can then be transferred by analogy, with compatibility checks when necessary. Finally, LLMs can bring general knowledge about products and how they are used, even when a catalogue has little or no behavioural history.

This combination makes it possible to move beyond a simple "similar products" approach towards something more useful:

recommending products that genuinely make sense together.

That is the goal of RecoKit: building relevant product recommendations even when a catalogue does not yet have enough behavioural data.