Schedule a Demo of Our Services
Complete the form below and we will be in touch shortly to schedule your demo.
Six Data Decisions That Make or Break a Real-Time CDP Project
|
Share This :
Nobody buys a Real-Time CDP for its data model. They buy it for the audiences: segments that update the moment a customer acts and reach every channel at once. And that part works. But whether those audiences are right depends on what sits underneath: the data decisions made long before anyone builds one.
Bad data rarely looks like bad data. It looks like a campaign that underperformed, a sales team that stopped trusting the alerts, or a complaint from a customer who unsubscribed months ago and is still getting emails. By the time someone traces it back to the data, the platform has already taken the blame.
This year I saw it from two sides. Preparing for the Real-Time CDP Expert exam, I noticed that less than a third of it is about building and activating audiences. The rest is about the data: how it’s modeled, how identities come together into one profile, how it gets in, how it’s governed, and how it’s monitored. At the same time, I was working on the data side of an enterprise client’s move to a new marketing automation platform, and the same questions kept coming up there too.
These are six lessons that came out of both. If you’re planning a real-time CDP implementation or moving customer data between any two systems, they’ll save you a few painful surprises.
Decide who is who before you load anything. Email is the key everyone reaches for, and it only works until it doesn’t. In a recent client project, two brands share many of the same contacts. One person can download a guide from one brand’s website with a work email and read every issue of the other brand’s newsletter on a personal email. Matched on email alone, that’s two people, and each brand sees half the story. It gets harder still in companies that grew by acquisition and run a separate CRM in each region, where the same customer can sit in several systems with no shared key. No setting fixes that, which is why the CDP certification exam spends so much time on identity strategy. Someone has to decide which identifiers count, which one wins when they disagree, and when two records are close enough to treat as one person. Everything built on top inherits that decision.
Agree on field names before any data flows. Every source writes to the schema and every destination reads from it, so small differences travel far. We had one system calling a field Department and another calling it Department. To a person, that’s the same field. To a data feed it isn’t, and that one capital letter broke the feed without raising an error. Data modeling is one of the biggest sections of the exam, and this is why. Build on standard fields where you can, keep one list of field names that all teams work from, and treat a schema change like a code change.
Make opting out stick. Consent rarely lives in one place. A preference center writes to one system, a CRM sync carries its own opt-out flag, and a warehouse feed can overwrite both. That’s how someone who asked to stop hearing from you ends up back on a list. Our rule on that project was simple: a feed can set an opt-out but never remove one, so no sync can put them back. It also helps to name one system as the owner of consent and have the rest follow it.
Don’t trust a click until you know who clicked. Email security tools open messages and click links before anyone reads them, so “clicked an email” can simply mean a scanner did. If those clicks feed a score or a sales alert, someone ends up calling a person who never read the email. Platforms now flag suspected bot activity, but a flag only helps if someone decides whether it counts. We report clicks with and without flagged bot activity side by side, so nobody mistakes a scanner for interest.
Find your slowest source. Web behavior can stream in within seconds, while CRM updates and email engagement often arrive in daily batches. In that same project, engagement data lands in the warehouse once a night, so anything that uses it is a day behind. That’s fine as long as everyone knows it. The exam gives ingestion a whole section for this reason: how data gets in sets how real-time anything can be. Show how fresh the data is wherever it’s used, so nobody promises same day follow-up on yesterday’s data. Real time is only as fast as the slowest source.
Check the count, even when nothing fails. We once requested a full folder list, and it came back with 33 folders. It was supposed to return 359. Nothing “failed” in a strict sense of the word. A default setting only looked a couple of levels deep, so the number was just wrong, and it would have stayed wrong in every report built on it. What protects you is a habit: pick the numbers that matter, like total contacts, opt-outs, and yesterday’s activity, and compare them from one system to the next every time data moves. The worst data problems don’t fail loudly. They quietly give you the wrong number.
None of this means waiting for perfect data. The better move is a first use case that tests all six at once. A good one: a known contact visits the same solution area twice in a week, joins an audience, gets relevant content, and their account owner gets a heads-up. Behind that flow, you have to know who the contact is, the fields have to line up, they have to be allowed to hear from you, the visits have to be real, the data has to be fresh enough to act on, and the counts have to add up. It’s small enough to ship and wide enough to show where the data still needs work.
The exam showed me where to look. The client project showed me why it matters. Nobody buys a Real-Time CDP for its data model, but that’s what decides whether it was worth buying. Audiences are only the tip of the iceberg. The data underneath is the real project.