Why product records become difficult when names, variants and identifiers disagree

A product file can look tidy and still describe several different things in the same row.

Take “Trail Runner Shoe.” That may be a style family. “Trail Runner Shoe, blue, size 9” is a specific sellable variant. A carton containing six pairs is a different trade item. A retailer’s listing ID identifies that retailer’s offer for one of those items.

All four records are related. They are not automatically the same record.

This is where catalog work gets difficult. The visible conflict may look like a duplicate: names differ, a barcode is missing, or one source says “blue” while another says “ocean.” The deeper problem is often that each source is describing a different level of the product hierarchy.

Start by defining what one row represents

Before asking whether two records match, decide what the table is meant to represent. Depending on the job, one row might stand for:

• a product family or model
• a configured variant
• a consumer unit
• a case or multipack
• a seller’s offer or listing
• a serialized physical item

There is no universally correct grain. A merchandising report may reasonably group all colors and sizes of a hoodie under one product family. A fulfillment system cannot substitute a navy medium for a gray large. A pricing analysis may need to distinguish a single bottle from a 12-pack, even when both contain the same formulation.

Problems begin when a flat file treats these levels as interchangeable because each has a product-looking name.

Names describe products; they do not settle identity

Names are useful evidence. They help people search, review, and understand records. But names are shaped by marketing language, retailer conventions, abbreviated specifications, regional wording, pack counts, and product revisions.

A laptop title may omit memory capacity in one feed and foreground it in another. A retailer may call a color “midnight,” while the manufacturer uses “navy.” A package label may include a promotional phrase that never appears in the supplier catalog.

Standardizing capitalization, punctuation, and common abbreviations can make comparison easier. It cannot determine whether two records are the same sellable item. A marketplace title that leaves out RAM, storage, keyboard layout, or charger configuration is not enough to establish an exact laptop match.

Variant attributes deserve special attention because they often carry the distinction a name obscures. Size, color, fit, voltage, formulation, storage capacity, and region-specific configuration can all matter. Which attributes define a distinct item depends on the product category and the business question, not on a universal matching rule.

Google Merchant Center reflects this distinction in its product data requirements: distinct variants need their own product IDs, while related variants share an item group ID. “Same product family” and “same sellable item” are deliberately different ideas.

An identifier is only as clear as its scope

An identifier can be strong evidence, but it is not a magic answer. A GTIN, manufacturer part number, retailer SKU, marketplace listing ID, and internal catalog key may all look unique. They do not identify the same kind of thing.

Record the identifier type, its assigning party or source, its exact value, and the item level it is meant to identify. This preserves a critical question: unique *to what*?

GS1’s treatment of GTINs is a helpful example. It defines trade items as goods or services priced, ordered, or invoiced at points in the supply chain. Its standards also recognize distinct product variants and packaging quantities. A unit, six-pack, and 12-pack can each require separate identification because they are different trade items.

That matters operationally. A 12-ounce bottle and a 12-pack may share brand, formulation, and a similar name. They differ in quantity, price, storage, replenishment, and barcode identity. Merging them can distort inventory counts and unit-price comparisons.

The same lesson appears in regulated products. The U.S. National Drug Code structure distinguishes a labeler, a specific product, and package size or type. The details are specific to that regulatory system, but the broader point applies widely: an identifier may describe a hierarchy rather than a single undifferentiated product concept.

Preserve relationships instead of forcing a master value

A more durable catalog keeps the hierarchy visible. It can link a product family to its variants, variants to package levels, and package-level items to source-specific offers.

That may mean separate fields or linked tables for product family or model, variant-defining attributes, package quantity and unit, issuer-assigned identifier, source listing ID, source name, and observed or effective dates.

A display title should remain available, but it should not be asked to carry every fact about identity.

When records disagree, use more outcomes than merge or reject. Useful decisions include:

• exact same sellable item
• same family, different variant
• same variant, different package
• source-specific offer
• retired or replaced item
• possible relationship requiring review

A practical review sequence is straightforward: compare identifier type and scope; establish the row’s grain; check variant-defining attributes; check packaging and net content; then consider observed and effective dates. The result may be an exact match, but it may also be a relationship that deserves to remain visible.

A cleaner-looking table is not always a truer one. Forced agreement can quietly misstate availability, prices, regulatory attributes, inventory, or sales performance. A trustworthy product catalog makes room for legitimate disagreement while preserving the evidence needed to explain it later.