Wat is het verschil, in één zin?
Een customer data platform (CDP) verzamelt klantdata uit elke bron, brengt die terug tot één identiteit per persoon en synchroniseert doelgroepen naar andere tools – data-infrastructuur die niets naar klanten verstuurt. Een customer engagement platform (CEP) is de activatielaag: een eigen opslag van profielen en events, plus de segmenten, journeys en berichten die mensen bereiken. Deze gids vergelijkt de twee categorieën; de checklist voor de beslissing – drempels, signalen, kosten – staat in onze gids Heb je een CDP nodig.
Wat doet een CDP dat een CEP niet doet?
Een CDP verzamelt events en kenmerken uit elke bron – SDK’s voor je website en app, server-side streams, imports uit je warehouse en factureringstools – brengt die terug tot één identiteit per persoon en synchroniseert de doelgroepen die daaruit volgen naar bestemmingstools. Het CDP Institute definieert een CDP als software die een blijvend, samengevoegd klantrecord aanmaakt en bijhoudt dat voor andere systemen toegankelijk is, en dat laatste deel zegt het al: het resultaat is een record dat andere systemen gebruiken. Een CDP is data-infrastructuur – ze verzamelt, koppelt en stuurt door – en het versturen gebeurt in de tools die ze voedt. Wat ze niet kan oplossen, is slordige input. Daarom is een helder trackingplan met een CDP net zo belangrijk als zonder.
Wat doet een CEP met die data?
Een CEP houdt een eigen first-party opslag van profielen en events bij, berekent daarop segmenten – inclusief dynamische segmenten die opnieuw worden berekend zodra events binnenkomen – en laat de journeys lopen die e-mail, sms, in-app berichten en pushmeldingen versturen. Ze beheert de laatste stap die de CDP bewust vermijdt: data omzetten in een bericht dat een klant echt ontvangt. De opslag is geen implementatiedetail. Profielen en events in een systeem dat je zelf beheert, zijn in de praktijk het grootste deel van wat eigenaar zijn van je klantdata betekent.
CDP vs. CEP: de vergelijking
De verwarring tussen CDP en CEP is commercieel, niet conceptueel – leveranciers aan beide kanten nemen steeds meer van elkaars vocabulaire over. De markt geeft ze daar reden toe: de brancheupdate van het CDP Institute van juli 2025 noemt 208 CDP-leveranciers, en schattingen van analisten die CDP.com heeft verzameld, komen voor de CDP-markt in 2026 uit op ergens tussen 4 en 10,5 miljard dollar, afhankelijk van wie er meet. De taken blijven echter verschillend. De tabel toont de verdeling die de marketing overleeft.
| Customer data platform | Customer engagement platform | |
|---|---|---|
| Hoofdtaak | Klantdata verzamelen, koppelen en doorsturen | Data activeren – segmenteren, orkestreren, versturen |
| Wat erin gaat | Events en kenmerken uit SDK’s, backends, warehouses, SaaS-tools | Events uit de eigen SDK en API, plus profielkenmerken |
| Wat eruit komt | Schone profielen en doelgroepen, gesynchroniseerd naar bestemmingstools | E-mails, sms, in-app berichten, pushmeldingen – en de analyses daarvan |
| Identiteitskoppeling | Kernfunctie – voegt dezelfde persoon samen over bronnen en apparaten heen | Basaal – meestal één identiteit per profiel in de eigen opslag |
| Verstuurt berichten? | Nee – per definitie geeft ze doelgroepen door aan tools die versturen | Ja – versturen is het hele punt |
| Wie het beheert | Data- of growth engineers | Marketeers en oprichters, met een engineer voor de inrichting |
| Wanneer het loont | Veel bestemmingen die hetzelfde gekoppelde profiel nodig hebben | Zodra je gebruikers hebt om te onboarden en te behouden |
Hoe ziet een probleem voor een CDP eruit?
- Meerdere bestemmingstools – advertentieplatforms, analytics, support, berichten – hebben elk hetzelfde schone profiel nodig, en elk bouwt nu zijn eigen versie.
- Je analytics-stack draait om het warehouse: het warehouse is de bron van waarheid, en elke tool verderop in de keten heeft een beheerd deel ervan nodig.
- Identiteiten zijn versnipperd over producten: dezelfde klant bestaat in twee apps onder drie e-mailadressen, en geen enkel systeem kan zeggen dat het om één persoon gaat.
- Het verzamelen van events gebeurt dubbel: elke tool levert een eigen snippet, een eigen schema en een eigen versie van dezelfde funnel.
Kan één systeem beide taken doen?
Voor een klein team meestal wel – vanaf de kant van de CEP. De first-party opslag van de CEP doet de verzamelhelft al: een SDK voor events aan de clientkant, een API voor events aan de serverkant, profielen en segmenten in dezelfde database als de journeys. Zet je daar een CDP bovenop, dan krijg je een tweede datalaag om te onderhouden – nog een schema, nog een synchronisatie om te debuggen – zonder nieuwe mogelijkheden. Voor een team met één product en één activatieplatform is een CDP een tweede datalaag, geen ontbrekende. Als de architectuursignalen hierboven echt aanwezig zijn, werken de twee goed samen: de CDP verzamelt en koppelt, en voedt dan de CEP, die de laatste stap beheert. Of je team die grens al over is, behandelt onze gids Heb je een CDP nodig stap voor stap.
Waar past fromHello?
fromHello is open source marketing automation: berichten die worden getriggerd door wat mensen doen. Het houdt een eigen first-party opslag bij: de JS/TS-SDK trackt events aan de clientkant met een offline queue, de events-API neemt events aan de serverkant aan, en profielen, segmenten, journeys en berichten staan in één database die je zelf kunt hosten of die fromHello Cloud voor je draait, in early access. Het is geen CDP en doet ook niet alsof: naast advertentiedoelgroepen en pixelrelays voor Meta, LinkedIn en Google, en uitgaande webhooks, is er geen catalogus met bestemmingen en geen identiteitsgraaf over tools heen. Laat je architectuur de CDP-signalen van hierboven zien, dan neemt fromHello in dat schema de plek van de CEP in: na de CDP, waar het de gekoppelde profielen gebruikt en de activatie doet. Kies je nog welk platform die plek moet innemen, dan is ons overzicht van open source tools voor marketing automation de plek om te beginnen.