Product Matching Across Multiple Marketplaces

The decision: which offers represent the same sellable product?

Cross-marketplace analysis fails when identity is treated as a title join. A 500 ml bottle is not the same offer as a two-pack of 500 ml bottles; a blue size-9 shoe is not interchangeable with size 10; and a marketplace listing can bundle accessories without changing the first words of its title. The buyer decision is therefore not simply whether two strings look alike. It is: which records are exact variants, comparable alternatives, or unrelated offers—and with what evidence?

The output should be a governed match graph that connects source listings to a canonical product record while preserving the original listing. That enables like-for-like pricing, assortment overlap, seller analysis, and search visibility without erasing meaningful differences.

Define the match classes before choosing a model

These classes must not be collapsed into one confidence score. A high-confidence similar relationship is still not an exact match. Downstream users need both match_type and confidence.

Use identifiers first, attributes second, language third

GS1 defines the GTIN as the identification key for trade items in its current General Specifications. Google likewise explains that manufacturer-assigned identifiers are shared across retailers and warns merchants not to guess or reuse an identifier from a similar product in its unique product identifier guidance. That makes a valid GTIN the strongest common join key—but not a license to skip validation.

1. Validate identifiers. Normalize UPC/EAN/GTIN formatting, verify check digits, and reject placeholder values.
2. Resolve the sellable unit. Compare pack count, net quantity, size, color, model, condition, and included accessories.
3. Use brand plus MPN. Google notes that brand and MPN can identify a product when GTIN is unavailable.
4. Normalize text and units. Standardize abbreviations, Unicode, measurement units, and brand aliases without discarding source text.
5. Apply image or language similarity only as supporting evidence. Use these signals for candidate generation, not proof of identity.

Variant handling deserves special care. Google’s guidance says different colors or sizes require different identifiers, while its structured-data mapping uses item_group_id to group variants. An exact match should occur at the variant level; the family relationship belongs in a separate field.

A production-ready match record

{
  "canonical_product_id": "cp_01842",
  "source": "marketplace-a",
  "source_listing_id": "A123",
  "observed_at": "2026-08-19T06:30:00Z",
  "identifiers": {
    "gtin": "08912345678905",
    "mpn": "BR-500"
  },
  "variant": {
    "size": "500 ml",
    "pack_count": 1,
    "flavor": "original"
  },
  "match_type": "exact",
  "confidence": 0.997,
  "evidence": [
    "gtin_exact",
    "brand_exact",
    "pack_exact"
  ],
  "model_version": "matcher-2026-08-01",
  "review_status": "auto_accepted"
}

Retain the observation timestamp, source URL, evidence, and matcher version. The canonical ID should be stable; the listing ID and attributes can change. Browse PLOTT’s marketplace directory, product information fields, and the retailer use case to map this record into a broader feed.

How to evaluate matching quality

Build a labeled evaluation set stratified by category and difficulty. Include private label, missing GTINs, bundles, multipacks, refurbished goods, near-identical variants, and multilingual titles. Report precision and recall separately for each match class. For price benchmarking, exact-match precision is usually more important than recall: one false match can create a bogus pricing alert.

• Measure results by category, source pair, identifier coverage, and match class.
• Set separate auto-accept and auto-reject thresholds; route the uncertain middle to review.
• Sample accepted matches continuously to detect source or model drift.
• Version corrections so historical analyses can be reproduced.
• Publish coverage: unmatched is a legitimate result, not an error to hide.

Limitations and what a POC must prove

Identifiers can be missing or misused, titles can be seller-authored, images can be shared across variants, and pack information may live only in an image. Similarity models also inherit category-specific failure modes. No honest POC promises 100% automation.

Before production, validate a representative SKU sample across the exact marketplaces, countries, and categories in scope. Agree on match taxonomy, measure precision and recall, inspect the worst false positives, test update behavior when listings change, and confirm the review and correction workflow. Request a matched sample dataset containing your own seed SKUs, source records, match evidence, and unmatched rows—not a cherry-picked generic demo.