Last Updated on September 7, 2026
Six PIM Practices That Never Make It Into the Sales Deck
Most product information management advice reads like it was written by someone who has never migrated a catalog. Single source of truth. Clean your data first. Get executive buy-in. All fine, and none of it helps on the Tuesday morning when a marketplace rejects 4,000 SKUs and nobody in the room can say why.
So I went looking for the practices that experienced data architects argue about and vendor blogs skip entirely. Here are six of them.
Scope every attribute before you build anything
Every field in your PIM needs a label that has nothing to do with its content. Is the value global, meaning identical everywhere? Is it locale specific, changing by language or market? Or is it channel specific, changing by where it ships?
That sounds like housekeeping. In practice it decides whether your publishing logic survives contact with a second market. Akeneo bakes the idea into its model with localizable and scopable flags, while Syndigo calls the same thing contextual modeling. Whatever the label, the principle holds. Your master record carries channel neutral truth, and overrides sit in a linked layer that inherits from it unless somebody deliberately changes a value.
Skip this step and you get the classic mess, which is one product record per channel. Then a single spec change becomes four edits in four places. Meanwhile a marketplace title limit of 80 characters quietly truncates the same field your webshop depends on.
One more thing worth flagging. If you sell into France, Belgium and Quebec with identical French copy, you do not need three French locales. You just tripled your enrichment workload for nothing. Turn a locale on only when the content genuinely differs.
Let classes own the attributes, then retire what nobody uses
Attributes should not live on the product record. They belong on a classification layer, so a product inherits its field set from the class it sits in. Change the class and the fields follow.
Then split those classes properly. What a product is, meaning flow rate, pressure rating and inlet size, belongs in one group. What a product does, meaning recommended environments and use cases, belongs in another. Mix the two and your completeness score stops meaning anything.
Now the part everyone skips. Governance is not only an approval process for new attributes. It is also a retirement process for old ones. AtroPIM has documented industrial catalogs carrying more than 200 record level attributes, many of them near duplicates added by different teams over several years. Every one of those got approved. None got removed.
So run a quarterly review, look at fill rates, and delete anything nobody has touched. On hierarchy, taxonomy specialists like Heather Hedden have been consistent for years. When items need multiple classifications, reach for facets rather than polyhierarchy. More than two or three polyhierarchies across an entire scheme is a signal to stop and rethink.
A single completeness percentage tells you almost nothing
Your dashboard says 94 percent complete. Complete for what, though?
A product can be fully ready for your own site and badly short for a retailer that demands six extra technical fields. So completeness has to be calculated per channel, per market and per product family. Anything else is a vanity number.
Then there is the gap between filled and complete. A field containing “TBC” passes a null check and fails a customer.
Once the scoring is real, add gates. Not every rule should block, though, because a wall of hard stops creates bottlenecks while a wall of soft warnings creates a team that ignores alerts. Sort your rules into blocking and warning, and write down why each one sits where it does. After that, apply the blunt test. If someone can click continue past your gate, you built a logger rather than a gate.
Fix data at birth, because that is where it breaks
Here is the number that reframed this whole topic for me. Research by Tadhg Nagle, Thomas Redman and David Sammon, published in Harvard Business Review, found that 47 percent of newly created records carry at least one critical error. Nearly half of them are wrong on arrival.
Which means supplier onboarding is not admin work. It is the highest leverage quality work in the building.
So treat it that way. Give suppliers a portal that validates at the point of entry instead of a spreadsheet template and a prayer. Build mapping templates per category and save them per supplier, because the first import takes half an hour and every one after it should take a click. Then issue scorecards, so suppliers see their own error rates and fix problems at source rather than sending you the same broken file next quarter.
Group Ici, working with Akeneo, grew from 300 to 950 SKUs and cut marketplace onboarding from roughly two months to under a week. Worth noting that this figure comes from vendor published material, so read it as directional rather than audited.
Compliance data grew up, and it has a calendar attached
If you sell into the EU, this one carries deadlines.
The EU Battery Regulation makes an electronic battery passport mandatory from 18 February 2027 for EV batteries, light means of transport batteries and industrial batteries above 2 kWh. No passport, no customs clearance. GPSR has applied since December 2024. PPWR generally applies from August 2026. ESPR, the framework sitting behind the wider Digital Product Passport, entered into force in July 2024, and its first working plan landed in April 2025 covering textiles, furniture, tyres, steel and aluminium among others.
None of that fits a marketing content model. Regulated fields need provenance, version control and a named owner in legal or regulatory. They also pull from PLM and ERP rather than from a copywriter.
So build compliance as its own attribute domain now, with a gate that blocks release until documentation is attached. Then map your categories against the ESPR working plan and watch for the delegated act that binds your sector. Those dates stay indicative until the act lands, which is exactly why you want the model ready early.
Something other than a human is reading your catalog
Shoppers now ask an assistant for the best robot vacuum for a 50 square metre flat. The assistant answers by reading structured attributes: coverage area, battery life, noise level, pet suitability. If your listing lacks those fields, you do not rank lower. You are simply absent from the answer.
That shifts what good product data looks like. You want deep attribute coverage, valid GTINs, schema.org markup in JSON-LD, and price and availability readable server side without JavaScript running first.
AI will fill those fields quickly, though it also repeats your legacy errors at speed. So route by confidence. High confidence values publish straight through, low confidence values go to a reviewer, and reviewers spend their time where being wrong costs most, meaning safety specs and compliance fields. Then feed the corrections back into your prompts so the same mistakes stop recurring.
The part I keep coming back to
Notice what none of these six require. No new platform, no migration, no procurement cycle.
Every one is a modeling decision, a governance habit or a measurement choice you can make inside the tool you already own. Start with attribute scope, since almost everything else gets easier once that is right.
