How to build PIM data that holds up over time

You have item details in the business system, technical dimensions in spreadsheets and product images in a shared folder. The salesperson uses a saved product sheet. The customer portal shows an older description. When someone notices the difference, several people have to search for the latest source material.

That is where work on PIM data begins. You need to decide which information applies, who may change it and which channels should receive the change.

A working setup makes it possible to follow a piece of information from its source to the published product. That requires well-designed fields, clear approvals and recurring checks. The choice of system needs to support the work your product managers will actually do.

How product information ends up in several systems

A new item often starts as an item number in the business system. The product manager adds to the specification in a spreadsheet. Marketing writes a description, and the salesperson gets further information from the supplier by email.

Each step can be reasonable at the time. Problems arise when no one decides which version the next person should use. A changed package dimension can sit in the supplier’s documentation while the website still shows the old value.

Imagine a reseller needs information on a spare part’s compatibility. The customer portal lacks the relationship to the main product. The salesperson searches old emails and sends a document whose validity has to be checked manually.PIM can own descriptions, technical attributes, images and documents, according to an agreed division of responsibility.

A single source therefore needs to be defined for each piece of information. If both the business system and the PIM can overwrite the same field, you need to decide which takes precedence. Otherwise a correct change can disappear at the next import.

Start by documenting how an item is created, changed and phased out. Include manual files and emails in the mapping. They often contain steps that are missing from the integration description.

The reasoning about how a PIM governs product data from the business system to the channels applies here too. A technical transfer, such as the connection between the business system and the e-commerce platform, needs to be complemented by decisions on field ownership, direction of change and error handling. Once those decisions are in place, you can assess what should be automated and what someone needs to approve.

Data model, attributes and taxonomies in a PIM

The data model describes what a product consists of and how the information fits together. Start with product identity. Item numbers, the supplier’s identity and the relationship between base product and variant need to be distinguishable.

Then separate attributes, units, languages, media and documents. A dimension needs a numeric value and a defined unit. A description needs a language and possibly a market. A document needs its own metadata.

If length, material and area of use sit in the same free-text field, reuse becomes difficult. A filter needs to be able to read the material as a distinct value. A comparison needs to find the corresponding dimension across several products.

A taxonomy arranges products into categories. The attribute list sets out which properties should describe the products in each category. The pumps category, for example, can be linked to attributes for flow, connection and material, while spare parts need compatibility relationships.

Give controlled values stable identities. A material name can then be shown in different languages without the link being lost. Let the unit field control which values are accepted, and document any conversion between imported and published units.

For variants, you need to specify what is inherited from the base product. A shared description can be inherited, while the variant’s dimensions need their own value. Also distinguish between an empty field and an active decision that the information isn’t relevant.

Variant inheritance becomes hard to manage if empty fields are interpreted differently between import and publishing. Decide whether an empty value means the variant should inherit, lacks the information or should hide it. The same rule needs to apply when a product manager edits manually.

Documents should be linked by document type, language, version and validity status. You can then determine which instruction belongs to a particular variant. A file in a folder is of limited help when the same product has changed during its lifetime.

Svensk Handel’s annual report for 2025 and PostNord’s E-barometer for 2025 describe how e-commerce is developing, but such figures say little about your product information. The data model needs to be tested against real product families, variant cases and documents before you use it for the whole range.

Data quality as a measurable property of PIM data

A filled-in field can contain a wrong value. A product can also have complete marketing copy and still lack a mandatory instruction. Data quality therefore needs to be judged against the rules for the product and channel in question.

Start with the coverage of mandatory attributes. Calculate it from the applicable fields, so that irrelevant properties aren’t counted as gaps. Show the result per product family and channel. Those responsible can then see where enrichment needs to start.

Also track the share of publishable items. An item should only count as publishable once all of the channel’s blocking rules are met. At the same time, decide how phased-out products and products in development should be handled in the calculation.

Errors per import run show where the import needs fixing. Break the errors down by cause, for example an unknown unit, a missing product relationship or a disallowed attribute value. Also show how much data the run processed, so the result can be interpreted.

The time from approved change to confirmed publication shows how the flow works after enrichment. Measure from a defined event to the receiving channel’s acknowledgement. The export file shows what was sent; the acknowledgement shows what the customer can see.

In the Swedish National Electrical Safety Board’s follow-up of electrical products sold online, 70 percent lacked instructions and safety information in Swedish. The result applies to the products checked and shouldn’t be generalised to all of e-commerce.

A missing safety instruction may need to block publishing. A missing inspiration image can be handled with a warning. Product managers need to specify which document requirements apply to each product and sales market.

Set the first measurement as the baseline and track recurring deviations. Assign the actions to a named role. A check without an owner risks leaving the same error in place after the next import.

Workflows, roles and governance in PIM work

When the supplier sends new product information, someone needs to receive it as preliminary material. The import should record the source and detect format errors. Only then does the information move on to enrichment and review.

A useful workflow has clear states for received, processed, reviewed and approved content. The states need to control what users are allowed to do. Whoever translates a description should be able to see which original was approved.

Approvals should apply to a specific version. If a critical dimension changes after approval, the product needs to be reviewed again according to your rules. Otherwise the approved status can hide a later change.

A simple responsibility matrix can be described through concrete decisions. The product owner approves the specification and variant relationships. Marketing approves copy and translations. Engineering is responsible for technical documents and product images, according to your internal division of work.

The PIM team checks that the information is approved and meets the publishing rules before syndication. The team needs the mandate to stop a product with critical shortcomings. It also needs to know who should investigate the deviation.

Distinguish between the person who registers the information, the person who approves it and the person responsible for its accuracy. In a smaller organisation, one person can hold several roles. The decisions still need to be documented so that a stand-in can follow them.

Supplier data, business system data and laboratory documentation can refer to different versions of the same product. Save references to the source material and to the variant or production batch it applies to. Also record who judged that the information may be used.

Version history should show what changed, who changed it and which approval followed. For information with limited validity, someone needs to be responsible for re-checking it. Having the source material saved doesn’t mean it is still valid.

Let the responsibility matrix follow the real organisation. If technical documents are approved by another department, the workflow needs to support that. A model that requires approval from an unstaffed role will pile up waiting products.

Syndication to websites, portals and reseller channels

Syndication means approved product information is distributed according to the recipient’s rules. A product website may need the full specification. The web shop needs a selection for the buying decision, while the reseller may require specific field names and document formats.

The source value should be kept when the presentation is adapted. The same connection dimension can appear in a comparison, a technical product sheet and a portal. It should be possible to change the channel’s formatting without anyone rewriting the product’s base information.

Every channel needs an explicit publishing filter. It should specify the permitted range, market, language and product status. Customer-specific selections also need to be tied to the right permissions, so that an approved item is shown to the intended recipients.

In customer portals and reseller portals, product information often meets the customer’s agreement and ordering flow. Descriptions and documents then need to work together with customer-specific prices and availability. That information may have different owners and update frequencies.

Stock status, delivery terms and order information need to be fetched according to their own rules. Copying fast-changing values into a manual product field creates an extra point that needs updating. Decide how old the information the receiving channel may use can be, and what should be shown during an outage.

A successful export shows that the sender created or sent the content. The recipient can still reject an item or a document. Save acknowledgements and link deviations to the published version.

Also test how the flow handles unpublishing, replaced documents and broken product relationships. A removed variant needs to disappear wherever it was shown. A replaced instruction needs to reach the channels that use it.

More extensive channel rules give more control but require more management. Keep shared rules central and document the channels’ exceptions. Those responsible can then assess which channels a change affects before it is sent.

More attributes require better source material

A new sustainability field can look simple in a requirements specification. When suppliers provide different source material, the work gets harder. One value may refer to the material, another to the whole product and a third to a specific production batch.

If these values end up in the same field, the user gets a comparable presentation even though the source material differs. False precision arises when the model hides such differences. Product managers need to be able to judge what the information actually describes.

The EU’s Ecodesign Regulation (ESPR) and digital product passports make traceable product information worth preparing for. GS1’s page on digital product passports describes the work and RISE’s recommendation to inventory existing information and how it needs to be extended and structured. That doesn’t mean every product is already covered by the same finished requirements.

For sustainability data, the value should be linked to its source, evidence and validity. Where needed, the model also has to state whether the information applies to the product, the variant or a specific production batch. These boundaries affect how the information may be presented.

An empty field can be an honest result when there isn’t enough evidence. Record the reason in a controlled way. Those responsible can then tell the difference between a pending supplier response, insufficient evidence and information that isn’t relevant.

The field also needs a recipient. Describe which decision or publication the information should support. If no one uses the value and no one is responsible for it, you should consider whether it belongs in the model.

Central governance suits cases where the same information is used in several contexts and needs to stay up to date over time. You need to set aside time for enrichment, approvals and checking source material. That effort remains even when imports are automated.

A simpler way of working can suit a limited range with few changes and a single publishing channel. Controlled files and a documented routine may then be enough. Assess the need based on product relationships, document requirements and differences between channels.

Someone in your organisation also needs to be able to say no to new fields. Otherwise the model grows with every request from a department. Prioritise information you can substantiate, maintain and use in a concrete task.

Questions to ask the supplier, and what the approach requires

How are the source and owner of a critical attribute stored, and what happens to the approval when the value changes? Ask the supplier to show the workflow with your own product data. Choose a variant family, a replaced document and an item missing a critical value. The answer shows whether the division of responsibility affects users’ work. Ask to see both the change and the saved history.

How are languages and documents handled per market, and how do you show that the recipient accepted the publication? The answer reveals where the delivery ends. Ask the supplier to show a rejected document and how the person responsible finds out what needs correcting.

Who checks rules and integrations at an upgrade, and how do you separate bug fixing from further development? The answer gives you a basis for judging ongoing management after go-live. Ask for the division of responsibility in the agreement and which checks will be carried out.

When changing platforms, you also need to assess what happens to the data model and the channels’ dependencies. The reasoning on choosing an e-commerce platform is therefore linked to reviewing the product flow. A change needs to be able to preserve your product identities and working relationships.

You need to appoint a product owner yourselves, arrange access to the source material and decide who approves what. A supplier like Glanser can support the modelling and build the checks. The assessment of your technical information needs to sit with people who have the right expertise.

On the PIM page, you can see how we work with gathering, quality-assuring and publishing product information, starting from a concrete product flow.