THE SHORT ANSWER
Treat product identifiers as stable text keys. Check duplicates within the correct merchant and market scope, preserve leading zeros, and inspect whitespace or case normalization before merging records. A duplicate warning should trigger identity review rather than automatic deletion.
Define the scope of uniqueness
An identifier may be unique within one merchant but collide across several stores. Document whether your pipeline uses merchant, source, market or destination context alongside the item key. Without that scope, a multi-client import can accidentally merge unrelated products.
Keep source identity and destination identity linked explicitly. If a destination requires a transformed key, retain the original and the transformation rule. Avoid relying on a row number, title or current URL as a permanent identifier.
Preserve text through every handoff
Spreadsheets can remove leading zeros or display long values in scientific notation. CSV readers can also infer numeric types. Configure identifier columns as text and test raw exported values, particularly after an analyst opens and saves a file manually.
Do not repair identity by applying one global padding rule without evidence. A shortened identifier may reflect formatting damage, but it can also be a legitimate different key. Compare with the authoritative source before changing the value that downstream systems use to recognize a product.
Classify collisions before resolving them
Duplicate rows may be exact repeats, separate variants with a reused key, or market offers that need additional context. Compare product facts and source references. The right fix depends on whether the catalog contains one sellable item or several.
Whitespace and case differences also deserve a documented policy. Normalizing them can expose accidental duplicates, but it can merge meaningful keys in a case-sensitive source. Keep the original text and show the proposed normalized relationship during review.
Make identity changes an explicit migration
Changing a key can look like a new product to a destination. Plan how the previous identity is withdrawn or updated under that destination’s contract. Retain the old-to-new relationship so support teams can explain historical exports.
Add a regression sample containing leading zeros, long numeric-looking keys, accented text and known collision cases. Recheck after parser or mapping changes. Identity quality is infrastructure: a small formatting correction can affect every later approval and release comparison.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative example: two stores both use SKU 0012. The combined workflow originally joins on SKU alone and overwrites one record. The corrected internal key includes store context while preserving each original SKU. A preview confirms that neither product inherits the other store’s approvals.
Your practical checklist
- Define uniqueness within merchant and market scope.
- Store and export identifiers as text.
- Classify exact duplicates versus reused keys.
- Review normalization before merging records.
- Keep an old-to-new map for intentional identity changes.
Common questions
Should duplicate rows be deleted automatically?
Only after the workflow establishes that they are truly redundant and the decision is recoverable. Different sellable items can share a mistaken key.
Can I use a product title as the unique key?
Titles change during merchandising and enrichment. Use a stable source identifier with documented scope instead.
Sources & scope
Official references checked 29 October 2026. Examples are illustrative, not customer results. Platform requirements can change; use current destination documentation for implementation decisions.
Our editorial method & corrections ↗