Key Takeaways
- Thin product data still costs sales. In a large 2026 survey across six countries, most online shoppers said they would switch sites when product information falls short.
- AI shopping agents consume structured feeds with strict field rules. Unstable IDs and placeholder values get rows rejected or misread, often without anyone noticing.
- The EU Digital Product Passport Registry has been live since July 2026. Passport data is product data, so it belongs in the same system as your e-commerce attributes.
- PIM software works through concrete mechanisms: a typed data model, variant inheritance, validation rules per channel, and export mappings. Buying a tool before defining these moves the mess into a new interface.
What Product Information Management Covers In E-Commerce
Most companies don't lack product data. They have several versions of it.
The ERP holds item numbers, prices, stock, and logistics data. Engineering keeps specs in PLM or spreadsheets. Marketing writes copy in documents, images sit in a DAM or on a shared drive, and suppliers send files with their own column names.
A PIM system pulls the descriptive part together: technical attributes, marketing texts, variants, relations such as accessories and spare parts, assets, translations, and channel-specific values. Then it publishes that data to webshops, marketplaces, product feeds, print catalogs, and partner portals.
The division of labor matters. The ERP stays the owner of price and stock. The PIM owns what the product is and how it's described. When two systems store the same field, and people edit both, the values drift apart.
Where Product Data Breaks
The failures are boring. That's why they survive.
A supplier sends weight as "1,5 kg" in one file and "1500 g" in another. The ERP short text field holds 40 characters, so "Cordless Drill 18V Brushless 2x5Ah Case" becomes the title on every marketplace. Someone fixes a description directly in a marketplace backend, and the next export overwrites the fix. Or it doesn't, and now two channels disagree. A T-shirt in six sizes and five colors is 30 sellable items, each with its own ID, image, and stock status. Translations get updated in German and forgotten in French.
None of this looks dramatic in a spreadsheet. Spreadsheets are very tolerant. They will store "N/A" in a weight column without complaint.
Shoppers are less tolerant. For its State of Product Experience 2026 research, Syndigo surveyed 8,736 adults in Australia, Brazil, France, Germany, the UK, and the US. Four in five said inaccurate or incomplete online representation hurts their view of a brand. Globally, 17% had recently run into inconsistent or contradictory product information. In the US, 31% returned a product because it didn't match what the product information had led them to expect. Germany was close behind at 30%.
83% of online shoppers in the six surveyed countries say insufficient product information is likely to send them to another site or app.
Returns are the expensive part. A return caused by wrong data pays for shipping twice, adds handling, and often loses the customer.
Current Trends And Risks In Product Data Management
AI Shopping Agents Read Your Feed
Shopping agents in chat interfaces compare products from structured data. Much of what they know comes from feeds and APIs that merchants submit, and page design doesn't travel with that data.
OpenAI's product feed specification for ChatGPT shows what this means in practice. A discovery feed needs nine fields per row: item_id, title, description, url, brand, seller_name, image_url, availability, and price. Titles should stay within about 150 characters and descriptions within 5,000, in plain text. The rules around those fields are where weak catalogs fail:
- Each purchasable item or variant gets its own row and a stable
item_idthat is never reused for a different item. Variants share agroup_id. Price must never appear in an offer ID. - Unknown optional values are omitted. Placeholder strings such as "null", "unknown", or "n/a" are not allowed. An empty shipping price counts as unknown.
- GTINs need exactly 8, 12, 13, or 14 digits with a valid check digit. Identifiers stay strings so leading zeros survive. Anyone who has opened a GTIN column in Excel knows why this rule exists.
- Dimensions describe the product without packaging, and units are never inferred from the market.
- Sale dates in the feed don't schedule price changes. When a price changes, the feed has to change.
- A malformed row can be rejected while valid rows keep processing. The catalog shrinks quietly unless someone checks the upload history.
The standard upload currently targets the US market. Other markets need setup that OpenAI confirms per integration. European sellers can still build the data now, because the same attributes serve Google-compatible feeds, marketplaces, and their own product pages.
The shopper side moves slower than the technology. In the Syndigo survey, 40% of shoppers globally trust product information provided by AI, and only 8% named AI recommendations among their top three purchase considerations. Ratings and reviews (53%) and detailed descriptions (52%) still lead. In the US, 69% said they have never let an AI agent buy on their behalf and never would.
So agents matter mostly for discovery and comparison today. Shoppers still make the final call on detailed content. Both depend on the same attributes. A company that structures its data once serves the feed and the product page from one source. A company that writes agent feeds by hand doubles its maintenance and its error rate.
The EU Digital Product Passport Is Now Infrastructure
The European Commission launched the Digital Product Passport Registry on 20 July 2026, together with a testing environment. The registry is an index. Product data stays decentralized, and economic operators must register each passport with its unique product identifiers and associated metadata.
Registration runs through a web interface or an API. Operators can request an electronic proof of registration to show B2B partners. The Commission also provides a free semantic repository with machine-readable data models, definitions, and vocabulary across product groups. Six of eight harmonized standards are already published. They cover unique identifiers, interoperability, data carriers, APIs, data exchange protocols, and data storage.
The first mandatory deadline is 18 February 2027 for certain large batteries. The registry also supports ESPR product groups such as textiles, steel and aluminum, tyres, furniture, ICT products, and energy-related products, plus toys, construction products, and detergents covered by other EU rules.
For e-commerce teams, the practical point is simple. A digital product passport is structured product data with legal weight. It needs identifiers at the level each product rule demands, attributes that often come from suppliers, and an API path to the registry. If the passport lives in a separate compliance tool, it drifts away from the product page.
A passport that says one thing and a product page that says another is a data quality problem with a regulator watching.
Most product-specific passport rules are not in force yet, so exact attribute lists will keep moving. The safer move is a flexible attribute model that absorbs new fields without a schema rebuild. Mapping your attributes to the Commission's vocabulary early saves a second migration later.
Generative AI Writes Faster Than Anyone Checks
AI text generation made product descriptions cheap. The risk is invented attributes. A model asked for an engaging description of a jacket with thin input data can call it waterproof. That claim flows into the page, the feed, and the agent's answer. Then it comes back as a return.
The control is mechanical. Generate text only from approved attributes. Mark generated fields as generated. Route them through a review status before any channel export. Regenerate when the source attributes change. The OpenAI spec asks for a factual product description, which is a good standard for every channel.
Price And Stock Change Faster Than Attributes
Attributes change monthly. Prices and stock change hourly. Feeds need both.
Keep ownership clean. The ERP or commerce platform owns price and availability, the PIM owns attributes, and the export layer merges them at publication time. When teams copy prices into the PIM by hand to make a feed work, the feed shows yesterday's price. Some B2B manufacturers do keep catalog prices in the PIM for print and partner catalogs. That works when an automated sync writes them, and nobody edits them manually.
How PIM Software Works In Practice
PIM software is a database with opinions. The opinions make it useful.
A Typed, Configurable Data Model
Products belong to classifications, sometimes called families. The classification decides which attributes apply. A cordless drill gets torque in Nm, battery voltage, chuck size, and weight. A T-shirt gets fabric composition, fit, and care instructions.
Each attribute has a type. A number with a unit stores 1.5 and kg separately, so the export can convert it. A list attribute accepts only defined values, so "Black", "black", and "BLK" collapse into one. A boolean answers yes or no and can't contain "maybe, check with supplier". Multilingual text keeps each locale in its own slot, so a missing French description shows up as an empty field instead of German text on a French page.
Technical manufacturers often add an industry classification such as ETIM on top. It gives them an attribute vocabulary they share with wholesalers, so the same torque value means the same thing at both ends.
Variants With Inheritance
A parent product holds shared values: brand, description, material, care instructions. Child products hold the values that define the variant, such as size and color, plus their own SKU, GTIN, images, and availability.
Edit the material once on the parent, and all 30 T-shirt variants update. This structure maps directly onto feed concepts like a group ID for the parent and an item ID per variant.
Import Mapping And Normalization
Import profiles map each supplier's columns to internal attributes. They convert units, translate list values ("schwarz" becomes "Black"), and strip stray whitespace. Rows that fail validation go to a review queue and stay out of the live catalog. The PIM records where each value came from, so a wrong value can be traced to the file that delivered it.
Validation Rules And Completeness
Rules define what "ready" means per channel and per locale. The webshop may require 12 attributes for drills. The agent feed requires the nine core fields plus a valid GTIN. A marketplace may need its own category code. The PIM computes a completeness score per product, channel, and language.
Format rules catch problems at entry. They check GTIN check digits, title length, mandatory units, and placeholder text before the value is saved.
The answer to "is the catalog ready for launch" should be a filtered list of products with the missing fields named.
Workflow, Permissions, And Change History
Field-level permissions decide who edits what. Compliance edits safety and passport attributes. Marketing edits copy. Suppliers fill their own attributes through a portal or a controlled import. Status fields such as draft, in review, and approved keep unreviewed content away from channels.
A change history records who changed which value and when. That record matters when a marketplace, a customer, or a market surveillance authority disputes a claim.
Channel Mapping And Export
One internal value maps to many outputs. The internal color "Anthracite" may export as "Gray" to a marketplace with a fixed color list. Title templates build channel titles from attributes, for example brand, product type, key spec, and variant, with length limits per channel. Units convert at export. Channel-specific overrides exist for cases where a channel needs different text, and they sit next to the master value so nobody loses track of them.
Exports run as scheduled files, API pushes, or delta updates that send only changed products. The same product record feeds the webshop, marketplaces, an agent feed, a print catalog, and a passport registration.
Here is how typical PIM elements line up with the OpenAI feed fields, and what tends to go wrong without them:
| PIM element | Feed field | Common failure without it |
|---|---|---|
| Variant SKU | item_id |
IDs regenerated on export, so the channel sees new products |
| Parent product | group_id |
Sizes and colors listed as unrelated items |
| GTIN stored as text | gtin |
Leading zero lost, check digit fails |
| Product dimensions with unit | dimensions |
Carton size sent as product size |
| Variant image link | image_url |
Every variant shows the black version |
| Return policy attributes | accepts_returns, return_deadline_in_days |
Fields left blank, so returns count as unspecified |
In Projects We Implemented
Our customers turn to us with a familiar setup. The ERP is the product master, and its fields were designed for orders and invoices. Product managers keep extended specs in category spreadsheets. Each marketplace has its own export script that someone wrote years ago. Translations travel by email as Excel files. A product launch waits until somebody assembles the right sheet, and errors surface when a customer calls.
In projects we implemented, the first weeks went into the data model. Software configuration came second. We define classifications and attributes with the product managers, import identifiers and logistics data from the ERP, and set validation rules per channel. After that, enrichment happens in one place and export profiles produce the channel formats. The daily question changes from "which file is current" to "which attributes are still missing". The PIM answers the second one with a list.
Distributors bring a different version of the problem. They receive supplier data in many formats, often for overlapping products. A mapping profile per supplier and a quarantine queue for failed rows let them onboard a new supplier's range without hand-cleaning every file.
We build this setup with AtroPIM, our open-source PIM on the AtroCore data platform. Admins configure the data model from the admin panel, permissions go down to the field level, and data leaves through the REST API or file exports. AI integration and automated data quality management are available as paid modules for teams that need them.
Choosing And Rolling Out PIM Software
Every PIM vendor shows a clean demo catalog. Your catalog is the real test.
A rollout that holds up in production usually follows this order:
- Start with one product category and the strictest channel you sell on, usually a marketplace or an agent feed with hard validation.
- Write the attribute dictionary first: name, type, unit, allowed values, owner, and source system for each attribute.
- Fix ownership per field. Price and stock come from the ERP, descriptive attributes live in the PIM, and the rule is written down.
- Configure validation and completeness rules before migrating data, so the migration itself exposes the gaps.
- Track four numbers from day one: completeness per channel, rejected feed rows, returns coded as "not as described", and days from product creation to first listing.
A configurable PIM needs upfront modeling. Teams without data modeling experience will need partner help for the first categories, and that cost lands before any benefit shows.
SaaS PIM moves hosting and updates to the vendor and limits deep customization. Self-hosted and open-source options give control over code and data, and someone has to run them. Both choices carry work. Pick the one whose work your team is better equipped to do.
A PIM also won't create missing supplier data. It makes the gaps visible and assigns them to a person. For a shop with a few hundred products, one channel, and a handful of attributes, the shop backend may be enough for now. The threshold tends to arrive with the second language or the first regulatory data request.