Dovresti usare il tuo data warehouse come CDP?

L'avvento dei data warehouse basati su cloud (DWH) ha portato un'implementazione più semplice, una maggiore scalabilità e migliori prestazioni a un numero crescente di casi d'uso basati sui dati. I DWH sono diventati più diffusi negli stack tecnologici aziendali, inclusi gli stack martech.

Inevitabilmente, questo pone la domanda: dovresti utilizzare il tuo DWH esistente come piattaforma di dati dei clienti (CDP)? Dopotutto, quando riutilizzi un componente esistente nel tuo stack, puoi risparmiare risorse ed evitare nuovi rischi.

Ma la storia non è così semplice e attendono molteplici potenziali modelli di progettazione. In definitiva, c'è un caso a favore e contro l'utilizzo del tuo DWH come CDP. Scaviamo più a fondo.

DWH come CDP potrebbe non essere adatto a te

Esistono diversi problemi inerenti all'utilizzo di un DWH come CDP. Il primo è ovvio: non tutte le organizzazioni dispongono di un DWH. A volte, un team DWH aziendale non ha il tempo o le risorse per supportare i casi d'uso incentrati sul cliente. Altre aziende implementano efficacemente un CDP come un quasi-data warehouse. (Non tutti i CDP possono farlo, ma hai capito.)

Supponiamo che tu abbia la maggior parte o tutti i dati dei tuoi clienti in un DWH. Il problema per molte, se non per la maggior parte, delle aziende è che i dati non sono accessibili in modo favorevole al marketing. In genere, un DWH aziendale è costruito per supportare casi d'uso di analisi, non casi d'uso di attivazione. Ciò influisce sul modo in cui i dati vengono etichettati, gestiti, correlati e governati internamente.

Ricorda che un DWH è essenzialmente per l'archiviazione e l'elaborazione, il che significa che i dati vengono archiviati in tabelle di database con nomi di colonne come attributi. Quindi scrivi istruzioni SQL complesse per accedere a quei dati. Non è realistico per i tuoi esperti di marketing ricordare i nomi di tabelle e colonne prima di poter creare segmenti per l'attivazione. O in altre parole, i DWH in genere non supportano il self-service del marketer come fa la maggior parte dei CDP.

Ciò tocca anche una questione strutturale più ampia. I DWH in genere non sono progettati per supportare i casi d'uso di marketing in tempo reale a cui si rivolgono molti CDP. Può eseguire calcoli rapidi e puoi pianificare l'acquisizione e l'elaborazione in modo che si verifichino a intervalli frequenti, ma non è ancora in tempo reale. Allo stesso modo, con alcune eccezioni, un DWH non vuole agire su dati grezzi, mentre i marketer spesso vogliono utilizzare dati grezzi (in genere eventi) per attivare determinate attivazioni.

Infine, ricorda che i dati e la possibilità di accedervi non costituiscono un CDP. La maggior parte dei CDP offre alcuni sottoinsiemi di funzionalità aggiuntive che non troverai in un DWH, come ad esempio:

• Sottosistema di eventi con attivazione.
• Risoluzione dell'identità anonima.
• Interfaccia marketer-friendly per la segmentazione.
• Profili di attivazione del segmento con connettori.
• Potenzialmente servizi di test, personalizzazione e raccomandazione.

Un DWH da solo non fornirà queste funzionalità, quindi dovrai reperirle altrove. Naturalmente, i fornitori di DWH hanno considerevoli mercati partner. Puoi trovare molte alternative, ma non sono native e richiederanno uno sforzo di integrazione e supporto.

Non sorprende quindi che ci siano molte chiacchiere sui "CDP componibili" e sul ruolo potenziale di un DWH in quel contesto. Ho sostenuto in precedenza che la componibilità è uno spettro e inizi a perdere benefici oltre un certo punto.

Dopo aver emesso tutti questi avvertimenti, un DWH può svolgere un ruolo come parte di uno stack di dati del cliente, tra cui:

• Eliminare una CDP attivando direttamente dal DWH.
• Utilizzo del DWH come quasi-CDP con una piattaforma ETL inversa.
• Coesistenza con un CDP.

Diamo un'occhiata a questi tre modelli di progettazione.

1. Collegamento delle piattaforme di marketing direttamente al tuo DWH

Questo è forse il caso più estremo che ho criticato sopra, ma alcune aziende lo hanno fatto funzionare, specialmente nell'era pre-CDP e le piattaforme (come Snowflake con il suo ampio ecosistema) stanno cercando di risolvere questo problema.

L'idea qui è che la tua piattaforma di coinvolgimento si connetta direttamente ai dati push-pull con un DWH. Molte piattaforme di posta elettronica e di automazione del marketing mature sono cablate in modo nativo per farlo, anche se in genere tramite push batch. I tuoi esperti di marketing utilizzano quindi la piattaforma di messaggistica per creare segmenti e inviare messaggi a tali segmenti nel caso del marketing in uscita.

Immagina di avere un'altra piattaforma di marketing o coinvolgimento, un sito Web personalizzato o una piattaforma di e-commerce. Ancora una volta si estraggono i dati da DWH, quindi si utilizza la piattaforma dell'applicazione Web per creare un altro set di segmenti per un coinvolgimento più mirato.

Vedi già il problema? Esistono già due serie di interfacce di segmentazione. Cosa succede se hai 10 piattaforme di marketing? 20? Continuerai a creare segmenti ovunque, quindi la tua promessa omnicanale scompare.

Infine, se dovessi aggiungere un'altra piattaforma di marketing che non supporta l'importazione diretta da un DWH?

2. Impiegare DWH con strumenti di reverse-ETL

Questo approccio risolve diversi problemi con il primo modello di cui sopra. In particolare, consente (in teoria) a uno specialista non DWH di creare segmenti universali virtualmente sopra il DWH e attivare più piattaforme. Con la trasformazione e un framework di connettori migliore, puoi applicare diverse mappature delle etichette e strutture di dati adatte al marketing a diversi endpoint.

Ecco come funziona. Le piattaforme ETL inverse estraggono i dati dal DWH e li inviano alle piattaforme di marketing dopo ogni trasformazione. È possibile eseguire più trasformazioni e inviare i dati a più destinazioni contemporaneamente. Puoi persino automatizzarlo e fare in modo che le esportazioni vengano eseguite regolarmente secondo una pianificazione predefinita.

Ma una copia di quei dati (o un sottoinsieme di essi) viene effettivamente copiata sulle piattaforme di destinazione, quindi in realtà non hai solo una singola copia di dati. Poiché la piattaforma ETL inverso non dispone di una copia dei dati, i segmenti o i segmenti di pubblico richiesti vengono sempre generati al momento della query (in genere in batch). Quindi li esporti verso le destinazioni.

Questo non è un approccio adatto se desideri avere trigger in tempo reale o campagne sempre attive basate su eventi. Certo, puoi automatizzare le tue esportazioni ad alta frequenza, ma non è in tempo reale. Man mano che aumenti la frequenza delle esportazioni, i tuoi costi aumenteranno in modo esponenziale.

Inoltre, sebbene gli strumenti di ETL inverso forniscano un'interfaccia di segmentazione, tendono ad essere più tecnici e incentrati sui DataOps piuttosto che sui MOps. Prima di dichiarare che si tratta di una soluzione "business-friendly" adatta al self-service del marketer, è necessario testarla attentamente.

3. DWH coesiste con CDP

Il tuo DWH aziendale funge da livello di infrastruttura dei dati del cliente che fornisce dati al tuo CDP (tra gli altri endpoint). Molti, se non la maggior parte, CDP ora offrono alcune funzionalità per la sincronizzazione dalle piattaforme DWH, in particolare Snowflake.

Esistono variazioni nel modo in cui questi CDP possono coesistere con DWH. La maggior parte dei CDP sincronizza e duplica i dati nel proprio repository, mentre altri (inclusi i fornitori di reverse-ETL) non ne fanno una copia. Tuttavia, potrebbero esserci dei compromessi che devi considerare prima di finalizzare ciò che funziona per te.

In generale, tendiamo a vedere le aziende più grandi preferire questo modello di progettazione, anche se con un'ampia variazione in merito a dove risiedono servizi critici come la risoluzione dell'identità del cliente.

Scava più a fondo: dove dovrebbe inserirsi una CDP nel tuo stack martech?

Incartare

Le piattaforme DWH svolgono ruoli sempre più essenziali negli stack martech. Tuttavia, continui ad avere più scelte architetturali sui servizi che rendi all'interno del tuo ecosistema di dati.

Penso che sia prematuro escludere i CDP nel tuo futuro. Ogni modello ha i suoi compromessi da tenere a mente mentre valuti le tue opzioni.