The same product data problem keeps showing up in different places.
You have fixed this before. Maybe not this exact attribute or this retailer, but the pattern is familiar. Something was wrong in a channel, a few people spent a week correcting it, and everyone moved on.
Then it happened again somewhere else.
The fix went where the problem showed up. It rarely goes where the problem started.
Take a package dimension entered incorrectly during item setup. The system sends the record downstream. A retailer publishes it. A shopper reads it on the product detail page, places the order, opens the box, and finds something that does not match. It goes back.
By the time the return surfaces, that incorrect value has already moved through several systems and created work for teams that did not enter it. Fixing the return addresses where the problem appeared. It leaves the original value, and the process that carried it downstream, untouched.
One wrong measurement travels the same path your product does
Product information doesn’t get referenced from a distance. It gets copied. Each handoff between item setup, the feed, and the retailer page produces another copy of whatever the previous step contained, and none of those copies carry any memory of being wrong.
That’s what makes a small error expensive. It isn’t sitting still while someone reviews it. It’s moving through the same distribution path built to move correct information quickly, at the same speed, with the same efficiency. The wrong package dimension reaches the shopper by working exactly as designed.
By the time anyone can see the mistake, it exists in several places at once, and the version the customer saw is the only one anybody is looking at.
The bill gets split across teams that never touched the data
Helen Grimster put it plainly during this webinar: bad data isn’t shy. It introduces itself to half the organization.
That’s the part most cost conversations miss. The wrong dimension doesn’t produce one invoice. It produces a support conversation, a credit, a shipping cost, a retailer relationship that needs tending, and an afternoon of someone’s time reconstructing what happened. None of those are large enough to escalate on their own, and none of them belong to the person who entered the number. The pattern shows up at scale: 26% of shoppers say they’ve returned a product in the last six months because it didn’t match what they saw while shopping, up five points from the year before.
So the cost gets absorbed instead of counted. Every team pays a small share out of a budget meant for something else, and no line item anywhere in the business is labeled incorrect package dimension. A problem nobody can see the full price of is a problem nobody is funded to solve at the source.
No one along the way confirms that the copies still match
Look back at the sequence and notice what isn’t in it. Item setup created a value. The feed moved it. Retailers published it. At no point did anything compare the version on the retailer’s page against the version in the record it came from and ask whether they still agreed.
That absence is the actual gap. The organization isn’t short on people who care about accuracy. It’s short on a step whose job is to confirm that the copies still match, and the return can’t do that job because it only fires after a customer has already acted on the wrong number.
Until something owns that check, every correction is a manual catch-up against a copy that already moved.
Manual work gets slower and less accurate long before it breaks
The gap usually gets filled by a person. Someone keeps a working file, watches for changes, re-keys values into a retailer portal, and remembers which fields that particular retailer treats differently. It works. It works well enough that no one classifies it as a risk.
What it does instead is decay. As products, retailers, and required fields multiply, the same routine takes longer, covers a smaller share of what’s changing, and depends more heavily on details that live in one person’s head. There’s no failure event to point at. There’s a slow rise in exceptions, and a growing distance between what the record says and what the channels are showing.
The manual check that once caught the wrong dimension doesn’t stop working. It just stops reaching everything.
Each new channel makes another copy of the same mistake
Every channel you add takes another copy of the product record and formats it to its own requirements. Add a marketplace, a new retailer, a regional site, and you haven’t added one destination. You’ve added another version of every product detail, maintained separately from the rest.
Now correcting the package dimension in one place fixes one place. The other copies keep publishing the original value, and each one can generate its own returns, its own retailer flags, and its own round of investigation. The error doesn’t spread. It gets duplicated, and the cost of correcting it rises with every destination.
This is the mechanism behind the recurring problem. Not carelessness, and not a team that needs more training. A detail that gets copied faster than anyone can verify it, into more places than any manual routine can reach.
Three questions to ask before moving forward
- The last time a product data problem surfaced, was it fixed where it appeared or in the record it came from?
- If the same product detail lives in several systems right now, what would tell you they disagree, and who would see that signal?
- How much of the work keeping product information current depends on one person’s routine that isn’t written down anywhere?
If the answers are uncomfortable, that’s useful. It means the problem is findable.
What this category is called
The practice of keeping product information in one record that teams and channels work from has a category name: product information management, usually shortened to PIM. It describes both a way of working and the software built to support it, and it exists because the copying problem above needs an owner rather than a heroic effort. PIM is a category rather than a single product, and providers define its edges differently. What it does, what it doesn’t do, and what it would actually check are the subject of the next article.
