Customer Data Platform (CDP) Architecture: Ingestion, Identity, Decisioning, Activation

A customer data platform (CDP) architecture has three layers. Ingestion collects events and consent state from every source and checks them against a contract. Decisioning resolves identities, builds segments and chooses actions. Activation delivers those actions to channels and writes an audit record. The same design runs as multi-tenant SaaS, vendor-managed single tenant, inside your VPC, or on-premise; what changes is who holds keys, egress and support access.

Who this is for: architects, security leads and marketing-operations owners who need a vendor-neutral reference before an RFP or design review. You get the layers, event contract, data model, deployment trade-offs and an acceptance test. Part of the Learn hub.

How does a CDP work?

The CDP Institute defines a customer data platform as software that creates and maintains a persistent, unified customer record other systems can access, delivered as a package or composed from parts such as a data warehouse 1. In practice a CDP does six jobs, in order:

1. Collect events and records from websites, apps, core systems, call centres and files.
2. Validate each against a contract; reject or quarantine what does not conform.
3. Unify identifiers into profiles.
4. Decide which audiences and actions apply, using rules, models or both.
5. Deliver decisions to channels and downstream systems.
6. Record what happened, and why, in a form an auditor can replay.

Most architecture arguments (packaged or composable, SaaS or self-hosted) are about where these jobs run and who operates them. For the category comparison see CDP vs CRM vs DMP vs MDM vs data warehouse; for basics, What is a customer data platform?.

Customer data platform architecture diagram: the three layers

Every serious CDP, packaged or composable, contains all of these parts, whether it ships them or you assemble them.

Layer 1: ingestion

Data enters four ways: SDKs for browser and app behaviour; a server-side HTTP API; streams (Kafka-style topics or change data capture); and batch files or warehouse syncs for CRM, core-banking or EHR extracts. All four should end at one gate: validation against a registered schema. Snowplow, for example, defines events as self-describing JSON Schemas in a registry, validates every event and sends failures to a separate location instead of discarding them 2.

Two feeds deserve their own lanes. The identity feed carries identifiers and the links between them (logins, CRM keys, device IDs). The consent feed carries consent changes, withdrawals and suppression entries from preference centres and call-centre tools. Neither should queue behind clickstream: a withdrawal stuck for six hours is a compliance defect, not a performance issue.

Layer 2: decisioning

The identity graph links identifiers into profiles; see the identity resolution explainer. Segmentation runs in two modes: streaming evaluation updates membership as events arrive and powers triggers, while batch evaluation recomputes large audiences over full history. You need both, and a batch recompute should reproduce the streaming result for the same data.

The decision engine chooses actions. An auditable split is that models produce scores and rules apply policy (eligibility, consent, frequency caps) to them. If a model decides credit, or life or health insurance pricing, the EU AI Act treats the system as high-risk under Annex III 3; real-time decisioning covers latency budgets and where rules beat models.

The AI agent layer (agent-assisted segmentation, workflow QA, anomaly detection, reporting) should call the same governed APIs as a human operator, with the same consent enforcement and logging, not a side door into the database. See running AI agents on customer data inside your boundary.

Layer 3: activation

The journey runtime holds state (waits, branches, exits) and calls channels; see customer journey orchestration. Reverse ETL syncs modelled warehouse data to operational tools; Hightouch describes a model (a query) plus a sync (destination, mode, mapping, schedule) that sends only rows that are new, changed or removed 4. Connectors and webhooks reach email, SMS, ads, contact centres and core systems. The audit ledger records what was actually delivered, not what was intended.

CDP ingestion, identity and activation: the event contract

The event contract is the most under-specified part of most projects. For every event type, define:

Duplicates, late events and replay

Duplicates are normal, so design for at-least-once delivery with idempotent processing. Exactly-once is an end-to-end property you assemble: Kafka's idempotent producer and transactions remove duplicates inside Kafka, but Confluent warns that systems claiming exactly-once may not cover failures of external producers or consumers 8. Keep a de-duplication window longer than your longest plausible retry or backfill gap.

Late events arrive after you computed a window. Flink's bounded out-of-orderness strategy holds the watermark at the highest timestamp seen minus a bound, and an idle input can stall progress unless marked idle 9. The business policy is yours: a trigger journey typically ignores events older than its window, while profile updates and batch recomputes accept them.

Replay recovers from bad deployments and backfills new destinations, but carries a consent trap. Segment's replay keeps the original consent object, so events dropped for consent are dropped again 10. Ask two questions: was this event lawfully collected (consent as captured), and may we act on it now (consent as of today)? Replays into channels must pass the second.

CDP data model: the minimum set of entities

Keep facts (events, consent changes, decisions, deliveries) as append-only history and derive current state from them. State you cannot rebuild is state you cannot explain.

Identity graph, merge and unmerge

Treat a merge as an event with lineage: which identifiers, which rule, which confidence, what triggered it. Lineage is what makes unmerge possible. Add guardrails too. Segment Unify limits how many values of one identifier type a profile can hold (defaults: one user ID, five of any other type) and ranks identifier priority 11. Adobe's linking rules let you mark a namespace unique so two people sharing a device are split rather than merged, and a graph holds at most 50 identities 12. Even good systems drift: Amperity says its IDs are meant to be stable but can "jitter" when new data separates two people with the same name 13.

Consent must survive both directions. On a merge, take the most restrictive state per purpose and channel. Keep suppression attached to the identifier, not the profile. After an unmerge, recompute both profiles from identifier-level history instead of copying consent from the survivor.

Consent and suppression as first-class state

Consent cannot be a profile column that some destinations read and others ignore. Under GDPR a controller must be able to demonstrate consent, and withdrawing must be as easy as giving it 14. After an objection to direct marketing you must stop, and the ICO notes it is often better to keep a suppression record with just enough detail to honour the opt-out 15. Apache Unomi lists built-in privacy controls among its core features 16.

Enforce at four points: ingestion (tag or drop events lacking consent context), segment evaluation (exclude before computing audiences), decision time (no consent, no action), and a last-mile check against the latest state immediately before sending. Set a withdrawal-to-enforcement target in minutes. Model suppression separately: it is a deny list that wins over everything. See consent withdrawal across channels.

Decision logging and explainability

Each decision record should hold: decision ID and time; profile reference; inputs or a versioned snapshot reference; rule, model and prompt versions; outcome; reason codes in plain language; consent and suppression state as evaluated; and the resulting delivery.

Regulation points the same way. GDPR Article 22 gives people a right not to be subject to solely automated decisions with legal or similarly significant effects, with safeguards such as human review 17. The EU AI Act requires high-risk systems to log events automatically over their lifetime 18, and the Digital Omnibus on AI moved Annex III high-risk obligations to 2 December 2027 19. Most marketing personalisation is not high-risk, but one logging format for every decision beats retrofitting. See explainable AI for customer decisions and the EU AI Act guide.

Audit ledger: append-only and hash-chained

Operational logs are for debugging: they rotate, and administrators can usually edit them. An audit ledger is append-only, ordered and tamper-evident. In a hash chain each entry stores the hash of its own content and of the previous entry, so changing or removing a past entry breaks every later hash. Periodically sign the head hash and store the checkpoint outside the platform's administrative domain, such as a separate account or write-once store. Certificate Transparency (RFC 6962) shows a stronger variant: an append-only Merkle tree with consistency and inclusion proofs 20.

Observability: what to measure

OpenTelemetry names the standard signals: traces, metrics and logs, plus baggage and profiles 22. Carry the event ID or a trace ID from gateway to connector so one event is traceable end to end, and keep personal data out of traces.

Deployment variants of the same architecture

The architecture stays the same; the trust boundary moves. Four variants cover most cases.

| Vendor-managed single tenant | Vendor, dedicated environment | Vendor or customer KMS, by contract | Dedicated, still vendor-operated | Vendor staff with elevated access | Tealium Private Cloud: single- or multi-tenant, BAA for private-cloud customers 24 | | Customer VPC or private cloud | You or a partner, in your cloud account | Customer-managed keys: you control policy, rotation, deletion 25 | Your network policy | Time-boxed, approved sessions, as in Azure Customer Lockbox, where customer approvers accept or deny engineer access 26 | Meiro private cloud on AWS, Azure, Google Cloud, Oracle, Hetzner 27; PrivyCDP | | On-premise or air-gapped | You | Your HSM or KMS | No outbound path; signed offline updates | None unless you invite it | Meiro on-premise 27; Apache Unomi, Apache-2.0 16; PrivyCDP |

What changes between columns is operational: key custody (who can decrypt), egress (what can leave), support access (who touches production, on what approval) and upgrades. PrivyCDP is a customer-owned, single-tenant deployment (on-premise, in your own AWS, Azure, GCP or OCI account, hybrid, or air-gapped) with customer-held keys and an immutable, append-only audit ledger; see deployment options.

SaaS is often right: small teams, low-risk data, no residency constraint, no platform-engineering capacity. Self-hosting moves upgrades, scaling, backups and on-call to you; price that honestly using the self-hosted guide, the composable vs packaged vs private comparison and TCO.

Anti-patterns

• Consent stored as a profile attribute that only some destinations read.
• Trusting a transport's "exactly once" instead of idempotent processing with event IDs.
• Merging on weak keys (shared email, shared device) with no limits and no unmerge.
• One log for both debugging and audit.
• Nightly suppression sync feeding channels that send hourly.
• AI agents with direct database or send access.
• Raw personal data or PHI in the ledger or traces.
• Replays into channels without re-checking current consent.

Acceptance test: follow one event from source to activation

Run this on any design or vendor demo with synthetic data (see proof of concept with synthetic data). Each step names the evidence to collect.

• 1. Set up a synthetic customer with two identifiers and a known consent state.
• 2. Emit a valid event with a fixed event ID. Evidence: accepted; schema version, event and received times stored.
• 3. Re-send the same event ID. Evidence: dropped as duplicate; profile unchanged.
• 4. Send an invalid event (forbidden field, wrong type). Evidence: quarantined with a reason.
• 5. Send two late events, one inside and one beyond your lateness policy. Evidence: each handled as policy says.
• 6. Introduce the second identifier. Evidence: merge event with lineage; consent recomputed as most restrictive.
• 7. Unmerge or block the identifier. Evidence: both profiles recomputed; suppression unchanged.
• 8. Cross a segment threshold. Evidence: streaming and batch membership agree.
• 9. Cause a decision. Evidence: record with version, input reference, reason codes, consent snapshot.
• 10. Withdraw consent while a message is queued. Evidence: measured propagation time; send blocked at the last-mile check.
• 11. Force a connector failure. Evidence: retry without double send; failure recorded.
• 12. Replay the day's events to a test destination. Evidence: current suppression respected.
• 13. Verify the ledger. Evidence: decision and delivery entries; chain verifies; a tampered copy fails.
• 14. Trace the event by ID. Evidence: full path visible, no raw personal data in traces.
• 15. Time the path against your latency budget.

A design that passes all fifteen is sound in any deployment variant. For procurement wording, see the CDP RFP template.

Back to the Learn hub. To run this acceptance test against your own sources, identity keys and consent model, start with deployment qualification, or see how the PrivyCDP platform is built to be deployed, keyed and audited inside your own environment.