Product Matching on a Marketplace: GTIN, EAN, and Where Identifiers Stop

Product matching on a marketplace is the step that decides which product page a seller's offer lands on, and every rung of it rests on a claim from the party with an interest in getting the import through.

The matching engine decides whether an offer lands on the right product page. An error in that direction is silent: nobody reports it, and you find out at a return or at a recall, when the buyer is already holding something other than what they ordered.

This article breaks down:

• Which 4 rungs does the product matching ladder have?
• Which costs more: a false match or a false split?
• Where does a product identifier stop working?
• What happens to the rows the engine cannot place?

Key insights

• A barcode in an import file is a claim from the person who wants the import to go through. Format validation tells you the number is well-formed and nothing about the item it names.
• The engine can fail two ways. A false split puts one product on two pages, and a curator fixes it in three minutes. A false match sends the buyer somebody else's goods, and nobody finds out until a return.
• So when in doubt, split. A clean-looking catalog bought with silent errors is a worse trade.
• Store what each offer matched on and how confident the engine was. Without it, you cannot undo a bad match, and you cannot tell which rung is producing them.

Is a product identifier a database key or a seller's claim?

A barcode in a column of an import file is not a fact about the product. It is a statement from the party with an interest in getting that import through.

You treat it as a database key, because that is convenient.

It is weaker than it looks, for three independent reasons. First: validation checks the check digit, which tells you only that the number is correctly built.

Second: the organization that issues trade identifiers assigns a number permanently to one item and does not allow reuse, but that rule binds its members, and your import is not one of them. Third: an empty field costs the seller a rejected row, so it gets filled with anything.

The scale of that third one is visible in public product feed specifications, which ban invented values in one rule and in another instruct: supply the identifier only when you are sure it is correct. Nobody writes sentences like that when the problem is theoretical.

Hence the question that organizes the whole subject: how much risk are you resting on somebody else's claim, and what do you do with the row where that claim is false or missing?

Which 4 rungs does the product matching ladder have?

Matching is a cascade. A row falls down until a rung catches it. Each rung is cheaper to maintain and more expensive when it misfires than the one above it.

1. Rung one: the trade identifier. Almost free.

It costs only when it is false, and then it costs the most, because the mistake is invisible.

2. Rung two: brand plus the manufacturer's part number. It needs the brand as a value list and the number at its most specific level.

A number given for a whole product family fuses the variants into one.

3. Rung three: a set of attributes plus the name. An approximate comparison.

The features that decide the identity of an item are the ones commercial names carry worst: model year, regional version, capacity, pack size.

4. Rung four: a person. The most expensive and always necessary.

Human error is not systematic, so you cannot filter it out with a rule.

Four percent of forty thousand rows is sixteen hundred cases for a person out of one night's batch. At forty decisions an hour, that is five person-days for one import run.

Which costs more: a false match or a false split?

They differ in cost and in how long they take to surface.

A false match: the offer lands on someone else's product

The page says one thing and the seller ships another.

Nobody reports it because the buyer does not know what should have arrived, the seller never sees the page through the customer's eyes, and you have no reason to open that one offer. It surfaces at a return or when you go looking for every unit from one batch.

Traceability at a recall is the subject of "GPSR for Marketplaces: Product Safety, Traceability, and Recalls".

A false split: one product exists as two pages

You see it immediately and in several places at once: two pages in search, offers scattered across both, a seller asking why his offer is not next to a competing one.

The fix is one decision by a curator.

Do the math on a single offer. A false match that lives for six weeks at fifteen units a week is ninety orders, each one a candidate for a return, an argument about fault, and an entry in the seller's statistics.

At a €1,000 cart and a 12% commission, each return opens the question of €120 of commission and €880 for the seller.

A false split costs three minutes of a curator's time.

The tuning conclusion is the opposite of the instinct for a "clean catalog": when in doubt, split rather than match. The engine should be brave on rung one and cowardly on rung three.

A higher confidence threshold worsens your automation statistics, and you pay that price knowingly. The second kind of error you know how to fix.

The first you cannot even count.

Where does a product identifier stop working? 7 cases

Seven situations where matching on a number stops working.

1. Goods with no code

Crafts, made-to-measure production, no-name imports.

The code does not exist and never will, and public feed specifications carry a separate flag for this case, "identifier does not exist": the absence of a number, declared explicitly, because an empty field is indistinguishable from a skipped one.

2. Bundles and multipacks

A bundle is a different item from a single unit and needs its own number.

Take a can at €5 and a pack of twenty-four cans at €120: listing the pack under the code and the price of one can costs €115 per order, and €115,000 across a thousand orders. You learn about it from the complaints.

3. Variants

The rules for assigning numbers require a separate identifier for every variant that matters to the buyer, and sellers send one number for the whole family.

Rung one then fuses the sizes into a single offer.

4. Refurbished and used goods

The same number, a different condition: if condition is not part of the identity of an offer, a buyer of a new item will see a refurbished offer.

5. Private label

There is usually no number, because there is no outside manufacturer.

The only key is the seller's own code, so the private labels of two sellers will never come together.

6. Reserved ranges

The trade identifier system sets aside blocks of numbers for the internal use of retail chains.

They are deliberately not unique worldwide, so one of those numbers describes one item in your catalog and another in the catalog next door.

7. Numbers that come back, and numbers pulled out of the air

The standard treats a number as permanently assigned, so the same code on a different product is not an accident: either the rule was broken, or the number never came from a legitimate pool.

The effect is the same either way. The one column you trust points at two different items.

What happens to the rows your matching engine cannot place?

Every vendor will tell you about the engine. Few will tell you what happens to the rest, and that is where the cost lives.

1. Reject it

The simplest option and the most common default.

The catalog stays clean, and the work moves to the party with the least reason to do it: the seller lists the easiest part of the assortment and never returns for the rest. Experienced sellers do not push their whole catalog onto a new channel anyway, and rejecting rows deepens that selection.

2. Accept it as a new product

Sales start immediately, and that is the only advantage.

Sixteen hundred unmatched rows from one night is sixteen hundred new pages. Across thirty runs, that is forty-eight thousand pages a month, most of them duplicates.

Cleaning that up and the destructive merge operation belong to "Duplicate Products on a Marketplace: Detecting and Merging Them Safely". You are at the intake end, and your job is not to create that work.

3. Accept it as a candidate

The row is taken in but creates no page: it goes into a queue with its best hit recorded and the reason that hit was not good enough.

More expensive than both of the others, and the only one that damages neither sales nor the catalog.

The candidate queue is an object in your system. It has a state, an owner, and an age.

Practitioners from large rollouts agree: a queue with no assigned owner is not worked; it only grows, and the argument over whether onboarding or the product data team fixes it is an argument about headcount. At a thousand rows a day, FIFO order is a bad idea.

Sort by potential, because an offer with a price and stock on a product that gets traffic is worth a minute of a curator's time, and a row with no price is not.

Why must match confidence be stored on the offer?

Record on every offer what it was matched on and with what confidence. A week later you can see that the offer hangs on a page, and no more.

Whether it got there on the identifier, on the name, or because somebody clicked on a Thursday has gone. Without that record you cannot unwind a false match and cannot measure the engine, because you do not know which rung is producing the errors.

Three numbers for the board, monthly, because the trend is what matters:

• the share of offers matched automatically (% of offers accepted in the period), which measures friction on the seller's side;
• the share of offers waiting in the queue plus the median age of the queue (% of offers, and days), which measures whether your staffing is realistic;
• the share of matches reversed within 30 days (% of matches made in the period): the only number about quality rather than throughput.

The last one is the most important and the most often missing. When the first number rises together with the third, you are buying automation with silent errors.

Why does product matching have to be idempotent?

Bulk import is a cycle: the same file comes in every day, mostly with unchanged content. Matching therefore has to be repeatable and idempotent: the same input gives the same result, and the row that created a product yesterday only updates it today.

You see the absence of that property within a week. Sixteen hundred rows with no identifier create a new product on every run: after seven days that is eleven thousand two hundred pages out of seven copies of one file.

Some solutions therefore refuse outright to treat a barcode as a write key and require the seller's own identifier instead. It sounds like a limitation.

It is an honest way of putting the problem.

Two requirements follow. A write key on the seller's side, stable between runs.

And a persisted matching decision: a row settled once does not come back into the queue.

What does product matching change about the rest of your catalog?

1. The key is a decision about friction

A mandatory identifier gives you the cleanest catalog and the narrowest supply. The ladder with a candidate queue gives wider supply and a standing operating cost.

There is no third option, and it is worth saying so to the board before launch.

2. The candidate queue needs a headcount line

A role, sized from the inflow of rows and the rate of decisions. It is the line that falls off the implementation sheet and comes back in month six as debt.

3. The key decides what the storefront can do

With no shared product, there is nothing to compare. Whether you want a shared page at all is settled by the catalog model.

4. Where the neighbouring topics live

Five neighbouring decisions have chapters of their own: who may overwrite a field, what to do when two sellers send conflicting data, attributes and the category tree, validation rules on a published catalog, and who approves a new page.

How do you check product matching on one import batch?

Take one night's import batch and count four numbers.

1. How many rows came in, and how many of them carried an identifier? In counts, so nobody rounds the problem away.
2. How many rows matched on each rung. If you cannot break it down, confidence is not being recorded, and that is your first finding.
3. Where the unmatched rows are: in a queue, in the catalog as new pages, or back with the seller as an error.
4. How many of them were in the same file yesterday? An idempotency test you can run without access to the code.

Then four questions for the vendor, with a request to show it on screen:

• Take one offer and show what it was matched on and with what confidence. If it is not visible in the interface, it is not in the data.
• Show me the candidate queue: who can see it, how many items it holds, the age of the oldest, and whether it can be sorted by sales potential.
• Upload the same file twice and show the product count before and after.
• Are the matching engine and the merge rules included in the price, or a separate module? With some vendors, it is the second, and then "the platform connects offers to products" is a sentence about a price list.

Which mistakes do operators make about product matching?

The identifier as an optional field "just for the ramp-up period." It comes back as offers you cannot find with any query. Set the exceptions with a list of categories.

Format validation is used for verification of the goods. A check digit tells you only that the number is well built.

Without an external registry, an invented number passes the gate just like a real one.

An engine tuned for the automatic match rate. The rate goes up, and nobody counts the silent errors.

A metric without its pair, "reversed matches," rewards exactly the error that hurts most.

An unmatched row taken in as a new product, because "sales cannot wait." Rational in month one, irreversible in month twelve: duplicates grow faster than anyone merges them.

A candidate queue with no owner and no age. The view exists, nobody opens it, and after six months the only decision left is to clear it without reading it.

What do you still have to settle about your own assortment?

A map of mechanisms. The engine is yours to design.

Confidence thresholds, attribute weights, and the list of categories with a mandatory identifier are decisions for your assortment and do not carry over from another rollout. You tune electronics with hard part numbers one way, apparel another way, and a catalog that has no codes by design a third way.

We also do not settle on what value of the automatic match rate counts as "good." Detached from the structure of an assortment, it means nothing, and given as a benchmark, it would be false precision. Measure your own and watch the trend together with the share of reversed matches.

Two things to confirm outside this article. The rules for assigning identifiers in your categories.

Confirm them with the organization that issues them, because rules for bundles, variants, and goods sold by weight are sector-specific. And the fields required by regulation, which in many categories are part of the identity of the item.

Summary: What does product matching rest on?

A number somebody else typed. The ladder makes that workable: the identifier catches most rows almost free, brand and part number catch the next few, attributes catch a few more, and a person catches the rest at minutes apiece.

What decides whether the arrangement holds is the bottom rung, because the rows nobody can place are where the cost lives. Reject them and your supply narrows.

Accept them as new pages, and you manufacture duplicates. Hold them in a queue with an owner, an age, and a sort by sales potential, and you pay for it in headcount you planned for.

Take one night's batch and count how many rows carried an identifier, which rung caught the rest, and how many were in yesterday's file too. Building a marketplace where every offer has to say what it matched on and how sure the engine was?

Talk to us about the build.

Frequently asked questions on product matching

What is product matching on a marketplace?

It is the step that decides which product page a seller's offer lands on. It usually runs as a cascade: a trade identifier first, then brand plus the manufacturer's part number, then a set of attributes with the name, and a person for whatever is left.

Is a GTIN enough to match an offer to a product?

No. A check digit proves the number is well built and proves nothing about the goods.

Seven situations break it outright: goods with no code, bundles and multipacks, variants sharing one family number, refurbished stock, private label, ranges reserved for retailers' internal use, and numbers that were reused or invented.

What should happen to an offer that matches no product?

Hold it as a candidate: take the row in, create no page, and record the best hit with the reason it fell short. Rejecting it pushes the work to the seller, who simply lists the easy part of their range. Accepting it as a new product turns 1,600 unmatched rows a night into about 48,000 pages a month, most of them duplicates.