Czy powinieneś używać swojej hurtowni danych jako CDP?

Pojawienie się hurtowni danych w chmurze (DWH) umożliwiło prostsze wdrażanie, większą skalę i lepszą wydajność w coraz większej liczbie przypadków użycia opartych na danych. DWH stały się bardziej rozpowszechnione w stosach technologii korporacyjnych, w tym w stosach martech.

Nieuchronnie nasuwa się pytanie: czy powinieneś wykorzystać istniejący DWH jako platformę danych klientów (CDP)? W końcu ponowne użycie istniejącego komponentu w stosie pozwala zaoszczędzić zasoby i uniknąć nowych zagrożeń.

Ale historia nie jest taka prosta i czeka na Ciebie wiele potencjalnych wzorców projektowych. Ostatecznie istnieją argumenty za i przeciw używaniu DWH jako CDP. Kopnijmy głębiej.

DWH jako CDP może nie być dla Ciebie odpowiedni

Istnieje kilka nieodłącznych problemów związanych z używaniem DWH jako CDP. Pierwsza jest oczywista: nie wszystkie organizacje mają DWH. Czasami korporacyjny zespół DWH nie ma czasu ani zasobów, aby wspierać przypadki użycia skoncentrowane na kliencie. Inne przedsiębiorstwa skutecznie wdrażają CDP jako quasi-hurtownię danych. (Nie wszystkie CDP mogą to zrobić, ale rozumiesz, o co chodzi).

Załóżmy, że masz większość lub wszystkie dane swoich klientów w DWH. Problemem wielu, jeśli nie większości, przedsiębiorstw jest to, że dane nie są dostępne w sposób przyjazny dla marketerów. Zazwyczaj DWH przedsiębiorstwa jest konstruowane w celu obsługi przypadków użycia analizy, a nie przypadków użycia aktywacji. Ma to wpływ na to, jak dane są oznaczane, zarządzane, powiązane i zarządzane wewnętrznie.

Przypomnijmy, że DWH służy zasadniczo do przechowywania i przetwarzania danych, co oznacza, że ​​dane są przechowywane w tabelach bazy danych z nazwami kolumn jako atrybutami. Następnie piszesz złożone instrukcje SQL, aby uzyskać dostęp do tych danych. Zapamiętywanie nazw tabel i kolumn przed utworzeniem segmentów do aktywacji jest nierealne. Innymi słowy, DWH zazwyczaj nie wspierają samoobsługi marketerów, jak robi to większość CDP.

Dotyka to również szerszego problemu strukturalnego. DWH zazwyczaj nie są zaprojektowane do obsługi przypadków użycia marketingu w czasie rzeczywistym, na które jest ukierunkowanych wiele CDP. Może wykonywać szybkie obliczenia i zaplanować pozyskiwanie i przetwarzanie tak, aby pojawiało się w częstych odstępach czasu, ale nadal nie odbywa się to w czasie rzeczywistym. Podobnie, z pewnymi wyjątkami, DWH nie chce działać na podstawie surowych danych, podczas gdy marketerzy często chcą wykorzystywać surowe dane (zwykle zdarzenia) do wyzwalania określonych aktywacji.

Na koniec pamiętaj, że dane i możliwość dostępu do nich nie czynią CDP. Większość CDP oferuje pewien podzbiór dodatkowych możliwości, których nie znajdziesz w DWH, takich jak:

• Podsystem zdarzeń z wyzwalaniem.
• Rozwiązanie anonimowej tożsamości.
• Przyjazny dla marketerów interfejs do segmentacji.
• Profile aktywacji segmentów ze złączami.
• Potencjalnie usługi testowania, personalizacji i rekomendacji.

Sam DWH nie zapewni tych możliwości, więc będziesz musiał je pozyskać gdzie indziej. Oczywiście dostawcy DWH mają duże rynki partnerskie. Możesz znaleźć wiele alternatyw, ale nie są one natywne i będą wymagały integracji i wsparcia.

Nic więc dziwnego, że dużo się mówi o „komponowalnych CDP” i potencjalnej roli DWH w tym kontekście. Wcześniej argumentowałem, że komponowalność to spektrum i zaczynasz tracić korzyści po przekroczeniu pewnego punktu.

Po wydaniu wszystkich tych zastrzeżeń, DWH może odgrywać rolę jako część stosu danych klienta, w tym:

• Pozbycie się CDP poprzez aktywację bezpośrednio z DWH.
• Wykorzystanie DWH jako quasi-CDP z odwrotną platformą ETL.
• Współistnienie z CDP.

Przyjrzyjmy się tym trzem wzorcom projektowym.

1. Podłączanie platform marketingowych bezpośrednio do Twojego DWH

Jest to być może najbardziej ekstremalny przypadek, który skrytykowałem powyżej, ale niektóre przedsiębiorstwa sprawiły, że to zadziałało, zwłaszcza w erze przed CDP, a platformy (takie jak Snowflake z jego szerokim ekosystemem) próbują rozwiązać ten problem.

Pomysł polega na tym, że Twoja platforma zaangażowania łączy się bezpośrednio z danymi push-pull za pomocą DWH. Wiele dojrzałych platform do automatyzacji poczty e-mail i marketingu jest natywnie podłączonych do tego, chociaż zazwyczaj odbywa się to za pomocą wsadowego wypychania. Następnie Twoi marketerzy używają platformy komunikacyjnej do tworzenia segmentów i wysyłania wiadomości do tych segmentów w przypadku marketingu wychodzącego.

Wyobraź sobie, że masz inną platformę marketingową lub angażującą, spersonalizowaną stronę internetową lub platformę e-commerce. Ponownie pobierasz dane z DWH, a następnie wykorzystujesz platformę aplikacji internetowych do tworzenia kolejnego zestawu segmentów w celu bardziej ukierunkowanego zaangażowania.

Czy widzisz już problem? Istnieją już dwa zestawy interfejsów segmentacji. Co by się stało, gdybyś miał 10 platform marketingowych? 20? Będziesz nadal tworzyć segmenty wszędzie, więc Twoja obietnica omnichannel zniknie.

Na koniec, co by było, gdybyś musiał dodać kolejną platformę marketingową, która nie obsługuje bezpośredniego pozyskiwania z DWH?

2. Zastosuj DWH z narzędziami odwróconego ETL

Takie podejście rozwiązuje kilka problemów z pierwszym wzorcem powyżej. Warto zauważyć, że pozwala (teoretycznie) specjalistom spoza DWH tworzyć uniwersalne segmenty praktycznie na szczycie DWH i aktywować wiele platform. Dzięki transformacji i lepszemu frameworkowi konektorów możesz stosować różne mapowania etykiet i przyjazne dla marketerów struktury danych do różnych punktów końcowych.

Oto jak to działa. Platformy Reverse ETL pobierają dane z DWH i wysyłają je do platform marketingowych po każdej transformacji. Możesz wykonać wiele transformacji i wysłać te dane do kilku miejsc docelowych jednocześnie. Możesz nawet zautomatyzować to i regularnie uruchamiać eksporty według wcześniej zdefiniowanego harmonogramu.

Ale kopia tych danych (lub ich podzbiór) jest faktycznie kopiowana na platformy docelowe, więc tak naprawdę nie masz tylko jednej kopii danych. Ponieważ platforma reverse-ETL nie ma kopii danych, wymagane segmenty lub odbiorcy są zawsze generowani w czasie zapytania (zwykle partiami). Następnie eksportujesz je do miejsc docelowych.

To nie jest odpowiednie podejście, jeśli chcesz mieć wyzwalacze w czasie rzeczywistym lub kampanie, które są zawsze aktywne na podstawie zdarzeń. Jasne, możesz zautomatyzować eksport z dużą częstotliwością, ale nie dzieje się to w czasie rzeczywistym. Gdy zwiększysz częstotliwość eksportu, Twoje koszty wzrosną wykładniczo.

Ponadto, chociaż narzędzia reverse-ETL zapewniają interfejs segmentacji, są one bardziej techniczne i koncentrują się na DataOps niż na MOps. Zanim uznasz to rozwiązanie za „przyjazne dla biznesu” i odpowiednie do samoobsługi marketerów, musisz je dokładnie przetestować.

3. DWH współistnieje z CDP

Twoje korporacyjne DWH służy jako warstwa infrastruktury danych klienta, która dostarcza dane do twojego CDP (między innymi punktami końcowymi). Wiele, jeśli nie większość, CDP oferuje teraz pewne możliwości synchronizacji z platformami DWH, w szczególności Snowflake.

Istnieją różnice w tym, jak te CDP mogą współistnieć z DWH. Większość dostawców CDP synchronizuje i powiela dane w swoich repozytoriach, podczas gdy inni (w tym dostawcy odwrotnego ETL) nie tworzą kopii. Mogą jednak istnieć kompromisy, które należy rozważyć przed sfinalizowaniem tego, co działa dla Ciebie.

Ogólnie rzecz biorąc, widzimy, że większe przedsiębiorstwa preferują ten wzorzec projektowy, aczkolwiek z dużą rozbieżnością co do tego, gdzie ostatecznie znajdują się takie krytyczne usługi, jak rozpoznawanie tożsamości klienta.

Kop głębiej: gdzie CDP powinien się zmieścić w twoim stosie martech?

Zakończyć

Platformy DWH odgrywają coraz większą rolę w stosach martech. Nadal jednak masz wiele możliwości wyboru architektury usług, które świadczysz w ramach swojego ekosystemu danych.

Myślę, że jest przedwczesne, aby wykluczyć CDP w twojej przyszłości. Każdy wzór ma swoje kompromisy, o których należy pamiętać podczas oceny opcji.