Definition
Product data is messy for structural reasons, not careless ones: it arrives from many sources with incompatible schemas, no single role owns it end to end, and much of it is keyed by hand. Two further mechanisms compound those: attributes accumulate as new categories and channels appear and are never retired, and channel-specific overrides get written downstream where they never flow back. Each of the five is a property of how catalogs are built rather than a mistake someone made, which is why the mess reliably returns after any cleanup that leaves the structure untouched.
Key points
- Many sources, incompatible schemas — every supplier, ERP, and acquired catalog models the same product differently, and the mismatch is imported along with the data.
- No single owner — merchandising, ecommerce, and supply chain each edit the record for their own purpose, and none of them is accountable for it as a whole.
- Attributes bolted on over time — fields added for one category or one campaign are never retired, so the schema becomes a sediment record of past decisions.
- Manual entry — spreadsheets and copy-paste introduce typos, unit confusion, and near-duplicates at a steady background rate that never reaches zero.
- Downstream overrides — a value corrected in a marketplace feed or a site-search config never travels back to the canonical record, so the source stays wrong while the symptom disappears.
Why does the mess come back after a cleanup?
Because a remediation project changes values, not mechanisms. It corrects the records in front of it without altering who may write to a record, which schema incoming files are mapped against, or where a channel-specific fix is allowed to live. Within a few supplier deliveries and one new channel launch, the same five mechanisms have regenerated the same conditions. The compounding factor underneath all of them is identity: with no stable identifier shared across sources, "these two rows are the same product" stays a human judgment call, and every judgment call is another opportunity for the catalog to disagree with itself.
Common pitfalls
- Blaming one team, one supplier, or one system for what is structurally a multi-source problem with no arbitration layer.
- Buying a PIM and expecting the tool to supply the ownership model and standards that it can only store and enforce once someone has decided them.
- Running a large one-off remediation without changing intake validation, which guarantees a repeat of the same project.
FAQ
Is one bad supplier usually the cause?
Rarely. A single non-compliant supplier is conspicuous and comparatively easy to fix. The persistent mess comes from many sources that are each internally reasonable but mutually inconsistent, combined with no arbitration layer deciding whose version of a contested field wins.
Does buying a PIM fix this?
A PIM gives you one place to hold the record and a mechanism to enforce rules, which removes some causes outright. It does not decide who owns which attributes, which schema suppliers map to, or whether channel teams may override values downstream. Those are governance decisions, and no tool supplies them for you.
Source
The identity problem underneath several of these causes is what the GS1 GTIN standard addresses, defining globally unique identification keys so the same trade item can be matched across trading partners instead of reconciled by name and description. The synchronization layer built on those keys is GS1's Global Data Synchronization Network (GDSN).