---
title: "Signals vs a CDP | Snowplow Signals"
description: "A CDP unifies who someone is and pushes audiences to marketing tools. Signals computes what they are doing now and serves it in-request. Most teams keep both."
source: https://signals.snowplow.io/evaluate/cdps
---

[Evaluate](https://signals.snowplow.io/evaluate) / Signals vs a CDP 

# 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.

[Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) 

The short answer

1. 01  
A CDP is a marketing activation system. Its unit of work is an audience, and its clock is minutes to hours.
2. 02  
Signals is a context layer for software. Its unit of work is an attribute, and its clock is milliseconds.
3. 03  
They overlap on the words, not on the job. Asking a CDP to sit in a render path is the usual mistake.

Most teams that adopt Signals keep their CDP.

Side by side

## 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         | <1s from the event to the attribute being current, then 6ms to read it.            | 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.                                |

Generalized from published capabilities of major CDP vendors · verify against the specific product in your evaluation

Choose Signals when 

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.

Choose a CDP when 

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.

They coexist well

## Keep the CDP. Add the layer it was never built for. 

Pattern 01 

### Shared collection

One validated event stream feeds both. The CDP gets its profiles; Signals computes live attributes off the same events.

Pattern 02 

### Signals in the product, CDP in the channel

The storefront and service desk read Signals. Campaigns keep running from the CDP.

Pattern 03 

### Triggers into the CDP

A Signals trigger fires the moment a condition is met and hands the moment to your existing activation stack.

<1s 

Event in to attribute updated

6ms 

Read latency, p50 in-region

any key 

Not limited to a resolved person

1 definition 

Live surface and model history agree

0 rip-outs 

Runs alongside the CDP you already have

Objections worth raising

## 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.

[Start free](https://signals.snowplow.io/start) [Talk to an engineer](https://signals.snowplow.io/start?intent=engineer) 

The real engine · no card · no sales call Also in Evaluate: [Signals vs a feature store](https://signals.snowplow.io/evaluate/feature-stores), [Signals vs building it yourself](https://signals.snowplow.io/evaluate/build-vs-buy), [Signals vs Tecton](https://signals.snowplow.io/evaluate/tecton), [Signals vs Feast](https://signals.snowplow.io/evaluate/feast), [Signals vs Chalk](https://signals.snowplow.io/evaluate/chalk), and [pricing →](https://signals.snowplow.io/pricing)