Bad product data rarely announces itself. It passes every check, populates every field, and reaches every channel looking exactly like the truth. That is precisely what makes it dangerous.
That product description reads confidently, is formatted correctly, and has been distributed to nine sales channels without a single system flagging it as problematic. The weight is listed. The materials are specified. The certifications are cited. Everything looks right.The weight comes from an older model that was discontinued two years ago. The material specification was carried over from a supplier data sheet that no one has verified since the manufacturer changed the formulation. And the certification was listed as expired eight months ago, but with no centralized product information to keep compliance and catalogue teams in sync, the field was never updated.
No error message. No red flag. No audit trail pointing to the problem. The data looks healthy because every system it passed through was designed to check whether the fields were populated, not whether the fields were true.
This is the core of the product data problem, and it is why it persists in organisations that believe they are managing it well.
What harmful product data actually looks like
The word “bad” is misleading when applied to product data, because it implies something visibly broken. In practice, the most damaging product data errors share four characteristics: they are complete, they are formatted correctly, they are consistent with surrounding records, and they are wrong.
The most common forms are not exotic. Outdated specifications presented as current are everywhere, particularly in manufacturing businesses where products evolve faster than the systems that describe them. Inferred attributes, where someone filled a gap with a reasonable guess rather than a verified fact, are common in businesses that onboard products at speed. Translated content that has drifted from its source meaning accumulates silently in any organisation selling across multiple markets. And duplicated records that contradict each other across channels create a situation where two people in the same company, looking at the same product in different systems, are working from different facts.
None of these looks broken. They look populated. The distinction matters enormously when you are trying to find them.
The data that causes the most damage is rarely the data that looks broken. It is the data that looks fine.
Why the pipeline is designed to miss it
To understand why harmful data passes undetected, it helps to trace how product information actually moves through a typical business. A product originates with a manufacturer or supplier, who provides a data sheet. That data enters an internal system, usually an ERP or a spreadsheet, where it gets formatted and categorised. It then moves to a Product Information Management system, or directly to sales channels, where it gets adapted, enriched, and distributed. At each handoff, the implicit assumption is that someone upstream has already verified it.
That assumption is rarely examined. The person who receives the supplier data sheet is often a purchasing or logistics team member whose job is to get the product into the system, not to audit the data quality. The person who formats and distributes it is often in marketing or operations, working from what is already in the system. The person responsible for the channel listings is often a digital team managing hundreds of products simultaneously. Nobody in this chain has a complete view of how the data was created or whether it remains accurate. Errors do not get caught at handoffs. They get inherited.
The result is what data quality practitioners sometimes call confidence without verification: a system that passes records forward efficiently while never questioning whether the records are true. The more automated and integrated the pipeline, the faster errors propagate and the harder they are to trace back to their source.
What to look for in your own pipeline
Most harmful data errors cluster around the same failure points. Ask these questions about your current setup:
- Where does product data first enter the business, and who is accountable for its accuracy at that point?
- When a supplier changes a specification, which team finds out, and how does that change reach every system that holds the old value?
- Which fields in your product records were populated by a person making a judgment call rather than by a verified source document?
- How old is the oldest product record in your active catalogue, and when was it last audited?
- If a product description contains an error today, how many channels would it need to be corrected across, and how long would that take?
The answers tend to be uncomfortable. That discomfort is the data quality problem made visible.
Nobody is adding up the cost
The financial impact of bad product data is large and almost universally underestimated, in part because it rarely appears as a single line item. Gartner’s research into data quality costs has consistently placed the average annual impact for large organisations in the tens of millions of dollars, with a widely cited figure of $12.9 million per year. The National Retail Federation reported that US consumers returned $890 billion worth of products in 2024, and industry research has persistently identified misdescription as a leading driver of avoidable returns, though the precise attribution varies by product category and retailer.
In the food and consumer goods sector, the picture is sharper still. The most common reason for product recalls in the United States is incorrect allergen labelling, a problem that sits exactly at the intersection of product data and physical reality. The FDA’s enforcement statistics show recall activity running at elevated levels in recent years, with direct costs per incident routinely exceeding the low seven figures when legal exposure, remediation, and lost sales are included. According to research published by the Food Marketing Institute, a significant majority of consumers report reducing or stopping purchases from a brand after a product safety incident, a figure that understates the full reputational damage, since it captures only the customers who are aware the incident occurred.
What makes these figures consistently underestimated is that the costs sit in different budgets. Returns appear in logistics. Complaints appear in customer service. Recalls appear in legal. Nobody adds them up and labels the total “product data failure,” even when that is exactly what it is. The result is that organisations treat these costs as operational friction rather than as a symptom of a fixable structural problem.
Where the problem either gets fixed or gets worse: the role of PIM
A PIM system is, in principle, the place where this problem gets solved. A PIM is designed to serve as the single authoritative source for everything a business knows about its products: specifications, attributes, certifications, descriptions, images, pricing rules, and channel-specific variants. When a PIM is well governed, a change to a product record cascades cleanly to every downstream channel. When it is not, it becomes the engine that distributes bad data everywhere simultaneously.
The difference between the two outcomes is not primarily a question of which PIM software a business uses. It is a question of what data governance practices exist around it. A PIM that accepts unverified supplier data without validation, allows fields to be populated without an auditable source, and has no workflow for reviewing content before publication will faithfully distribute whatever it receives. It will do so at scale, across every channel, in every language, with complete technical efficiency.
Good PIM governance looks quite different in practice. It means that every attribute has a defined owner, not just a field name. It means that changes to product specifications trigger a review process rather than an automatic update. It means that gaps in product records are flagged explicitly rather than silently filled by whoever last touched the record. And it means that the chain from supplier data sheet to published description is traceable, so that when an error is found, its origin can be identified and the fix can be applied at the source rather than patched individually across thirty channels.
This kind of governance is not glamorous work. It requires decisions about who owns what data, how conflicts between sources are resolved, which fields require verification before publication, and how frequently active records are audited. Most organisations skip these decisions during implementation because they slow down the rollout. The cost of skipping them shows up later, quietly, distributed across returns and complaints and recall notices.
What good PIM governance requires in practice
These are not software features. They are organisational decisions that a PIM system can support but cannot make for you:
- Assign explicit ownership to each product attribute, not just to the product record as a whole. The person responsible for the specification field should be different from the person responsible for the marketing description.
- Build a distinction between fields that require a verified source document and fields that can be populated by judgment. Treat them differently in your review process.
- Create a process for what happens when a supplier updates a specification. It should reach the PIM record automatically or through a defined handoff, not wait until someone notices the discrepancy.
- Set a review cadence for active records, not just for new product onboarding. Product data that was accurate at launch degrades over time and needs to be treated accordingly.
- Before enabling any AI content generation, establish what the AI will use as its input. If the input is unverified, the output will carry the same errors forward with added fluency.
The build-vs-buy question, honestly
Enterprise PIM systems have traditionally carried significant licensing costs and vendor-controlled roadmaps, which means that some of the decisions about how product data is structured, governed, and enriched are effectively made by a third party. Open-source alternatives change this: when the code is freely available and self-hostable, the organisation owns its data pipeline outright, can define its own validation logic, and is not dependent on a vendor’s release cycle to implement the governance rules its products require.
But the tradeoff is real in the other direction too. Open-source platforms shift the cost from licensing to implementation and maintenance. For organisations without dedicated technical teams, that trade is not obviously favourable. The governance decisions that determine data quality outcomes are the same regardless of which system an organisation uses; the question is whether the organisation has the internal capacity to enforce them without vendor support, and whether the flexibility of an open platform justifies the overhead of owning the infrastructure.
For businesses managing complex product catalogues across multiple markets — particularly in sectors where data accuracy carries legal or safety consequences, the calculus tends to favour platforms that can be configured deeply rather than customised superficially. This is the profile that open-source systems built on extensible data foundations are designed for: organisations that need genuine control over data structures, integration with existing ERP and e-commerce environments, and the ability to scale without renegotiating a licensing agreement each time requirements grow. AtroPIM sits in this category. It’s an open-source platform built on a broader data layer, deployable on-premise or in the cloud, with a modular architecture that allows organisations to start with core functionality and expand as needed.
For businesses where catalogues are simpler and speed of deployment matters more than configurability, a well-governed enterprise platform may be the more practical choice. The licensing model is ultimately a secondary consideration. The governance model is not.
What genuinely healthy data requires
There is a useful distinction between data that looks healthy and data that can demonstrate it is healthy. Most product data management sits in the first category. The goal is to reach the second.
Data that can demonstrate it is healthy has four properties that most product records lack. First, it has a traceable origin: every attribute value can be linked to a source document or a verified input, not just to “whoever last edited the record.” Second, it has a known age: the system records when each field was last verified, not just when it was last modified. A field can be modified without being verified, and that distinction matters enormously for allergen information, safety certifications, and technical specifications. Third, it has defined ownership: a named person or team is accountable for its accuracy, not just for its population. And fourth, it has a change process: when the physical product changes, a defined workflow ensures the data record updates accordingly.
These properties do not emerge from software alone. They require organisational decisions about accountability that most businesses have not made explicitly. The PIM system is where those decisions get encoded, but it cannot make them. That part belongs to the people running the business.
The question behind the question
The original question, why harmful product data looks perfectly healthy, has a straightforward answer: because the systems businesses built were designed to move data efficiently, not to verify it continuously. Completeness and formatting are easy to check automatically. Truth is not. So systems check completeness and formatting, label the result as healthy, and distribute it everywhere.
The practical implication is that improving product data quality is not primarily a technology problem. It is an accountability problem. The data quality improvements that actually hold over time are the ones attached to a specific person’s responsibility, a defined process, and a review cadence. Software can make those things easier to sustain, but it cannot substitute for them.
The businesses that manage this well tend to share one characteristic: they decided, at some point, to treat the product record as something that carries real accountability rather than as a best-effort description that gets corrected when complaints come in. That decision changes what the PIM is used for, what the governance around it looks like, and ultimately what reaches the customer. The data does not become healthy on its own. Someone has to be responsible for it being true.
These are not software features. They are organisational decisions that a PIM system can support but cannot make for you:
- Assign explicit ownership to each product attribute, not just to the product record as a whole. The person responsible for the specification field should be different from the person responsible for the marketing description.
- Build a distinction between fields that require a verified source document and fields that can be populated by judgment. Treat them differently in your review process.
- Create a process for what happens when a supplier updates a specification. It should reach the PIM record automatically or through a defined handoff, not wait until someone notices the discrepancy.
- Set a review cadence for active records, not just for new product onboarding. Product data that was accurate at launch degrades over time and needs to be treated accordingly.
- Before enabling any AI content generation, establish what the AI will use as its input. If the input is unverified, the output will carry the same errors forward with added fluency.
The build-vs-buy question, honestly
Enterprise PIM systems have traditionally carried significant licensing costs and vendor-controlled roadmaps, which means that some of the decisions about how product data is structured, governed, and enriched are effectively made by a third party. Open-source alternatives change this: when the code is freely available and self-hostable, the organisation has full control over its data pipeline, can define its own validation logic, and is not dependent on a vendor’s release cycle to implement the governance rules its products require.
But the tradeoff is real in the other direction too. Open-source platforms shift the cost from licensing to implementation and maintenance. For organisations without dedicated technical teams, that trade is not obviously favourable. The governance decisions that determine data quality outcomes are the same regardless of which system an organisation uses; the question is whether the organisation has the internal capacity to enforce them without vendor support, and whether the flexibility of an open platform is worth the overhead of owning the infrastructure.
For businesses in sectors where product data accuracy carries legal or safety consequences (food, pharmaceuticals, regulated consumer goods) the case for owning the pipeline more completely is stronger, because the cost of a governance failure is higher and the need for custom validation logic is greater. For businesses where the risk profile is lower and speed of deployment matters more, a well-governed enterprise platform may be the more practical choice. The licensing model is a secondary consideration. The governance model is not.
What genuinely healthy data requires
There is a useful distinction between data that looks healthy and data that can demonstrate it is healthy. Most product data management sits in the first category. The goal is to reach the second.
Data that can demonstrate it is healthy has four properties that most product records lack. First, it has a traceable origin: every attribute value can be linked to a source document or a verified input, not just to “whoever last edited the record.” Second, it has a known age: the system records when each field was last verified, not just when it was last modified. A field can be modified without being verified, and that distinction matters enormously for allergen information, safety certifications, and technical specifications. Third, it has defined ownership: a named person or team is accountable for its accuracy, not just for its population. And fourth, it has a change process: when the physical product changes, a defined workflow ensures the data record updates accordingly.
These properties do not emerge from software alone. They require organisational decisions about accountability that most businesses have not made explicitly. The PIM system is where those decisions get encoded, but it cannot make them. That part belongs to the people running the business.
The question behind the question
The original question, why harmful product data looks perfectly healthy, has a straightforward answer: because the systems businesses built were designed to move data efficiently, not to verify it continuously. Completeness and formatting are easy to check automatically. Truth is not. So systems check completeness and formatting, label the result as healthy, and distribute it everywhere.
The practical implication is that improving product data quality is not primarily a technology problem. It is an accountability problem. The data quality improvements that actually hold over time are the ones attached to a specific person’s responsibility, a defined process, and a review cadence. Software can make those things easier to sustain, but it cannot substitute for them.
The businesses that manage this well tend to share one characteristic: they decided, at some point, to treat the product record as something that carries real accountability rather than as a best-effort description that gets corrected when complaints come in. That decision changes what the PIM is used for, what the governance around it looks like, and ultimately what reaches the customer. The data does not become healthy on its own. Someone has to be responsible for it being true.
