PIM for e-commerce pays off only once ownership is clear

A product manager needs to get a new campaign out before lunch. The item number and stock level sit in the business system, marketing works in an Excel file with copy and images, and a reseller is waiting for its feed. Before anything can be published, someone has to compare versions, correct attributes and make sure the same product looks the same in every channel.

That is where PIM becomes a financial question. If product data isn’t shared, every new channel becomes another thing to maintain. The cost grows in small steps, but it grows every week.

The catalogue spread across four systems

That is also why many PIM discussions start in the wrong place. They begin with software, when the real problem is ownership. You need to decide who owns each piece of information and where the valid version should live.

In that situation, it helps to first sort out the flow between the business system and the channel. A clear picture of the integrations often shows where duplicates and manual steps arise, and those connections are exactly what needs to be stable when the website and the business system need to talk to each other. When that part is unclear, PIM just becomes one more place where the same thing gets rewritten.

This is also where the cost picture changes. Future corrections are often the biggest item. PIM should therefore be assessed as part of your channel set-up.

What PIM actually does in an e-commerce architecture

PIM is the layer that holds product information together between the business system and the channel. The business system owns things like pricing logic, stock and transactions. PIM owns the sellable information people actually see on the website, in the portal and in feeds.

The key is to separate core data from localised attributes. Core data includes item numbers, GTIN, units of measure and technical specifications. Localised attributes include language, currency, legal texts, VAT logic and market-specific additions.

When that separation is missing, everything gets mixed together. Technical data ends up in marketing copy and local requirements end up in the master register. A PIM works better when every field has a clear home and publishing is governed by rules rather than manual judgement.

Stock and price normally sit in the business system, where availability, base price and order value are governed. Technical core data sits in the PIM or in the product source, for example item numbers, dimensions and compatibility. Channel copy such as headlines, descriptions and images belongs in the PIM, while local requirements are often owned by marketing or legal, for example language, VAT, compliance and category fit.

This model becomes especially clear when products are reused across several digital flows. A product website, a customer portal and a reseller feed should draw on the same foundation and present different surfaces on top of it.

For many organisations, this is also where a more productised approach fits better. Glanser works with a function library with fixed scope and fixed price, which means basic components don’t have to be reinvented for every project. That only becomes relevant once you know the structure really needs to hold up over time.

Data quality as a measurable board-level issue

Product data quality can be measured before a PIM project even starts. It belongs at management level because the errors affect orders, customer enquiries and returns.

Good PIM work starts with automated checks. An item should not move forward if mandatory attributes are missing, if units of measure are inconsistent or if a variant and its main product don’t match. Image requirements, language status and duplicate checks also belong here.

The data should also be modelled as a versioned structure. That makes it possible to trace a change in a shared property to the channels it affects; otherwise management quickly slips back into manual routines.

This becomes especially clear with technical documents, certificates and installation data. They often need to carry a revision, a validity date and a target audience. Without that metadata, it becomes hard to tell whether a file may be used.

Process metrics say more about maturity than revenue figures do. The share of publishable items, the time from change to publication, the number of blocking validation errors and the share of complete attributes per category show where work gets stuck. You can track them in your current environment.

That is enough to tell the difference between perceived order and actual control. As these metrics improve, it also becomes easier to see whether PIM is the right next step or whether the problem lies earlier in the chain.

Channel strategy in a Nordic reality

When several countries and several channels are involved, it isn’t enough to think about the product once. A Danish market needs its own legal texts. A Swedish reseller chain may need its own item numbers and language packs. A customer portal often wants to reuse the range, prices and documents from the same source.

That is why channel-independent publishing becomes relevant. Otherwise the same product has to be rebuilt every time it is shown somewhere else. With PIM, the website, portal and resellers become thin presentation layers on top of the same structured foundation.

There is therefore a need to connect the product model all the way to the order and payment flow. If checkout and product data live in different worlds, localisation ends up half-finished.

Monolithic publishing works when everything is built directly in the web shop’s CMS. It is simple at first, but quickly becomes heavy when more markets and channels need to carry the same content. Every new surface then has to be adapted by hand.

A PIM-based model works better when channels need to reuse the same structure. Core data can be kept together centrally, and each channel can show what is relevant to its audience. It is a much better arrangement when the range is large and the product logic varies.

For readers in the middle of that discussion, there is a broader look at how PIM systems usually fit into the e-commerce architecture. That kind of modelling question often matters more than the choice of a single module.

When PIM is the wrong solution to the right problem

PIM doesn’t fit every situation. If you have a small range, one channel and a well-run business system, a clear integration can go a long way. A new layer is then often more administration than benefit.

This is worth saying out loud. Many companies buy solutions that are too big too early, because they confuse order with system investment. If the processes haven’t been decided, PIM just becomes a new place where unclear ownership carries on.

If the data volume is small, launches are rare and one person already keeps the product content together, the next step may be to improve what you have. You should then measure the share of complete attributes, the time from change to publication and errors in orders or channel data before deciding.

This is also the right moment to think about sustainability data separately. The EU’s ESPR, which entered into force on 18 July 2024, introduces digital product passports in which sustainability information follows the product through its life cycle, according to the Swedish Chemicals Agency’s page on the Ecodesign Regulation (ESPR). For some organisations, this means the PIM must be able to separate marketing, legal requirements and confidential supplier data.

When the range is broad, the channels many and publishing frequent, the benefit becomes clear. Manual work goes down, and it becomes possible to control what is published where. That is also when a PIM becomes a tool for control.

It is important to be honest about that boundary. If the organisation can’t assign someone responsible for data quality, or if no one owns the exceptions, you should wait. A PIM doesn’t solve unclear responsibility.

An implementation that holds up in ongoing management

A good rollout starts with the current situation. You need to know how complete the data is, how long it takes from change to publication and where errors arise in channel data. Without that picture, every further discussion becomes a little too comfortable.

The attribute model then needs to be governed per category. Electronics need different mandatory fields than clothing, and pharmacy products need a different structure than furniture. A single template for everything usually only looks efficient on paper.

You need an appointed product sponsor, clear ownership of core data in the business system and a process for exceptions. If no one owns data quality, every correction becomes a new special case. Even a good PIM then loses its order.

This way of working doesn’t suit every organisation either. If you can’t set aside time for ownership and validation, it is better to clean up the processes first than to introduce yet another structure.

Once the solution is live, the next question is who carries responsibility at upgrades. Version tracking, compatibility and bug fixing then become important. Glanser Care is an example of a contracted management responsibility at a fixed monthly cost, where upgrades shouldn’t require a new quote each time.

Questions to ask the supplier before you decide

Ask how they separate ownership in the business system from ownership in the PIM. The answer quickly shows whether they have a clear model for data sources or are just talking about order in general terms. Also ask what actually blocks publishing and how validation and language packs are handled before go-live, because that shows whether quality control is built in or merely claimed.

Finally, ask what happens when the platform or business system is upgraded, and whether responsibility remains once the project is finished. If the answer is vague, you know management will probably come back as a new cost item later.

On the PIM page, you can see how we build the product data model, validation and publishing to the website, portals, and resellers.