Why Product Matching Looks Easy in a Demo and Falls Apart in Production

Claro treats product matching as a continuous decision process, not a one-time import task. That distinction matters from the first supplier file onward: a model that connects 20 clean SKUs during a demo has not proved that it can resolve a changing catalog containing missing codes, partial descriptions, unit differences, and near-identical variants.

The clean sample is only the top of the problem. Real supplier catalogs form a three-tier pyramid. Each tier removes evidence the previous tier relied on, and each requires a more capable form of entity resolution.

The three tiers of product matching difficulty

Tier 1: clean exact matches

At the top are records that share a trustworthy identifier. A supplier sends GTIN 04012345678901; the same valid GTIN already exists in the catalog. Or both sides contain the same manufacturer and part number after spaces, punctuation, and case are normalized.

This is useful work, but it is lookup with safeguards—not proof that a matching system can handle the full catalog. Even here, packaging levels, recycled GTINs, transcription errors, and manufacturer changes must be checked. Exact equality is strong evidence only when the field’s meaning and source are understood.

Demo datasets tend to overrepresent this tier because the output is fast and visually convincing. In production it is usually the smallest, easiest slice.

Tier 2: fuzzy and contextual matches

The next tier contains the same product expressed differently:

Supplier A: ACME HF-2200 BRG 20MM SEALED
Catalog:    Acme deep-groove bearing, 20 mm, model HF2200

There may be no identical string. Brand aliases need resolving, part numbers need careful normalization, and 20MM must be understood as a bore diameter rather than a pack quantity. Fuzzy matching product data can retrieve this candidate, but a string score alone cannot decide it safely.

The engine must combine positive evidence—manufacturer, normalized MPN, dimensions, material, taxonomy—with negative evidence. A matching name cannot override conflicting voltage, thread pitch, pack size, or revision. That is the difference between similarity and identity; fuzzy matching versus entity resolution explains the boundary in detail.

Tier 3: semantic matches with no shared identifier

At the base are the cases that consume human time. One source describes a product by application, another by technical specification, and neither shares a usable code. Descriptions may be translated, truncated, or inherited from an old ERP. A former supplier code may exist only in a purchase-order history.

Matching now depends on what the system knows around the row: manufacturer relationships, category-specific attributes, former codes, prior validations, compatible units, and the difference between an identical item and a functional alternative. Semantic similarity can surface candidates, but it must be grounded in this product knowledge and constrained by variant-defining facts.

This tier is why matching supplier products without a GTIN needs multiple independent signals. It is also where a generic text model is most likely to produce a plausible but commercially dangerous false match.

Why the demo stops predicting production performance

Four changes occur after the demonstration:

1. The evidence distribution changes. The proportion of incomplete, multilingual, and identifier-free rows rises sharply.
2. False positives become expensive. Joining two different 230V and 110V products can corrupt pricing, availability, and compliance data downstream.
3. Catalogs drift. Suppliers add columns, revise descriptions, replace codes, and change packaging. A rule calibrated once gradually stops fitting the input.
4. Decisions accumulate. Today’s confirmed match should improve tomorrow’s result. A stateless batch job throws that history away on every run.

That last point is central to how Claro approaches matching. The system retains source identity, earlier decisions, attribute variants, and confidence evidence, then evaluates each new or changed record against that growing context. It does not force a PIM replacement; it adds a resolution layer around the systems and files already in use.

Evaluate the pyramid, not the highlight reel

Ask a vendor to report results separately for all three tiers. Build a test set from your own rejected imports, manual mappings, and known duplicates. Include hard negatives: adjacent sizes, different voltages, successor products, and similar descriptions from different manufacturers.

For each tier, measure:

• Precision: of the pairs declared matches, how many are truly the same product?
• Recall: of the known true matches, how many did the system find?
• Coverage: what share can be automated at the required precision?
• Review quality: do uncertain cases arrive with evidence a human can verify quickly?
• Drift: does performance hold on a later supplier file, not just the calibration sample?

Production matching is a loop

The durable workflow is: ingest, normalize, retrieve candidates, score evidence, auto-accept only above a calibrated threshold, route ambiguity to review, preserve the decision, and repeat when the source changes. Why fuzzy-match scripts break at scale shows why a static comparison job cannot manage that loop.

If duplicates are already present, use the catalog deduplication playbook to turn confirmed matches into reversible canonical records. To see how Claro applies the same process to your supplier data, book a demonstration built around a representative production sample—not 20 hand-picked rows.

FAQ