1. Home
  2. News
  3. Product data
Product data

Product data platform for ecommerce, B2B and compliance workflows

A product data platform unifies attributes, media and compliance documents for ecommerce and B2B. How to model data, connect the ERP and prepare for DPP.

Product data platform for ecommerce, B2B and compliance workflows

A product data platform for ecommerce, B2B and compliance is a single place where product attributes, texts, media, documents and compliance evidence are modelled once, owned by named people and published to every channel – webshop, B2B portal, marketplaces, print catalogues and, increasingly, public product passports. It sits between the ERP, which stays the source of truth for commercial data, and the channels that consume product information. Whether you need a classic PIM, a custom platform or a product data platform with compliance features built in depends on how many channels you serve, how regulated your products are and how often the data changes.

The problem it solves

In most growing B2B companies product data ends up scattered. Article numbers and prices live in the ERP. Marketing texts sit in the shop backend. Technical data sheets are PDFs on a shared drive. Safety data sheets, declarations of conformity and certificates are emailed on request. Each channel gets its own copy, and each copy drifts.

The symptoms are familiar:

  • the same product has different dimensions in the shop and in the B2B portal,
  • a new product takes weeks to go live because data is collected by email,
  • distributors ask for data in their own format and someone builds spreadsheets by hand,
  • a customer or an auditor asks for a certificate and nobody is sure which version is current.

What belongs where: ERP, PIM and product data platform

A clean split of responsibilities prevents most of these problems:

  • ERP – article number, units, prices, stock, tax data, supplier references. It is the commercial source of truth.
  • Product data platform or PIM – descriptive attributes, marketing texts in several languages, images, videos, technical documents, category structures, channel-specific variants of content.
  • Compliance layer – regulated attributes (materials, hazardous substances, energy data, origin), evidence documents with validity dates, and the history of who changed what and when.
  • Channels – shop, B2B portal, marketplaces, feeds for distributors, public product pages or passports reached via QR code.

In smaller setups the PIM and compliance layer are one system. In others, a dedicated platform such as our own DPPC handles product passports and compliance data alongside an existing PIM. The point is that each attribute has exactly one owner and one source.

Designing the data model

The data model decides whether the platform stays useful. Key decisions:

Product families and attribute sets

Group products into families that share attributes (cables, adhesives, packaging, garments). Each family has an attribute set with types, units and validation rules. A free-text field for "weight" in every product is how inconsistencies start; a numeric field with a fixed unit is how they are prevented.

Variants and inheritance

Colour and size variants should inherit shared attributes from a parent and only override what differs. This keeps translations and documents in one place.

Localisation

Distinguish between translatable fields (descriptions, marketing claims) and fields that are the same in every language (dimensions, codes). Translations need a status, so a channel can refuse to publish an incomplete language version.

Documents as data

Treat certificates and declarations as records with type, scope (which products), issuer, issue date and expiry, not just as files. Then the platform can warn when a document expires and show which products are affected.

Channel views

Each channel needs a subset of data in its own shape. Define channel views explicitly: which attributes, which languages, which completeness rules must be met before a product is published there.

Compliance and the Digital Product Passport

The EU Ecodesign for Sustainable Products Regulation (ESPR, Regulation (EU) 2024/1781) introduces Digital Product Passports, with concrete requirements defined product group by product group in delegated acts. For batteries, the Battery Regulation already sets a passport obligation from February 2027. Even where no obligation applies yet, customers and distributors increasingly ask for structured sustainability and material data.

A product data platform prepared for this needs:

  • attributes for materials, substances, origin and repair or recycling information,
  • versioning, so you can show what data was valid when a product was sold,
  • public and restricted views of the same product, since not every attribute is for everyone,
  • stable identifiers and resolvable links, for example QR codes following GS1 Digital Link,
  • an audit log of changes and approvals.

We describe the passport side in more detail in Digital Product Passport platform for product data.

Integration architecture

A typical data flow looks like this:

  1. The ERP publishes new or changed articles through an API or scheduled export; the platform creates or updates the product skeleton.
  2. Product managers and technical staff enrich the product: attributes, texts, media, documents.
  3. Completeness rules per channel decide when the product can be published.
  4. Approved changes are pushed to channels through APIs or feeds – the shop, the B2B portal, marketplaces, distributor exports.
  5. Public product pages or passports are generated from the approved compliance data.
  6. A nightly job compares key identifiers between ERP, platform and channels and reports differences.

Integrations should be event-driven where channels support it and fall back to scheduled synchronisation where they do not. For the integration layer itself, see our article on API integration services for ERP, CRM and ecommerce. A practical example of a multi-channel B2B and ecommerce setup is our project for Inspirion GmbH, integrated with the LEO API.

Build, buy or combine?

  • Off-the-shelf PIM fits when your data model is close to standard retail or distribution needs and you mainly need enrichment and channel feeds.
  • A custom platform makes sense when your products have unusual structures (formulations, configurable products, technical parameters with complex rules), when compliance data is central, or when the platform must be deeply tied to your B2B portal.
  • A combination – existing PIM plus a dedicated compliance and passport layer – is often the most pragmatic route for companies that already have a working PIM.

Common mistakes

  • Starting with the tool instead of the data model. Migrating messy data into a new system just moves the mess.
  • No ownership. Every attribute group needs a responsible person or team.
  • Importing everything. Legacy fields nobody uses should be dropped, not migrated.
  • Ignoring completeness rules. Without them, channels publish half-finished products.
  • Documents as attachments only. Without metadata, expiry and scope, compliance evidence cannot be managed.

Next step

Take one product family and list its attributes, documents and the channels it is published to, noting where each piece of data lives today. That exercise alone shows where the gaps and duplicates are. If you want to discuss how a platform could look for your products, including passport and compliance requirements, see our DPPC product data services or contact us to walk through your current setup.

FAQ

Frequently asked questions

What is the difference between an ERP and a product data platform?

The ERP holds commercial data such as article numbers, prices, stock and tax data. A product data platform manages descriptive attributes, texts, media, documents and compliance data and publishes them to channels.

Do we need a product data platform for the Digital Product Passport?

You need structured, versioned product and compliance data with stable identifiers and public and restricted views. A product data platform is a practical way to provide that, either on its own or alongside an existing PIM.

Should we buy a PIM or build a custom platform?

An off-the-shelf PIM fits standard retail and distribution data. A custom platform or a dedicated compliance layer makes sense for complex product structures, central compliance requirements or tight integration with a B2B portal.

How should certificates and declarations be managed?

As records with type, product scope, issuer, issue date and expiry rather than as plain files. The platform can then warn about expiring documents and show which products are affected.

How to turn this topic into a project

JiraSoft looks at topics like this through the lens of a real system: data, backend, API integrations, B2B workflows, Google visibility and content prepared for AI answers. This article is a starting point for a practical workflow conversation.

Turn this topic into a concrete project

Send the current situation, system stack and business goal. We will suggest the first delivery step.

Book a free call +48 887 883 084

#softwareThatDelivers

No noise. Real systems. Software that runs in production.

Talk about the project