What to ask after the demo. Sixteen claims every CEP and CDP pitch makes, decoded into architecture, with the questions that separate a real answer from a slide.
Every CEP and CDP demo repeats the same handful of claims: real-time, composable, agentic, zero-copy. None of them are false so much as compressed: a whole architecture decision folded into a word that sounds finished. This tool doesn't rank vendors or name names; that scoring is procurement's job, and it stays there. What follows unpacks sixteen of the most common claims into what they actually require underneath, where the ambiguity lives, and the three questions that get you past the slide. These are the same claims that show up, vendor by vendor, in Field Notes on CEP, and most cards link to the matching capability on MarTech Ledger, where you can check what each platform has actually released and when. Bring the questions to your next briefing.
The pitch “Our identity graph gives you a single view of every customer.”
Force specificity
Match rate isn't a fixed number, it depends on the identifiers and population behind it. How would you actually validate match rate and false-positive rate against a sample of my own data before I commit?
How do you handle identity merges and splits when a match turns out to be wrong after messages have already gone out?
Can I see the actual matching logic, deterministic keys versus probabilistic scoring, or is that entirely proprietary?
What it actually means
An identity graph is a set of deterministic and probabilistic rules that decide when two signals, a cookie, an email hash, a loyalty ID, belong to the same person. The single view is the output; the graph underneath it is a confidence model with error rates most vendors don't volunteer.
Where it gets fuzzy
A demo identity graph, stitched from a clean sample dataset, behaves nothing like the same graph running against your actual messy, multi-brand, multi-market customer base.
Red flag if the answer is
They quote a single, unqualified match-rate percentage with no mention of which identifiers it's based on.
A credible answer sounds like
They can describe their merge and unmerge process for a bad match in real detail, because it has happened to them before.
The pitch “One unified profile for every customer, across every channel.”
Force specificity
How do you handle a customer who exists in three source systems with three different IDs and no shared key?
When two source systems disagree about the same field, a phone number or an opt-in status, whose data wins, is that precedence rule based on source of truth or event time, and can I reconfigure it myself as ownership changes?
What is the profile refresh latency when a source system updates? How stale can the unified view get, and by how much?
What it actually means
Unification is a claim about identity resolution and schema, not a screen. It requires every source system to agree on what a customer even is, and that is an organisational negotiation as much as a technical one.
Where it gets fuzzy
A demo profile screen pulling cleanly from three sample sources says nothing about whether the platform can reconcile your actual CRM, POS, and app data, each of which may define 'customer' differently.
Red flag if the answer is
They can't describe a conflict-resolution rule and just say "it merges automatically" with no further detail.
A credible answer sounds like
They have a named precedence or survivorship rule for conflicting source data and can show it configured live.
The pitch “We enrich every profile with hundreds of data points, automatically.”
Force specificity
Which of these attributes are directly observed, and which are modelled or inferred? What is the typical accuracy for the modelled ones?
What is the data provenance and legal basis for using each third-party attribute in the markets where I operate?
What happens to a campaign already using one of these attributes when the underlying third-party source changes or goes stale?
What it actually means
Enrichment appends third-party or inferred attributes, demographic, firmographic, intent signals, onto a first-party profile. Provenance and accuracy vary a great deal between attributes, and whether you can legally use a given one depends on its source and your markets.
Where it gets fuzzy
'Hundreds of data points' sounds authoritative, but many enrichment attributes are modelled rather than observed, and the interface rarely tells you which is which.
Red flag if the answer is
They can't distinguish observed fields from inferred ones, or can't say where a given attribute actually originates.
A credible answer sounds like
They hand you an attribute-level dictionary: source, refresh cadence and confidence, per field.
Decisioning & DeliveryWho decides what happens next, and on what evidence.
The pitch “Real-time personalization, out of the box.”
Force specificity
From the moment an event fires, how many milliseconds until a decision is made, and how many more until the message reaches the channel?
Does that number hold for every channel you're selling me, or only for push and in-app, with email and paid still running on a batch sync?
What happens to that latency under peak load, during a flash sale or a seasonal traffic spike?
What it actually means
Real-time is a claim about latency, not a single fixed number. It can mean the profile updates within milliseconds of an event, that the decision itself fires within milliseconds, or simply that a dashboard refreshes faster than the old nightly batch job. Those are three different pieces of architecture, and only one of them ever reaches the customer.
Where it gets fuzzy
A live-updating dashboard is the usual proof in a demo, but a dashboard refreshing quickly says nothing about how fast a triggered message or a decisioning call actually reaches the channel.
Red flag if the answer is
They answer with an aggregate percentage, such as "99% of events processed within X seconds", instead of a latency figure for the specific journey you asked about.
A credible answer sounds like
They give you a measured, per-channel latency figure and can point to a reference client running at close to your volume.
The pitch “AI decides the next best action for every customer, automatically.”
Force specificity
What is the actual fallback logic when the model has no data for a customer, such as a new lead with zero history?
For a specific customer, can I see which inputs, constraints and ranking factors actually drove the decision, and where the suppression logic sits relative to the model's ranking?
Who owns the objective function? When two teams' journeys compete for the same send, whose goal wins, and where is that configured?
What it actually means
Decisioning is an arbitration problem. When five journeys all want to message the same customer today, something has to pick one. AI can rank the candidates, but the rules for what counts as a win, the suppression logic, and the fallback for when the model has no signal are still architecture decisions someone has to own.
Where it gets fuzzy
"AI decides" gets sold as if it removes the need for a decisioning framework. In practice it only moves the ranking step into a model; the arbitration rules around it still need an owner.
Red flag if the answer is
"It just learns and optimises itself" is the entire answer, with no mention of which inputs or constraints actually shape a given decision.
A credible answer sounds like
They walk you through a specific arbitration example, two journeys competing for one customer, and can point to the exact inputs, constraints and suppression rule that decided it.
The pitch “Agentic AI that plans and executes campaigns on its own.”
Force specificity
Walk me through an actual multi-step sequence the agent completed with zero human approval, from goal to executed action.
Where are the guardrails? What can the agent never do without sign-off, and who configures that boundary?
When the agent gets it wrong, how do I find out, and how far downstream does the damage travel before anyone notices?
What it actually means
Agentic implies multi-step autonomy: the system sets a sub-goal, chooses an action, observes the result, and adjusts, without a human approving each step. That is a different thing from a copilot that drafts a campaign for a human to approve, and different again from workflow automation that runs a fixed sequence once triggered. The real question is where delegated execution authority actually sits, and most 'agentic' features on the market today are one of the first two, wrapped in the third's language.
Where it gets fuzzy
The gap between "generates a campaign brief" and "plans and executes a multi-step journey with no human checkpoint" is the whole question, and a demo rarely makes it visible.
Red flag if the answer is
The 'agent' turns out to be a single generative-AI content step bolted onto an otherwise rule-based journey.
A credible answer sounds like
They show a clearly defined guardrail boundary and an audit trail of what the agent decided and why.
The pitch “True omnichannel orchestration: every channel working together in real time.”
Force specificity
If a customer converts through email, does an in-flight SMS or push step in the same journey know within seconds, or does it send anyway?
Is frequency capping and channel priority computed once across all channels, or configured separately per channel with no shared view?
Can you show one customer's full cross-channel touch history on a single timeline, not per-channel logs stitched together afterward?
What it actually means
Omnichannel implies a shared decisioning and state layer across channels: what happens on email should be visible to push, SMS and in-app within the same journey. Multichannel, the older pattern most platforms actually run, fires each channel from the same trigger but keeps them independent afterward.
Where it gets fuzzy
A demo showing email, push and SMS firing from one trigger looks omnichannel. Whether the platform notices a customer converted on one channel and stops the others is a separate, much harder claim.
Red flag if the answer is
The demo only shows channels firing in parallel from one trigger and never a case where one channel's outcome changes another's.
A credible answer sounds like
They walk through a real cross-channel suppression example: an action on one channel visibly stops or reshapes what happens on another.
The pitch “Our AI predicts churn and propensity before it happens.”
Force specificity
What exact outcome was the model trained to predict, and how was that label defined?
Can I see accuracy or lift measured on a cohort from my own business, not your reference dataset?
How often does the model retrain, and what happens to live scores while a retrain is running?
What it actually means
A predictive model outputs a probability score trained against a specific historical outcome. Its usefulness rests entirely on how that outcome was labelled, how recent and representative the training data is, and what action actually fires when a score crosses a threshold.
Where it gets fuzzy
An accuracy figure in a vendor deck describes their training set, not your customer base. 'Predicts churn' also implies more certainty than a probability score actually carries.
Red flag if the answer is
They can't state the training label precisely, or can't share any performance figure measured on data resembling mine.
A credible answer sounds like
They give a concrete lift or precision figure on comparable data and can explain the retraining cadence in detail.
The pitch “Composable architecture: no vendor lock-in.”
Force specificity
If I stop paying you tomorrow, where does my customer profile data live, and can I export it in a format another tool can read without a migration project?
Which parts of your platform can I actually replace with a competitor's component, and which are load-bearing and non-negotiable?
Do you charge separately for the components I don't use, or is 'composable' a suite priced under a new label?
What it actually means
Composable, in the strict MACH sense (Microservices, API-first, Cloud-native, Headless), means every capability is a separately deployable service you can swap out. In practice, most platforms sell a suite with better APIs and call the whole thing composable.
Where it gets fuzzy
A platform can be thoroughly API-first and still hold your customer profile hostage inside its own proprietary store, which is exactly the lock-in composability is supposed to remove.
Red flag if the answer is
The honest answer to "what can I replace" is "nothing, really", but the deck still leads with composable.
A credible answer sounds like
They can name, specifically, which of their own modules a real client has already swapped out for a competitor's.
The pitch “Zero-copy integration: activate straight from your warehouse, nothing duplicated.”
Force specificity
At the moment a message sends, are you querying my warehouse live, or activating against a copy you synced earlier? How stale can that copy get?
What is the query latency and cost impact on my warehouse when your platform activates at my actual send volume?
If I revoke your warehouse access right now, does personalization stop immediately, or keep running off a cached copy?
What it actually means
True zero-copy means the query itself runs against the warehouse at the moment a message sends. Many integrations sold under that name still sync a working copy of the audience into the platform's own store on a schedule, which functions like reverse ETL with a friendlier name. A smaller group sit in between: an in-memory cache held only for the duration of one activation and discarded right after, which is architecturally much closer to true zero-copy than a copy that persists and refreshes on a timer, even though both technically touch a second location for a moment.
Where it gets fuzzy
The distinction matters because a synced copy drifts from the warehouse and creates a second place governance has to reach, exactly what zero-copy is meant to avoid.
Red flag if the answer is
'Zero-copy' turns out to mean a sync job that runs every fifteen minutes instead of overnight.
A credible answer sounds like
They can state exactly what stays in the warehouse, what, if anything, gets cached, and for how long.
The pitch “Native integrations with every platform you already use.”
Force specificity
Who built and maintains this specific integration, your team or the other vendor's, and when was it last updated?
Does this integration expose the other platform's full object model with real-time, two-way webhooks, or does it poll a limited subset of fields on a schedule?
Can I see this integration running in a live customer environment at roughly my scale, not just in a sandbox?
What it actually means
'Native' should mean a maintained, first-party connector built and supported by the vendor. Sometimes it means a generic webhook template, or a connector built once for a sales demo and never touched again.
Where it gets fuzzy
The word papers over a real spectrum, fully managed and versioned, community-maintained, or a one-off proof of concept, all displayed as the same logo on the same integrations page.
Red flag if the answer is
'Native' turns out to mean a generic REST webhook with the other vendor's logo added to a slide.
A credible answer sounds like
They can name the maintaining team, the last update date, and a reference client running it in production.
The pitch “Collaborate with partners in a privacy-safe clean room, no raw data ever leaves your walls.”
Force specificity
What is the smallest aggregate size, the k-anonymity threshold, you allow a query to return, and who enforces it?
Can either party ever export row-level matched data out of the clean room, under any workflow?
Who has audited this, and can I see the audit, or is 'privacy-safe' a description you apply to yourselves?
What it actually means
A clean room's actual guarantee lives in its query restrictions: the aggregation threshold it enforces, and whether row-level data can ever be exported. Those specifics vary a lot between vendors, more than the reassurance on the slide usually lets on. A threshold that holds for any single query can still be defeated by running many overlapping ones and comparing the results, so the real protection is in how the platform limits or monitors that pattern, not just the minimum group size on paper.
Where it gets fuzzy
"Privacy-safe" sounds like a fixed, audited standard. It's an implementation choice, and some clean rooms permit far more row-level exposure than others.
Red flag if the answer is
There's no stated minimum aggregation threshold, and they can't name an independent audit.
A credible answer sounds like
They can state the exact aggregation threshold and point to a real audit or certification, not a marketing claim.
The pitch “Consent is enforced everywhere, automatically, the moment someone opts out.”
Force specificity
When someone withdraws consent, how long before that change is enforced across every downstream export and integration, not just the next campaign send?
Can you show consent status at the level of a specific processing purpose and channel, or is it one global opt-in and opt-out toggle?
What happens to data already synced to a downstream partner before the withdrawal, can that be pulled back, or does the change only stop future syncs?
What it actually means
Enforcement means a consent change propagates to every downstream system and channel within a bounded, known time, not just the next campaign send. The real architecture question is what "everywhere" actually covers: ad platform syncs, enrichment vendors, analytics exports, and channel-specific rules that vary by market.
Where it gets fuzzy
A demo showing one email suppressed after an opt-out says nothing about whether that signal reaches an ad platform sync already queued, or whether SMS and WhatsApp, which often carry separate consent requirements by market, actually honour the same change.
Red flag if the answer is
The honest answer is that consent is checked at send time only, and data already shared with downstream partners keeps circulating on the old consent until their own next batch job.
A credible answer sounds like
They can show a consent change propagating to a specific downstream export within minutes, and explain plainly what happens to data already shared before the change.
The pitch “Full data residency: your data never leaves the region, sovereign cloud guaranteed.”
Force specificity
Which specific data flows, storage, processing, backups, support access, are actually confined to the promised region, and which aren't?
Do you use subprocessors or global support teams who can access this data, and where are they located?
What does the residency guarantee say in the contract, versus what's said in this conversation?
What it actually means
A residency claim is about where data is physically and legally stored. It says nothing on its own about processing, backups, subprocessors or support access, all of which can route through infrastructure outside the promised region unless explicitly scoped in.
Where it gets fuzzy
'Never leaves the region' usually describes primary storage. Processing steps, backups and the support engineer who can access the account are a separate question the same sentence doesn't answer.
Red flag if the answer is
The residency claim covers primary storage only, and processing, backups or support access are left unaddressed.
A credible answer sounds like
They provide a data flow diagram showing exactly which systems and regions touch the data, end to end.
The pitch “No-code journey builder: marketers build campaigns without IT.”
Force specificity
What is the most complex journey a marketer, with no engineering support, has actually built and shipped on this platform?
When something breaks, an empty segment, an event that never fires, who debugs it, do they need engineering to do it, and can a marketer version, roll back or safely promote a change without breaking a live journey?
How do you prevent a marketer from building a suppression rule that accidentally contradicts a consent requirement?
What it actually means
No-code removes the need to write code for the common path. It rarely removes the need for someone who understands data schema, event definitions, and suppression logic, which is architecture knowledge whether or not it's ever expressed as a script.
Where it gets fuzzy
A clean drag-and-drop canvas in the demo hides how much of the underlying data model a marketer still has to understand correctly to avoid sending the wrong message to the wrong segment.
Red flag if the answer is
The honest answer is that every non-trivial journey still routes through an implementation team, no-code or not.
A credible answer sounds like
They point to a specific, non-trivial journey a marketer built and maintains solo, and can describe how that person debugs it.
The pitch “Full observability into every journey, you'll always know exactly what happened and why.”
Force specificity
For one specific customer, can you show the full decision trail, which journey, which branch, which data value tipped it, at the exact moment a message sent?
How far back does that trace history go, and does it survive a schema change or a journey edit made after the fact?
When a customer gets the wrong message, how long does it typically take your own team to reconstruct what actually happened?
What it actually means
Observability means reconstructing, after the fact, why one specific customer got, or didn't get, one specific message: which segment they matched, which journey branch fired, and what data was actually available at the moment of the decision. Aggregate journey dashboards, the thing most demos show, are a different and much shallower capability.
Where it gets fuzzy
A dashboard full of funnel and conversion metrics looks like observability, but it rarely answers the question that actually matters during an incident, why did this one customer get this one message, or why didn't they.
Red flag if the answer is
They can only show aggregate journey performance dashboards, and admit that reconstructing one customer's specific path takes a ticket to their own support team.
A credible answer sounds like
They pull up a real customer's full decision trail live, in front of you, in under a minute.
The platform changes that actually move architecture, once a week. No noise.
Weekly
Release notes decoded
For MarTech architects
No spam. Just one email per week.
This site uses third-party analytics cookies to understand how visitors interact with content. They are set only if you consent. See the Cookie Policy for details.