Skip links

Is er een nieuwe definitie voor het CDP nodig?

Is er een nieuwe definitie voor het CDP nodig?

De vroegste Customer Data Platforms (CDP) werden geïntroduceerd vóór 2010; de term CDP werd bedacht om deze opkomende categorie  te beschrijven in 2013. Mijn definitie is sindsdien maar weinig veranderd sinds we het CDP Institute lanceerden in 2016 en luidt als volgt: “packaged software packaged software that builds a unified, persistent customer database accessible to other systems.” Het Institute voegde in 2019 de RealCDP-checklist toe om meer specifieke kenmerken aan de definitie toe te voegen, in de hoop kopers te helpen ervoor te zorgen dat een systeem dat zichzelf een CDP noemde, daadwerkelijk de use cases kon ondersteunen die van een CDP werden verwacht. 

Tegen die tijd begonnen brancheanalisten hun eigen definities te maken, die, hoewel anders geformuleerd, in grote lijnen overeenkwamen met de definitie van het CDP Institute. Zelfs de belangrijkste marketing suite-leveranciers, die aanvankelijk beweerden dat een aparte (“permanente”) database niet nodig was, hebben uiteindelijk die positie laten varen en producten geïntroduceerd die aan de criteria van het CDP Institute voldeden.

Een succesvol concept zoals CDP neemt snel een eigen leven aan. Het werd al snel duidelijk dat veel mensen de term CDP in een veel lossere zin gebruikten, om te verwijzen naar elk systeem dat klantprofielen opbouwde en deelde. Dit ging verder dan “packaged software” en omvatte op maat gemaakte systemen en systemen met een meer beperkte reikwijdte dan een “Real CDP”. Deze uitbreiding vertekende sommige enquêteresultaten in rapporten van het Institute, maar leek verder relatief onschuldig; in ieder geval leek weerstand zowel pedant als zinloos. Wat echt belangrijk was, was dat deze systemen CDP-gebruikers nog steeds toegang gaven tot de samengevoegde profielen.

Helaas stopte de evolutie van de term daar niet. Naarmate het CDP populairder werd, adopteerden veel leveranciers het label, ongeacht of ze zelfs aan de lossere definitie voldeden. Tegelijkertijd boden legitieme CDP-leveranciers aanvullende mogelijkheden om de gegevens in de profielen te analyseren en te implementeren. De resulterende verwarring leidde uiteindelijk ertoe dat sommige leveranciers het CDP-label volledig vermeden, omdat het niet langer een nuttige manier bood om hun producten te onderscheiden. Vandaag de dag noemen leveranciers die op zoek zijn naar het nieuwste label zich eerder “digital experience managers” dan een CDP, zelfs als hun producten aan de CDP-eisen voldoen.

Maar de grootste uitdaging voor het nut van het CDP-label ontstond de afgelopen jaren toen een aantal leveranciers beweerde, dat de kernfunctie van het CDP – een dedicated database opgebouwd door het importeren van gegevens uit andere systemen, oftewel “persistentie” – kon worden opgegeven terwijl ze het resultaat nog steeds een CDP noemden. Hun argument was dat klantprofielen kunnen worden ondergebracht in een algemeen datawarehouse, dat de meeste bedrijven al in gebruik hadden. 

Deze bewering kreeg enige plausibiliteit door het feit dat moderne cloud datawarehouse-technologieën, zoals Snowflake, Google Big Query en AWS Redshift, inderdaad worden gebruikt door sommige conventionele CDP-leveranciers. Het probleem was echter dat ze impliciet aannamen dat het datawarehouse van elk bedrijf de gegevens had georganiseerd in bruikbare klantprofielen. In feite voeren maar heel weinig datawarehouses de specifieke taken uit, met name identiteitsoplossing (ID resolution), aggregatie op klantniveau en real-time respons, die nodig zijn om CDP-gebruiksscenario’s te ondersteunen. Hoewel het technisch mogelijk is om deze functies toe te voegen aan een bestaand datawarehouse, is dit meestal een groot project dat vaak meer kost, langer duurt en minder bruikbare resultaten oplevert dan het installeren van een aparte, conventionele CDP. (Zoals altijd, hangt de precieze situatie af van de situatie.)

Een positief resultaat van de interesse in profielen die zijn gebaseerd op datawarehouses is geweest dat sommige CDP-leveranciers ervoor hebben gekozen om hun systemen op te splitsen in modules waarmee gebruikers de gegevensvoorbereidingsfuncties afzonderlijk kunnen aanschaffen van de rest van de CDP. Dit stelt bedrijven in staat die een op datawarehouses gebaseerd systeem willen om nog steeds te profiteren van de volwassen capaciteiten die deze CDP-leveranciers in de loop der jaren hebben ontwikkeld. Deze leveranciers hebben vaak ook de mogelijkheid toegevoegd om gegevens van een datawarehouse of een ander extern systeem te combineren met gegevens die zijn opgeslagen in een conventionele, persistente CDP-database, zonder die externe gegevens daadwerkelijk in de CDP te laden. Dit biedt enkele voordelen van de aanpak op basis van datawarehouses, zoals verminderde dataverplaatsing en opslagkosten, terwijl de voordelen van het persistente CDP behouden blijven, zoals meer controle en flexibiliteit.

Je zult hebben gemerkt dat al deze veranderingen betrekking hebben op de invoerkant van de CDP-datastroom. Het was ooit een zeer eenvoudig proces: gegevens van andere systemen werden gekopieerd naar het CDP, waar ze werden geformatteerd tot profielen en gedeeld met andere systemen. Nu kan het invoerproces een mix zijn van het kopiëren van gegevens naar de CDP, het lezen van volledig gevormde profielen uit een datawarehouse, of het combineren van interne en externe gegevens. Daarentegen is de delivery-kant van het proces hetzelfde gebleven: het CDP deelt zijn profielen met andere systemen.

In sommige gevallen heeft dit geleid tot een subtiele verschuiving in de perceptie van het doel van het CDP: van een systeem dat klantprofielen opbouwt tot een systeem dat die profielen levert aan andere systemen. In dit perspectief is de kernfunctie van de CDP het omzetten van algemene profielen in de specifieke formaten die nodig zijn voor analytische, orkestratie- en bezorgsystemen (die we “activatiesystemen” kunnen noemen als je bereid bent wat jargon in te ruilen voor eenvoud). Dit kan nog steeds enige dataverwerking omvatten, zoals het vooraf berekenen van model scores en aggregaten om ze in realtime beschikbaar te maken, en nieuwe datastructuren om de resultaten van die verwerking op te slaan. Dus er gebeurt hier meer dan alleen een eenvoudige dataoverdracht of API-call.

Sommige mensen gaan nog een stap verder en beweren dat het CDP eigenlijk gedefinieerd zou moeten worden als een activatiesysteem dat profielen leest vanuit ergens anders. Aangezien drie kwart van de CDP’s die we volgen eigenlijk wel enige activatiemogelijkheden hebben, is dit niet zo gek als het misschien klinkt.

Dat gezegd hebbende, ben ik nog niet klaar om het CDP opnieuw te definiëren. “Packaged software” en “persistent customer database” zijn zinvolle termen die één configuratie onderscheiden van andere benaderingen (“op maat gemaakte software” en “externe profielen”) die ook profielen beschikbaar kunnen stellen aan andere systemen. Belangrijker nog heeft de verpakte/persistente configuratie aanzienlijke kosten- en uitvoeringsvoordelen ten opzichte van de op maat gemaakte/externe alternatieven. Het is dus belangrijk om het onderscheid tussen de twee benaderingen niet te vervagen.

Afbeelding met schermopname, tekst, cirkel, Elektrisch blauw

Automatisch gegenereerde beschrijving

Hoogstens zou ik retroniemen willen suggereren die het “Packaged CDP” (verpakt/persistent) onderscheiden van het “Warehouse CDP” (op maat/extern). Volgens de definitie bouwt het “Warehouse CDP” niet zijn eigen profielen op, dus lijkt de term de fundamentele functie van de CDP te negeren. Je zou dat oxymoronisch kunnen noemen, zo niet gewoonweg dwaas. Maar als we de kernfunctie van het CDP iets herschikken naar het leveren van profielen in plaats van ze te creëren, kunnen we dit bezwaar overwinnen en wellicht markttermen introduceren die intuïtief begrepen worden.Afbeelding met schermopname, tekst, cirkel, lijn

Automatisch gegenereerde beschrijving

Je zult ook opmerken, dat de verschuiving van profielcreatie naar -bezorging de nadruk legt op de deliverykant van de CDP-stroom, wat we hebben opgemerkt als de meest stabiele en van toepassing zijnd op zowel de packaged als de warehouse-benaderingen. Dit stelt ons in staat om mee te gaan met de trend om CDP opnieuw te definiëren als een customer profile sharing system.

Kortom, het belangrijkste onderscheid is of de primaire klantprofielen worden opgebouwd en opgeslagen in het datawarehouse van het bedrijf of in een aparte CDP-database. Het is de moeite waard om dat onderscheid te handhaven, omdat de ene benadering vertrouwt op het technisch personeel van het bedrijf om de functies samen te stellen die nodig zijn om de profielen op te bouwen en op te slaan, terwijl de andere vertrouwt op een packaged CDP om die functies te leveren. Er zijn variaties binnen elk thema, waaronder of de datawarehouse-modules van een CDP-leverancier gebruikt om zijn profielen samen te stellen of om ze te helpen bezorgen, of real-time gegevens naar het datawarehouse worden gestuurd of apart worden bewaard, en of het CDP zijn profielen verrijkt met externe gegevens zonder die gegevens te importeren. Deze zijn belangrijk vanuit praktisch oogpunt, maar hebben geen invloed op de fundamentele architectuur van het systeem. Door eerst te focussen op waar de profielen zich bevinden, zouden kopers moeten begrijpen welke belangrijke keuze ze moeten maken. Deze keuze zal op haar beurt de andere beslissingen bepalen die ze moeten overwegen.

Benieuwd naar de mogelijkheden?

We leren je graag kennen. Neem vrijblijvend contact op met onze specialist rondom Customer Data Strategy, Frans Melenhorst.