Product matching
Product matching is the process of deciding whether two product records from different sources describe the same physical item. It applies entity resolution — identifier lookup, attribute comparison, and text similarity — to link a supplier's spreadsheet row, a competitor's listing, and your own SKU to one entity. It is the backbone of deduplication, cross-referencing, and any enrichment that pulls data from a source you do not control.
What a match actually means
Two records match when they refer to the same physical item you could pull off a shelf. That sounds obvious until you open real supplier data.
One vendor sends HEX CAP SCR 3/8-16X2 GR8 ZN. Another sends Bolt, hex head, 3/8"-16 x 2 in., grade 8, zinc plated. Same bolt. Nothing in common as a string. Neither row carries a GTIN.
Matching is not one decision. It is several, and they have different rules:
| Match type | Question it answers | What it's used for |
|---|---|---|
| Identity | Same manufacturer item, same pack? | Deduping supplier files into a golden record |
| Variant sibling | Same family, different size or finish? | Building parent-child variants |
| Cross-reference | Different brands, functionally interchangeable? | Competitive conversion, substitutions |
| Listing link | Does my SKU correspond to this ASIN or competitor PDP? | Pricing, MAP checks, content gap analysis |
| Source link | Is this manufacturer spec sheet about my SKU? | Enrichment from external sources |
Conflating these is the most common failure mode. A 3/8-16 Grade 8 bolt in zinc and the same bolt in yellow chromate are siblings, not duplicates. Merge them and you have silently deleted a sellable SKU.
How entity resolution works for SKUs
Entity resolution is a pipeline, not a similarity score. The steps:
- Normalize. Case-fold, expand abbreviations (
SCR→ screw), parse units (2"→ 2 in), canonicalize thread callouts (3/8-16), strip vendor prefixes from part numbers. - Block. Comparing every record to every record is quadratic and pointless. Group candidates by brand, by normalized MPN stem, by category, by a token key. Only compare within blocks.
- Compare. Turn each candidate pair into a feature vector: identifier agreement, spec agreement, text similarity, image similarity.
- Score and decide. Combine features into a confidence value and apply thresholds.
- Cluster. If A matches B and B matches C, resolve the group. Transitive closure is where one bad pair drags a whole cluster in.
The features do not deserve equal weight:
| Signal | Example | Weight |
|---|---|---|
| Brand + MPN, normalized | 3M + DBR/Y-6 vs 3m co. + dbry6 | Decisive |
| GTIN / UPC | 00012345678905 | Decisive when present and valid |
| Critical spec agreement | thread 3/8-16, grade 8, length 2 in | Strong; a disagreement is a veto |
| Title text similarity | cosine over embedded titles | Weak alone; good for candidate generation |
| Image similarity | perceptual hash of the primary image | Corroborating; packaging shots lie |
| Price proximity | list prices in the same range | Nearly worthless; never decisive |
The veto rule matters more than the score. If one record says a UL listed 600V wire connector and the other says 300V, no amount of title similarity should pull them together. Encode disqualifying attributes per category and let them override.
Where identifiers run out
Buyers assume identifiers solve this. They solve the easy half.
- MPNs are not globally unique.
100is a real part number for more than one manufacturer. An MPN only identifies when paired with a resolved brand — and brand strings arrive as3M,3M Company,3M ELECTRICAL, and3m co. - Same MPN, different pack. The each and the box of 100 often share an MPN. They are different sellable items with different GTINs and different prices.
- UPCs get reused and mistyped. Check digits catch some of it. Recycled codes from discontinued items catch nobody.
- Revisions drift. A RoHS or spec revision adds a suffix.
-RCis the same functional part to a buyer and a different SKU to purchasing. - ASINs are many-to-one. Resellers create duplicate listings for one manufacturer item. Matching your SKU to "the" ASIN often means matching to a set.
So identifier lookup is the first pass, not the system. Everything the first pass misses falls to attribute-level resolution, which is exactly where the long tail lives.
Precision, recall, and where humans belong
Errors are not symmetric. A false merge corrupts a golden record, cross-contaminates specs, and is hard to unwind six months later. A false split leaves you with a duplicate you can find again. Tune for precision on merges.
That means two thresholds, not one:
- Auto-accept above the high threshold: identifier agreement plus no spec vetoes.
- Review queue between the thresholds. Show the pair side by side with the specific fields that disagree highlighted — not a raw score.
- Auto-reject below the low threshold, but log it. Rejects are where you find your normalization gaps.
Measure both directions on a labeled sample from your own catalog, per category. Fasteners are decided by thread pitch, length, grade, and finish; a 600V wire connector is decided by its UL listing and voltage rating. A model tuned on one will underperform on the other.
And keep the decisions. A match is a durable fact with provenance: matched on what, when, by whom, at what confidence. Matches that are silently re-derived and change between runs are worse than none.
Why it sits under everything else
Almost every catalog project a distributor runs is a matching problem with a different name on the ticket.
Onboarding a new supplier's 8,000-row file? You need to know which rows are already in your catalog. Pulling specs from a manufacturer's PDF library? You need to know which PDF belongs to which SKU. Checking whether a competitor lists the item cheaper? You need the link first. Filling a UNSPSC code from a reference source? You had to match to that source.
Your PIM stores the resolved entity. It does not go find the other four records that describe it and decide whether they are the same thing. The PIM holds the answer; something has to produce it.
Frequently asked questions
What is the difference between product matching and deduplication?
Deduplication is one outcome of product matching. Matching decides whether two records describe the same item; dedupe acts on that by collapsing them. Matching also produces links you never merge — your SKU to an ASIN, your part to a competitor's equivalent, your item to a manufacturer spec sheet. Same engine, different action taken on the result.
Can you match products without a GTIN or UPC?
Yes, and you have to — most B2B catalogs are mostly identifier-free. You fall back to brand plus normalized MPN, then to attribute-level comparison: thread pitch, grade, voltage rating, dimensions, material. Text similarity generates candidates; specs decide. A disagreement on a critical attribute like 600V versus 300V should veto the match regardless of how similar the titles read.
How accurate does product matching need to be?
Precision on merges should be very high, because a bad merge corrupts a golden record and is painful to reverse. Recall can be lower, because a missed match just leaves a duplicate you catch later. Practically: auto-accept only high-confidence pairs, route the middle band to human review, and measure both numbers per category on your own labeled sample.
Does my PIM do product matching?
PIMs handle identity inside your catalog — a SKU key, variant relationships, sometimes a basic duplicate check on import. What they generally do not do is resolve your records against outside sources: supplier files with no shared identifier, marketplace listings, manufacturer spec libraries. That external resolution is the work Anglera does alongside your PIM, then writes the result back into it.
How do you match SKUs to Amazon ASINs?
Start with GTIN lookup where you have valid barcodes. For the rest, use brand plus MPN against listing attributes, then verify with specs and image comparison. Expect a set, not a single answer — resellers create duplicate listings for the same manufacturer item. Store each link with confidence and provenance so pricing or MAP decisions built on it can be audited.