CDP-Implementierung: Datensammlung

CDP-Implementierung: Phasen der Umsetzung

Die valantic Blogserie über die CDP-Implementierung liefert Ihnen einen detaillierten Einblick in die unterschiedlichen Prozessphasen. Nach der Projektorganisation, der Spezifikation und der Basiskonfiguration folgt nun Phase Vier in der Umsetzung: die Datensammlung.

Datensammlung anlegen

Bereits in der vorgelagerten Spezifikationsphase wurde mit allen Beteiligten definiert, welche Daten für die ausgewählten Use Cases notwendig sind und in welcher Form und Frequenz diese an die Customer Data Platform übermittelt werden sollen. Zudem wurde in der Basiskonfiguration festgelegt, ob die Quellsysteme direkt in die CDP integriert sind, oder ob außerdem noch eine Art Middleware benötigt wird. An diesem Punkt – Phase Vier – angelangt, herrscht also Klarheit über die benötigten Quellsysteme und Datensätze. Folgende Datentypen können dabei unterschieden werden:

• Kund*innenstammdaten: Hierunter fallen alle Stammdaten der Kund*innen, die für die Personalisierung der definierten Use Cases benötigt werden – beispielsweise eine eindeutige ID pro Kund*in.

• Consents: Hierbei handelt es sich um die benötigten Einwilligungen der Kund*innen, um die entsprechenden Inhalte verarbeiten zu dürfen.

• Events: Unter Events versteht man sowohl digitale als auch offline Touchpoints der Kund*innen, die zu einem bestimmten Zeitpunkt als sogenannte Events in der CDP abgespeichert werden.

• Katalogdaten: Die Katalogdaten beschreiben die Ablage weiterer Objekte, die mit Kund*innen und Events in Beziehung stehen und sich regelmäßig ändern können. Ein Beispiele sind etwa Produktdaten aus dem Shop oder dem PIM-System.

Neben den eben genannten Datentypen sind folgende Möglichkeiten zum Sammeln der Daten in den meisten CDPs integriert:

• (REST-) -API: Diese http-basierte und sehr flexible Möglichkeit der Datensammlung wird von den meisten CDPs angeboten und bietet üblicherweise unterschiedliche Endpunkte für das Lesen und Schreiben der einzelnen Datentypen.

• Datenbanken-basiert: Da die meisten CDPs cloudbasierte SaaS-Lösungen darstellen, muss die Datenbank von außen erreichbar sein. Diese wird dann regelmäßig via SQL abgerufen. Die Structured Query Language (SQL) dient als Standardsprache für die Kommunikation zwischen den diversen Datenbanken. Die SQL fungiert dabei als eine Art Schnittstelle, in der externe Anfragen von User*innen in für die Datenbank verständliche Befehle übersetzt werden.

• Datei-basiert: In diesem Fall werden regelmäßig Dateien abgerufen, wie etwa eine CSV-Datei, die dann über eine URL, einen SFTP-Server oder in der Cloud abgelegt werden.

• Web/ App SDK-basiert: Mit den meisten Customer-Data-Plattformen wird zusätzlich ein Software Development Kit (SDK) angeboten, um das Verhalten der Kund*innen nachverfolgen zu können. Wichtig: Um DSGVO-konform zu agieren, sollte das SDK erst nach Bestätigung der Cookies geladen werden.

Agiles Zusammenarbeiten für eine effektivere Umsetzung

Für die Implementierung der Datensammlung empfiehlt sich ein agiler Ansatz, wie bereits im ersten Teil unserer Blogserie beschrieben. Für die Integration der diversen Quellsysteme ist also ein enger Austausch mit der internen Entwicklungsabteilung anzuraten. Auf diesem Weg können Tests sehr detailliert durchgeführt und bereits gelieferte Daten auf Richtigkeit und Vollständigkeit überprüft werden. Die Dauer des Implikationsprozesses ist stark von der Anzahl der Quellsysteme und der Komplexität der Use Cases abhängig, weshalb der Zeitraum zwischen wenigen Wochen bis hin zu mehreren Monaten variieren kann. Ein agiler Umsetzungsansatz bietet hier den Vorteil, dass weniger komplexe Use Cases bereits frühzeitig umgesetzt werden können.

Ist die Basiskonfiguration abgeschlossen und die Implementierung der Datensätze im Gange, kann die nächste Projektphase beginnen: die Konfiguration der Use Cases.