Put two customer data platform demos side by side. Both decks say "real-time." Both say it on the homepage, in the analyst slide, in the answer to your first question. One of them, when a shopper adds a 400 dollar item and stalls at checkout, can change what that shopper sees on the next page in about a third of a second. The other one, behind the same word, runs a job that gathers the day's events and rebuilds profiles overnight. By the time it knows about the abandoned cart, the shopper is asleep.
Nothing in the word "real-time" tells you which one you are looking at. There is no standard behind it, no certification, no agreed number of milliseconds. The CDP Institute's vendor directory lists more than 25 platforms that describe themselves as real-time, and practitioner write-ups are blunt that the term gets stretched to cover anything from milliseconds to hours. That range is not a rounding error. It is the difference between a CDP that can run in-session personalization and one that cannot, sold under identical language.
This piece takes the phrase apart. Real-time is not one property of a CDP. It is at least four separate latencies, and a platform can be fast on one and slow on the rest while still, technically, calling itself real-time. Once you can name the four, you can test any claim in a demo instead of trusting it.
Where the phrase came from, and why it slipped
The CDP exists to solve a timing problem the systems before it could not. A data warehouse is built for analysis, not for reacting; data lands, sits, and gets queried later. A campaign tool of the 2010s worked in scheduled sends and overnight list pulls. As more of the customer relationship moved to live digital surfaces, the website, the app, the in-session moment, that scheduled cadence started to lose money. McKinsey's work on data activation found that trigger-based messages, the ones that fire off a fresh customer signal, lifted email open rates from the 10 to 15 percent range of generic targeted sends to 25 to 35 percent. Speed was not a feature. It was the point.
So vendors competed on it, and the language inflated. The clearest illustration is a lawsuit. In 2023 Salesforce was sued by Karl Wirth, co-founder and former chief executive of the personalization company Evergage, which Salesforce had acquired and folded into the product launched at its 2022 Dreamforce conference as Genie, later Data Cloud. Wirth's whistleblower retaliation complaint alleges that Salesforce planned to market Genie as operating in real-time when, by his account, core operations that should have completed in milliseconds were taking hours. He alleges he raised it internally as likely securities fraud and was removed days before the launch. Salesforce has denied wrongdoing, and in 2024 a federal judge declined to dismiss the suit, letting it proceed. Set the legal merits aside; the case is useful because it shows the gap is not theoretical. A platform can put "real-time" on the main stage while parts of it run on a batch cadence.
The four latencies hiding inside one phrase
A customer event has to travel a long way before it changes what a customer experiences. Picture it as a pipeline. Each stage adds its own delay, and "real-time CDP" almost never specifies which stage it describes.
One: ingestion latency. How fast does the event arrive in the platform at all? A CDP that streams events, accepting each one as it happens through an API or SDK, has low ingestion latency. A CDP that imports events in scheduled file loads has already lost minutes or hours before the event is inside the system. This is the stage vendors most love to call real-time, because streaming ingestion is genuinely common and genuinely fast. It is also the least meaningful on its own.
Two: profile update latency. The event is in. How long until the unified customer profile actually reflects it? This is where identity resolution happens, the stitching of an anonymous session to a known person across devices. Identity matching, especially the probabilistic kind, is heavy work and frequently runs in batches. An event can be ingested in a second and still not touch the profile for hours, because the identity job that would attach it has not run yet.
Three: segment recomputation latency. The profile is updated. But your campaigns target segments, not raw profiles, and a segment is a query: "added to cart, no purchase, value above 200 dollars." For the updated profile to qualify, segment membership has to be recomputed. This is the stage most often quietly batched. Segment evaluation commonly runs on a schedule, sometimes hourly, very often nightly. A profile can be bang up to date and still sit outside the segment that would trigger the message, because the segment will not be re-evaluated until 2 a.m.
Four: activation latency. The profile qualifies for the segment. Now the CDP has to push that fact to the place that acts on it: the email platform, the ad networks, the website personalization engine, the contact centre. Every destination has its own delay. Some accept a live API call, some a batch file every few hours. A perfectly fast CDP feeding a destination that only ingests hourly is, from the customer's point of view, an hourly CDP.
The principle that ties these together is the most useful idea in this debate: the system is only as fast as its slowest link. If any one of the four stages runs in batch, the whole pipeline is batch, no matter how fast the other three are. A CDP can stream ingestion in milliseconds, resolve identity in milliseconds, and still be a six-hour CDP because segments recompute overnight. The vendor is not necessarily lying when they say "real-time." They are describing stage one and letting you assume the rest.
The distinction that matters most: ingestion versus activation
Of all the blur, one split does the most damage when missed. Real-time ingestion and real-time activation are different claims, and a vendor can honestly hold the first without holding the second.
Real-time ingestion means events flow in continuously. Real-time activation means a fresh event can change a live customer experience before that experience is over. The first is plumbing into the platform. The second is the platform changing the outside world. Streaming ingestion is now close to standard. Genuine end-to-end activation, where every later stage is fast enough to beat the customer's attention span, is rare and expensive.
When a demo says "real-time," the question that cuts through is which one they mean. Watch for the proof, not the adjective. A vendor showing you a live event landing on a dashboard has proven ingestion and nothing else. A vendor showing you an event change a person's segment membership and then change what a second screen displays, end to end, while you watch, has proven activation. Most demos show the first and let you feel you have seen the second.
A useful real example: how Adobe labels its own tiers
The most honest thing in this market is that some platforms publish their own latency tiers, which both proves the spectrum is real and gives you a vocabulary. Adobe's Real-Time CDP offers three methods of evaluating a segment, and they are not close in speed.
Edge segmentation is the fast tier, built for same-page and next-page personalization, and per Adobe's documentation it can take up to roughly 350 milliseconds for an inbound event to qualify a profile. Streaming segmentation is the middle tier, aimed at same-session and same-day intent, and it can take up to about 5 minutes. Batch segmentation is the slow tier: every segment is also evaluated against every profile in a scheduled job that runs nightly.
Read that again, because it is the whole article in one product. The same platform, under the same brand name "Real-Time CDP," contains a 350-millisecond path and a once-a-night path. Which one a use case lands on depends on how the segment is built; complex logic often cannot run on the fast tier. This is not a criticism of Adobe. It is the opposite. Adobe is being unusually clear about a spectrum that most of the market leaves as a single fuzzy word. The lesson for a buyer is that "does your CDP do real-time" is the wrong question even for a platform that genuinely does. The right question is which tier my specific use case will run on.
Which use cases actually need true real-time
Here is the part that saves money. True sub-second, end-to-end real-time is hard and costly to run, and most marketing work does not need it. Paying for it everywhere is a common, expensive mistake. The deciding test is simple: is the customer still in the moment? If acting late means acting after the window has closed, you need real-time. If acting an hour or a day later is just as effective, you do not.
Genuinely needs true real-time, because the window is open and short:
- In-session web and app personalization. Changing the next page based on what the visitor just did only works inside the session. After it ends, the chance is gone.
- High-intent cart and checkout abandonment. The recoverable moment is minutes wide. A reaction that arrives the next morning is a different, weaker tactic.
- Real-time suppression. Someone just bought the product, or just opted out. If the segment does not update fast, you pay to advertise a thing they own, or you message someone who told you to stop. That is wasted spend and a trust cost at once.
- Triggered transactional and service moments. An order confirmation, a fraud alert, a delivery update. Lateness here is not a missed optimisation, it is a broken experience.
Does not need true real-time, and forcing it just raises the bill:
- Audience building for paid media. For ad platform audiences, completeness and clean identity matching matter more than latency, and waiting for fuller enrichment can produce better match rates than syncing fast and half-formed. Daily or even weekly is fine.
- Lifecycle and nurture email. A welcome series measured in days does not get better by recomputing its segments every five minutes.
- Churn and lifetime-value scoring. These models read long-range history. Refreshing them nightly is standard.
- Most reporting and analysis. Decisions made over weeks do not need data seconds old.
Map your own use cases onto that split before you talk to a vendor. The output is a single requirement: how fast do my fastest few cases need to be, and how fast are the rest comfortable being. That requirement is what you take into the demo, instead of the word.
The questions that pin a vendor down
You cannot test a claim with the question "is it real-time," because the honest and the evasive answer are the same word. You test it by forcing specifics.
Make them run your fastest use case end to end, live. Not a recorded scenario, not ingestion alone. Pick your hardest case, in-session personalization or high-value cart abandonment, and ask them to trigger a real event and show it travel all the way to a changed customer experience while you watch.
Ask for the number at each of the four stages, separately. Ingestion latency, profile update latency, segment recomputation latency, activation latency. A vendor who can quote four numbers understands their pipeline. A vendor who keeps answering with one word is hiding the slow stage.
Ask specifically how often segments recompute, and whether that is configurable. This is the stage most often batched. If segments re-evaluate nightly or hourly, no amount of streaming ingestion makes the platform real-time for a triggered use case. Find out whether a fast evaluation tier exists and what limits apply to it.
Ask them to prove it in two channels at once. Cross-channel timing is where real-time quietly fails. Ask to see an event update onsite content and suppress a paid audience together. If the website reacts instantly and the ad platform catches up tomorrow, you have found the ceiling.
Ask where delays come from, by name. Identity matching, consent checks, segment computation, destination sync. A credible vendor will name their own bottleneck without flinching. A vendor who says there are no delays is the one to distrust.
Ask what happens under load. Does time-to-action hold when traffic spikes on a sale or a launch day, when real-time matters most? Or does the pipeline slow precisely when you are leaning on it?
Ask what the marketer sees when something lags. Can the team see that an audience is stale, with a timestamp on the last update, or do they only find out when results drop? Observability into latency is itself a feature, and its absence is a warning.
A platform that answers all of these with concrete, consistent specifics is probably as fast as it says. A platform that keeps retreating to the adjective is telling you, without meaning to, where the batch job is hiding.
Where this is heading
The phrase is about to be tested harder, because the next thing reading the customer profile is not a person, it is an AI agent. A marketer building a segment can tolerate a profile that is an hour stale and never notice. An agent deciding and acting on the profile continuously cannot; stale context produces a wrong action at machine speed and machine volume. As agentic CDPs move from pitch to production, "real-time" becomes a hard engineering requirement that the slow stages, batched identity and nightly segment jobs, will openly fail to meet.
"Real-time" was never one thing a CDP either has or lacks. It is a pipeline of four latencies, only as quick as its slowest link, and the buyer's job is to find that link before signing, not after the cart-abandonment program underperforms for a quarter. The spectrum is real, it runs from sub-second to overnight, and it hides behind a single word. You cannot make the word mean less. You can refuse to accept it without the four numbers behind it.
Council summary
The post argues that "real-time CDP" is not one property but four separate latencies, ingestion, profile update, segment recomputation, and activation, and that a platform can be fast on one while slow on the rest and still claim the label. The fix it hands the reader is concrete: map use cases to whether the customer is still in the moment, then pin vendors down with stage-by-stage numbers and a live end-to-end test. Council checks confirmed the load-bearing facts: the Adobe tiers of roughly 350 milliseconds for edge, up to 5 minutes for streaming, and nightly batch match Adobe's documentation, and the McKinsey open-rate figures of 10 to 15 percent against 25 to 35 percent are accurate. The Salesforce section was tightened so the whistleblower claims read clearly as allegations, with the verified detail that a federal judge declined to dismiss the suit in 2024. The takeaway holds: do not accept the word without the four numbers behind it.
Comments