Guide / Digital Systems & Commerce
A Product Identifier Is More Important Than It Looks
Distinguish internal IDs, supplier references, SKUs and GTINs. Preserve identity, packaging context and mappings before automating downstream catalogue work.
A product title changes, a supplier updates its reference, and an import creates a second record for an item already in the catalogue. The duplicate looks like a data-cleaning problem. Its root cause is often a missing decision about identity: which value represents the product, who controls it and whether it is allowed to change.
Identifiers carry relationships through the system. Prices, stock, images, orders and marketplace listings attach to them. When identity is ambiguous, every downstream operation must guess whether it is updating an existing item or creating a different one.
If you cannot reliably identify the product, every downstream automation is negotiating with ambiguity.
Distinguish the identifier’s scope
An internal product ID belongs to the catalogue’s own model. A supplier reference identifies something within a supplier’s system. A SKU is a stock-keeping reference used within an organization’s inventory or selling context. A GTIN belongs to a standardized trade-item identification system.
These identifiers may coincide in a small workflow, but treating them as interchangeable creates fragile assumptions. Two suppliers can use the same local reference for different items. One product can appear under several supplier references. A business can change its SKU convention without intending to change the product itself.
Represent scope explicitly. A supplier reference generally needs the supplier identity alongside it. An internal ID should remain stable even when display labels change. A mapping table can connect external references to internal records while preserving who asserted the relationship.
Avoid using a product title as a primary matching key. Titles are descriptions, often edited for readability, language or marketing. Similar titles can describe different variants, while different titles can describe the same item.
Understand what GTIN identifies
GS1’s GTIN Management Standard defines rules for decisions about trade-item identification, including changes that may require a new GTIN. It should be consulted for the actual product change rather than replaced with an informal rule that every modification always creates a new identifier.
GTIN and EAN are often used loosely in catalogue conversations. Keep the identifier distinct from the barcode representation and the field label used by a particular supplier. A column called EAN needs a documented accepted format and meaning; the name alone does not establish that every value is valid or correctly assigned.
Preserve identifier strings, including leading zeros where relevant. Numeric storage and spreadsheet coercion can alter representation. Validation should check the applicable format and check digit rules, but passing those checks does not prove that the identifier belongs to the stated product.
That final relationship requires provenance. Record where the value came from and how it was matched. A mathematically valid identifier attached to the wrong record can be more dangerous than an obviously malformed one because it passes basic automated checks.
Packaging changes the object being identified
A single unit, a multipack and a case can represent different trade items or selling units. The catalogue must know which object a reference describes. Otherwise a price or stock update can be applied at the wrong packaging level.
Model the relationship explicitly: the sellable item, its packaging context and any conversion needed by the workflow. Do not infer that a supplier quantity is expressed in the same unit the storefront sells merely because both records share a recognizable product name.
This distinction matters during matching. Two records with the same brand and description may differ in pack size. A similarity-based match can look convincing while joining a unit to a case. The resulting error can propagate into price, availability and order fulfillment.
Use known packaging attributes as part of the review evidence. When the information is missing, hold the match for clarification rather than silently selecting the closest-looking record. Ambiguity is a state to resolve, not a reason to invent an identifier relationship.
Keep aliases without losing authority
External identifiers change. A supplier may replace a reference or merge catalogues. Keeping an alias can preserve continuity, but aliases need lifecycle information. An old reference should not remain an unrestricted synonym if the supplier later reuses it for another item.
Record the mapping’s source, status and effective context. Depending on the workflow, that may include validity dates or supplier catalogue revisions. The model should support explaining why a particular input matched a particular internal product at the time it was processed.
A mapping is a claim about identity, and claims need provenance.
Avoid allowing every import to overwrite mappings automatically. A newly supplied reference that conflicts with an accepted relationship should create a reviewable exception. The operator needs to see both the old relationship and the proposed replacement.
The supplier-data article describes the broader interface contract. Identity rules are a central part of that contract because they determine where every other supplied value will land.
Separate matching from merging
Matching identifies a possible relationship between records. Merging changes the catalogue based on that relationship. Keeping these stages separate makes uncertain matches reviewable before they affect orders, stock or publication.
A deterministic exact match under a trusted scoped identifier may be suitable for automatic processing. A match based on normalized descriptions, dimensions or brand may require additional evidence. The confidence needed depends on the consequence of a mistaken merge.
Do not use a single confidence score as a substitute for explaining the evidence. A reviewer should know which attributes agree, which conflict and which are missing. A high score can conceal a decisive packaging mismatch if the scoring model rewards many superficial similarities.
When records are merged, preserve references needed by downstream systems and a history sufficient for correction. Deleting the losing record without considering existing links can leave orders or marketplace mappings pointing to something that no longer exists.
Test identity invariants
Identity rules make good regression tests because their failures can affect many workflows. An internal ID should remain stable when a title changes. Two suppliers using the same local reference should not collide. A unit and a case should not merge solely because their descriptions match.
Use fixtures that represent these distinctions. Include leading zeros, renamed supplier references, unknown identifiers and conflicting mappings. Tests should assert the intended relationship, not simply that the parser returns a string.
Also test repeated imports. The same accepted record should update the intended product without creating another one. A changed identifier should follow the documented alias or review path. A missing identifier should not cause the system to fall back silently to a weaker match.
These checks protect the catalogue’s structure, while human review handles judgments that remain outside the automated contract. The two complement each other: tests prevent known mistakes from returning, and review addresses evidence the system cannot confidently interpret.
Expose identity carefully in operator interfaces. Show the human-readable description alongside the stable internal reference and relevant supplier scope. A screen that displays only titles makes similar variants hard to distinguish; a screen that displays only opaque IDs makes review unnecessarily difficult. The combination helps a person confirm the object before approving a mapping, especially when images or descriptions are shared across several packaging levels.
Make correction possible without rewriting history
A mistaken identity mapping can contaminate several systems before anyone notices. Recovery requires knowing which records and deliveries used it. Provenance and run history make that investigation possible; a current mapping table alone may not.
Correct the mapping through an explicit process, then reconcile affected outputs. Replaying every historical operation blindly may create new problems, especially when orders or customer communications are involved. The appropriate repair depends on which effects can be changed and which must remain part of the record.
Document the distinction between an identifier change, a product change and a correction to a previously wrong mapping. They may look similar in a database update while carrying different business meanings.
The identifier deserves design attention early because it becomes infrastructure for everything that follows. A clear identity model lets automation attach facts to the right object consistently. Without it, even a well-tested transformation can deliver accurate values to the wrong product.