How product matching works

Two shops sell the same product and describe it differently. One calls it Rain jacket, men’s, M, blue, the other Men’s rain coat — blue (medium). Nothing in those two pages tells a computer they are the same thing. Matching is the step that decides they are.

You need it the moment you compare prices, because a price only means something next to the price of the same product.

What you give it

Matching runs inside a scraper group. A group holds:

• Your list — the group’s main scraper. Your own products, your own SKUs.
• The sources — the other scrapers in the group. The shops you compare yourself with.

One column is the identity column: the one that names a match. For products that is usually sku; for companies it could be a registry code. It works the same for any kind of data — products, leads or locations.

Then you say which columns to compare with which. Each of those pairings is a line: your title against their name, your ean against their gtin13, your picture against their picture.

The order is fixed

Every run goes through the same three steps, and the first one that can decide, decides:

1. Codes — EAN, GTIN, MPN, your own article numbers. A code that matches is the end of the argument.
2. Text — product names, brands, sizes, colours. Scored, not read: a name that is nearly the same scores high, a name that is nothing like it scores low.
3. Pictures — the product photos, compared as images.

You can switch any step off. You cannot reorder them. This is why a feed with real barcodes matches far better than one without: it never has to fall back to guessing from words.

Price, currency and stock are a special case. They are never what makes a match — they are a sanity check on one. A candidate whose price is a tenth of yours loses score; stock is what decides between two variants that are otherwise identical.

Three answers, not two

A finished run puts every compared product in exactly one bucket:

The Review bucket is the honest part. The alternative — forcing every row into yes or no — buys a clean-looking match rate with wrong prices inside it. Approving a pair in review moves it to Matched and it stays there.

A match also records how close it got: the exact variant (right size, right colour) or only the product model. That distinction matters when the two shops stock the same jacket in different sizes.

How you see the result

In the portal, a matched group has tabs for the run history, the setup, the Results (the three buckets as pills you can filter) and Match quality — which answers three separate questions that are easy to confuse:

• Are the matches we made right?
• Did we find all the ones that exist?
• How much of this could we check at all? (Only available when the run could be graded against known codes.)

A high match rate with a low “are they right” score is a worse outcome than a low match rate, and the panel is built so you cannot read one without the other.

Over the API, the same results come from match/data and match/buckets. Every row carries the decision, the score, what decided it and which master product it belongs to — the full field list is in Matched row fields.

What it does not do

• It does not invent a product. A row with no fitting master lands in No match; it is never attached to the nearest thing.
• It does not silently change your data. Cleaning and conversion are a separate step — see Cleaning and group rules.
• It does not guarantee a number. Match rate depends on what the shops publish; a market where nobody prints a barcode will need text and pictures, and will land some rows in review.

Set it up

Want this as a finished result?

If you would rather receive your products next to every competitor’s price than build the group yourself, that is Product matching  — we run the matching and deliver the result by CSV, Excel or API.

What’s next

• Set the rules up → Group matching reference
• Read the matched rows → Matched data
• Clean the data first → Cleaning and group rules
• See it end to end → Competitor price comparison, end to end