Insight

Three acronyms turn up in the same meeting and usually only one of them is relevant. PDM manages engineering definition: CAD files, drawings, revisions and bills of materials. PIM manages the commercial information you sell with: attributes, descriptions, images and channel-ready content. MDM governs the shared master records every system depends on, of which product is one domain. The phrase product data management causes most of the confusion, because it means the first one in engineering and the second one in ecommerce.

Most distributors do not have one product catalogue. They have five, and nobody owns the relationship between them. The ERP holds the list finance and the trade counter trust. The website holds a subset of it with better photography. A spreadsheet on somebody’s desktop holds whatever was last uploaded to a marketplace. Product catalogue management is the work of making those versions agree without maintaining each one by hand.

Search for Amazon listing optimisation and you will be sold copywriting. Better bullets, punchier titles, keyword-rich descriptions. We have rewritten plenty of Amazon copy over fifteen years and it does move numbers. It is also the second-order fix. In Amazon’s own published guidance, what decides whether a shopper ever sees your listing is the structured attribute data behind it. Amazon states the consequence of leaving those attributes empty in one unambiguous sentence.

A Google Shopping feed is not a marketing asset. It is a schema with a validator attached. Every disapproval traces back to an attribute that was empty, malformed, or contradicted by your own website. Google publishes the whole specification. Below is what it requires, which omission triggers which disapproval, and which of those a feed tool can fix. The rest have to be fixed in the PIM.

A marketplace listing rejected on submission is almost never a copywriting problem. It is an empty field, a value the channel does not recognise, or a category mapped to the wrong node. The causes are finite, they are published, and they are all fixable in your PIM before the feed leaves the building.

Search for supplier onboarding and almost everything you find is about procurement. Vendor risk, bank details, compliance questionnaires, master data in the ERP. All necessary, none of it the reason your new range is not on the website. The part that takes the time is product data. Getting a specification, a description, images and a hundred structured attributes out of a supplier, in a state you can sell from. That is a different process with different owners, and most distributors run it as a series of one-offs. Below is the supplier onboarding stage model we use to make it repeatable.

Your new line form is a spreadsheet. It has somewhere between forty and two hundred columns. There is a hidden tab nobody has opened since the person who built it left. The filename ends in v4_FINAL, and the version number stopped incrementing three years ago. A buyer emails it to a supplier. The supplier fills in what they can and guesses the rest. Someone in merchandising fixes it by hand. That loop is where speed to market goes, and it is the same loop in almost every distributor we work with.

A distributor sends us a category export. It has eight or nine hundred rows. We sort by product count and the bottom third of the tree holds fewer than five items per node. Somewhere near the middle there is a level that exists because the website menu needed a third click. Product taxonomy design is rarely a question of how deep the tree should go. It is a question of which decisions belong to categories and which belong to attributes. Depth is what you notice when that split has gone wrong.

Checked on 20 August 2026, the first line of Google’s published English taxonomy file still reads # Google_Product_Taxonomy_Version: 2021-09-21. That Google taxonomy lists 5,595 categories across 21 top-level branches, seven levels deep at its deepest point. The en-GB file carries the same version number. Google describes its own categorisation as “continuously evolving”. The gap between that and a static published file causes most of the mapping confusion we are asked to fix.

Most attribute models we inherit have between 1,200 and 4,000 product attributes, and fewer than 200 of them are doing any work. The rest are duplicates, supplier leftovers, free-text escape hatches and fields that were mandatory for a project that finished four years ago. Nobody deletes them, because nobody can prove they are unused. This is how a data model that was supposed to make products findable ends up making enrichment impossible. Here is how we define, scope, level and govern an attribute model that stays the size it should be.

Data quality assurance on a product catalogue is a rule library, not a dashboard. The dashboard is what you show the board. The rules are what stop a broken SKU reaching a channel. Most teams we meet have built the dashboard and never written the rules, so the number moves and nothing changes. This piece is the rule library. Four families of checks, how to write them, where to run them, and what to do when they fail.

A product data quality assessment should take three to six weeks and end with three things. A scored picture of one part of your catalogue. A named mechanism behind each failure. A costed, sequenced remediation plan you can take to a budget holder. If it ends with a dashboard and no plan, it was an expensive way to confirm what everyone already suspected. This is the method we run, written out in full so you can run it yourself.

Search for data quality dimensions and you get six words: completeness, uniqueness, timeliness, validity, accuracy, consistency. That list is real, it has a proper source, and it was written for customer and transaction records rather than for catalogues. Applied to a product record without translation it produces scores that look precise and change nothing. This page does the translation.

Product data enrichment is the work of turning a supplier’s raw record into something you can actually sell from. A part number, a trade price and forty words of manufacturer prose go in. A classified, attributed, described and illustrated product record comes out. That is the whole job. What varies enormously is how much of it a given catalogue needs, which is why nobody will quote you a price over the phone.

Most product data business cases die in the same meeting. They are written as a data project, so the finance director reads a cost with a vague benefit attached. The ones that get funded read as a change to three or four lines in the profit and loss. A measurement plan is bolted on. This article gives you that structure. The value lines that survive scrutiny, the ones that do not, the inputs to gather, and the eight objections you will get.

We sell outsourced enrichment, so treat what follows with the scepticism it deserves. We also turn work away roughly once a quarter. The honest answer to in-house vs outsourced data enrichment is that neither model wins outright. It depends on how specifiable your work is, how steady the volume is, and whether the knowledge involved is worth keeping inside the building. Here is the comparison we actually use when a Head of Product Data asks us which way to go.

Ask three suppliers for a product data enrichment cost and you will get three numbers that cannot be compared. One quotes per SKU. One quotes a day rate. One quotes a fixed price for a batch of ten thousand lines. None of them state what is inside the price, so the cheapest quote is usually the one with the smallest scope hidden in it. This article gives you the cost model instead of a headline rate, because the model is the thing you can budget against.

Most AI visibility tools give you a score out of a hundred and no way to act on it. The useful version of this exercise is different. You define a fixed panel of buying questions, run it across the assistants your buyers use, and record the whole answer each time. Then you read the citations rather than the score. This is the method we use, written out in full so you can run it yourself.

Ask an assistant which product to buy and it does not consult one ranked list. It rewrites your question into several queries. It pulls from a live search index and a merchant feed at once, then writes an answer from both. The products it names and the sources it links are chosen by two different mechanisms. Understanding how AI assistants choose products matters, because most catalogue owners are working on the wrong one.

Almost everything written about LLM optimisation is about blog posts. Write clearly, use headings, answer the question early. Fine advice, and useless if your problem is 400,000 SKUs where the torque rating lives in the middle of a paragraph. Product catalogues fail machine reading for structural reasons, not stylistic ones. This is what those reasons are, and what you change in the data model to fix them.