Two questions come before any Digital Product Passport can go live: what should the data model look like, and how far is the current catalog from that model. Get the model wrong and every category you add multiplies the rework. Skip the audit and you plan against guesses instead of facts. This guide covers both: a practical structure for a DPP-ready data model, and a repeatable way to audit a catalog against it. It follows the ESPR Annex I parameters explained in this companion guide and feeds directly into the free DPP Data Field Mapper .
Start from eight data domains, not a single flat list
The Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781, does not publish one master field list. Annex I sets the parameters that ecodesign requirements can cover, and each product group’s delegated act picks the parameters and the exact data that applies to it. Rather than wait for every act, group your model into eight domains that nearly every product group will need in some form.
| Domain | Typical fields | Usual owner |
|---|---|---|
| Identification | Unique product, operator and facility identifiers; GTIN and model | Product, IT |
| Documentation | Manuals, declarations of conformity, safety information | Compliance, legal |
| Materials and substances | Composition, substances of concern, recycled content | Sustainability, suppliers |
| Durability and reliability | Expected lifetime, reliability indicators, warranty | R&D, quality |
| Repair, reuse and upgrade | Repairability, spare parts, repair instructions, updates | R&D, after-sales |
| Environmental footprint | Energy use, carbon footprint, resource use | Sustainability |
| Circularity and end of life | Recyclability, disassembly, take-back, waste | Sustainability, operations |
| Supply chain | Supplier and site map, raw material origin, due diligence | Procurement, compliance |
This structure does two things. It gives every attribute a home before you know the final field list, and it gives you a natural way to report progress: complete, partial or missing, domain by domain, rather than one undifferentiated percentage.
Design the schema: five decisions that are expensive to change later
1. One identifier scheme, decided early
Decide how your GTIN, internal SKU, model number and the unique product identifier relate to each other before building anything else. The unique identifiers expected for products, economic operators and facilities are meant to follow the ISO/IEC 15459 series or an equivalent. Retrofitting an identifier scheme after products are already live is the single most disruptive change a program can face.
2. A core model plus category overlays
Keep a small set of fields common to every product (identity, manufacturer, documentation) and add overlays per category or product group for the fields specific to it. A single flat schema that tries to hold every possible field for every category becomes unmanageable once more than two or three groups are in scope.
3. One unit and one value list per field
Store weight in grams or kilograms, never a mix, and record the unit explicitly. Materials, substances, countries and similar attributes should come from a controlled list, not free text, so the same value is never written three different ways across the catalog.
4. Evidence attached to the value, not filed separately
Every claim that could be checked, a recycled-content percentage, a durability figure, a substance disclosure, should carry a link to its evidence: a certificate, test report or declaration, and the date it was issued. A value with no evidence is a liability, not an asset.
5. Versioning at three levels
Track schema version (the model itself), record version (a product’s data over time) and payload version (what was actually published) separately. When a question comes up about what a customer or authority saw on a given date, only this separation lets you answer it precisely.
Audit the catalog against the model
An audit is not a one-off spreadsheet exercise. Run it as a repeatable check with the same eight questions every time, so results are comparable across categories and over time.
| Check | Question to ask | Common failure |
|---|---|---|
| Identity and classification | Does every SKU have a GTIN, model number and a category assigned? | Missing or duplicate identifiers; products with no category |
| Core specification fields | Are the fields your category needs present and in a controlled format? | Free-text values where a controlled list should exist; missing units |
| Material and substance data | Is composition recorded at product or component level, with a source? | Composition present for the product but not per component; no substance-of-concern screening |
| Durability and repair data | Are lifetime, warranty and repair information captured for the products that need them? | Fields exist in the schema but are empty for most products |
| Environmental data | Is there a carbon footprint or other environmental figure, with a stated method? | A number exists with no method or date, which will not survive scrutiny |
| Evidence and documents | Is every claim backed by a certificate, test report or declaration you can produce? | Values entered without the evidence that supports them |
| Supplier and origin data | Do you know which supplier and site produced each component? | Origin known at the finished-product level only |
| Multilingual and market data | Is consumer-facing content available in the languages your markets need? | Only the original language exists; other markets show blank or fallback text |
Score each domain rather than the catalog as a whole. A catalog that is 95% complete on identification and 10% complete on substances of concern is a different problem than one that is evenly 50% everywhere, and the two need different remediation plans.
A five-step process to go from zero to a scored model
- Inventory current attributes. List every field you already hold, in every system, and where it lives (ERP, PLM, PIM, spreadsheets).
- Map to the eight domains. Assign each existing field to a domain, and flag domains with no field at all. The DPP Data Field Mapper does this mapping and produces a ranked gap list automatically.
- Score completeness and evidence, not just presence. A field that is populated but has no evidence is only half done.
- Fix identifiers and structure before content. Standardising units, identifiers and value lists is cheap now and expensive after the catalog has grown.
- Prioritise by product group status. Spend first on groups closest to a delegated act; the DPP Product Category Lookup shows where each one stands.
Where this fits in the wider programme
Building and auditing the data model is phases two and three of a six-phase programme. The full sequence, including scope, supplier evidence, carrier selection and rollout, is in the 30-step ESPR compliance roadmap , tracked with the free ESPR Compliance Roadmap . The data behind the model still has to reach the product through a data carrier; see how QR code, Data Matrix, NFC and RFID compare for that decision. For the regulatory detail behind each domain, read the ESPR Annex I parameters guide , and for the wider programme view, the Digital Product Passport guide .
Frequently asked questions
What should a Digital Product Passport data model include?
Group attributes into eight domains: identification, documentation, materials and substances, durability and reliability, repair and upgrade, environmental footprint, circularity and end of life, and supply chain. Use a small core schema for every product plus category-specific overlays.
How do I audit a catalog for DPP readiness?
Check each of the eight domains for presence, format consistency, and evidence, not just whether a field exists. Score domains separately rather than producing one overall percentage, since gaps cluster differently by domain.
Should I use a flat data model or an extensible one?
A hybrid works best: a stable core for identity and governance fields, with extensible, versioned overlays for category-specific fields. A single flat schema becomes unmanageable once more than a few product groups are in scope.
What is the most common data modeling mistake?
Not deciding an identifier scheme early. Retrofitting how GTIN, SKU and the unique product identifier relate to each other after products are already live is the most disruptive change a programme can face.
Why does evidence matter as much as the data value?
A value with no supporting certificate, test report or declaration cannot be defended if it is challenged. Evidence should be attached to the value itself, with a date, not filed separately.
How does this relate to Annex I of the ESPR?
Annex I lists the parameters that ecodesign requirements can cover. The eight-domain model translates those parameters into concrete data fields and owners, which is what a delegated act ultimately expects a company to produce.
