The CDP Went Live. Why Is Marketing Still Using the ESP?
08 Aug 2026
The CDP Went Live. Why Is Marketing Still Using the ESP?
The go-live was a success. The steering committee signed it off, the vendor published a case study, and the data landed. Eighteen months later the marketing team is still pulling segments out of the email platform, the CDP's run cost is climbing, and nobody can say what it is for.
This is the most common outcome we see, and it is not a failure of the software. It is what happens when a data engineering and operating model project is run as a software installation. The platform did what it was configured to do. Nobody configured the parts that would have made it useful.
The four things that were never designed
The use cases. Most programmes start from the data: what sources exist, what fields they have, how to get them in. The use cases come later, on the assumption that once the data is unified, marketing will find things to do with it. They do not, because a resolved customer record on its own is not a campaign. What should have come first is a short list of things the business will do differently once the data exists, each with a number attached, and the data model built backwards from those.
The identity rules. Every CDP resolves records into people, and every one does it according to rules somebody chose: which identifiers count, which win when they conflict, what happens to a guest checkout and a loyalty account with the same email. Those rules decide who your customers are. In most stalled programmes they were set by the implementer from defaults, nobody in marketing can explain them, and the segments built on top are quietly wrong in ways that surface only when a customer complains about being emailed as two people.
The data contracts. A CDP is fed by other systems, and those systems change. The ecommerce platform adds a field, the app renames an event, the loyalty vendor changes an export format. Without a written agreement about what each source sends, in what shape, and who is told when it changes, the pipelines break silently and the first sign is a segment that stopped growing three months ago.
The run model. Somebody has to watch the pipelines, handle the upstream changes, evolve the use cases and keep an eye on cost. In a stalled programme that person was the implementation partner, who left at go-live, or a data engineer who has since moved on. Marketing owns the outcomes and cannot see the plumbing. The data team owns the plumbing and does not own the outcomes.
How to tell you are there
You probably already know. But the specific signs are these:
Campaign segments are still built in the email platform, or in a spreadsheet, because the CDP's segments "are not quite right".
Nobody in the marketing team can describe the identity rule for what makes two records the same customer.
The CDP run cost has risen without anyone deciding it should. Workflows run more often than the use case needs, full recomputes happen where incremental would do, and events are collected at maximum granularity because no retention policy was ever set.
The platform team and the marketing team do not share a backlog. Requests go one way and estimates come back the other.
The vendor relationship is now about licence renewal rather than about what to build next.
If three of those are true, the programme has stalled, whatever the dashboard says.
How to recover
The instinct is to replatform. That is almost always wrong. The platform is rarely the problem, and a second implementation run the same way produces the same result at twice the cost.
What works is smaller and less glamorous:
Pick two or three use cases with money attached. Existing-customer suppression in paid media. A replenishment journey for a category with a known repurchase cycle. Lapse-risk flags for the loyalty base. Things a commercial owner will notice if they work.
Wire them properly, end to end. Not "the segment exists in the CDP" but "the segment reaches Meta, is refreshed daily, and the campaign is live against it". Most stalled programmes have segments that exist and never travel.
Measure the lift with a holdout. A control group that does not receive the treatment, so the result is evidence rather than a claim. This is the part that funds the next set of use cases, because it turns the CDP from a cost centre into something with a number beside it.
Write the identity rules down in a form marketing can read, and change the ones that are wrong. This usually takes a workshop, not a project.
Decide who runs it. Either your team takes it over, with documentation, training and a written run book, or you keep a partner on managed support with a defined remit: pipelines, upstream changes, use case evolution, cost. What does not work is leaving it to whoever has time.
The point
A CDP that marketing uses every week and a CDP that marketing routes around look identical in the vendor's dashboard. The difference is entirely in whether the use cases, identity rules, data contracts and run model were designed, and those are the four things a software installation does not include.
If you are about to start one, put them first. If you have one that stalled, they are where to look, and they are recoverable without starting again.
