DPP-Datenmodell: Produktidentität, Datenfelder, Nachweise und Zugriffsrechte

Diese Seite vertieft einen Baustein des Digitalen Produktpasses.

Ein DPP-Datenmodell ist mehr als eine Liste möglicher Attribute. Es beschreibt, welches reale Produkt ein Datensatz meint, woher jede Aussage kommt, wer sie freigibt, wie sie sich über die Zeit verändert und wer darauf zugreifen darf. Ohne diese Regeln bleibt selbst eine technisch schöne DPP-Seite nur eine zweite Produktdatenkopie.

Der Digitale Produktpass im Überblick erklärt den rechtlichen und technischen Rahmen. Dieser Leitfaden geht eine Ebene tiefer: Er zeigt ein umsetzbares, produktgruppenunabhängiges Grundmodell. Es ist ausdrücklich keine universelle Compliance-Vorlage.

Was heute feststeht – und was produktspezifisch bleibt

Die ESPR legt die Systemlogik fest: DPP-Daten müssen auf offenen Standards beruhen, interoperabel, maschinenlesbar, strukturiert, durchsuchbar und übertragbar sein. Der Produktpass wird über einen Datenträger mit einer persistenten eindeutigen Produktkennung verbunden. Die jeweils geltenden delegierten Rechtsakte bestimmen unter anderem die konkreten Daten, den Datenträger, dessen Platzierung, die Granularität auf Modell-, Chargen- oder Artikelebene sowie die Zugriffsrechte.

Das bedeutet für Projekte: Du kannst die Architektur und den Feldvertrag heute vorbereiten. Du solltest aber keine erfundene Liste als endgültige EU-Pflichtfelder verkaufen. Halte deshalb drei Kategorien getrennt: sichere horizontale Anforderungen, begründete fachliche Vorbereitung und noch offene produktspezifische Pflichten.

Primärquellen: ESPR, insbesondere Artikel 9 bis 13 und Anhang III, die harmonisierten DPP-Systemstandards und die JRC-Methodik zur Auswahl von DPP-Daten.

Die sechs Schichten eines belastbaren DPP-Datenmodells

1. Produktidentität

Die Identität beantwortet zuerst: Welches Produkt ist gemeint? Dokumentiere das verwendete Identifikationsschema, die Kennung, den verantwortlichen Wirtschaftsakteur und – wenn verlangt – die Betriebsstätte. Trenne die Kennung von der URL, unter der Daten heute ausgeliefert werden. Eine stabile Identität muss auch nach einem Plattformwechsel weiter auflösbar bleiben.

2. Granularität und Geltungsbereich

Lege explizit fest, ob der Pass für ein Modell, eine Charge oder ein einzelnes Produkt gilt. Das ist keine technische Detailfrage. Die Granularität entscheidet, welche Werte gemeinsam genutzt werden dürfen und welche pro Charge oder Seriennummer variieren. Materialrezepturen können modellbezogen sein, ein Produktionsdatum chargenbezogen und ein Reparaturverlauf artikelbezogen.

3. Fachliche Produkt- und Zirkularitätsdaten

Diese Schicht enthält die eigentlichen Aussagen: Produktmerkmale, Materialien, Stoffe, Reparierbarkeit, Haltbarkeit, Recyclinginformationen, Energie- oder Umweltkennwerte und weitere produktspezifische Angaben. Speichere Werte nicht als fertige Marketingtexte. Ein Wert braucht einen Datentyp, gegebenenfalls eine Einheit, eine Definition und eine erlaubte Kardinalität.

4. Nachweise und Herkunft

Eine Aussage wie „35 Prozent Rezyklatanteil“ ist ohne Herkunft schwach. Verknüpfe relevante Werte mit Lieferantenerklärung, Prüfbericht, Zertifikat, Berechnung oder Messung. Der Nachweis braucht mindestens Typ, Aussteller, Erstellungsdatum, Gültigkeit und einen stabilen Verweis. Bei sensiblen Dokumenten kann der Datensatz öffentlich sein, während das Original nur für berechtigte Rollen zugänglich bleibt.

5. Governance und Lebenszyklus

Das Modell muss festhalten, welches System fachlich führend ist, wer einen Wert verantwortet, wer freigibt und wann eine Aktualisierung nötig wird. Ergänze Status, Versionsnummer, Gültigkeitszeitraum, Änderungsgrund und Beziehung zur Vorgängerversion. Ein DPP ist kein einmaliger Export, sondern ein über Jahre gepflegtes Datenprodukt.

6. Zugriff und Auslieferung

Trenne gespeicherte Daten von ihrer Darstellung. Verbraucher, Reparaturbetriebe, Geschäftspartner, Recyclingunternehmen und Marktüberwachung können unterschiedliche Sichten benötigen. Zugriffsregeln gehören deshalb in das Modell und nicht erst in die Oberfläche. Geschäftsgeheimnisse und personenbezogene Daten werden nicht automatisch öffentlich, nur weil sie intern zum DPP-Prozess gehören.

Der Feldvertrag: neun Angaben pro Datenfeld

Ein Feldname allein reicht nicht. Für jedes relevante Feld sollte ein kleiner Vertrag dokumentiert werden:

• Maschinenname und fachliche Definition: eindeutig und unabhängig von der Oberfläche;

• Datentyp und Einheit: zum Beispiel Dezimalzahl in Kilogramm statt Freitext;

• Kardinalität: genau ein Wert, optional oder wiederholbar;

• Granularität: Modell, Charge oder einzelner Artikel;

• Quellsystem: PIM, ERP, PLM, LCA-System, Lieferantenportal oder Dokumentenmanagement;

• Data Owner und Freigaberolle: fachliche Verantwortung statt nur technischer Ansprechpartner;

• Nachweisanforderung: Dokument, Messung, Berechnung oder keine zusätzliche Evidenz;

• Gültigkeit und Aktualisierungsauslöser: Zeitablauf, Lieferantenwechsel, Rezepturänderung oder Korrektur;

• Zugriff und Qualitätsregel: öffentliche oder beschränkte Zielgruppe sowie Wertebereich, Format und Vollständigkeit.

Diese neun Angaben machen Lücken sichtbar, bevor Code entsteht. Sie verhindern außerdem, dass ein DPP-Anbieter zum stillen Eigentümer der Datenlogik wird. Das Feldmodell sollte außerhalb einer einzelnen Plattform exportierbar und versioniert bleiben.

Modell, Charge oder Einzelprodukt: die Granularität richtig wählen

Beginne nicht automatisch auf Seriennummernebene. Eine feinere Granularität erhöht Datenvolumen, Ereignisverarbeitung, Kosten und Fehlerquellen. Sie ist sinnvoll, wenn individuelle Eigenschaften oder Lebenszyklusereignisse relevant sind. Sind alle vorgeschriebenen Werte für eine Produktfamilie identisch, kann ein Modellpass ausreichend sein – sofern der produktspezifische Rechtsakt das erlaubt.

• Modellebene: gemeinsame Konstruktion, technische Merkmale, Bedien- und Reparaturinformationen;

• Chargenebene: Produktionszeitraum, Werk, Materialcharge, Prüfergebnis oder Lieferantenlos;

• Artikelebene: Seriennummer, individueller Eigentums- oder Reparaturverlauf, konkrete Komponenten.

Praktisch ist ein vererbtes Modell: gemeinsame Werte liegen auf Modellebene, abweichende Chargen- oder Artikeldaten ergänzen oder überschreiben sie nachvollziehbar. So vermeidest Du Millionen fast identischer Datensätze.

Quellsysteme zuordnen: PIM, ERP, PLM und Lieferanten

Das DPP-System sollte nicht für jedes Feld zum neuen Master werden. Das PIM führt typischerweise vermarktbare Produktmerkmale und Übersetzungen, das ERP Artikel, Chargen, Lieferanten und Bewegungsdaten, das PLM Konstruktion und Stücklisten. LCA- oder Compliance-Systeme liefern Berechnungen und Bewertungen; Lieferantenportale liefern Primärnachweise. Die konkrete Aufteilung variiert – entscheidend ist, dass pro Feld eine führende Quelle und ein Konfliktfall definiert sind.

Für Shopware oder andere Commerce-Systeme gilt: Der Shop kann eine DPP-Ansicht ausliefern oder darauf verlinken, sollte aber nicht ungeplant zum alleinigen Archiv für regulatorische Produktdaten werden. Identität, APIs und Nachweise müssen auch außerhalb eines einzelnen Vertriebskanals funktionieren.

Nachweise statt unbelegter Nachhaltigkeitsaussagen

Modelliere Evidenz als eigenes Objekt. Ein Nachweis kann mehrere Felder stützen; ein Feld kann mehrere Nachweise benötigen. Speichere nicht nur eine PDF-URL, sondern auch Aussteller, Methode, Version, Gültigkeitszeitraum und – wenn sinnvoll – einen kryptografischen Prüfwert. Bei einer Korrektur bleibt nachvollziehbar, welche DPP-Version auf welchem Nachweis beruhte.

Das ist besonders wichtig, wenn DPP-Daten später für Einkauf, Reparatur, Marktüberwachung oder automatisierte Entscheidungen genutzt werden. Maschinenlesbarkeit ohne Provenienz skaliert auch Fehler schneller.

Versionierung, Korrekturen und dauerhafte Erreichbarkeit

Eine gedruckte Kennung kann jahrelang im Umlauf bleiben. Deshalb sollte sie auf eine kontrollierte, persistente Identität verweisen und nicht direkt auf eine kurzlebige CMS-Seite. Die Auslieferung darf sich ändern; die Identität und die Auflösungslogik müssen stabil bleiben. Definiere außerdem, ob eine neue Version einen Datensatz ersetzt, ergänzt oder nur einen Fehler korrigiert.

Das seit Juli 2026 verfügbare EU-DPP-Register speichert Kennungen und Metadaten, nicht automatisch den vollständigen Produktpass. Unternehmen bleiben für Hosting, Datenqualität, Zugriff und langfristige Verfügbarkeit ihrer eigentlichen DPP-Daten verantwortlich.

DPP-JSON-Beispiel: eine Startstruktur, keine Compliance-Vorlage

Das folgende gekürzte Beispiel zeigt die Trennung von Identität, Fakten, Evidenz, Governance und Zugriff. Es ist absichtlich generisch. Ersetze weder die Felddefinitionen noch die Granularität ungeprüft für eine reale Produktgruppe.

{
  "passport": { "status": "active", "version": 3 },
  "identity": { "granularity": "batch", "productIdentifier": {} },
  "facts": { "materials": [], "repairability": {} },
  "evidence": [{ "supports": [], "type": "supplier-declaration" }],
  "governance": { "dataOwner": "Product Compliance", "sourceSystems": [] },
  "access": { "public": [], "restricted": [] }
}

Versioniertes JSON-Beispiel v1.0 herunterladen. Eine einfachere visuelle Vorlage findest Du zusätzlich auf der Seite DPP-Beispiel und Vorlage.

DPP-Datenmodell in sieben Schritten erstellen

1. Pilotprodukt und wahrscheinlich relevante Rechtsakte abgrenzen.

2. Granularität und bestehende Produktkennungen dokumentieren.

3. Kandidatenfelder nach Pflicht, fachlich empfohlen und optional klassifizieren.

4. Für jedes Feld Quelle, Owner, Definition, Format, Qualität und Zugriff festlegen.

5. Nachweise, Gültigkeit und Änderungsereignisse modellieren.

6. HTML-Ansicht und maschinenlesbare API aus demselben Datenvertrag testen.

7. Mit einem realen Produkt, echten Lücken und einem Plattformwechsel-Szenario validieren.

Die technische Reihenfolge im Gesamtprojekt zeigt die DPP-Umsetzungsroadmap. Wenn mehrere Systeme, Lieferanten und Verantwortliche zusammengeführt werden müssen, findest Du auf DPP-Beratung und Umsetzung den passenden Projektrahmen.

Häufige Fehler beim DPP-Datenmodell

• eine universelle Pflichtfeldliste versprechen, obwohl produktspezifische Regeln noch fehlen;

• QR-Code, Produktkennung und Produktpass als dasselbe Objekt behandeln;

• Freitext und PDFs sammeln, ohne maschinenlesbare Werte und Herkunft zu modellieren;

• alle Daten auf Einzelproduktebene duplizieren, obwohl Modell- oder Chargenvererbung möglich wäre;

• Zugriffsrechte erst nach dem Datenimport diskutieren;

• den DPP-Anbieter zum einzigen Ort für Felddefinitionen, Historie und Identifikatoren machen;

• eine schöne Demo bauen, aber Korrekturen, Archivierung und Betreiberwechsel nicht testen.

Der beste frühe Test ist deshalb kein perfektes Mock-up. Nimm ein schwieriges Produkt, einen fehlenden Lieferantennachweis, eine Korrektur und einen Rollenwechsel. Wenn das Modell diese Fälle verständlich abbildet, trägt es später auch die Oberfläche.