Duplicate Products on a Marketplace: Detecting and Merging Them Safely

A duplicate product on a marketplace is two pages for one thing, and merging them is a destructive operation on a live catalog that most platforms cannot undo.

A duplicate in your catalog scatters the competition between offers and costs you a few percentage points of conversion. A bad merge costs you orders, reviews, page addresses, and integrations. In the solutions we know, you cannot undo it.

This article breaks down:

• Which 5 sources produce duplicate products?
• What does a product merge touch?
• Why is reversibility a condition of merging?
• When is it cheaper to live with a duplicate?

Key insights

• A duplicate can wait. A bad merge usually cannot be undone. So the risk here is speed, and delay is the safe direction.
• One merge repoints eight things at once: offers, orders, reviews, prices, page addresses, seller integrations, carts, and reports.
• Keep a table of old identifiers to new. One row per merge buys back your redirects, your integrations, and any report for a closed period.

Why is merging duplicate products a destructive operation?

A duplicate looks like a cosmetic error: two product pages for the same thing, one of them to delete. That is why merging looks like housekeeping and reaches the team as a housekeeping task, with no approval and no dry run.

With one click, you rewrite history. The internal product identifier is the key that eight other things hang from: offers, orders, reviews, prices, page addresses, seller integrations, carts, and reports.

A merge is three operations at once: picking the winner, disposing of the loser, and repointing everything that used to point at the loser. The third one is what nobody counts before the first time.

Do not assume that an "unmerge" button exists. In some of the solutions we know, a merge is carried out by deleting the losing record and repointing its offers to the winner.

In others, it happens automatically, with no notification to the operator and no way to say which record should win. Both are irreversible, and in the second case you find out after the fact.

From this comes the asymmetry that should govern your policy: a duplicate is a reversible state; a bad merge usually is not. You can merge a duplicate at any time: tomorrow, next month, after you gather the evidence.

You can unmerge only if somebody planned for it in advance. So the risk runs against intuition: what costs you is speed.

Which 5 sources produce duplicate products?

Merging treats the symptom. The source matters, because four of the five remedies below have nothing to do with merging.

1. No identifier at listing time

If the trade identifier is an optional field, you have nothing to match on.

The remedy is the entry gate and the exceptions policy from "Product Matching on a Marketplace: GTIN, EAN, and Where Identifiers Stop".

2. Variants listed as separate products

A model in seven sizes and two colors comes in as fourteen separate product pages.

These are not duplicates, and merging them will destroy data: the remedy is the variant model from "Product Taxonomy for a Marketplace: Categories, Attributes, and Variants".

3. The seller never found the existing product

This is the most common source and the most underrated.

Practitioners point to it as the main one, and the diagnosis is uncomfortable: this is a failure of the search box in the seller panel. If finding the product page takes a separate step and an exact hit on the name, a seller uploading a file with eight thousand rows will not take that step.

The remedy is matching done at the moment of import, with a message saying "we found three candidates".

4. A re-import under a new identifier

The seller changes their own codes or moves to a different integrator, and the same thing comes in a second time.

The remedy is import idempotency on a natural key: the same row uploaded twice must produce one record.

5. Bundles and multipacks

The trade identifier standards are unambiguous here: a case pack gets its own identifier, separate from the single unit.

In practice, sellers enter the identifier of the single unit, so the bundle lands on the product page of one piece. The consequence is commercial.

The page says "pack of 24 for €89"; the offer next to it costs €4.20, wins on price, and sells a thousand units of something other than what the buyer thought. The remedy is to make the number of units in the pack part of the matching key.

Merging this makes it worse.

Which 2 classes of duplicate candidate can a machine judge?

A merge candidate arises in two different ways, and that distinction belongs in your policy, because it settles what the machine may do.

Deterministic candidates come from the same trade identifier, or the same brand plus part number. The answer is binary and checkable.

Approximate candidates come from the name, the attributes, the photo, and the price. Record linkage methodology is consistent on this point: hard rules give you high precision and catch the obvious pairs, while probabilistic methods give you a confidence score and a threshold that trades false matches for misses.

There is no threshold that removes both errors at once.

The line reads: automation only on the deterministic class. Everything else goes into a candidate queue with a confidence score and the name of the person who works through it.

That is a job. At 2,900 approximate candidates and forty decisions an hour, you are looking at more than 70 hours, which is almost two weeks of one person working full time.

Raising the threshold shortens the queue and increases the number of duplicates you never see. That is a choice you make.

What does a product merge touch? The 8-item inventory

This list is the core of the article, because almost nobody draws it up before the first merge. Each item gets one sentence about what breaks.

1. Offers and stock levels

If the platform allows one seller offer per product, and the seller had offers on both product pages, one of them quietly disappears with its stock.

2. Historical orders

An order line points at a product, so once the loser is deleted, the order starts showing a different name than the buyer saw at purchase.

That is the same thing you go looking for during a product recall, which product safety and recalls cover.

3. Reviews and ratings

You are pouring two sets together: 62 reviews averaging 4.1 and 9 reviews averaging 4.8 give you 71 reviews and an average of 4.19.

The arithmetic is correct, and the message lies if those were two different things.

4. The price series

The unit of price history is a specific seller's offer, so the offer-level series survive the repointing.

A series counted at product page level turns into a mash-up of two products, and the price reduction message is calculated from it.

5. Page addresses and search positions

Delete the loser, and you delete an address: 1,200 merges are 1,200 dead addresses.

Without a permanent redirect, you lose the signals you accumulated, and public guidance from the largest search engine talks about keeping redirects for at least a year. The same note applies to comparison shopping feeds.

6. Integrations holding the old identifier

The seller's integrator sends stock every fifteen minutes, which is 96 times a day, to an identifier that no longer exists.

Usually it fails quietly, with no alert, and the offer is left with no stock.

7. Carts and wish lists

A buyer comes back three days later to a cart where the line points at a record that no longer exists, and sees a blank with no explanation.

8. Reports for closed periods

Sales per product for a closed quarter change after the fact if the report is computed live from the current catalog.

Freeze a dated snapshot.

Why is reversibility a condition of merging products?

If a merge cannot be undone, then it is not a catalog operation. It is a one-way decision.

One-way decisions have an approver and a trail, like everything in the queue from the approval queue. The difference is not a formality: it changes the staffing, the pace, and who answers for the outcome.

The minimum you always need is a permanent mapping table: old identifier to new, kept forever. Three things come back through it: page addresses (the redirect), integrations, and historical reports.

The cost is one row per merge. That is why it is better not to delete the loser, but to mark it withdrawn and pointing at the winner.

It is also worth knowing what an unmerge does not mean. It does not restore the state of the world.

It splits the identities apart and sends offers, reviews, and order lines back where they were. For that to be possible, the system has to record what belonged to whom before the merge.

Without that snapshot, an unmerge is impossible even with the best will on the vendor's side. That is a technical question worth asking earlier than the question about the button.

When is it cheaper to live with a duplicate product?

This is counterintuitive advice, worth stating plainly, because a candidate queue looks like a backlog, and people want to close backlogs down to zero.

A duplicate costs you when it divides the competition or confuses the buyer. Four places where you really pay: products with several offers (offers spread across two product pages do not compete, so the buyer does not see the best price), high turnover, categories compared on price on external sites, and products covered by safety obligations, where an invisible product page is a hole.

A product with one offer and two page views a month costs you nothing and is not worth the risk. In this article's example, out of 3,800 candidates, only 620 concern products with at least two offers or at least 20 views a day.

Those 620 are about fifteen hours of work, which is two days. The remaining 3,180 stay in the queue, and that is the correct decision.

Catalog debt as a program is catalog debt, and winding down what does not sell anyway is retiring what does not sell.

That gives you one operating rule: sort the queue by the cost of the duplicate. Confidence tells you whether you are allowed to merge.

Cost tells you whether it is worth it.

What does merging change about the rest of your catalog?

1. The internal product identifier stops being a technical detail

Page addresses, feeds, and seller integrations hold it, so it is a public commitment and should be treated as a permanent identifier. That stays true after the product stops existing.

2. A merging policy is a document

It has to answer four questions: who may merge, on which class of evidence, who approves, and whose field values survive the operation. That last one belongs to data ownership in field ownership, and a dispute over the values themselves belongs to "When Two Marketplace Sellers Disagree About Product Data".

3. Detection has to reach the published catalog

A rule that runs only at the point of entry will not find the duplicates you already have, and turns the problem into a treadmill: you produce them faster than you close them. What a rule can do to a live catalog is settled in catalog rules.

How do you test a product merge in a vendor demo?

Three metrics worth having on one screen: how many candidates are waiting in the queue (the stock), how many merges you do per week (the flow), and how many merges were undone (the quality). The third one matters most, and it is also a test of the platform itself.

If unmerging is not possible, that metric does not exist. That is the answer to the question you just asked.

A scene to ask for live, on screen. Take two products, each with at least one order and at least one review.

Ask to have them merged on screen, and then to have that same merge undone. After each of the two steps, check five things: what the line in the old order shows, how many reviews there are and what the average is, what the old page address returns, what an integration querying the old identifier gets, and what the sales report for a closed month shows.

Three answers you do not buy. "It can be done through a support ticket" means it is not in the product, and you will not do it a thousand times.

"We take an export before the operation" means you have a file. "Nobody has asked for that yet" means nobody has yet merged a product that had a review.

Which mistakes do operators make about duplicate products?

1. Merging on an approximate match with no human involved

One candidate that just clears the threshold is enough to fuse a multipack with a single unit. You discover it a thousand orders later.

2. A merge that deletes the loser with no mapping table

You lose the addresses, the integrations, and the ability to answer what exactly one person bought, all at the same time.

3. Treating the duplicate queue as a backlog to be cleared in full

Most of the items cost nothing, so you are paying with operational risk for tidiness nobody will ever see.

4. Fixing variants and multipacks by merging them

It looks like the same task, and it is the opposite one: merging a bundle with a single unit breaks the price, the stock level, and traceability all at once.

5. Detection set up only at the point of entry

New offers are clean, the catalog keeps growing duplicates, and the "candidates in the queue" metric gets counted for the first time during a migration to another platform.

What do you still have to settle about merging?

This is a map of operations on data. It is neither a manual nor a policy ready to sign.

Four things you have to settle at home, because they depend on the structure of your catalog and have no general answer.

The confidence threshold for your categories. It depends on how well your assortment is covered by trade identifiers.

In categories without them, every match is approximate, and automation is off the table.

Where merging should happen: in your product data system or in the platform. That follows from the direction of synchronization in "Who Owns Product Data on a Marketplace?" and is an architectural decision.

The point at which merging becomes a separate project with a budget, rather than a task for the catalog team. It depends on the size of the queue and on how much of it really costs you.

Who carries the cost of a bad merge toward the seller whose offer disappeared or landed on somebody else's product page? This is a contractual term, and at scale it is worth settling before it happens for the first time.

While you are there, check whether your appeal path from the rules on decisions about sellers covers catalog operations and not only suspensions.

Summary: What makes a product merge safe?

Knowing what it touches before you press the button, and keeping a way back. Automate only the class of candidate that is binary, because an approximate match one point over the threshold is how a multipack fuses with a single unit.

Keep a permanent mapping of old identifier to new, so addresses redirect, integrations translate, and a closed quarter still reports the number it reported. Then sort the queue by what each duplicate costs you, and leave the ones that cost nothing alone: a page with one offer and two views a month is worth less than the risk of touching it.

Ask a vendor to merge two products with an order and a review each, on screen, and then to undo it. Building a marketplace where a merge leaves a mapping table and a way back?

Talk to us about the build.

Frequently asked questions on duplicate products

What causes duplicate products on a marketplace?

Five things, and only one of them is fixed by merging. No identifier at listing time, variants listed as separate products, a seller who could not find the existing page, a re-import under new codes, and multipacks entered under the single-unit code.

What does merging two products break?

Anything holding the losing identifier. Offers and stock, historical order lines, review averages, price series kept at page level, page addresses and their search signals, seller integrations posting stock every fifteen minutes, carts, wish lists, and reports for closed periods.

Can a product merge be undone?

Only if the system recorded what belonged to which product before the merge. Some platforms delete the losing record outright, and some merge automatically with no notice.

Ask about the snapshot before you ask about the button, and treat an export taken beforehand as a file rather than an unmerge.