A CDP unifies who someone is. Signals answers what they are doing now.
Customer data platforms are built to resolve identity and push audiences to marketing destinations. Signals is built to compute attributes on the event stream and hand them to your application inside a request.
Different job, different clock.
| Dimension | Signals | Typical CDP |
|---|---|---|
| Primary consumer | Your application code: renderers, rankers, agents, service tooling. | Marketing and lifecycle tools: email, ads, messaging. |
| Unit of work | An attribute, keyed on any entity you choose. | A segment or audience, keyed on a resolved person. |
| Freshness | Recomputed on the event stream, read in single-digit milliseconds. | Minutes to hours, depending on the sync and the destination. |
| Entity model | user · session · account · basket · listing · store. Identity resolution optional. | A unified customer profile. Identity resolution is the product. |
| Read interface | An API call in your request path, or a trigger when a condition is met. | Destination connectors and reverse ETL syncs. |
| Data model | Schema-validated events, yours, landing in your warehouse. | Often a proprietary profile store you query through their UI. |
| Who configures it | Engineers, in code, versioned. | Marketers, in a segment builder. |
Generalised from published capabilities of major CDP vendors · verify against the specific product in your evaluation
The consumer is a product surface that has to render in under a second.
You need to key on something that is not a person.
The same definition has to feed a live surface and a trained model.
Engineers, not marketers, own the logic and want it in version control.
Identity resolution across channels is the problem being solved.
Marketers need to build and ship audiences without engineering.
The output is a campaign in an email, ads or messaging tool.
Consent and preference management across destinations is central.
Keep the CDP. Add the layer it was never built for.
Shared collection
One validated event stream feeds both. The CDP gets its profiles; Signals computes live attributes off the same events.
Signals in the product, CDP in the channel
The storefront and service desk read Signals. Campaigns keep running from the CDP.
Triggers into the CDP
A Signals trigger fires the moment a condition is met and hands the moment to your existing activation stack.
Read latency, p50 in-region
Not limited to a resolved person
Live surface and model history agree
Runs alongside the CDP you already have
The questions your architect will ask.
Does Signals replace our CDP?
Rarely. It replaces the part of the CDP you were trying to use in a request path, which it was not designed for.
Can Signals do identity resolution?
It can key on a resolved id if you have one, but it does not require it. Session, basket and listing keys need no identity graph.
Can marketers use it?
Definitions are written by engineers. Triggers can hand moments to the tools marketers already use.
Where does the data live?
Your warehouse. Events are schema-validated on the way in and remain yours.
Test the claim on your own events.
Define one attribute, read it from your product, and compare the latency to whatever you run today. 14 days, no card, no sales call.
Also in Evaluate: Signals vs a feature store, Signals vs building it yourself, and pricing →