The Barcode Problem: Why AI Agents Keep Comparing the Wrong Products

Two retailers sell the same bottle of aftershave. One calls it "DIOR Fahrenheit Aftershave Lotion 100ml". The other calls it "Dior Fahrenheit After Shave, 100 ml". A human glances at both and knows instantly. A string comparison sees two different products, or — worse, depending on how it is tuned — decides that a 50ml bottle at half the price is the same thing.

This is the identity problem, and in agentic commerce it is not a minor data-quality nuisance. It is the foundation. Every price comparison an AI agent makes is a claim that two listings are the same product. Get that wrong and everything downstream — the saving, the recommendation, the purchase — is wrong with it, while looking perfectly correct.

What an identifier is, and what a title is

A barcode is an identity. The GTIN system — EAN-13 in Europe, UPC-A in North America, and the longer GTIN-14 for cases — assigns a globally unique number to a specific manufactured product. Two listings carrying the same GTIN are the same item, whatever their titles say.

A title is a description written by a merchandiser to sell. It contains marketing words, category words, size formats that vary by retailer, and abbreviations that differ by market. It was never designed to be an identifier and it does not behave like one.

Matching on titles is not a weaker version of matching on barcodes. It is a different operation with a fundamentally different error profile.

The distinction shows up in the kind of mistake each makes. A barcode match fails by finding nothing — annoying, but honest. A title match fails by finding something wrong, and presenting it with exactly the same confidence as a correct match.

The identifiers worth knowing

• GTIN / EAN / UPC — the barcode on the packaging. Global, manufacturer-assigned, the strongest identity available. Carries a check digit, so a malformed one can be rejected rather than silently mismatched.
• MPN — the manufacturer's own part number. Useful, but only unique when paired with the brand.
• ASIN — Amazon's internal identifier. Excellent within Amazon, meaningless outside it.
• Retailer listing ids — a specific listing at a specific shop. Precise about the listing, silent about whether two listings are the same product.

Only the first is a cross-retailer identity. The others are strong within their own boundary and cannot, by themselves, join two shops together.

Why so much commerce data has no barcode

If barcodes solve the problem, why is title matching still the norm? Because the identifier is frequently missing at exactly the point it would be useful.

1. Marketplaces often do not require sellers to supply one, so listings for identical items carry different identifiers or none.
2. Some categories genuinely have no GTIN: handmade goods, made-to-order furniture, most fashion at the item-variant level.
3. Retailer pages frequently publish structured data with the price and the name but omit the barcode, even when the merchant holds it.
4. Feed formats vary in whether the field is mandatory, so it survives some pipelines and is dropped by others.

The result is a market where the identifier exists in the world — it is printed on the box — but is absent from the data layer where an agent would use it.

What retailers should do about it

If you run a shop and want AI agents to price your products correctly rather than confuse them with something else, this is a short and unglamorous list.

• Publish the GTIN in your product structured data, using the schema.org gtin13, gtin12 or gtin fields, on the product page itself.
• Publish it per variant, not per product family. The 200ml and the 50ml are different GTINs and must be different structured-data blocks.
• Include brand and MPN alongside it. Where a barcode is genuinely absent, brand plus MPN is the strongest available fallback.
• Keep the identifier stable across your own catalogue changes. A GTIN that moves between products is worse than none.
• Make sure the identifier on the page matches the identifier in your feeds. Where they disagree, the page is the one an agent can check.

None of this is new advice — it is largely what Google Merchant Center has asked for years. What has changed is the consequence. Structured data used to affect how your listing appeared in a shopping tab. It now affects whether an autonomous system can tell your product apart from a cheaper imitation of it.

What good systems do when the barcode is missing

Real catalogues have gaps, so the interesting question is not whether a system requires an identifier but what it does without one.

The honest approach is to report identity strength separately from price accuracy. Those are two independent questions, and collapsing them into a single "verified" badge is the standard failure of the category. An offer can have a barcode-exact identity and a price nobody has re-read in a month. Another can have a price read twelve seconds ago against a product matched on a title string. One number for both invites a reader to trust the weaker half at the strength of the stronger one.

The second thing a good system does is refuse. Where the match cannot clear a relevance bar, the answer is no answer — not the closest available guess. In verification specifically, a false positive is the worst outcome available: an assistant told "confirmed" about the wrong product will state it with more confidence than it had before it asked.

For shoppers, the practical version is one sentence: when an AI assistant shows you a surprisingly cheap match, check that the size, model year and edition are the ones you asked for before you check anything else. That is where the error almost always is.