Most distributors treat the catalog as a file they upload. It is actually a record they own, and the difference shows up about six months in, when the data is measurably worse than the day they started maintaining it.

That is the strange part. The catalog does not decay from neglect. It decays from maintenance.

What is catalog data quality for a distributor?#

Catalog data quality is whether every product record carries the identity, attributes, units, and pricing a buyer or a machine needs to find the right part and order it without calling a rep. Not whether the record exists. Whether it is usable at the moment of the search.

The operator consequence is blunt. A part your system carries but cannot surface is inventory you paid for and cannot sell online. It sits in the bin, it is in the ERP, and it is invisible to the person trying to buy it. Every hour a rep spends being a human search engine is an hour spent compensating for a blank field.

Where does distributor product data actually go bad?#

It rots in five specific places. Almost every catalog problem you have is one of these.

Missing filter attributes. A buyer narrows by bore size, seal type, or environmental rating, and correct products vanish from the result set. Not because the parts are wrong. Because the field is blank, and a blank field fails every filter. This is the most expensive one and the least visible, because nothing errors out. The buyer just concludes you do not carry it.

Inconsistent units of measure. Each, box, case, and 100-pack all living in one quantity column. A buyer orders 10 expecting pieces and receives 10 cases. This is the failure that costs real money on the first order and real trust on the second.

Supplier descriptions carried over verbatim. Two identical parts from two suppliers read as two different products because nobody normalized the language. Your catalog now has an internal disagreement about what it sells.

Duplicate records. The same item lives under a house SKU and under a manufacturer part number, and nothing links them. Stock looks split, pricing drifts apart, and neither record is fully populated because the enrichment work got done twice, on two halves.

Prices that mean something else in the source system. A 0.00 in an export is the classic one. In some source systems that means unpriced. Import it literally and you have just published a free part.

Why does the catalog get worse every time you maintain it?#

Here is the mechanism, and it is worth understanding precisely because the fix is a rule, not a project.

Most import routines treat an incoming file as the truth for every column in it. If the file has an empty cell, the import writes the empty cell. So an enrichment pass that fills in 400 seal-type values on Monday gets silently erased by Tuesday night's supplier feed, which does not carry seal type at all and therefore sends blanks.

Nobody notices, because nothing failed. The import reported success. The work is just gone.

Take a 6205-2RS deep groove ball bearing. Its useful attributes are bore, outer diameter, width, and seal type: 25mm, 52mm, 15mm, and contact rubber seals on both sides. Your inside sales manager types those in on Monday because a buyer complained they could not filter for sealed bearings. The supplier's price-and-stock feed runs Tuesday at 11pm. It carries part number, price, and quantity, and nothing else. Wednesday morning the bearing is back to being invisible in the sealed-bearing filter, and the only person who knows is the buyer who gives up and calls a competitor.

Two rules stop this permanently.

Empty never beats data. An absent or blank incoming value never nulls a populated field. A re-import merges field by field instead of replacing the record wholesale. This one rule eliminates most catalog decay outright, and it is the difference between an import that enriches and an import that overwrites.

A human correction outranks the next feed. When someone fixes a field by hand, that field is theirs until an admin explicitly releases it back to source control. Otherwise you are asking your team to do work that the system is designed to undo.

How do you tell which product record is right?#

Last-write-wins is not a conflict policy. It is the absence of one, and it means the correctness of your catalog depends on the order your imports happened to run.

Give every source a precedence rank instead. A low-confidence enriched value should be displaced automatically the moment a real source supplies that field, quietly and with a record of it. Two real sources that disagree are a different situation entirely: that is a judgment call, and it should park for human review rather than silently swapping values every time each feed runs.

Keep identity strict while you are at it. One primary key per product. Barcode and manufacturer part number are useful as secondary match keys, but they should feed a review queue, never trigger a silent merge. Secondary keys are wrong often enough that an automatic merge on one will eventually fuse two genuinely different parts into a single record, and unmerging is far harder than merging.

Competitor part number matching is a related problem worth solving, but it is a lookup layer over a clean catalog, not a substitute for one.

Why does an audit trail matter more than a clean export?#

Because the question that actually comes up is never "is the catalog clean." It is "who changed this price, from what, and when."

A field-level change log answers that in ten seconds. Without one, every data dispute becomes an argument between two people who are each confident and neither of whom can prove anything. And an organization that cannot resolve those arguments never fully trusts the catalog, which means it never turns off phone ordering, which means the whole self-service investment stays half-finished.

The framing that matters: the catalog is a durable asset that should improve over time. Not a cache of the last upload. If your product data is worse than it was a year ago, you do not have a data problem, you have an architecture problem.

What changes when buyers start at an AI answer?#

The penalty for a thin attribute is changing, and it is getting worse.

Salsify's 2026 Consumer Research, a survey of nearly 3,000 respondents across the US, UK, and Canada, found that 61 percent of shoppers now use AI shopping tools in some capacity, and 22 percent incorporate AI search tools like ChatGPT into their buying journeys. The same research found that 31 percent of shoppers were convinced to purchase when detailed product descriptions and specifications were supplied by an AI shopping tool.

That is consumer research, not distribution data, and it should be read as a signal about behavior rather than a forecast for your MRO business. But the mechanism transfers, and the direction is not ambiguous. Industrial buyers are the same people on a weekday.

Here is why it matters structurally. A thin attribute used to mean ranking lower in a site search. The product still appeared, just further down, and a determined buyer found it. When a machine is assembling the answer, a thin attribute means not being considered at all. There is no page two. A specification a machine can quote back with confidence is the only thing that gets surfaced, and blanks are not quotable.

Which reframes the seal-type field on that 6205-2RS. It was a filter nicety. It is becoming the thing that decides whether the part exists to the buyer.

A short cleanup order of operations#

If your catalog needs work, the sequence matters more than the ambition.

Start with the attributes your buyers actually filter on. Not the whole schema. Pull the filters your store exposes and the questions your reps answer most, and fix those fields first. The rest of the schema can wait indefinitely and usually should.
Fix units of measure before descriptions. Wrong quantities cost real money and real credibility. Bad prose costs neither.
Resolve duplicates through a review queue. Never a bulk automatic merge. The time you save is not worth the records you fuse.
Turn on change history before the first big import. Not after the first dispute. A change log that starts today cannot tell you what happened last quarter, and last quarter is exactly what someone will ask about.

Where this fits#

Copiara is being built as a Shopify app, and this is the part of the job it takes. Shopify stays the system of record for your products: your variants, your images, your base prices, your inventory. What Shopify has nowhere to put is the layer that decides whether a part is findable, so Copiara's catalog enrichment holds it alongside: the attributes, the provenance, and the field-level change history. Imports enrich rather than blindly overwrite, a hand correction outranks the next feed for that field, and every mutation writes a revision so the record has a history rather than just a current state.

The Copiara concierge sits on the same data and carries the same honest limits: it cross-references a competitor part number only when a valid cross-reference exists, it works from the buyer's own company pricing and stock, and it does not invent an answer for a part that is not in your usable catalog data. That last constraint is the point. A concierge grounded in your catalog is exactly as good as your catalog, which is another argument for fixing the attributes first.

Copiara is not on the Shopify App Store yet. If you run a distribution operation and the catalog decay described above sounds familiar, talk to us.

Catalog Data Quality for Distributors: Where It Rots