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.
A supplier sends you a BMEcat file. It is 300MB of XML, half the descriptions are in German, and nobody can tell you whether it is version 1.2 or version 2005. BMEcat is the XML standard for exchanging product catalogues between suppliers, distributors and procurement systems, published by BME e.V. in Germany. If you buy from continental European manufacturers, you will meet it, and the English-language explanations of it are thin.
A GTIN identifies your product. It does not describe it. We watch suppliers discover that difference every year, usually the week a retail customer accepts the barcode and then rejects the listing. GS1 standards are excellent at the job they were built for. Selling the product is not that job.
A UNSPSC code tells a procurement system what kind of thing was bought. It tells a customer nothing at all about the product. That distinction is where most UNSPSC work quietly goes wrong. We map UNSPSC for distributors and manufacturers most years, usually alongside ETIM or a merchandising tree.
ECLASS, ETIM and UNSPSC get shortlisted against each other in the same meeting, and they should not be. They do three different jobs. ECLASS describes what a product is made of and how it performs, across every industry there is. ETIM does the same job in more depth for technical products in a narrower set of sectors. UNSPSC puts a code on a line of spend and stops there. When distributors ask us which one to adopt, the answer is usually two of them, for two different reasons.
ETIM 10.0 contains 5,640 product classes and 16,728 features. Neither of those numbers is the one that hurts. The one that hurts is 73,085, the count of class-feature relations in the model. A feature in ETIM carries no fixed unit and no fixed value list. Both are set per class. That single design decision is why ETIM mapping projects fall apart in month two. It is the first thing we walk through on every ETIM engagement.
AI in product data has a clean dividing line, and it is not the one most articles draw. The question is not whether a task is complex. It is whether the output can be checked against something.
Product classification is not filing. It is the structure that decides whether an engineer with a specification in mind finds your part in twenty seconds. Or buys it from someone else. In a catalogue of tens of thousands of SKUs, an inconsistent structure is not untidy. It is lost revenue that never appears in any report, because nobody measures the searches that returned nothing useful.
Clean product data pays back. What nobody can honestly tell you is by how much, in your business, without measuring it first. Every vendor case study you have been sent describes a different merchant, with a different catalogue, at a different starting point.
Do you need a PIM? For most businesses that put the question to us, the answer is yes, no, or not yet. It is rarely a close call once the right evidence is on the table. The difficulty is that almost everyone you can ask has a reason to say yes. Vendors sell platforms.
Industrial product data is not marketing collateral. It is the evidence an engineer uses to decide whether your part belongs in their design. And whether the plant is still running on Monday. Bearings, valves, and safety equipment are not bought on brand preference. They are selected on performance, compliance, and fit.
Product content performance is a different question from product data quality, and most teams only measure the second. Completeness scores tell you the attributes are populated. They tell you nothing about whether the content is doing any commercial work.
Product data sourcing sets the ceiling on everything downstream. No amount of cleaning, enrichment, or platform investment recovers information that was never obtained, and most catalogues are limited by acquisition rather than by processing.