Sollten Sie Ihr Data Warehouse als CDP verwenden?

Das Aufkommen von Cloud-basierten Data Warehouses (DWHs) hat einer wachsenden Zahl von datengesteuerten Anwendungsfällen eine einfachere Bereitstellung, größere Skalierbarkeit und bessere Leistung gebracht. DWHs sind in Tech-Stacks von Unternehmen, einschließlich Martech-Stacks, immer häufiger anzutreffen.

Dies wirft zwangsläufig die Frage auf: Sollten Sie Ihr bestehendes DWH als Kundendatenplattform (CDP) nutzen? Denn wenn Sie eine vorhandene Komponente in Ihrem Stack wiederverwenden, können Sie Ressourcen sparen und neue Risiken vermeiden.

Aber die Geschichte ist nicht so einfach, und mehrere potenzielle Designmuster warten auf Sie. Letztendlich spricht einiges dafür und dagegen, Ihr DWH als CDP zu verwenden. Lassen Sie uns tiefer graben.

DWH als CDP ist möglicherweise nicht das Richtige für Sie

Es gibt mehrere inhärente Probleme bei der Verwendung eines DWH als CDP. Der erste ist offensichtlich: Nicht alle Organisationen haben ein DWH eingerichtet. Manchmal hat ein DWH-Team eines Unternehmens nicht die Zeit oder die Ressourcen, um kundenorientierte Anwendungsfälle zu unterstützen. Andere Unternehmen setzen ein CDP quasi als Data Warehouse ein. (Nicht alle CDPs können das, aber Sie verstehen, worauf es ankommt.)

Angenommen, Sie haben die meisten oder alle Ihre Kundendaten in einem DWH. Das Problem für viele, wenn nicht die meisten Unternehmen besteht darin, dass die Daten nicht auf vermarkterfreundliche Weise zugänglich sind. Typischerweise ist ein Unternehmens-DWH so konstruiert, dass es Analyseanwendungsfälle unterstützt, nicht Aktivierungsanwendungsfälle. Dies wirkt sich darauf aus, wie die Daten intern gekennzeichnet, verwaltet, verknüpft und geregelt werden.

Denken Sie daran, dass ein DWH im Wesentlichen zum Speichern und Rechnen dient, was bedeutet, dass Daten in Datenbanktabellen mit Spaltennamen als Attributen gespeichert werden. Anschließend schreiben Sie komplexe SQL-Anweisungen, um auf diese Daten zuzugreifen. Es ist unrealistisch, dass sich Ihre Vermarkter Tabellen- und Spaltennamen merken, bevor sie Segmente zur Aktivierung erstellen können. Oder anders gesagt, DWHs unterstützen in der Regel keinen Marketer-Self-Service, wie dies bei den meisten CDPs der Fall ist.

Dies berührt auch ein allgemeineres strukturelles Problem. DWHs sind normalerweise nicht darauf ausgelegt, Echtzeit-Marketing-Anwendungsfälle zu unterstützen, auf die viele CDPs abzielen. Es kann schnelle Berechnungen durchführen, und Sie können die Aufnahme und Verarbeitung in regelmäßigen Abständen planen, aber es ist immer noch nicht in Echtzeit. In ähnlicher Weise möchte ein DWH mit einigen Ausnahmen nicht auf Rohdaten reagieren, während Vermarkter häufig Rohdaten (normalerweise Ereignisse) verwenden möchten, um bestimmte Aktivierungen auszulösen.

Denken Sie schließlich daran, dass Daten und die Möglichkeit, darauf zuzugreifen, noch kein CDP ausmachen. Die meisten CDPs bieten eine Teilmenge zusätzlicher Funktionen, die Sie in einem DWH nicht finden werden, wie zum Beispiel:

• Event-Subsystem mit Triggerung.
• Anonyme Identitätsauflösung.
• Marketer-freundliche Schnittstelle zur Segmentierung.
• Segmentaktivierungsprofile mit Konnektoren.
• Potenziell Test-, Personalisierungs- und Empfehlungsdienste.

Ein DWH allein wird diese Fähigkeiten nicht bieten, also müssen Sie diese woanders beschaffen. Natürlich haben DWH-Anbieter beträchtliche Partnermarktplätze. Sie können viele Alternativen finden, aber sie sind nicht nativ und erfordern Integrations- und Supportaufwand.

Es überrascht daher nicht, dass viel über „zusammensetzbare CDPs“ und die potenzielle Rolle eines DWH in diesem Zusammenhang geredet wird. Ich habe zuvor argumentiert, dass Zusammensetzbarkeit ein Spektrum ist und Sie ab einem bestimmten Punkt anfangen, Vorteile zu verlieren.

Nach all diesen Vorbehalten kann ein DWH als Teil eines Kundendatenstapels eine Rolle spielen, einschließlich:

• Wegfall eines CDP durch Aktivierung direkt aus dem DWH.
• Verwendung des DWH als Quasi-CDP mit einer Reverse-ETL-Plattform.
• Koexistenz mit einem CDP.

Schauen wir uns diese drei Designmuster an.

1. Marketingplattformen direkt mit Ihrem DWH verbinden

Dies ist vielleicht der extremste Fall, den ich oben kritisiert habe, aber einige Unternehmen haben dies zum Laufen gebracht, insbesondere in der Zeit vor der CDP, und Plattformen (wie Snowflake mit seinem breiten Ökosystem) versuchen, dies zu lösen.

Die Idee dabei ist, dass Ihre Engagement-Plattform eine direkte Verbindung zu Push-Pull-Daten mit einem DWH herstellt. Viele ausgereifte E-Mail- und Marketing-Automatisierungsplattformen sind dafür nativ verkabelt, wenn auch typischerweise per Batch-Push. Ihre Vermarkter verwenden dann die Messaging-Plattform, um Segmente zu erstellen und im Falle von Outbound-Marketing Nachrichten an diese Segmente zu senden.

Stellen Sie sich vor, Sie hätten eine andere Marketing- oder Engagement-Plattform, eine personalisierte Website oder E-Commerce-Plattform. Auch hier beziehen Sie Daten aus dem DWH und verwenden dann die Webanwendungsplattform, um einen weiteren Satz von Segmenten für ein gezielteres Engagement zu erstellen.

Siehst du das Problem schon? Es gibt bereits zwei Gruppen von Segmentierungsschnittstellen. Was passiert, wenn Sie 10 Marketingplattformen hätten? 20? Sie werden weiterhin überall Segmente erstellen, sodass Ihr Omnichannel-Versprechen verschwindet.

Was wäre schließlich, wenn Sie eine weitere Marketingplattform hinzufügen müssten, die die direkte Aufnahme aus einem DWH nicht unterstützt?

2. Setzen Sie DWH mit Reverse-ETL-Tools ein

Dieser Ansatz löst mehrere Probleme mit dem ersten obigen Muster. Insbesondere ermöglicht es (theoretisch) einem Nicht-DWH-Spezialisten, universelle Segmente virtuell auf dem DWH zu erstellen und mehrere Plattformen zu aktivieren. Mit der Transformation und einem besseren Konnektor-Framework können Sie verschiedene Label-Mappings und vermarkterfreundliche Datenstrukturen auf verschiedene Endpunkte anwenden.

So funktioniert das. Reverse-ETL-Plattformen ziehen Daten aus dem DWH und senden sie nach jeder Transformation an Marketingplattformen. Sie können mehrere Transformationen durchführen und diese Daten gleichzeitig an mehrere Ziele senden. Sie können es sogar automatisieren und Exporte regelmäßig nach einem vordefinierten Zeitplan ausführen lassen.

Aber eine Kopie dieser Daten (oder eine Teilmenge davon) wird tatsächlich auf die Zielplattformen kopiert, sodass Sie wirklich nicht nur eine einzige Datenkopie haben. Da die Reverse-ETL-Plattform keine Datenkopie hat, werden Ihre erforderlichen Segmente oder Zielgruppen immer zum Zeitpunkt der Abfrage generiert (normalerweise in Stapeln). Dann exportieren Sie sie zu Zielen hinüber.

Dies ist kein geeigneter Ansatz, wenn Sie Echtzeit-Trigger oder Always-On-Kampagnen basierend auf Ereignissen haben möchten. Sicher, Sie können Ihre Exporte mit hoher Frequenz automatisieren, aber das ist nicht in Echtzeit. Wenn Sie Ihre Exporthäufigkeit erhöhen, werden Ihre Kosten exponentiell steigen.

Auch wenn Reverse-ETL-Tools eine Segmentierungsschnittstelle bieten, sind sie eher technisch und eher auf DataOps als auf MOps ausgerichtet. Bevor Sie dies zu einer „unternehmensfreundlichen“ Lösung erklären, die für den Self-Service von Vermarktern geeignet ist, müssen Sie sie sorgfältig testen.

3. DWH koexistiert mit CDP

Ihr Unternehmens-DWH dient als Infrastrukturebene für Kundendaten, die Daten an Ihr CDP (neben anderen Endpunkten) liefert. Viele, wenn nicht die meisten CDPs bieten jetzt einige Funktionen zur Synchronisierung von DWH-Plattformen, insbesondere Snowflake.

Es gibt Variationen, wie diese CDPs mit DWH koexistieren können. Die meisten CDPs synchronisieren und duplizieren Daten in ihrem Repository, während andere (einschließlich Reverse-ETL-Anbieter) keine Kopie erstellen. Es könnte jedoch Kompromisse geben, die Sie berücksichtigen müssen, bevor Sie festlegen, was für Sie funktioniert.

Im Allgemeinen sehen wir tendenziell größere Unternehmen, die dieses Designmuster bevorzugen, wenn auch mit großen Abweichungen davon, wo solche kritischen Dienste wie die Auflösung der Kundenidentität letztendlich angesiedelt sind.

Graben Sie tiefer: Wo sollte ein CDP in Ihren Martech-Stack passen?

Einpacken

DWH-Plattformen spielen eine immer wichtigere Rolle in Martech-Stacks. Sie haben jedoch weiterhin mehrere architektonische Möglichkeiten, welche Dienste Sie in Ihrem Datenökosystem bereitstellen.

Ich denke, es ist verfrüht, CDPs in Ihrer Zukunft auszuschließen. Jedes Muster hat seine Kompromisse, die Sie bei der Bewertung Ihrer Optionen berücksichtigen sollten.