Product data model design: build it before you select a PIM

Why design the data model before selecting a PIM?

Design the data model first, because the model decides which requirements matter and how vendors should prove them. Most PIM selections fail before the first demo, because buyers compare software before they have defined their data model. The correct sequence is Data, then Process, then People, then Tooling.

1. 1DataThe model, the attributes and who owns each attribute group
2. 2ProcessHow products are created, enriched, approved and published
3. 3PeopleOwners, data stewards and the capacity to do the work
4. 4ToolingThe platform that runs the first three

A designed model changes the selection in three ways. Vendors configure your families and attributes, so the demo shows your complexity. Requirement owners can write precise data model requirements, as described in the PIM requirements guide. Scope, ownership conflicts and standards needs surface while changes are still cheap.

The model is also the one deliverable that survives the selection. Whichever vendor wins, the entity overview, family structure and attribute inventory become the configuration specification. After go-live, the inventory becomes the data dictionary. Work spent on the model before selection is therefore never lost.

Which entities does a product data model need?

A product data model needs a small set of core entities and a clear owner and source for each. Start with the entity overview before any attribute work, because entities decide where each attribute will live.

Not every business needs every entity. A brand without suppliers can drop the supplier entity. A manufacturer with regulated products will need evidence as a first-class entity. Requirements for regulatory evidence are covered in requirements for regulatory product data.

How do we structure families and variants?

Structure families around shared attributes, and variants around the axes that create sellable units. Families define what complete means for a product type. Variants define which values are shared and which differ.

Start with families. Group products that share most attributes and the same completeness rules per channel. Build a parent and child hierarchy where a set of attributes is common to several families, such as general logistics data. Keep the number of families as low as the attribute differences allow.

Then define the variant structure per family.

1. List the variant axes, such as colour, size or voltage.
2. Decide the levels: model, optional sub-model and variant.
3. Assign each attribute to one level, based on where its value changes.
4. Mark which identifiers belong to the variant, such as GTIN and supplier article number.

The level assignment is the most important design choice. An attribute placed too high forces overrides. An attribute placed too low forces repeated entry. Requirements DM-012 and DM-013 then test whether the vendor enforces your levels in editing, import and API writes. Both are explained on data model and data quality requirements.

How do we build an attribute inventory?

Build the attribute inventory as one row per attribute with the same columns for every family. The inventory is the input vendors configure for the demo and the specification the implementation partner configures afterwards.

Collect attributes from every current source: spreadsheets, ERP fields, webshop exports, retailer templates and supplier files. Expect duplicates with different names and conflicting definitions. Resolving them is the main work, and it is cheaper now than during migration.

In PIMvendors selections, buyers complete the inventory in full for two or three representative families before the demo. The rest follows at family level during implementation.

Who owns which product data?

Every attribute group needs a named owner and steward, and every attribute needs one source system. Ownership is the link between the data model and the governance model.

Owners decide definitions, allowed values and quality rules for their attribute groups. Stewards maintain the rules and resolve issues day to day. In a typical split, product management owns descriptive and technical attributes, and marketing owns channel content and assets. Supply chain owns logistics and packaging data, and compliance owns regulatory attributes and evidence.

Source systems need the same clarity. The ERP usually owns article number, status, base unit and logistics data. The PIM owns descriptive, technical, marketing and channel data. Ownership per attribute between ERP and PIM is tested by requirement IN-009.

Record owner, steward and source in the inventory itself. Requirement PR-042 then checks that the PIM shows the owner on the editing screen, so ownership is visible in daily work. The governance side is covered in product data governance.

How should standards shape the data model?

Standards should shape the model where your customers require them, and stay a mapping layer elsewhere. A model copied from a classification standard rarely fits marketing and channel needs. A model that ignores the standard makes every export a manual project.

Map internal attributes to the standard features that trading partners expect. Electrotechnical, installation and building wholesale expects ETIM. Industrial procurement often uses ECLASS. Retail through data pools follows GS1. Keep the internal model stable and maintain the mapping as configuration, with coverage reports per class (DM-047).

Standards move. ETIM 10.0 was published in December 2024 with 119 new classes and 33 removed, according to ITEK. ECLASS 15.0 added 490 classes and about 810 properties, in 31 languages. Record the release version used per mapping, so the impact of the next release can be assessed. Standard-specific guidance is on the ECLASS and ETIM pages.