Customer Data Platform: Build or Buy?
Personalisierung ist und war schon immer ein relevantes Thema in der Online-Kontaktaufnahme mit (potenziellen) Kunden. Mit nahendem Ende der Third-Party Cookie-Technologie, welche bis dato die Grundlage für die Datenerfassung und Zuordnung von Nutzerinteraktionen der meisten Marketing-Tools darstellt, wird der eigene Datenbestand (First-Party) zunehmend relevanter. Fragmentierte Profile einzelner Nutzer gilt es zu zentralisieren und unter Beachtung neuer datenschutzrechtlicher Anforderungen zusammenzuführen, um auch in Zukunft eine individuelle Customer Journey Experience zu gewährleisten. In diesem Zusammenhang wurden Customer Data Platforms in den letzten Jahren für viele Unternehmen interessant. Es stellt sich jedoch die Frage nach ihrer Notwendigkeit. Die Anschaffung einer Customer Data Platform ist oftmals mit hohen Kosten, direkten Eingriffen in die Marketingstrategie und dem operativen Datenfluss mehrerer Tools und Systemen verbunden. Einige Unternehmen besitzen bereits eine bestehende Daten-Architektur in Form eines performanten (Marketing-) Data Warehouse, dessen operative Nutzung tief verwurzelt ist. Für andere Strukturen ist die Integration einer solchen End-to End-Lösung mit Einschränkungen in ein bestehendes komplexes Ökosystem verbunden, weshalb die Investition in den Ausbau der eigenen Cloud-Umgebung sinnvoller wäre. Bevor man sich mit der Wahl eines passenden CDP-Anbieters beschäftigt, sollte daher die bestehende Daten-Architektur evaluiert werden, um gegebenenfalls den Ausbau der eigenen Infrastruktur um nötige Funktionalitäten vorzuziehen.
Dieser Beitrag soll als Entscheidungsgrundlage dienen, um den Rahmen für die Nutzung einer CDP und/oder ihrer Funktionalitäten im eigenen Unternehmen abwägen zu können.
1. Nutzen einer CDP für datengetriebene Unternehmen
Die Frage über die Rolle und Notwendigkeit einer Customer Data Platform ist immer im Zusammenhang mit dem bestehenden Data Management in der Organisation zu beantworten. Viele Unternehmen, die in datengetriebenen Geschäftsfeldern agieren, verfügen bereits über bewährte Infrastrukturen (ETL/ELT-Prozesse) und/oder Plattformen und Tools zur Datenverarbeitung und Aktivierung.
Zunächst gilt es, die Aufgabenbereiche und Funktionalitäten verschiedener Data Management Tools abzugrenzen, um den Funktionsumfang und die Anforderungen an eine CDP-Lösung definieren zu können. Das folgende Schaubild bietet eine Übersicht über gängige Lösungen, die in einer datengetriebenen Organisation schon häufig genutzt werden, und zeigt Überschneidungspunkte einzelner Funktionalitäten mit einer CDP auf:
①Eine Data Management Platform (DMP) nutzt anonymisierte und pseudonymisierte Daten, während die CDP zusätzlich personenbezogene Daten verarbeitet und somit das Kundenprofil hochgradig personalisiert.
② Ein Customer Relationship Management System (CRM) fokussiert sich auf die Customer Journey innerhalb der Organisation, während die CDP diese zusätzlich mit Kontaktpunkten des Nutzers außerhalb des Unternehmens verbindet.
③ Eine CDP baut auf den Funktionen einer DMP, eines DWH sowie eines CRM auf und kombiniert diese miteinander, um einen holistischen Blickwinkel auf die Customer Journey innerhalb und außerhalb des Unternehmens zu ermöglichen (360 Customer View).
2. CDP-End-to-End-Lösungen
Die Einführung einer Customer Data Platform kann zeit- und ressourcenintensiv sein und mit hohen Investitionskosten einhergehen. Dennoch haben CDP-Anbieter ihre Berechtigung und können für einige Unternehmen das richtige Mittel zur Wahl darstellen, wenn die individuellen Anforderungen und Kriterien für den Unternehmenszweck erfüllt sind. Im Folgenden werden grundlegende Vor- und Nachteile einer CDP-End-to-End-Lösung betrachtet.
2.1 Vorteile
Vertikale Einsatzmöglichkeiten
Es gibt bestimmte CDP-Anbieter, die Ihre Leistung vertikal, also auf eine bestimmte Art von Unternehmen, abgestimmt haben (Branche, Größe, Zweck usw.). Unternehmen, die auf eine vertikale CDP-Lösung setzen, verwenden allerdings oft zusätzlich ein (Marketing-)Data Warehouse für tiefgreifendere Analysen und nutzen lediglich Funktionen wie das Identity-Resolution und Matching der CDP, welches an die bestehenden Data Pipelines von Data Warehouse angeschlossen wird.
No-Code-Funktionalitäten und User Interface
Die Kernkompetenz einer CDP stellt die Identitätsauflösung (Identity Resolution) personenbezogener Daten und ihre Anreicherung mit Profilfragmenten dieser Nutzer aus diversen Tools und Marketing-Kontaktpunkten dar. Technische Abläufe und ihre Einhaltung gesetzlicher Vorschriften für die Datenverarbeitung liegen in der Hand der Plattform und laufen zum größten Teil hinter einem benutzerfreundlichen User Interface ab, ohne dass der Nutzer tief in technische Details einsteigen muss.
Eine CDP benötigt keinen „Modern Data Stack“
Der Ausbau einer Cloud-Umgebung auf Basis eines (Marketing-)Data Warehouse ist nur so gut wie das Data Warehouse selbst. Besteht keine performante Architektur um das Data Warehouse, kann eine CDP eingesetzt werden, um Engpässe in der Marketing-Aussteuerung zu mildern.
Real-Time-Funktionalitäten
Einige CDPs verfügen über Echtzeit-Funktionen, die sich mit einem Data Warehouse allein nur schwer oder nahezu unmöglich erreichen lassen. In den meisten Branchen sind wirkliche Real-Time-Funktionalitäten jedoch weder notwendig noch hilfreich. Die meisten Processing-Funktionen, die als Real-Time beworben werden, bieten zudem eher eine “Near-Time”-Datenverarbeitung. Dennoch gibt es bestimmte Anwendungsfälle, in welchen die Ausführung von Vorgängen in Echtzeit sinnvoll ist. Zum Beispiel sollte eine Transaktionsbenachrichtigung wie „Danke für Ihren Einkauf“ nicht erst eine Stunde später zugestellt werden.
Maintenance und SLA
Einer der wichtigsten Vorteile einer CDP: Mit dem Einkauf einer standardisierten CDP End-to-End-Lösung ist in den meisten Fällen ein umfangreiches Service-Level-Agreement (SLA) vertraglich inkludiert. Das SLA beinhaltet oftmals Zugang zu einem direkten Ansprechpartner sowie einem Support-Team für technische Probleme und Fragen. Ein wesentlicher Vorteil stellt jedoch die Sicherstellung der Instandhaltung der technischen Infrastruktur der Plattform durch den Anbieter dar. Im Gegensatz zu einem individuellen Cloud-Setup liegt die Verantwortung der Datenverarbeitung- und -bereitstellung durch die Plattform aufseiten des Anbieters, wodurch technische und personelle Ressourcen eingespart werden.
2.2 Nachteile
Kosten und Time-to-Market
Ein entscheidender Faktor gegen den Einsatz einer End-to-End-Lösung stellt das finanzielle Investment dar. Die Einsparung interner Ressourcen und Infrastruktur auf Unternehmensseite lassen sich Anbieter teuer bezahlen. Neben den initialen Investitionskosten für die Integration und Inbetriebnahme der CDP-Lösung stehen die laufenden Kosten für die Nutzung häufig in keinem sinnvollen Kosten-Nutzen-Verhältnis. Hinzu kommt eine lange Integrationszeit, da durch den Eingriff in bestehende Strukturen operative Abläufe negativ beeinflusst werden können.
Flexibilität und Anpassungsfähigkeit
Auch wenn die meisten End-to-End-Lösungen standardmäßig eine Vielzahl an Konnektoren und konfigurierbaren Schnittstellen für gängige Tools und Datenquellen bieten, sind sie doch recht starr in ihrer Datenarchitektur und Datenverarbeitung. Die Datenstrategie des eigenen Unternehmens ist daher stark abhängig von den Innovationen und Updates der CDP-Anbieter. Zudem stellt sich die Frage, ob alle lizenzierten Funktionen einer CDP überhaupt genutzt werden. Häufig ist lediglich die Nutzung einiger Kernfunktionalitäten von Bedeutung. Gezahlt wird jedoch in der Regel für den vollen Funktionsumfang der Plattform. Mit dem Ausbau einer Cloud-Umgebung, wie bspw. der Google Cloud, könnten nach dem Pay-per-Use-Modell Leistungen besser auf den individuellen Bedarf angepasst werden.
Eine CDP benötigt keinen „Modern Data Stack“
Der Ausbau einer Cloud-Umgebung auf Basis eines (Marketing-)Data Warehouse ist nur so gut wie das Data Warehouse selbst. Besteht keine performante Architektur um das Data Warehouse, kann eine CDP eingesetzt werden, um Engpässe in der Marketing-Aussteuerung zu mildern.
Intransparenz
Die Nutzung eines schicken User Interface sowie von standardisierten Konnektoren und Modellen für die Datenverarbeitung birgt neben der Einsparung personeller und technischer Komplexität allerdings auch Intransparenz. Gerade relevante Kernfunktionen wie das Audience Modelling sind davon betroffen. In Zukunft werden Audiences nicht mehr manuell mit simplen Operatoren und/ oder Verknüpfungen erstellt, sondern mit entsprechenden Algorithmen automatisiert. Die Bildung von Segmenten und Audiences auf Basis statistischer Verfahren ist derzeit in allen angebotenen CDPs nicht transparent und auch nicht anpassbar. Data-Scientisten werden mit dem derzeitigen Funktionsumfang nicht viel anfangen können.
Hosting
Es ist nicht immer ist gewährleistet, dass das Hosting der von der CDP generierten und verarbeiteten Daten auch in europäischen Hoheitsgebieten stattfindet. Die Datenverarbeitung personenbezogener Daten steht demnach im Konflikt mit der bestehenden Rechtsprechung nach DSGVO und ePrivacy. Bei der Anbieterwahl sollte daher ein besonderes Augenmerk auf die Sicherstellung des Datenschutzes nach gegebenen Standards der Rechtsprechung gelegt werden.
Wettbewerbsvorteil
Bei einem hohen Grad an Standardisierung sowie fehlender Transparenz und Anpassungsfähigkeit von Funktionen und Abläufen stellt sich die Frage nach dem wahren Wettbewerbsvorteil, den eine CDP-End-to-End-Lösung mit sich bringt. Ein hoher Standardisierungsgrad ist gleichzeitig auch immer ein Todesurteil für individuelle Anpassungsmöglichkeiten an das eigene Geschäftsmodell. Während bei dem Aufbau einer eigenen Cloud-Umgebung vollständige Kontrolle und Anpassungsfähigkeit an Abläufe und Algorithmen besteht, bringt der Einkauf einer CDP-End-to-End-Lösung Intransparenz in das digitale Ökosystem.
3. Gründe für den Aufbau einer Customer Data Infrastruktur
Die Einführung einer CDP ist ein fundamentaler Eingriff in bestehende Marketing-Strukturen auf strategischer wie auch auf operativer Ebene. Ist eine erprobte und performante DatenArchitektur im individuellen Cloud-Setup gegeben, sollte die Notwendigkeit der Implementierung einer CDP-End-to-EndLösung infrage gestellt werden. Besteht bereits ein performantes (Marketing-)Data Warehouse, in welchem Daten in einer hohen Qualität aus verschiedenen Quellsystemen geladen und zusammengeführt werden, gilt es einen passenden “Anbieter-Fit” zu evaluieren oder ggf. den Auf- bzw. Ausbau der individuellen Cloud-Umgebung vorzuziehen. Falls die Organisation also bereits über eine erprobte ETL/ELT-Infrastruktur und ein (Marketing-)Data Warehouse verfügt, werden im Folgenden fünf Gründe für einen Aufbau einer Customer Data-Infrastruktur aufgelistet:
1. Daten sind zentralisiert vorhanden
Eine Customer Data Platform wird von Anbietern häufig als „Single Source of Truth“ bezeichnet. In Wirklichkeit erstellt die Plattform meistens eine fragmentierte Kopie der Daten. Die Wahrscheinlichkeit ist also groß, dass sich Kundendaten bereits in dem Data Warehouse und anderen Systemen, wie bspw. einem CRM, befinden. Standardmäßig besitzt eine CDP in der Regel nur Zugriff auf die Verhaltens- bzw. Event-Daten von digitalen Plattformen und Webseiten. Ist dies der Fall, sollte der Ausbau der bestehenden Cloud-Umgebung um notwendige Funktionalitäten für die Zentralisierung von Nutzerprofilen und ihrer Segmentierung sowie für die Überführung an die entsprechenden Marketing-Tools in Erwägung gezogen werden.
2. Die CDP passt nicht in das bestehende Cloud-Setup
Mit dem Aufkommen der Cloud-Technologien wurden SaaS-Tools eingeführt, die direkt mit dem Cloud Data Warehouse zusammenarbeiten. Die Tools und Erweiterungen ermöglichen es, ohne großen technischen Aufwand Daten zu generieren, zu transformieren und in die Tools zurückzuspielen. Eine CDP an sich profitiert aber nicht zwangsläufig von diesen Erweiterungen. Wird bereits eine Cloud-Umgebung, wie bspw. die GCP, genutzt, lassen sich benötigte Erweiterungen einfach nach dem “Pay-per-use”- Modell skalierbar hinzufügen.
3. Datenschutz und Sicherheit
Auch wenn die Pseudonymisierung der Daten von der Plattform übernommen wird, speichert der Großteil der CDP-Anbieter die erhobenen Daten in ihrer eigenen Cloud-Umgebung. Die Auslagerung empfindlicher Kundendaten zu den Servern von Drittanbietern birgt entsprechend neue Sicherheitsrisiken und schränkt den Umfang der Datenverarbeitung und das Management innerhalb der Plattform ein. Zunehmende Regulierung im Datenschutz durch ePrivacy und GDRP, dem Privacy Shield und der Datensicherheit (SOC2, ISO, etc.) begünstigt Daten-Architekturen, die auf die Sicherheit ihres eigenen IT Setups bauen
4. Flexibilität und Grenznutzen
Ein Data Warehouse bzw. eine ganze Cloud-Umgebung verfügt über einen Funktionsumfang, den eine CDP allein nicht abdecken kann, darunter über die Fähigkeit, beliebige relationale Daten zu modellieren und abzufragen. Es lässt sich argumentieren, dass eine CDP in ihrer Konfiguration flexibel ist, jedoch sehr unnachgiebig, wenn sich das Datenmodell im Laufe der Zeit der geschäftlichen Entwicklung anpassen soll. Zusätzlich kommt eine End-to-End-Lösung in der Regel mit einer Vielzahl an Funktionen und Features daher, die nicht unbedingt benötigt, jedoch bezahlt werden
5. Kosten und Zeitrahmen
Neben einem hohen finanziellen Investment bedeutet die Implementierung einer CDP für die meisten Unternehmen auch eine Zeitinvestition in personelle Ressourcen. Die Einrichtung einer CDP erfordert ein hohes Maß an abteilungsübergreifender Zusammenarbeit. Erste Ergebnisse stellen sich erst nach einer mehrmonatigen Integrationsphase ein.
Bei dem Auf- und Ausbau des individuellen Cloud-Setups bestehen zwar die gleichen organisatorischen Hürden und Herausforderungen, allerdings ist es einfacher und kosteneffizienter, einzelne Use Cases und Funktionalitäten Schritt für Schritt aufzubauen und zu erweitern. Änderungen sind in kleinen Schritten oft einfacher in Organisationen zu etablieren. Dabei fallen bei einem individuellen Cloud-Setup im Gegensatz zu einer CDP keine vollumfänglichen Lizenzgebühren an, sondern nur die Kosten der tatsächlichen Nutzung der Cloud Ressourcen. In Bezug auf Change Management und Kosteneffizienz bei der Einführung kann ein individuelles Cloud-Setup also durchaus Vorteile bringen.
4. Aufbau und Nutzung einer Customer DataInfrastruktur im eigenen Cloud-Setup
Ist die Entscheidung für den Auf- und Ausbau eines individuellen Cloud-Setups gefallen, gilt es, die bestehende Daten-Infrastruktur zu evaluieren und um sinnvolle Abläufe, Schnittstellen und Services (Tools) zu erweitern. Ein performantes Cloud Data Warehouse, das mit skalierbaren Data Pipelines relevante Daten konsolidiert und weiterverarbeitet, bildet das Fundament. Das folgende Kapitel widmet sich den nötigen Anforderungen an eine bestehende Data Warehouse-Architektur, um den Ausbau der Cloud-Umgebung um CDP-Funktionalitäten nachhaltig und zukunftssicher zu gestalten. Am Beispiel der Google Cloud Platform wird anschließend eine solche Architektur dargestellt und auf Fallstricke eingegangen, die es während des Auf- bzw. Ausbaus zu beachten gilt.
4.1 Die Weiterentwicklung des Data Warehouse als zentraler Architektur-Baustein
Das Hinzufügen von CDP-Funktionalitäten zu einem bestehenden (Marketing-)Data Warehouse erfordert in der Regel weniger technischen Aufwand als erwartet. Viele Bestandteile sind bereits vorhanden und müssen lediglich angepasst bzw. um einzelne Bausteine erweitert werden, welche die Cloud-Umgebung zur Verfügung stellt. Es werden jedoch mehrere Kernkomponenten benötigt, um eine flexible und skalierfähige Kundendaten- und Marketing-Architektur zu gewährleisten.
4.1.1 Datenerfassung und Permission Management
Die Kernkompetenz einer CDP liegt in der Erstellung einheitlicher Nutzerprofile und Segmente für die Marketing-Aktivierung. Um diese zu gewährleisten, müssen relevante Daten zunächst aus den einzelnen Quellsystemen und Datenbanken erfasst und in das Data Warehouse geladen und zusammengeführt werden.
Je nach Art der Daten und deren Nutzungszweck bedarf es entsprechender Information und Einwilligung des Nutzers bzw. des Kunden. Sollen bspw. Online-Nutzungsdaten erhoben werden, sind in der Regel entsprechende Consents nötig, die vom Nutzer abgefragt werden. Die Datenerfassung von anonymisierten Daten (z.B. Website Visits) und die Einhaltung ihrer datenschutzrechtlichen Anforderungen (Dokumentation, Widerruf und Löschung) lassen sich u.a. mit einer Consent Management Platform konfigurieren. Im Bereich E-Mail-Marketing muss ein sogenannter Double Opt-In des Interessenten eingeholt werden, bevor ihm Marketinginformationen per E-Mail zukommen gelassen werden. Bei der Erhebung und Verarbeitung von Kundendaten ist besondere Vorsicht geboten. Hierfür bedarf es grundsätzlich ebenfalls einer Aufklärung und separaten Zustimmung durch den Nutzer.
Die technische Herausforderung ist es nun, die Daten und Einwilligungen aus unterschiedlichen Systemen für das Matching der Kundendaten zusammenzubringen und gleichzeitig entsprechende Löschpflichten und Prozesse zu gewährleisten, um die Einhaltung der Einwilligung zu ermöglichen. Um Kundendaten nun mit anonymisierten Daten wie Online Behavior Daten (Web- und App-Nutzung) zusammenzuführen und anschließend für das Marketing zu nutzen, muss zunächst nach der Erlaubnis gefiltert werden. Liegt die Erlaubnis vor, kann der Eintrag mit der Online Behavior-Beobachtung im Data Warehouse zusammengeführt werden. Zudem werden alle Opt-Ins und Einwilligungen zusammen mit dem Kundenprofil importiert. Um Löschprozesse und Auskunftspflichten etc. einzuhalten, werden entsprechende Prozesse innerhalb des Data Warehouse implementiert, die bei Aufruf die Daten löschen.
Die Auswahl einzelner Marketingkanäle, die mit den entsprechenden Kundendaten kontaktiert werden dürfen, wird ebenfalls über entsprechende Regeln auf Basis des User Consents ausgesteuert. Somit wird sichergestellt, dass nur Daten an ein Marketing Tool gesendet werden, wenn für dieses auch ein Consent vorliegt.
4.1.2 ETL/ELT-Pipeline
Abhängig von der Größe des Unternehmens bestehen wahrscheinlich bereits eine Reihe von verschiedenen SaaS-Anwendungen und Datenquellen, die zusätzlich zu den Event- und Verhaltensdaten, die über Websites oder Apps erfasst werden, Kundendaten sammeln. In diesem Fall müssen diese Informationen in das Data Warehouse importiert werden, um sie zu nutzen. Hierfür gibt es eine Reihe von fertigen Tool-Lösungen (z.B. Fivetran, Supermetrics), welche bereits eine Vielzahl vorgefertigter Konnektoren bieten, um Daten aus Cloud-Anwendungen, Tools und Datenbanken in das Data Warehouse zu importieren. Oftmals stellt die verwendete CloudUmgebung auch eigene SaaS-Anwendung (bspw. Cloud Dataflow in der Google Cloud) bereit, um die Daten zu transformieren und anschließend in das Data Warehouse zu laden.
4.1.3 Identity Resolution
Die Identitätsauflösung erfolgt, wenn ein einzelnes Kundenprofil aus mehreren Systemen zusammengefügt wird. Es handelt sich dabei um eine angewandte Form der Datenmodellierung. Mithilfe von SQL und dbt lassen sich Benutzerprofile und Event Streams aus verschiedenen Systemen (WWS, CMS, CRM, Marketing etc.) unter Verwendung gemeinsamer IDs (E-Mail, Telefonnummer, User-IDs, Cookies, Geräte-ID, IDFA etc.) auflösen. Das Endergebnis ist ein angereichertes Kundenprofil in Kombination mit einer zugehörigen Aktivitätshistorie von Interaktionen eines Kunden mit dem Unternehmen über alle Touchpoints hinweg. Neben der eigenständigen Identitätsauflösung im Data Warehouse gibt es ebenfalls Saas-Tools, wie bspw. Senzing, die sich in eine bestehende Cloud-Umgebung integrieren lassen.
4.1.4 Audience Building und Transfer
Für das Thema Audience Building und Transfer gibt es eine Reihe von Lösungsansätzen. Entweder lässt sich die Erstellung der Audiences direkt im Data Warehouse vornehmen oder mittels Tool Lösung (z.B.: Rudderstack oder hightouch). Für die Erstellung der Audiences bietet beispielsweise die Google Cloud mit BigQuery eine Reihe an integrierten Machine Learning-Funktionalitäten (BigQuery ML) sowie eine eigene AI-Plattform, die Vertex AI. Diese Funktionen gehen weit über die Data Science-Funktionen gängiger CDP-End-to-End-Lösungen hinaus.
4.2 Beispiel-Architektur anhand der Google Cloud-Umgebung
Mit einer breiten Anzahl an SaaS-Tools und einem “Pay-as-you-go”-Zahlungsmodell bietet die Google Cloud für viele Unternehmen eine gute Grundlage für den Aufbau einer soliden Daten-Infrastruktur. Das folgende Schaubild soll einen beispielhaften Auf- bzw. Ausbau einer performanten Daten-Pipeline mit CDP-Kernfunktionalitäten darstellen:
Sources
In den meisten datengetriebenen Unternehmen befindet sich bereits ein Data Warehouse, in dem Daten aus verschiedenen Quellsystemen konsolidiert und analysiert werden. Oftmals beschränkt sich die Analyse jedoch auf Webdaten von Nutzern, die aus diversen Tools im Rohdatenformat in das Data Warehouse geladen werden. Um tiefgreifendere Erkenntnisse über den Nutzer und über seine verhaltensbasierten Onlinedaten hinaus zu erhalten, empfiehlt es sich, diese mit Daten aus weiteren nutzerrelevanten Quellsystemen und Datenbanken anzureichern.
Collect
Seit der Einführung der DSGVO, den ePrivacy Richtlinien und dem TTDSG unterliegt die Datenerfassung von (Online-)Nutzerdaten im europäischen Raum klar definierten Einwilligungsvorschriften. Werden Nutzerdaten über verschiedene Systeme erhoben und miteinander zusammengeführt, bedarf es einem gut organisiertem und transparentem Permission Management, um die Verarbeitung aller erhobenen Daten zu dokumentieren und rechtlich abzusichern. Je nach Quellsystem und Sensibilität der erfassten Daten müssen hierfür separate Einwilligungen beim Nutzer eingeholt werden. Die wohl bekannteste Einwilligungsform ist der Cookie Consent für verhaltensbasierte Webdaten. Er befähigt Marketing- und Analyse-Tools, Identifier wie Cookie-IDs (Client-IDs, Advertiser-IDs etc.), Device-IDs (IDFA, GAID etc.) und Fingerprints (User Agent etc.) zu erheben. Hinzu kommen separate Einwilligungen für die Erhebung von E-Mail-Adressen (Newsletter) oder für die Vergabe von User-IDs, welche für die Erstellung von Kundenkonten genutzt werden und oft für die pseudonymisierte Zuweisung personenbezogener Daten mit dem CRM-System synchronisiert werden. Für die Zusammenführung aller gesammelten Daten eines Nutzers und deren Verarbeitung wird ebenfalls eine gesonderten Einwilligung benötigt, welche zentral gemanagt werden sollte.
Das Schaubild bietet lediglich eine Veranschaulichung der Komplexität eines Permission Managements anhand einer Beispiel-Architektur. Der Umfang sowie die Art und Weise, wie Permission Management im Unternehmen gehandhabt wird, ist immer auf den unternehmensspezifischen Einzelfall abzuwägen und bedarf einer individuellen Rechtsberatung.
Process
Sind die nötigen Einwilligungen gegeben, werden die Daten extrahiert, transformiert und in das Data Warehouse (BigQuery) geladen. In dem oben genannten Beispiel werden die verhaltensbasierten Webdaten über einen clientseitigen GTM per Data Stream an einen GTM Server übermittelt. Nutzerrelevante Daten aus anderen Quellsystemen lassen sich je nach Beschaffenheit direkt über Google PubSub streamen oder mittels Batch in einen temporären Objektspeicher (Cloud Storage) laden. Über Cloud Dataflow werden die relevanten Daten aus den Quellsystemen, wenn nötig, in das entsprechende Datenformat transformiert und anschließend in das Data Warehouse (BigQuery) geladen. Über das Ressourcen-Autoscaling von Dataflow lässt sich die Latenz der gesamten Datenpipeline minimieren, was die Verarbeitungskosten pro Data Set reduziert. Zudem bieten Tools wie fivetran und Supermetrics zahlreiche API-Schnittstellen zu relevanten Marketing-Systemen und können diese Daten an Data Warehouse-Lösungen (wie BigQuery) übermitteln.
Store – Analyze
Wie in Kapitel 4 bereits erwähnt, stellt das Data Warehouse den Grundbaustein für die Erstellung und Auslieferung zentralisierter Kundenprofile an die Zielsysteme dar. Mit integrierten Maschine-Learning-Modellen und der VertexAI Platform bietet BigQuery, bzw. die Google Cloud, ein breites Spektrum an Verfahren für das Audience Modelling (Clusteranalysen, User-Scorings etc.) von Kundendatensätzen an. Tools wie Senzing können die notwendige Identitätsauflösung (Identity Resolution) der einzelnen Datensätze übernehmen oder in Verbindung mit Tools wie Rudderstack direkt in BigQuery vor oder nach dem Processing im Data Warehouse angewendet werden. Im oben genannten Beispiel findet die Identitätsauflösung nach dem Laden und Processing der Daten im Data Warehouse statt.
Activate
Tools wie Rudderstack, hightouch oder Segment bieten die notwendige Infrastruktur und API- Schnittstellen zur Marketing-Aktivierung der Daten. Ihre Aufgabe ist es letztendlich, die in BigQuery erstellten Audience-Listen an die gewünschten Zielsysteme (z.B. Google Ads, Facebook etc.) zu übermitteln. Diese Funktionen lassen sich auch in benutzerdefinierten Tools und Services in der Cloud-Umgebung übernehmen. Hierbei ist jedoch abzuwägen, ob die Kosten der Cloud, die Sicherstellung und die Maintenance der API-Verbindung zu allen verwendeten Marketing Tools nicht die Lizenzierung einer darauf spezialisierten Software übertreffen.
5. Empfehlung
Die Funktionen, die eine CDP zur Bildung einheitlicher Nutzerprofile für die Marketing-Aktivierung auf Basis von First-Party-Daten bietet, sind im Hinblick auf den Wandel der Cookie-Technologie ein relevantes Thema für jedes datengetriebene Unternehmen. Jedoch ist der Einkauf einer CDP-End-to-End-Lösung nicht für jedes Unternehmen der richtige Weg, wenn bereits eine performante Daten-Architektur auf Basis eines (Marketing-)Data Warehouse in der Cloud besteht. Im Gegensatz zu einer CDP bietet die Cloud Zugriff auf eine sklarierfähige Rechenleistung, für eine zentrale Anwendung von build-in Data Science und Machine Learning-Methoden. Dies ermöglicht die Nutzung fortgeschrittener Segmentierungs- und Analysefunktionen für das Audience Building. Der Ausbau der bestehenden Daten-Architektur um eine Customer Data-Infrastruktur stellt somit langfristig eine flexiblere und zukunftssichere Technologie dar und ist eine gute Alternative zu herkömmlichen CDPs.