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.

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.

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.

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.

Ask an AI shopping assistant for a cordless impact driver under two hundred pounds with a brushless motor, and it will give you five products. Your competitor is in that list. You are not. Nothing is broken on your site. Nobody has penalised you. The assistant simply could not establish that your product met the conditions, so it moved on. Here are the six reasons that happens, and what each one looks like inside a real catalogue.

Most AI readiness assessments are workshops. Someone scores your organisation out of five on culture, skills and governance, then hands over a heat map. It tells you nothing about whether an assistant can answer a question about your products. This diagnostic does. It runs against your own catalogue. It takes five working days of one person’s time. It ends with a number you can put in front of a board.

Most articles about the digital product passport explain the policy. The policy is the easy part. A digital product passport is a structured data record. It ties to a product through an identifier and a data carrier. It holds fields you almost certainly do not have, at a level of identity your PIM was probably not built for. That is the part that costs money, and it is the part nobody prices.

From 18 February 2027, an electric vehicle battery cannot be placed on the EU market without a battery passport. The same goes for an e-bike battery, and for any industrial battery above 2 kWh. That date sits in Regulation (EU) 2023/1542, and the European Commission’s Digital Product Passport Registry has been live since 20 July 2026. This is the first digital product passport that will actually bite. For almost every distributor and manufacturer we speak to, it is a data problem long before it is a compliance problem.

ESPR is the Ecodesign for Sustainable Products Regulation, and it is the law that creates the Digital Product Passport. It entered into force on 18 July 2024 and it applies to almost every physical product sold in the EU. There are plenty of legal summaries of it. There are almost none that answer the question a product data team actually has: which attributes, at what granularity, held in which system. That is what this piece covers.

Most DPP readiness assessments are questionnaires. They ask whether you have a sustainability strategy, score you out of five, and produce a chart. That tells you nothing you can act on. The only useful test is run against your actual product records, field by field. It takes an afternoon. Below are the twelve checks we run on a client catalogue. Each one names the data it tests and what a fail looks like.

Most catalogues we open have four identifiers in one column. A GTIN is the GS1 number that identifies a trade item, and EAN and UPC are older names for two of its formats. An MPN is the manufacturer’s own part number. An ASIN belongs to Amazon and identifies a listing, not a product. Here is what each one is, who issues it, and where it belongs in your data model.