How a Price-Comparison Site Is Built on Barcode Data

The problem is identity, not price

Collecting prices is the easy half. Every retailer publishes them, and a feed is a feed. The hard half is deciding that this row from shop A and that row from shop B are the same product, because until you can do that you have a list of prices rather than a comparison.

Names will not do it. The same shoe appears as "Nike Air Max 95 Premium", "Air Max 95 Premium (Men's)" and "NIKE AIR MAX 95 PREMIUM GREEDY" depending on who typed it, and those three strings have to collapse to one product. Colour words differ, gender markers come and go, and half the catalogue has the brand name repeated inside the product name. Fuzzy matching on names produces exactly the failure you would expect: confident merges of things that are not the same item.

What does work is an identifier the manufacturer assigned. For groceries that is the GTIN printed as a barcode. For footwear and apparel it is usually the manufacturer style code, with the GTIN available per size where the retailer publishes it.

Style codes and GTINs do different jobs

The two identifiers sit at different levels, and conflating them causes real damage.

A comparison page is about the colourway — you want every shop that sells that shoe on one page — so the style code is the natural key. The GTIN then resolves the level below it: this shop has EU 42 in stock, that one does not. Use the GTIN as the page key and you get forty near-identical pages, one per size. Use the style code as the size key and you cannot tell sizes apart at all.

Normalise before you compare

Identifiers only match if you compare them in the same shape, and retailers do not agree on shape. The same style code appears as IM2211-001, IM2211/001, im2211 001 and sometimes as the colourway suffix alone. GTINs arrive as 12, 13 or 14 digits depending on where the product was listed, and a 12-digit UPC is the same number as the 13-digit EAN that carries one leading zero.

So both identifiers need a canonical form before they are used as keys: strip separators and case from style codes, and left-pad GTINs to 14 digits. That second rule is the one people skip, and it produces duplicate catalogue entries for one product — a UPC row and an EAN row that never meet. The GTIN converter shows the padding, and the barcode validation tool catches the truncated and mistyped values that would otherwise become their own phantom products.

Check digits earn their keep here. A feed value that fails its check digit is a typo, not a new product, and rejecting it at intake is far cheaper than discovering it as a duplicate later.

A worked example

HYPEIBIZA is a European sneaker price-comparison site, and it is a clean illustration because its whole surface depends on getting identity right. A product page there shows every retailer carrying that colourway, each one's price, its stock state and the sizes it still holds — which is only possible because the rows arriving from dozens of separate retailers have already been folded onto one style code.

Two consequences of that design are visible from the outside. First, the product page is per colourway rather than per size, so the sizes appear as a filter over the offers instead of as separate pages. Second, the site can look a product up from the barcode on the box: scan the EAN and you arrive at the page for that colourway, because the size-level identifier resolves upward to the product-level one.

The failure mode is equally visible on any comparison site that skips this work — the same shoe listed twice under slightly different names, each with half the retailers, so neither page tells you where it is cheapest.

Identity also decides the picture

Once identity is solved, everything else attaches to it. A catalogue assembled from many retailers inherits many images of varying quality, and the identifier is what lets you pick one per product rather than showing whichever shop happened to be first. The same applies to descriptions, release dates and colourway names.

This is why product data and pricing are the same project. A price without a confident product identity is a number with nothing to attach to, and an image without one belongs to no page in particular. If you are building this rather than buying it, the API documentation covers looking identifiers up programmatically, and any GTIN lookup page shows the shape of a resolved record.