Bad Product Data Is a Customer ProblemFirst

Most companies discover their product data problem through IT: an import that fails, a sync that breaks, a ticket that waits in a backlog. So they treat it as an IT problem, and they look for an IT fix. But the customer met the problem long before anyone wrote the ticket. The reality is simple: bad product data is a customer problem before it is an IT problem.

What a buyer does when the data is missing or wrong

In a store, a buyer can pick up the box, read the label and ask someone. Online, the product page is the box, the label and the salesperson at the same time. When a field is empty or wrong, there is nobody to ask, so the buyer does one of three things.

• Hesitates. The size, the compatibility or the ingredient they need is not on the page, so they open another tab to check somewhere else, and often they finish the purchase there.
• Leaves. They search with their own words, filter on the attribute that matters to them, and get nothing, or get the wrong products. For them, your product does not exist.
• Returns. They bought on the information that was shown, and what arrived is different. The sale becomes a cost, and some of the trust leaves with the parcel.

The last one is well documented. Hong and Pavlou (2014) in Information Systems Research define product fit uncertainty as the degree to which a consumer cannot assess whether a product's attributes match their preference. The authors report that, compared with uncertainty about product quality, it had a significantly stronger effect on product returns. Their data came from consumers who had recently bought through buy-it-now listings on an online marketplace, so it is one setting, but it shows why a missing or vague attribute is not a cosmetic issue.

None of these behaviors looks like a data problem from the inside. It looks like a conversion problem, a search problem or a logistics problem, and that is why it so often lands on the wrong team.

Where it shows up in the numbers you already watch

You do not need a new dashboard to see bad product data. It already sits in reports that other teams own, under other names.

• Zero-result searches. Your site search logs show what customers typed and what came back empty. Often those empty results are not missing products, they are products described with words or attributes the customer does not use.
• Returns. Return reasons such as "not as described" or "wrong size" point straight to a field on a product page.
• Marketplace rejections. When a marketplace or a retail partner rejects a listing, the reason is often a missing mandatory attribute, a wrong category or an identifier that does not match.
• Support tickets. Every question like "is this compatible with my model?" or "what are the dimensions?" is a customer asking for data the page should have given.

If we go deeper, these four signals share one root. They are measured downstream, by people who cannot fix the cause, because the cause sits upstream, in the catalog.

A field story: when the catalog learned the customer's words

On the D2C site of a global petcare brand, too many customer searches came back with nothing. The products were there. The problem was how the catalog was organized: categories and attributes reflected how the company saw its range, not how pet owners look for a product.

The answer was not a new search engine. The catalog categories and attributes were reworked for search, so they matched what people actually look for and so the search could use them. In a year, searches returning zero results dropped from about 8% to about 2%, a figure reported by the client team.

From the customer side, nothing looked like an IT project. They simply found the product. That is the whole point: the fix was in the data, but the result was in the customer's hands.

What to fix first

Once a team accepts the problem is real, the reflex is often to buy a new tool or to launch a big enrichment campaign. Both can help, but only after the basics are in place. This is the order I would follow.

The data model

Families, attributes and variants decide what a product page can say and what a filter can offer. If the model is wrong, nothing built on top of it can be right. A European DIY retailer had built its catalog on a supplier classification: 1,324 flat families, each carrying between 196 and 385 attributes. With that many attributes per family, completeness meant nothing, and teams could not tell what was really missing for a shopper. A classification made to exchange data between companies is useful, but it is not the structure a shopper needs.

The attributes customers filter on

Not every attribute deserves the same effort. Start with the ones customers use to narrow their choice: size, compatibility, material, age, dietary need, whatever decides the purchase in your category. Your zero-result searches and your filter usage tell you which ones they are. Make them mandatory, turn them into controlled lists instead of free text, and fill them before anything else.

Identifiers

A barcode or a GTIN is a promise to everyone outside the company: marketplaces, retailers, distributors, comparison sites. When it is wrong, the product gets rejected, merged with another one or listed twice. In a global petcare catalog, 67% of products shared a duplicated barcode, caused by product versioning and low GS1 maturity. Correcting that later means going back to every partner who already received the data. The cheapest moment to get identifiers right is the first one.

The rules are not even the same from one channel to the next. Niemir and Mrugalska (2022), in a conference paper at AHFE, compared how major marketplaces, e-commerce platforms and comparison services handle basic attributes such as brand, product image, net content and classification. Mandatory fields, formats and validation rules differed from one platform to another, and most used their own categories instead of a global standard. The authors conclude that it is currently not possible to use one set of product data for all e-commerce platforms. Their comparison is based on platform documentation, not live catalogs, but the lesson holds: every channel takes its own copy of your data, so the master record behind it has to be clean and owned.

Ownership

Every field needs a name next to it: who creates it, who validates it, who answers when it is wrong. Without that, data quality depends on goodwill, and goodwill does not scale. Many problems that look like missing tool features are in fact missing owners. Data coming from suppliers is usually where this breaks first (see why supplier data is where PIM projects fail). If your catalog still lives in spreadsheets, Excel vs PIM explains when a spreadsheet stops being enough.

To connect these fixes with the four signals from earlier, here is where each signal usually points:

The customer is now sometimes an AI assistant

More and more buyers start by asking an AI assistant what to buy. The assistant does not browse your pages the way a person does. It reads structured facts, compares them, and recommends the products it can describe with confidence. If an attribute is empty, inconsistent across channels or hidden inside a paragraph of marketing text, the assistant has nothing solid to work with, and it recommends a product whose data is clearer.

So the same fixes now serve two readers at once: the person on the product page, and the assistant that answers before that person ever reaches it. A clean model, filled filter attributes, correct identifiers and clear ownership are exactly what make a product easy to recommend. I go deeper on this in why products do not appear in AI search results.

Regulation pushes in the same direction. Rules on product information, labeling and environmental claims ask for structured, traceable data, especially in the EU, so the work you do for customers also prepares you for compliance. See why EU sustainability rules are a product data problem.

Start from the customer, not from the ticket

Listen, nobody is saying IT does not matter. Integrations, imports and platforms are real work, and they deserve to be done well. But it is not because the symptom appears in an IT system that the cause is technical. The cause is usually a model, a missing attribute, a wrong identifier or a field nobody owns, and the first person who pays for it is the customer.

So the next time a product data issue arrives as a ticket, ask a different first question: what did the customer see, and what did they do next? The answer usually tells you what to fix first.

If you want a second pair of eyes on your own catalog, I work as an independent PIM consultant and can review it with you, starting from what your customers actually search for.

Sources: Hong, Y. and Pavlou, P. A. (2014). Product fit uncertainty in online markets: Nature, effects, and antecedents. Information Systems Research, 25(2), 328-344. https://doi.org/10.1287/isre.2014.0520. Niemir, M. and Mrugalska, B. (2022). Product data quality in e-commerce: Key success factors and challenges. AHFE International, 36. https://doi.org/10.54941/ahfe1001626.