First-Party- & Zero-Party-Daten: Die neue Datenbasis

Seit Jahren wird der Tod des Third-Party-Cookies ausgerufen — mal als apokalyptisches Szenario, mal als übertriebene Branchenpanik. Die Realität liegt nüchtern dazwischen: Google hat die vollständige Abschaffung in Chrome mehrfach verschoben, aber die Richtung ist unveränderlich. Safari und Firefox blockieren Third-Party-Cookies seit Jahren. iOS 14.5 hat die IDFA-basierte Attribution de facto zerstört. Die regulatorische Landschaft in Europa, durch DSGVO und ePrivacy-Richtlinie, macht das Tracking ohne aktive Einwilligung zu einem rechtlichen Risiko, das viele Unternehmen noch immer unterschätzen.

Was diese Entwicklungen gemeinsam erzwingen, ist ein Paradigmenwechsel: weg von der passiven Datenbeschaffung durch Dritte, hin zur aktiven Daten-Infrastruktur, die ein Unternehmen selbst aufbaut und kontrolliert. Dieser Paradigmenwechsel ist nicht in erster Linie technischer Natur. Er ist strategischer Natur. Wer ihn als reines Cookie-Ersatzproblem behandelt, verpasst die eigentliche Frage: Wie entsteht eine Datenbasis, die wirklich handlungsfähig macht?

Ich arbeite täglich mit Mittelständlern und Gründern, die entweder zu spät gemerkt haben, wie abhängig sie von externen Tracking-Anbietern waren, oder die jetzt die Chance sehen, etwas Grundsätzliches anders zu machen. Dieser Artikel beschreibt den strukturellen Rahmen, den ich dabei für sinnvoll halte — kein Produkt, kein Anbieter, sondern ein Denkmodell.

Die Begriffe werden oft synonym verwendet, bezeichnen aber konzeptionell verschiedene Dinge. First-Party-Daten sind Daten, die ein Unternehmen durch direkte Interaktionen mit Nutzern erhebt — Websitebesuche, App-Nutzung, Kaufhistorie, E-Mail-Öffnungsraten, Support-Tickets. Der Nutzer gibt diese Daten ab, ohne sie notwendigerweise bewusst bereitzustellen. Sie entstehen als Nebenprodukt einer Handlung.

Zero-Party-Daten hingegen — ein Begriff, der von Forrester Research geprägt wurde — sind Daten, die ein Nutzer proaktiv und absichtlich teilt. Präferenzen, die er in einem Onboarding-Prozess angibt. Interessen, die er in einem Präferenz-Center auswählt. Antworten auf eine direkte Frage in einer E-Mail-Kampagne. Der wesentliche Unterschied ist nicht technischer, sondern kontextueller Natur: Zero-Party-Daten entstehen aus einem expliziten Austausch — der Nutzer gibt etwas her, weil er einen Gegenwert erwartet oder versteht.

Dieser Unterschied hat erhebliche Konsequenzen für Qualität und Verlässlichkeit. First-Party-Daten sind verhaltensbasiert und damit tendenziell präzise, aber auch interpretationsbедürftig. Jemand, der eine Produktseite dreimal besucht, ist vielleicht kaufbereit — oder recherchiert für einen Freund. Zero-Party-Daten sind deklarativer Natur: weniger Volumen, aber höhere Intentionsdichte. Ein Nutzer, der angibt, monatlich 5.000 Euro für Marketing-Software auszugeben, ist eine qualitativ andere Datenbasis als einer, der eine entsprechende Seite besucht hat.

Die häufigste Fehlannahme beim Aufbau einer First- und Zero-Party-Datenstrategie ist, dass Daten in einem einzigen Moment erhoben werden müssen — beim Formular-Ausfüllen, beim Kauf, beim Newsletter-Opt-in. Diese Vorstellung führt zu langen, abschreckenden Formularen und zu Daten, die nach wenigen Monaten veraltet sind.

Der konzeptionell sauberere Ansatz ist Progressive Profiling: die schrittweise Anreicherung eines Profils über mehrere Touchpoints hinweg. Ein Nutzer, der sich zum Newsletter anmeldet, gibt zunächst nur E-Mail und Namen an. Beim zweiten Besuch — wenn er auf einen bestimmten Artikel klickt — wird ihm eine kontextbezogene Frage gestellt. Beim nächsten Kontakt kommt eine weitere. Jede Interaktion ist ein Anlass, das Profil zu vertiefen, ohne das Erlebnis zu stören.

Technisch ist das keine Hexerei. Es erfordert eine CRM- oder CDP-Schicht, die Teilprofile persistiert, und eine Logic-Schicht, die entscheidet, welche Frage wann sinnvoll ist. Was es tatsächlich erfordert, ist eine inhaltliche Entscheidung: Welche Datenfelder sind für welche Use Cases relevant? Diese Frage wird in der Praxis selten vor der technischen Implementierung gestellt — was dazu führt, dass Systeme Daten sammeln, die niemand jemals auswertet.

Consent-Management wird in den meisten Unternehmen als Compliance-Problem behandelt: Ein Consent-Banner wird implementiert, ein Anbieter integriert, das Thema gilt als erledigt. Diese Sichtweise ist aus strategischer Perspektive kurzsichtig.

Consent ist die Eingangsbedingung jeder datenbasierten Aktivität. Ob und wie Daten erhoben, gespeichert und genutzt werden dürfen, hängt direkt davon ab, welche Zustimmungen vorliegen. Eine Consent-Orchestrierungs-Schicht, die diese Zustimmungsstatus systemübergreifend verwaltet und an alle nachgelagerten Systeme weiterpropagiert, ist kein technisches Nice-to-have, sondern die Grundlage einer belastbaren Daten-Infrastruktur.

Konkret bedeutet das: Ein Consent Management Platform (CMP) muss nicht nur den Banner steuern, sondern die Zustimmungen eines Nutzers in strukturierter Form an CRM, CDP, Marketing Automation und Analyse-Tools weitergeben. Wenn ein Nutzer seine Zustimmung für Analyse-Cookies zurückzieht, muss dieser Status in allen verbundenen Systemen aktualisiert werden — in Echtzeit, nicht im nächsten nächtlichen Batch-Job.

Im DACH-Kontext ist diese Anforderung keine akademische Überlegung. Aufsichtsbehörden haben in den vergangenen Jahren wiederholt Bußgelder für Cookie-Praktiken verhängt, die nicht dem Stand der Rechtsprechung entsprachen — auch gegen Unternehmen, die formal eine CMP verwendeten, aber deren Consent-Signale nicht korrekt weiterleiteten. Die technische Sorgfalt ist hier rechtlich bedeutsam.

Ein Customer Data Platform ist kein Produkt, sondern ein Architekturprinzip. Es bezeichnet die Idee, Kundendaten aus verschiedenen Quellen in einem persistenten, vereinheitlichten Profil zusammenzuführen — einem Profil, das für andere Systeme zugänglich und aktivierbar ist. Das unterscheidet ein CDP von einem Data Warehouse (das primär für Analyse gebaut ist) und von einem CRM (das primär für Vertriebsworkflows gebaut ist).

Für den Mittelstand ist die Frage selten, welche CDP-Software man einsetzt. Die Frage ist, wie man die CDP-Logik mit verfügbaren Tools umsetzt — denn die meisten mittelständischen Unternehmen werden kein Enterprise-CDP im sechsstelligen Bereich einführen. Was sie können: eine Architektur aufbauen, die die Grundprinzipien umsetzt.

Das erste Prinzip ist die Identitätsauflösung. Derselbe Nutzer hat in der Regel mehrere Datenpunkte in verschiedenen Systemen: eine E-Mail-Adresse im CRM, eine anonyme Session-ID im Analytics-Tool, eine Kundennummer im Shop. Eine CDP-Architektur verknüpft diese Datenpunkte zu einem kohärenten Profil — soweit rechtlich zulässig und technisch möglich.

Das zweite Prinzip ist die Aktivierungsschicht. Daten, die im System schlummern, haben keinen Wert. Die Frage ist: In welchem System, zu welchem Zeitpunkt, auf Basis welcher Datenpunkte, wird welche Aktion ausgelöst? Diese Aktivierungslogik — oft als Audience-Building oder Segmentierungs-Engine bezeichnet — ist der operative Kern einer CDP-Architektur.

Die DSGVO ist im B2B-Kontext ein häufig missverstandenes Thema. Der weitverbreitete Glaube, dass B2B-Kommunikation — also Kommunikation zwischen Unternehmen — grundsätzlich weniger streng reguliert ist, ist in dieser Pauschalität falsch. Personenbezogene Daten bleiben personenbezogene Daten, auch wenn sie im Kontext einer Geschäftsbeziehung verarbeitet werden. Die E-Mail-Adresse eines Einkaufsleiters ist ein personenbezogenes Datum.

Was im B2B-Kontext tatsächlich anders ist: Die Rechtsgrundlage für die Verarbeitung kann sich unterscheiden. Während im B2C-Bereich Einwilligung (Art. 6 Abs. 1 lit. a DSGVO) und Vertragserfüllung (lit. b) die zentralen Grundlagen sind, kommt im B2B-Bereich häufiger das berechtigte Interesse (lit. f) zur Anwendung — insbesondere für Marketing-Kommunikation an bestehende Kunden oder an Kontakte, die im beruflichen Kontext bekannt wurden.

Das berechtigte Interesse ist keine Freifahrtkarte. Es erfordert eine dokumentierte Interessenabwägung, die nachweist, dass das Unternehmensinteresse an der Kommunikation die schutzwürdigen Interessen der betroffenen Person nicht überwiegt. Diese Abwägung muss bei jeder Änderung der Verarbeitungszwecke wiederholt werden.

Für die Daten-Infrastruktur bedeutet das: Jeder Datenpunkt muss mit einer Rechtsgrundlage verknüpft sein. Systeme, die keine Provenienz-Dokumentation für erhobene Daten ermöglichen, sind im DSGVO-Kontext strukturell problematisch — unabhängig davon, wie gut die jeweiligen Daten im operativen Sinne genutzt werden könnten. Die technische Infrastruktur muss die rechtliche Dokumentation mitdenken, nicht als Anhang, sondern als Kernfunktion.

Die folgenden Quellen sind Ausgangspunkte für eine vertiefte Auseinandersetzung mit den im Artikel beschriebenen Themen. Sie sind keine abschließende Bibliographie, sondern eine Auswahl seriöser Primär- und Sekundärquellen.