Andreas Spenst

Wenn du für ein international oder global agierendes Unternehmen tätig bist und damit beauftragt wurdest, eine #customerdataplatform für die ultimative Omni-Channel Customer Experience für deine Kunden einzuführen, wirst du dir vermutlich die Frage nach dem sinnvollsten Betriebsmodell für deine CDP stellen. Dabei stehen dir gleich mehrere Optionen zur Auswahl:

1. Du führst die CDP zentral ein und verwaltest auch die Use Cases darin zentral.
2. Du führst die CDP zentral ein, dezentralisierst aber die Umsetzung von Use Cases, indem du die Use Case Operations in deine lokalen Teams auslagerst.
3. Du führst die CDP erstmal nur in einem Markt ein, baust dort einen Blueprint und rollst diesen dann angepasst an lokale Gegebenheiten aus, wobei der Betrieb dann auch im jeweiligen Markt erfolgt.
4. Du führst die CDP zentral ein, verwaltest aber lediglich die Lizenz. Die Märkte nutzen diese dann in vollem Umfang lokal auf eigene Faust.
5. Du erklärst den lokalen Marketern lediglich, warum du der Meinung bist, dass sie eine CDP benötigen. Auswahl, Einkauf und Betrieb machen die lokalen Mitarbeiter dann aber selbst.

Es gibt da sicherlich noch weitere Varianten und Nuancen dazwischen. Bevor du dich aber auf eine der Möglichkeiten festlegst, solltest du unbedingt die Implikationen kennen, die deine Entscheidung mit sich führt.

In den meisten Fällen wird das Handling einer lokalen CDP-Lösung die mit Abstand einfachere Variante sein. Datenschutzrechtlich musst du nur einen Markt betrachten, die Anzahl von Stakeholdern, mit denen du dich abstimmen musst, ist überschaubar. Die Datenquellen müssen nur für einen Markt angeschlossen und Datenstrukturen aufbereitet werden, die Anzahl der Konnektoren für die Aktivierung der Kampagnen ist ebenfalls überschaubar etc. Wenn es nur so einfach wäre, wäre der Beitrag an dieser Stelle bereits vorbei und ich säße schon auf meiner Terrasse mit einem Feierabendbier in der Hand und der Sonne im Gesicht. Es gibt nämlich durchaus gute Gründe, wieso du dir ggf. trotzdem Gedanken über eine globale Strategie für deine Omni-Channel-Architektur machen solltest.

Zum einen wären da die Lizenz- und Kostenvorteile einer globalen CDP-Lizenz. Desto mehr Events du über deine CDP feuerst, umso niedriger die Kosten pro Event. Gliederst du das hingegen auf viele einzelne Accounts oder gar lokal unterschiedliche CDP-Lösungen, betreiben alle lokalen Teams die CDP zu höheren Kosten pro Event. Darüber hinaus möchtest du deine Kampagnen und Use Cases ggf. global umsetzen und nicht pro Markt. Bspw. willst du eventuell Warenkorbabbrecher in der DACH Region mit gleichen Angeboten „targeten“. In einem globalen Account musst du den Use Case entsprechend nur einmal bauen, statt ihn pro Markt aufzusetzen. Das reduziert wiederum nicht nur die Setup Kosten für den Use Case, sondern spiegelt sich auch langfristig in der Maintenance und Optimierung der Use Cases wider. Das setzt aber auch voraus, dass deine Werbenetzwerke global organisiert sind. Andernfalls läufst du Gefahr, den Überblick bei den Konnektoren für die Aktivierung zu verlieren. Stell dir vor, du hast 30 Märkte und alle haben einen eigenen Tiktok und DV360 Account. Dann hast du zentral schon mal 60 Konnektoren, die du verwalten musst.

Darüber hinaus benötigt man für den Betrieb einer CDP ein cross-funktionales Team, bestehend aus verschiedensten Rollen wie z.B. Daten-Experten, Audience Managern und technischen Profilen. Falls du das pro Markt lokal abbilden kannst, Glückwunsch! Viele Leser werden dich dafür beneiden.
In den meisten Fällen dürfte das aber zu Kapazitätsengpässen führen.
Baust du ein solches Team aber nur einmal auf, kannst du auch hier signifikante Synergien rausholen. Gleichzeitig hast du den Vorteil, dass ein zentral organisiertes Team das gesamte Know-How trägt und dieses entsprechend in alle Märkte übertragen kann, während der Know-How Transfer bei lokalen Teams sehr viel schwerer zu organisieren ist.

Im Kontext einer Customer Data Platform, die so viele neue Möglichkeiten für eine effiziente Omni-Channel Experience schafft, dürfte der Begriff „Standardisierung“ zu einem entsetzten Zusammenzucken bei dem einen oder anderen Leser/in führen. Aber genau das ist der Trade-Off, wenn du von den beschriebenen Vorteilen wie Kosteneffizienz und Synergien profitieren möchtest. Voraussetzung hierfür ist aber eine global möglichst harmonisierte Infrastruktur mit gleichen oder ähnlichen Datenquellen, Datenstrukturen, Use Cases und im besten Fall auch identischen Aktivierungskanälen. Ist das der Fall, kannst du neue Ideen und Kampagnen mit maximaler Effizienz gleich global ausrollen. Das gibt dir zudem die Möglichkeit, mit deinen Tech-Experten einen Release-Zyklus mit Standard-Releases einzuführen, was nicht nur die Release-Kommunikation in Richtung deiner internationalen Stakeholder vereinfacht, sondern auch die Aufwände bei der Maintenance deutlich reduziert. Wenn deine Websites, Online-Shops oder CRM-Systeme international aber unterschiedlich sind, wird sicherlich auch die Datenstruktur eine andere sein. Selbst bei identischen Use Cases musst du dann pro Markt eigene Audiences bauen und jede CDP Instanz wird zu einer Custom Lösung. Eine solche Struktur zentral zu verwalten dürfte ziemlich schnell zu einem Albtraum werden.

Im Prinzip ist die Faustformel ganz einfach:

je einheitlicher dein globales Setup ist, umso eher lohnt sich eine zentrale Strategie für deine Customer Data Platform.

Entscheidend sind aber vor allem die Daten und deren globale Verfügbarkeit. Kannst du global mit den gleichen Datenstrukturen arbeiten, kannst du auch deine Audience-Strategie und damit dann auch deine Use Cases international vereinheitlichen. In der Regel ist die Realität aber etwas komplizierter als nur schwarz oder weiß. Du musst dann für dich entscheiden, welche Vorteile für dich wichtiger sind oder mit welchen Nachteilen du besser leben kannst.

Du planst die Einführung einer Customer Data Platform (kurz CDP) in deinem Unternehmen? Dann hast du sicherlich schon einige CDP Anbieter kennengelernt und verstehst die unzähligen Vorteile, die eine CDP im Herzen deiner Martech Architektur hat. Aber kennst du auch die Stolpersteine, die dem einen oder anderen Product Owner einer CDP die Schweißperlen auf die Stirn treiben? Daher widme ich diesen Beitrag den aus meiner Sicht 5 wichtigsten Hürden, die eine CDP Einführung erschweren oder sogar zum Scheitern verurteilen.

Ok, du hast deine CDP Ausschreibung mit Bravour gemeistert, deine Organisation hat mittlerweile verstanden, dass CDP keine Abkürzung für eine neue Partei ist und jetzt kann es losgehen. Dein Backlog ist voll mit Ideen, was man mit der CDP jetzt so alles anstellen könnte und du bist bereit, deine Kunden mit einer Omni-Channel Experience zu beglücken, die die Welt noch nicht gesehen hat. Doch dann die Ernüchterung: Du wolltest doch eigentlich einfach nur die Online-Daten deines Online-Shops nutzen, um die ultimativen Use Cases zu bauen. Doch die Datenqualität ist leider nicht so gut, wie du gehofft hattest. Die Datenattribute haben kryptische Bezeichnungen, die du nicht zuordnen kannst. Deine Online-Daten sind lückenhaft und maximal heterogen. Jede Online-Plattform nutzt ein anderes Tracking-Konzept und schließlich hat jeder Markt die Daten in seiner Sprache benannt, was die Deutung und Zusammenführung von Conversions nahezu unmöglich macht. Zudem stellst du fest, dass deine CRM-Daten, die du ja eigentlich mit den Echtzeit-Online-Daten koppeln – neudeutsch stitchen – wolltest, lückenhaft sind und jeder Markt sein eigenes CRM-System nutzt. Als wäre das nicht genug äußern die Händler der Europäischen Märkte starke Bedenken bzgl. der Datenschutzkonformität und plötzlich fehlt dir die datenschutzrechtliche Grundlage für die Nutzung der Kundendaten.

Ja ich gebe zu, ich habe hier etwas dick aufgetragen, aber das sind reale Herausforderungen, die so in verschiedenen Nuancen den Product Owner für die CDP treffen.

Eine solide Datenbasis ist das A und O einer CDP-Einführung.

Gerade im Kontext global oder international agierender Unternehmen ist das Thema komplex.

Ohne die nötige Datenqualität und eine gezielte Datenstrategie für 1st Party Daten wirst du spätestens bei der Skalierung deiner Use Cases oder der CDP Roll-Outs in Schwierigkeiten geraten.

Es gibt viele verschiedene Ansätze, dieser Herausforderung zu begegnen, um deine CDP Einführung zum Erfolg zu bringen. Bereite deine Datenbasis gut auf die CDP Einführung vor und suche dir kleine Stücke aus dem Datenkuchen, um iterativ über die Komplexität Herr/in zu werden.

Du hast die Herausforderung gemeistert und deine ersten Datenquellen füttern die CDP bereits, während dich deine Kollegen/innen als den Herrn der Realtime-Data feiern. Jetzt musst du die Daten nur noch in Targeting-Regeln gießen und daraus Audiences basteln. Ggf. hast du bereits reichlich Erfahrungen gesammelt, deine 1st Party Daten zu segmentieren oder in deinem Web-Analytics Tool präzise Audiences zu bauen. Herausfordernd wird es aber bspw. dann, wenn du plötzlich Online- und Offline-Daten hast und diese nun in Kombination verwenden kannst.

Das ermöglicht dir nicht nur völlig neue Strategien, sondern erfordert zum Teil völlig neue Denkmuster.

Unter Umständen stellt sich dann zudem die organisatorische Frage, wer eigentlich der Owner der Use Cases mit gemischten Datentöpfen ist. Ist das der Marketing- oder doch der Aftersales-Bereich? Globale Setups von CDPs bergen zudem die Herausforderung, dass ggf. international weder die Datenbasis identisch ist noch dieselben Plattformen und Touchpoints verfügbar sind. Das ist dann vor allem im Sinne der Skalierung von Use Cases ein echtes Problem. Aber selbst, wenn du in keine dieser Herausforderungen rennst, wirst du spätestens nach ein paar dutzend Audiences in der CDP merken, wie wichtig eine eindeutige Bezeichnung und einheitliche Taxonomie ist und wie essenziell die Struktur deiner Audiences in der CDP ist. Je nach Kommunikations-Kanal, in dem du diese Audiences aktivieren willst, solltest du unbedingt die Besonderheiten kennen. Planst du bspw. die Aktivierung über Social Media-Kanäle, muss deine Audience die magische Marke von 1000 Nutzern für das Retargeting knacken. Ein E-Commerce Unternehmen wie Zalando lacht vermutlich darüber, ein B2B-Unternehmen mit weniger Traffic auf den eigenen Seiten hat es da aber schon deutlich schwerer. Für Owned Channels wie Website oder Newsletter gelten diese Limitierungen nicht, aber ggf. musst du hierfür gesondert sog. Ausschluss-Regeln anpassen (über diese sog. Exclusions entscheidet man, wann ein Nutzer aus einer bestimmten Zielgruppe fällt), um möglichst viele Nutzer personalisiert über die Owned-Kanäle ansprechen zu können.

Die Customer Data Plattformen sind ein echter Game-Changer im Marketing.

Sie führen verschiedene Datenquellen zusammen und überbrücken die Online- und die Offline-Welt. Sie verwandeln das Buzzword „Omni-Channel“ in Realität und bringen dank der serverseitigen Integration mit Media-Kanälen auch gleich noch eine Lösung für das Cookieless-Future Dilemma mit. So verlockend diese Fähigkeiten sind, so komplex können sie werden.

Die Gefahr ist groß, dass man sich bei der Integration von Datenquellen in endlose Schnittstellen-Projekte stürzt.

Wieso hier nicht auch gleich noch die IoT-Daten (Internet of Things) hinzufügen und dann am besten auch gleich noch 3rd Party Daten ergänzen? Diese bisherigen Datensilos müssen natürlich auch irgendwie verknüpft werden. Also baust du dir gleich noch einen ID-Graph, der sicherheitshalber schon mögliche Szenarien der kommenden 20 Jahre umfasst. Und bei der Aktivierung, … naja wieso nicht aus dem vollen schöpfen. Du hast vielleicht bisher nur die eine DSP genutzt, aber wenn die CDP doch schon mal 100te von built-in Konnektoren verfügt, wieso sollte man sie dann nicht anbinden? Und weil sich viele dieser Konnektoren sowohl Client- als auch Server-seitig anbinden lassen, machst du am besten gleich beides. Sicher verfügt deine CDP auch über AI Fähigkeiten und die Prediction Use Cases sind zum Greifen nah.

Ja, die CDP ist in der Tat eine kleine Revolution im Management von Customer Journeys.

Der Versuch, all diese Fähigkeiten auf einmal auszuschöpfen wird in einer endlosen Schleife von Abstimmungen mit allen Daten- und Kanalverantwortlichen enden, gepaart mit exzessiven Schnittstellen-Implementierungs-Orgien.

Schneide den Elefanten daher lieber in Scheiben im Sinne einer agilen Annäherung deiner Use Cases an deine Zielvision. Starte erstmal nur mit einer Datenquelle und baue erste Use Cases damit. Aktiviere die Audiences vielleicht erstmal in zwei Kanälen und schaffe so schon mal einen ersten Mehrwert mit der CDP. Sammle erste Erfahrungen damit und iteriere dich von Datenquelle zu Datenquelle und von Kanal zu Kanal. So schaffst du Sprint für Sprint zusätzlichen Mehrwert und die Learnings kannst du direkt in deine nächsten Use Cases einfließen lassen.

Als erfahrener Projektmanager hast du es dank guter Vorbereitung der Daten, einer ausgefeilten Audience-Strategie und einem guten Gespür für agile und iterative Implementierungsansätze geschafft, die ersten Use Cases zum Leben zu erwecken. Die Kampagne übertrifft alle Erwartungen und keiner in deiner Organisation hinterfragt mehr, ob sich denn der ganze Aufwand der CDP-Einführung gelohnt hat. Deine Martech-Truppe knallt Audience für Audience raus und die Zahl der Konnektoren nimmt stetig zu. Aber wer optimiert eigentlich die laufenden Kampagnen? Wer prüft, ob Audiences volllaufen und aktivierbar sind? Und wie finden Change Requests oder Incident Meldungen ihren Weg zu den Verantwortlichen? Und hast du dir mal Gedanken zum Service Level Agreement für die Lösung von Bugs oder die Implementierung neuer Use Cases gemacht? Es fällt dir wie Schuppen von den Augen: Du hast zwar ein Implementierungs- und Roll-Out Team, aber keine Operations-Truppe. Zu allem Überfluss verlässt ein Teammitglied deiner Martech-Mannschaft das Unternehmen, aber die Umsetzung der Audiences und Schnittstellen sind nirgends dokumentiert. Release Notes suchst du vergeblich. Und dann verabschiedet sich auch noch die API zu deinem CRM. Aber natürlich merkst du das erstmal nicht, weil sich keiner dafür zuständig fühlt.

Klar, es ist immer spannender, Innovationen zu treiben und neue Möglichkeiten auszureizen. Aber die Pflege von Bestandslösungen gehört genauso dazu, wie die Implementierung und der Roll-Out der Lösung. Was für Software-Entwickler und Architekten ein Low-Brainer ist, ist für das Marketing-Umfeld noch relativ neu. SaaS lautet da das Stichwort, also Software as a Service. Da kümmert sich doch eh der Anbieter um alles, oder? Nicht ganz, denn die Komplexität einer CDP mit all ihren Konnektoren und Abhängigkeiten zu weiteren Systemen ist ein kritischer Knotenpunkt in deiner Architektur. Denke daran, dass ggf. ein nicht unerheblicher Teil deines Media Spendings darüber läuft und der Betrieb der Plattform entsprechend sichergestellt sein muss.

Je nachdem, wo die Customer Data Plattform in deiner Organisation angesiedelt ist, also Marketing, Sales, IT oder doch bei den Data Analysten, kann die Umsetzung von Use Cases ein echter Kraftakt werden. Du brauchst Daten von den Datenexperten oder von den Sales-Teams, die Architekturfreigabe von den IT-Kollegen und für die Aktivierung sind ggf. verschiedene Teams involviert. Zum einen sind da die Media Buyer, die Social Media Experten und die DSP-Verantwortlichen, zum anderen willst du ggf. auch Owned Channels integrieren und benötigst den Support des Newsletter-Teams. Und wenn du deinen Online-Shop auch noch personalisieren willst, dann brauchst du ggf. auch den E-Commerce Product Owner.

Gelingt es dir, alle Parteien ins Boot zu holen und dir deren Unterstützung zu sichern, wird in den meisten Fällen relativ bald eine Frage aufkommen:

Wer ist eigentlich für diese plattform- und kanal-übergreifenden Use Cases verantwortlich?

Was passiert eigentlich, wenn jeder Kommunikationskanal bis dato seine eigenen Audiences gebaut hat und diese nun zentral aus einer Customer Data Platform geliefert werden? Und wie stellst du dann eigentlich sicher, dass deine Zielgruppen nicht an jedem Touchpoint eine andere Message und völlig willkürliche Assets erhalten? Du wirst schnell merken, dass diese Rolle in den meisten Fällen noch gar nicht besetzt ist. Denn was du jetzt benötigst ist eine Art Journey Manager, der die Fäden übergreifend zusammenhält und so die Nutzeransprache über alle Kanäle hinweg harmonisiert.

Vielleicht fragst du dich jetzt, ob die Sache mit der CDP wirklich eine gute Idee war. Nun ja, Argumente für die Erweiterung deiner Marketing-Architektur um eine CDP gibt es viele. Ich will dir mit diesem Beitrag keineswegs Angst machen. Keine der oben beschriebenen „Herausforderungen“ ist unlösbar und ja, obwohl ich dich hier davor gewarnt habe, wirst du trotzdem, aufgrund der Komplexität des Themas, in das eine oder andere Problem hineinlaufen. Ich hoffe allerdings, dass ich dir mit diesem Beitrag einige Kopfschmerzen ersparen konnte und wünsche dir viel Erfolg bei deinem Customer Data Platform Projekt. Gerne stehe ich auch für einen persönlichen Austausch zu dem Thema zur Verfügung. Schreibe mich hier auf LinkedIn einfach direkt an.