CDP-implementatie: dataverzameling

Blogreeks: van organiseren tot live gaan

⏰ Geschatte leestijd: 3 minuten

De blogserie over CDP-implementatie geeft je gedetailleerde inzichten in de verschillende fasen van het project. Na de projectorganisatie, de specificatie en de basisconfiguratie volgt fase vier in het implementatieproces: dataverzameling.  

Een gegevensopslagplaats maken

In de voorafgaande specificatiefase hebben alle deelnemers gedefinieerd welke gegevens vereist zijn voor de geselecteerde use cases en in welke vorm en frequentie deze naar het CDP moeten worden verzonden. In de basisconfiguratie werd bepaald of de bronsystemen direct in het CDP zijn geïntegreerd of dat er een soort middleware nodig is. Op dit punt – fase vier – is er duidelijkheid over de benodigde bronsystemen en datasets. De volgende gegevenstypen kunnen worden onderscheiden:  

• Basisgegevens van klanten: Dit omvat alle gegevens van de klanten die nodig zijn voor de gepersonaliseerde boodschap, bijvoorbeeld een unieke ID per klant. 

• Toestemmingen: Dit zijn de vereiste toestemmingen van de klanten om de bijbehorende inhoud te mogen verwerken.  
   
• Events: Zowel digitale als offline touchpoints van de klanten worden op een bepaald moment als zogenaamde events opgeslagen in een klantprofiel binnen het CDP.  
   
• Catalogusgegevens: Catalogusgegevens beschrijven de opslag van andere objecten die verband houden met klanten en evenementen en die regelmatig kunnen veranderen. Voorbeelden zijn productdata uit de shop of het PIM-systeem. 

Naast de zojuist genoemde gegevenstypen zijn de volgende opties voor het verzamelen van gegevens geïntegreerd in de meeste CDP’s:  

• (REST)-API: Deze http-gebaseerde en zeer flexibele manier om gegevens te verzamelen wordt aangeboden door de meeste CDP’s en biedt meestal verschillende eindpunten voor het lezen en schrijven van de afzonderlijke gegevenstypen.  
   
• Databasegebaseerd: Aangezien de meeste CDP’s cloudgebaseerde SaaS-oplossingen zijn, moet de database extern toegankelijk zijn. De informatie wordt dan regelmatig opgehaald via SQL. De structured query language (SQL) dient als standaardtaal voor de communicatie tussen de verschillende databases. Het SQL functioneert als een soort interface waarin externe query’s van gebruikers worden vertaald naar commando’s die de database kan begrijpen.  
   
• Bestandsgebaseerd: In dit geval worden regelmatig bestanden opgehaald, zoals CSV-bestanden, die vervolgens worden opgeslagen via een URL, een SFTP-server of in de cloud. 
• Web/ App SDK-gebaseerd: Bij de meeste CDP’s wordt ook een software development kit (SDK) aangeboden om het gedrag van klanten te volgen. Belangrijk: Om te voldoen aan de AVG, mag de SDK alleen worden geladen nadat de cookies zijn geaccepteerd.  

Wendbaar samenwerken voor een effectievere implementatie

Voor de implementatie van de data repository is een wendbare aanpak aan te raden, zoals reeds beschreven in het eerste deel van onze blogserie. Daarom is voor de integratie van de verschillende bronsystemen een nauwe uitwisseling met de interne ontwikkelingsafdeling aan te raden. Op deze manier kunnen tests tot in detail worden uitgevoerd en kunnen reeds aangeleverde gegevens worden gecontroleerd op juistheid en volledigheid. De duur van het implementatieproces is sterk afhankelijk van het aantal bronsystemen en de complexiteit van de use cases, waardoor het tijdsbestek kan variëren van enkele weken tot enkele maanden. Een agile implementatieaanpak biedt het voordeel dat minder complexe use cases in een vroeg stadium geïmplementeerd kunnen worden.  

Zodra de basisconfiguratie is voltooid en de implementatie van de datasets aan de gang is, kan de volgende fase van het project beginnen: de configuratie van de use cases. 

Ook interessant