Beach Clubs and CDPs
An analysis on how CDPs fall short in real-world implementations, leading to disappointment, technical debt and the need for good old fashioned engineering.
What’s a CDP?
A CDP is like a Beach Club or a Brunch… You think you know what you’re getting into, until you get the bill and start questioning the whole concept 💸
Customer Data Platforms (aka CDPs) have been around for over a decade and are built on the appealing idea of a centralized, cross-platform repository of customer identities and interactions to compute on, fan out, and automate communications and workflows with.
Surprisingly, despite the appeal, strong momentum from privacy regulations, mass adoption and premium pricing, CDPs haven’t meaningfully matured at their core. Instead, they’ve shifted towards composability:
- unbundling their components,
- exposing ingestion pipelines,
- externalizing storage to data warehouses,
- and relying on general-purpose platforms for scalable, testable, version-controlled computation and identity resolution.
What CDPs have done over the years is like a Beach Club letting you bring your own mint, lime, and rum to customize your mojito, but still charging you full price for it… 🍋🟩
In short, despite the appeal and the tailwinds, rather than strengthening their core capabilities, CDPs have outsourced them.
Why is this happening? Because while the CDP idea kind of makes sense, the solutions they offer don’t generally cut it and can’t cover the scenarios and engineering standards that real live data activation solutions require. Hence, they open up their components for other tooling that’s better suited for the job.
CDPs sell an aspirational vision, implementing them is like taking the Marshmallow Tower Challenge to the next level.
Creds to A Real-Life Example
A few years ago, I met a Nordic tech retailer who bought into the CDP pitch and implemented a commercial platform, backed by some strong business cases. One of those cases, flagship of the platform in particular, was the classic: a cart abandonment recovery email flow.
They implemented the platform and got to work with the cart flow. Immediately, they ran into blocker after blocker that the platform couldn’t account for:
- Cart movements weren’t simple adds and removes. Carts could be merged when users logged in, and needed to be worked around outside the platform.
- In order to avoid CTAs leading to out-of-stock products, live stock checks and warehouse computations were required on mail generation and triggering.
- Email dynamic content required a custom HTML template builder.
- A very volatile pricing strategy meant they had to render prices dynamically onto images in the emails.
- To top it all off: guardrails, testing, monitoring and a bunch of fallback handling were needed… all while relying on a black-box identity resolution service they didn’t fully trust.
The result? They made it work. The flow delivered business value. But the CDP (and even the CRM) didn’t add much to the service. Besides the shaky identity resolution, the CDP became just middleware to move telemetry in and out of the data warehouse, and the CRM a pure mail dispatcher.
In the end: They paid premium for the brunch, but cooked their own eggs benedict 🥑🥚
Build vs. Buy: A False Binary
CDPs sell an aspirational vision, but the real value rarely ever comes from the platform itself. Value comes from the tailored solutions teams build around specific business challenges and opportunities.
Do I mean that organizations should not buy into commercial CDPs? Should one build instead of buying? Yes, that’s what I mean, because in this case the “build vs. buy” is a false binary.
Even if you buy a CDP, you’ll still be building. Very little comes truly “out of the box,” and the toolkit you get will quickly feel heavy, engineering-wise, cost-wise, and operations-wise. In the end, you’ll be paying for an expensive marshmallow tower and you’ll cover technical debt with more technical debt.
Bottom line: If you have CDP aspirations, no matter the path you chose, have some sharp use cases from the get go and get some solid engineering practices and people around them 👷
Why bother about CDPs?
CDPs are still widely pitched as silver bullets for personalization. Product managers, marketing leaders, and even some engineering leadership (all with the best intentions and common sense) bite hard and way too often into this pitch. This leaves engineering and data teams in a very tough spot, cornered by a big tech investment, implementing something that feels like trying to force a round peg into a square hole… Or to put it more bluntly: implementing anti-patterns.
This dynamic is not exclusive to CDPs… it’s a common pattern in the fascinating world of data SaaS products. And I believe just talking and reflecting about it can help a lot of organizations and teams by:
- Elevating internal conversations to push back against oversimplified narratives from vendors and stakeholders.
- Preventing disappointment and technical debt.
- Strengthening the buying process and the negotiation of renewals.
- Improving budgeting, planning, and expectation setting.
- Pushing vendors to build better products and sharpen their value propositions.
- Ultimately, creating long lasting value for companies investing in customer data activation.
In the near future, I’m planning to dig deeper into the idea of the commercial CDP as an antipattern, how to build smarter instead of buying blindly, and share some reflections on managing and optimizing the financial impact of CDPs and related Data FinOps practices.
Looking forward to feedback, beach club stories, vendor groans, and brunch anecdotes.
Note on Vendors
- I’m speaking generally and not naming specific CDPs on purpose.
- The challenges described are common across the category and not tied to one brand.
- Some complexity is simplified to focus on the bigger picture, not technical details.
- More detailed, vendor-specific exploration could be interesting too, but that’s for another day!