Drie manieren om een CDP-architectuur op Google Cloud te ontwerpen

De meeste bedrijven zitten in een of andere fase van digitalisering. Een onderdeel daarvan is vaak meer aandacht voor de klant: de klantervaring verbeteren door die persoonlijk te maken, ongeacht het kanaal of het soort contact.

Google Cloud als basis voor een Customer Data Platform

Een Customer Data Platform (CDP) kan de basis zijn voor die bredere omslag, en die versnellen. Goed ingericht kan de CDP het hart worden van de marketingtechnologie en de rest van de bedrijfsbrede stack: hij brengt klantdata op orde en verbetert de ervaring van de klant, en die van de zakelijke gebruiker.

Marketingmogelijkheden die je in de digitale economie nodig hebt, zijn onder meer:

• Personalisatie en segmentatie op schaal
• Passende aanbevelingen voor content en producten
• Relevante digitale ervaringen in realtime
• Eenduidige boodschappen over alle kanalen
• Prestaties meten over domeinen en kanalen heen
• Eén architectuur die veilig is, privacy respecteert en goed geregelde data governance heeft

Bedrijven hebben een Customer Data Platform ingevoerd of zijn daarmee bezig, als vast onderdeel van een bedrijfsbreed dataplatform. Daarmee verzamelen, bewerken en analyseren ze data over hun doelgroepen, en gaan ze met die doelgroepen in gesprek. Een CDP brengt klantdata uit allerlei bronnen samen tot één beeld van de klant, en levert zo de marketing- en compliancemogelijkheden hierboven.

Zie de CDP en wat hij kan als een verlengstuk van een stevige datastrategie en één bedrijfsbrede architectuur.

Zie de CDP dus niet als vervanging van een datastrategie en een bedrijfsbrede architectuur. Wie hem als verlengstuk ziet, haalt meer rendement uit de investering, omdat de CDP aansluit op de rest van je systemen.

Een voorbeeld. Een beddenbedrijf wil klanten zes jaar na aankoop een nieuwe matras aanbieden, omdat de matrassen gemiddeld zo lang meegaan. De klant krijgt een e-mail met een waardebon, met de naam en de afbeelding van het product dat de klant nu gebruikt. Die gegevens staan in het data lakehouse, niet in de CDP. Dat kan, omdat de data in je CDP gekoppeld en op elkaar afgestemd is, en via de managed services van Google Cloud direct beschikbaar is in je lakehouse.

Zijn je data lakehouse en je CDP met elkaar verbonden, dan kunnen ook je datateams hun domeinkennis, inzichten en modellen kwijt in het klantcontact dat de CDP aanstuurt.

Voor bedrijven die besloten hebben in een CDP te investeren, is de belangrijkste vraag welke onderdelen ze zelf bouwen en welke ze kopen of in licentie nemen. Daar ging een groot deel van mijn vorige artikel over. Ook bij kant-en-klare CDP-onderdelen moet je bepalen waar je belangrijkste data staat, en wie toegang heeft tot de data zelf en wie alleen tot de inzichten. Mijn advies is meestal om de belangrijke data in eigen data lakes te houden, gebouwd op Google Cloud Storage en BigQuery-opslag.

Grip op first-party klantdata, inclusief persoonsgegevens (PII), wie erbij kan en hoe die beheerd wordt, is voor merken een flink concurrentievoordeel, en daarnaast een wettelijke plicht. Door privacywetgeving zoals de AVG moeten bedrijven weten waar hun data staat en hoe ze die beschermen.

Ook bij bedrijven die al een CDP hebben, zien we vaak dat teams of afdelingen datasets en inzichten los van elkaar gebruiken. Ze worden niet genoeg samengevoegd om een volledig beeld te krijgen over afdelingen, platformen, soorten content en dergelijke heen. En uiteindelijk willen klanten weten waar hun data staat en wie er goed gebruik van kan maken.

Tot slot verdwijnen third-party cookies, die voor mediamarketeers en mediabudgetten belangrijk zijn geweest. Bedrijven die klantreizen met third-party cookies volgen, moeten steeds vaker andere manieren vinden om hun doelgroep te bereiken.

Hoe je een CDP-architectuur op GCP bouwt

Onze klanten kiezen meestal voor een van drie architecturen:

1. Volledig geïntegreerde CDP-suites

Deze aanpak past bij klanten die één tool willen, en die snel willen. Ik zie hier twee soorten bedrijven.

Het verschil tussen grote en kleinere bedrijven

Willen grote ondernemingen één of twee suites combineren en speelt de prijs nauwelijks een rol, dan kunnen de grotere suites een optie zijn, zoals in de afbeelding hieronder. Je hebt dan wel het budget en eigen data engineers voor de koppelingen nodig. Een kostenpost die je niet moet onderschatten, is de interne afstemming: bij een kant-en-klare oplossing moeten sommige gebruikers zich aanpassen aan de tools en werkwijzen van het platform. De directe kosten zijn de prijs van het hele platform en van de datarijen die erin opgeslagen zijn.

Weeg ook de afhankelijkheid van één leverancier mee, voor functies, voor het tempo van vernieuwing en voor flexibiliteit, zoals besproken in dit artikel: 'Should I bring my data and analytics to Salesforce?'

Kleinere bedrijven die weinig maatwerk nodig hebben in bedrijfsregels, code en modellen, kunnen ook voor een suite kiezen. Naarmate ze volwassener worden, kunnen ze overstappen op een modulaire architectuur met de beste tool per onderdeel.

Voorbeeld van een architectuur op hoofdlijnen met volledig geïntegreerde suites op Google Cloud Platform:

2. Modulaire CDP's

Bij deze hybride aanpak kies je zelf welke CDP-onderdelen je in de public cloud bouwt en welke je koopt of in licentie neemt. Zo kun je per use case de beste tool kiezen, en betaal je niet voor functies die je niet nodig hebt. Je voegt functionaliteit toe als je behoeften groeien. Je hebt nog steeds eigen data engineers nodig, en meestal kost dat meer tijd dan bij een volledige suite. Daar staat tegenover dat je de kosten van je CDP directer in de hand hebt en kunt verlagen. Hoe je een MarTech-stack bouwt op een platform in de public cloud met kant-en-klare applicaties, als onderdeel van een modulaire architectuur, lees je uitgebreid in deze blog.

Mijn advies aan middelgrote en grote bedrijven met grote klantdatabases is meestal: bouw, combineer en koop wat in de public cloud mogelijk is, en bewaar alle data daar en niet in de modules. Heb je het genormaliseerde 360-gradenklantbeeld in GCP, dan ben je veel minder tijd kwijt als je van CDP-module wisselt of er een uitprobeert.

Koppel tools die deze clouds zelf niet bieden. Bijvoorbeeld een onderdeel met een gebruikersinterface om klantprocessen in te richten, zoals Salesforce Einstein en Selligent die bieden. Zo krijg je het beste van twee werelden: integratie, orkestratie, slimme modellen, en daarbovenop de tools van andere leveranciers die je wilt gebruiken.

In deze voorbeeldarchitectuur hebben we per onderdeel drie logo's gezet, terwijl er duizenden onderdelen zijn om uit te kiezen. De technische en operationele complexiteit valt mee als je het goed inricht. Crystalloids kan je helpen bij de keuze en bij een architectuur die bij je organisatie past.

3. Volledig headless, van begin tot eind op GCP

De derde aanpak is de CDP bouwen op het bestaande lakehouse, met alles wat Google aan IaaS, PaaS en SaaS biedt. Dit is voor bedrijven met het budget en de mensen, zelf of via een partner, en meestal zijn dat grote digital natives. Ze hebben volledige vrijheid en zeggenschap over eigendom, werkwijze en het beheer van de datalevenscyclus, inclusief CI/CD, containers en dergelijke. Ze bouwen de onderdelen in hun eigen tempo, en testen om hun ontwikkelkeuzes op data te baseren.

Een groot verschil met de modulaire aanpak: bij een Google-first aanpak ontwikkel je de functionaliteit in GCP, en koop je alleen applicaties of neem je ze in licentie als GCP het niet biedt, of als een onderdeel van een derde om een bepaalde reden beter past. Een ander voordeel zijn de directe koppelingen met de advertentietools van Google.

Ook een zelfgebouwde CDP gebruikt kant-en-klare applicaties, zoals e-mailsoftware en SaaS voor visualisatie, maar alleen voor de basisfuncties. Het 360-gradenklantbeeld en de analytische weergaven staan altijd in de CDP op GCP, niet in CDP-onderdelen van derden.

Onze klanten Body & Fit, Coolblue en Rituals Cosmetics zijn voorbeelden van digital natives die het zelf bouwen op GCP.

Beginnen met een CDP-architectuur op GCP

Er is niet één juiste aanpak voor het bouwen van een CDP. Het hangt af van waar je bedrijf staat met de cloud, hoe groot en complex het is, wat het bedrijf nodig heeft, en welke mensen je zelf hebt of via een partner zoals Crystalloids.

Heb je niet de juiste mensen in huis, met name voor softwareontwikkeling, data engineering en data science, maar wel het budget, dan is een volledige CDP-suite een optie.

Groeit de datakennis binnen je organisatie, dan is het logisch om de ontwikkeling uit te besteden aan een gespecialiseerde partner zoals Crystalloids, die ervaring heeft met het bouwen van CDP's op GCP en met het inkopen van de beste tools voor specifieke functies.

We hebben klanten die elk van deze aanpakken hebben gekozen, of met de ene begonnen en naar een andere overstapten toen ze meer mensen in hun datateam aannamen.

Zorg dat alle betrokkenen achter de keuze staan, houd ze op de hoogte en geef ze een routekaart voor de invoering en de acceptatie door gebruikers, ook na de aankoopbeslissing. Brede betrokkenheid over afdelingen heen is een belangrijke kenmerk van succes.

Steun en betrokkenheid van de directie helpen ook. Dat is makkelijker als de CDP bijdraagt aan de strategische doelen en de koers van het bedrijf.

Waarom Google Cloud?

Het belangrijkste is dat je met GCP als basis een moderne, flexibele CDP bouwt die met je bedrijf meegroeit en meeschaalt met je gebruikers en use cases, veilig en binnen de privacyregels.

Wil je weten waarom Google Cloud Platform bij jouw eisen past, lees dan waarom onze klanten, vroeger en nu, voor Google Cloud kozen om hun CDP te bouwen en er nog steeds op draaien.

Conclusie

Ons advies aan middelgrote en grote bedrijven met grote klantdatabases is meestal: bouw, combineer en koop wat in de public cloud mogelijk is. Koppel tools die deze clouds zelf niet bieden.

Een onderdeel met een gebruikersinterface om klantprocessen in te richten, zoals Salesforce Einstein, Tinyclues en Selligent bieden, is daar een voorbeeld van. Zo krijg je het beste van twee werelden: integratie, orkestratie, en daarbovenop de tools van andere leveranciers die je wilt gebruiken.