Data Product
Auch: Data product, Data-as-a-product, DaaP, Produit de donnees, Produit data
Ein Datenbestand, der wie ein Produkt gemanagt wird: mit Owner, definierten Nutzern, garantierter Qualität und messbarem Geschäftswert.
Was es ist
Ein Data Product ist ein wiederverwendbarer Datenbestand, der wie ein echtes Produkt konzipiert, ausgeliefert und gepflegt wird und nicht wie ein einmaliger Report oder ein ad hoc erstellter Extrakt. Es hat einen verantwortlichen Owner, einen bekannten Kreis von Consumern, einen expliziten Quality Contract und einen klaren Bezug zum Geschäftswert.
Anders als eine Rohtabelle, die im Warehouse liegt, ist ein Data Product für den Konsum aufbereitet. Typischerweise bündelt es:
- Die Daten selbst (ein kuratiertes Dataset, eine Metrik, ein Feature Set oder eine API).
- Metadaten und Dokumentation (Schema, Definitionen, Lineage, Ownership).
- Service-Garantien (Freshness, Vollständigkeit, Genauigkeit, Verfügbarkeit).
- Zugang und Interfaces (SQL-Tabelle, API-Endpoint, Dashboard oder Feed).
Warum es zählt
Die meisten Organisationen ertrinken in Datasets, denen niemand traut und die niemand findet. Daten als Produkt zu behandeln, richtet die Incentives neu aus:
- Accountability: Jemand ist dafür verantwortlich, dass es korrekt und nützlich bleibt.
- Vertrauen: Consumer erhalten dokumentierte, garantierte Qualität statt Rätselraten.
- Reuse: Ein gut gebautes Produkt bedient viele Teams und reduziert doppelte Pipelines.
- Value Tracking: Nutzung und Ergebnisse werden gemessen, sodass Produkte mit geringem Wert abgeschaltet werden können.
Diese Denkweise liegt modernen Ansätzen wie Data Mesh zugrunde, bei dem Domain-Teams ihre eigenen Data Products besitzen und veröffentlichen.
Wie es in der Praxis eingesetzt wird
Ein Data Product aufzubauen und zu betreiben umfasst meist:
1. Consumer und Use Case definieren. Wer braucht das, und um was zu entscheiden?
2. Einen Owner benennen. Ein Product Owner (oft in einer Business-Domain) ist verantwortlich.
3. Einen Data Contract festlegen. Schema, Freshness und Qualitätsschwellen vereinbaren (ein Service Level Agreement, kurz SLA).
4. Bauen und veröffentlichen. Über ein stabiles Interface bereitstellen, mit Dokumentation in einem Katalog.
5. Monitoren und iterieren. Nutzung, Qualität und Wert verfolgen; Änderungen sorgfältig versionieren.
Ein konkretes Beispiel
Ein Händler baut ein „Customer 360“ Data Product.
- Owner: der Domain Lead Customer Analytics.
- Consumer: Marketing (Segmentierung), Finance (Lifetime Value) und ein AI-Team (Features für ein Churn-Modell).
- Contract: täglich bis 6 Uhr aktualisiert, 99 Prozent Identity Match Rate, nur DSGVO-konforme Felder.
- Interface: eine governte Tabelle plus eine dokumentierte API.
- Wert: gemessen an Campaign Lift, Modellgenauigkeit und eingesparten Stunden gegenüber dem wiederholten Neubau von Joins.
Weil es ein Produkt ist, flickt das Marketing-Team keine Spreadsheets mehr zusammen, das AI-Team bekommt stabile Features, und Finance nutzt dieselben Kundendefinitionen wie alle anderen. Wenn das Schema geändert werden muss, versioniert der Owner es und informiert die Consumer, statt nachgelagerte Arbeit still zu zerstören.
Siehe auch
Häufige Fragen
Was ist ein Data Product?
Ein Data Product ist ein wiederverwendbarer Datenbestand, der wie ein echtes Produkt gemanagt wird und nicht wie ein einmaliger Report: mit verantwortlichem Owner, einem identifizierten Kreis von Consumern, einem expliziten Quality Contract und einem messbaren Bezug zum Geschäftswert. In der Praxis bündelt es die Daten (Dataset, Metrik, Feature Set oder API), deren Metadaten und Dokumentation, Service-Garantien zu Freshness und Genauigkeit sowie ein stabiles Zugangs-Interface.
Was ist der Unterschied zwischen einem Data Product und einer Tabelle im Warehouse?
Eine Rohtabelle wird gespeichert; ein Data Product ist für den Konsum aufbereitet. Die Tabelle existiert ohne dokumentierte Ownership, ohne Qualitätszusage und ohne bekannte Consumer, also weiß niemand, ob man ihr trauen kann. Ein Data Product ergänzt einen Owner, ein dokumentiertes Schema mit Lineage, ein SLA zu Freshness und Vollständigkeit sowie ein stabiles Interface, und genau das macht es für mehrere Teams wiederverwendbar.
Warum sollten sich ein CMO oder CFO für Data Products interessieren und nicht nur das Data-Team?
Weil der Owner eines Data Products meist in einer Business-Domain sitzt und nicht in der IT, und weil die Consumer Marketing, Finance und AI-Teams sind. Ein gemeinsames „Customer 360“-Produkt bedeutet, dass Marketing-Segmente, die Lifetime-Value-Berechnung in Finance und das Churn-Modell dieselben Kundendefinitionen nutzen statt drei auseinanderlaufender Spreadsheets. Der Wert wird ebenfalls in Business-Begriffen verfolgt: Campaign Lift, Modellgenauigkeit, eingesparte Stunden.
Was gehört in einen Data Contract?
Ein Data Contract legt fest, worauf sich Consumer verlassen können: das Schema, die Aktualisierungsfrequenz und Qualitätsschwellen, ausgedrückt als SLA. Für ein „Customer 360“-Produkt könnte das eine tägliche Aktualisierung bis 6 Uhr sein, eine Identity Match Rate von 99 Prozent und nur DSGVO-konforme Felder. Entscheidend ist, dass jede Änderung dieser Bedingungen versioniert und den Consumern angekündigt wird, statt nachgelagerte Arbeit still zu zerstören.
Wo fängt man an, wenn man ein erstes Data Product aufbaut?
Beginnen Sie mit dem Consumer und der Entscheidung, nicht mit der Pipeline: Wer braucht diese Daten, und um was zu entscheiden? Benennen Sie dann einen verantwortlichen Owner, vereinbaren Sie den Data Contract zu Schema, Freshness und Qualität, veröffentlichen Sie über ein stabiles Interface mit Dokumentation in einem Katalog, und überwachen Sie Nutzung, Qualität und Wert, damit Produkte mit geringem Wert abgeschaltet werden können. Wer den ersten Schritt überspringt, endet mit Datasets, die niemand nutzt.