PIM data model requirements: attributes, variants and data quality
PIM data model requirements define how a PIM stores and controls product data: typed attributes, families, variants, relationships, units, locales, validation, completeness, classification, versioning and regulatory data. The decisive data model requirements are business-user configuration, channel and locale values, variant levels, validation on every entry path and completeness gates per channel.
What belongs in PIM data model requirements?
Data model requirements describe how the PIM structures, stores and controls product data. They form the first of four domains in the PIM requirements guide, because every process, integration and channel depends on them. PIM Selection publishes 60 data model requirements in 11 groups.
| Group | Requirements (count) | Decisive IDs |
|---|---|---|
| Attributes | 6 | DM-002, DM-005, DM-006 |
| Families | 5 | DM-007, DM-008 |
| Variants | 5 | DM-012, DM-013, DM-016 |
| Relationships | 5 | DM-017, DM-021 |
| Units | 6 | DM-022, DM-025 |
| Localisation | 5 | DM-028, DM-030 |
| Validation | 6 | DM-033, DM-034, DM-036 |
| Completeness | 5 | DM-039, DM-041 |
| Classification | 6 | DM-044, DM-045, DM-046 |
| Versioning | 5 | DM-050, DM-053 |
| Regulatory data | 6 | DM-055, DM-058, DM-059 |
The requirements only work when the target model exists on paper first. Designing the product data model before selection explains how to build the attribute inventory that vendors configure for the demo.
Which data model requirements decide the selection?
Five data model requirements separate vendors more than the rest. Most mature PIM systems meet the basic attribute and family requirements. The differences show up in configuration effort, value scoping, variant control and rule enforcement.
- Business-user configuration (DM-002): adding and retiring attributes without a vendor release or developer.
- Channel and locale values (DM-005): one attribute holding global, channel and locale values with clear precedence.
- Variant levels (DM-013): each attribute fixed at model, sub-model or variant level, and enforced on import and API writes.
- Validation on every entry path (DM-033): the same rules for screen edits, file imports and API writes.
- Completeness gates (DM-039, DM-041): completeness per channel and locale that blocks publication below the threshold.
In PIMvendors selections, these five are where demo impressions and implementation reality diverge most often. A vendor may show validation in the user interface while imports bypass it. A vendor may show variants while all attributes sit on one level. Test each of the five on your own data, through every entry path, before you score.
How do we test variants and inheritance in a demo?
Test variants with your own most complex product, imported in full, and change shared values once at model level. Vendor demo catalogues use simple two-axis variants that every system handles.
Choose a product with at least two variant axes, such as colour and size, and a realistic number of variants. Ask the vendor to import it with your attribute levels. Then run four checks in the demo.
- Change a shared description at model level and show which variants receive it (DM-012).
- Import a model-level value on a single variant and confirm the PIM blocks or redirects it (DM-013).
- Override one value on one variant and show the override flag (DM-015).
- Import a duplicated GTIN and a wrong check digit (DM-016, DM-035).
Inheritance between families works the same way. Add an attribute to a parent family and show that the child families receive it, with one child overriding the mandatory setting (DM-008). Moving a product between families should show which values will be dropped before the user confirms (DM-009).
How should a PIM handle units, locales and classification?
A PIM should store units, locales and classifications as controlled, structured data that converts on output. Free text in any of these three areas breaks filtering, standards exports and translation.
Units need a controlled list and a separate numeric value (DM-022). Conversion happens on output without changing the stored value (DM-023). Each packaging level carries its own dimensions (DM-025). Range values such as operating temperatures belong in minimum and maximum fields (DM-027).
Locales need values per locale with configurable fallback per channel (DM-028). Translation status per attribute and locale marks outdated translations when the source text changes (DM-030). Country-specific values, such as legal warnings, sit apart from language values (DM-032).
Classification needs several trees per product (DM-044) and managed import of external standards with the release recorded. Standards move regularly. ETIM 10.0 was published in December 2024 with 119 new classes, according to ITEK. ECLASS 15.0 followed on 29 November 2024 with 490 new classes. Requirements DM-045 to DM-048 make those release changes manageable.
Validation, completeness and versioning as quality controls
Validation, completeness and versioning are the three controls that keep data quality measurable after go-live. Together they stop bad data at entry, show what is missing and record every change.
Validation covers single-attribute rules (DM-033) and cross-attribute rules (DM-034). Cross-attribute consistency is where most channel rejections originate, such as a battery flag without a battery type. Import errors must name the product, attribute and rule in business language (DM-036). Rules should be configurable as blocking or warning per channel (DM-037).
Completeness is calculated per product, channel and locale (DM-039) and drives a publication gate (DM-041). Dashboards with drill-down (DM-040) and personal work lists (DM-043) turn the score into work.
Versioning records every change with source and user (DM-050) and allows comparison and restore (DM-051). It also reproduces a product as it was on a past date (DM-052). Lifecycle states control what each channel receives (DM-053). How these controls fit into wider governance is covered in measuring product data quality.
Regulatory data in the data model
Regulatory data needs structured attributes from the start, because regulation turns product data into a legal obligation. Adding compliance fields as free text after go-live creates data nobody can report on.
The DM domain holds six regulatory requirements. Packaging component data per packaging level supports PPWR obligations (DM-055). Material composition and substances of concern support ESPR (DM-056). Digital Product Passport attributes are flagged and measured separately (DM-057). Manufacturer and responsible operator details (DM-058) and safety warnings per language (DM-059) support GPSR online offer requirements. Commodity and origin references support EUDR due diligence (DM-060).
GPSR has applied since 13 December 2024. Online offers must show the manufacturer details, product identification and warnings or safety information, according to Fieldfisher. The evidence, versioning and passport side of these attributes is covered on requirements for regulatory product data.
The 60 published data model requirements
The full DM set is listed below with statement, rationale, test, default priority and tags. Filter, adjust and export it in the PIM requirements checklist.
{{list:requirements:DM}}
Ask every vendor to configure your two hardest product families before the demo. How long that takes, and who has to do it, tells you more than any feature list.
Frequently asked questions
What is the most important data model requirement for a PIM?
The most important data model requirement is that business users can change the model through configuration, without a vendor release or custom code (DM-002). Product data models change every month. Attributes are added, families split and channels added. A PIM that needs a developer for each change slows every launch and makes the implementation partner a permanent cost.
How many attributes can a PIM handle?
Mature PIM systems handle thousands of attributes, so the raw number rarely separates vendors. The useful test is performance and usability at your own attribute count, locale count and family structure. Provide your attribute inventory and a volume sample before the demo, then measure editing, filtering and export times on that data, as PL-020 and PL-023 describe.
Should completeness be measured per channel?
Yes. A single completeness score hides that a product can be ready for the webshop and still incomplete for a marketplace or a data pool. Requirement DM-039 asks for completeness per product, channel and locale. DM-041 then uses that score as a publication gate, so a product below the threshold for a channel is withheld from that channel.
Do we need ETIM or ECLASS support in our PIM?
ETIM or ECLASS support is needed when your customers or wholesalers expect classified data in those standards. That applies to most electrotechnical, installation, building and industrial supply chains in Europe. Requirements DM-045 and DM-046 ask for managed import of the standard with the release version recorded, so mappings survive the next release.
Sources and method
- ITEK: Release ETIM 10.0
- ECLASS: Release 15.0 available now
- Fieldfisher: New obligations under the EU General Product Safety Regulation
How this page was made: drafted by the PIM Selection editors from the sources listed, checked against the PIMvendors selection method, and signed off by a named expert. Editorial policy.
Cite this page
PIM Selection (2026). PIM data model requirements: attributes, variants and data quality. PIMvendors.com. https://pimselection.com/requirements/data-model-requirements/ (version 2026-10-14).