Customer data platform architecture begins before a vendor demo. A CDP can ingest, resolve, segment, and activate data, but it cannot infer what an event was intended to mean, whether an identifier was verified, which consent state governed collection, or whether a destination may use the result. If those contracts are ambiguous, a fast platform simply distributes ambiguity into more profiles and channels.
Define the event and profile system first: business events, stable identities, provenance, correction, consent and purpose attributes, replay behavior, and destination rights. Then evaluate products against that design. This separates durable customer-data semantics from vendor-specific pipelines and gives procurement a concrete test: can the platform preserve and enforce the organization's contracts under realistic volume, latency, deletion, and change?
Inventory decisions and activations before data sources
List the decisions the CDP will support: suppressing messages after opt-out, building an onboarding audience, personalizing a product surface, measuring campaign incrementality, or routing a service case. For each, identify required facts, acceptable age, identity confidence, lawful purpose, destination, and consequence of error. This prevents an indiscriminate collect-everything program and reveals when a warehouse query, CRM workflow, or analytics pipeline is sufficient without a CDP.
Trace each decision backward to business events, not source tables. An order-placed event has a producer, business time, order identity, customer evidence, value semantics, and lifecycle. A row updated in a database may represent correction, fulfillment, cancellation, or a technical retry. Capturing the business transition gives downstream systems a durable meaning and allows late or replayed events to be handled deliberately.
Standardize an event envelope and business payload
Separate transport metadata from domain payload. The envelope should carry event ID, type, source, schema reference, occurrence time, ingestion time, subject, environment, and correlation identifiers. CloudEvents offers a vendor-neutral specification for common event context; organizations can adopt its concepts or map them to an equivalent internal envelope. The payload then contains the business facts defined by the owning domain.
| Contract field | Purpose | Example rule | Failure handling |
|---|---|---|---|
| event_id | Detect duplicate delivery | Unique within producer namespace | Quarantine collisions with different payloads |
| event_type | Select stable business semantics | Past-tense names such as order.placed | Reject unknown major types |
| occurred_at | Preserve business ordering | Producer timestamp with timezone | Retain ingestion time separately |
| schema_ref | Resolve validation and compatibility | Immutable versioned URI | Do not guess payload version |
| subject | Route to the affected entity | Stable order, account, or session ID | Allow null only by contract |
| consent_context | Evaluate collection and use | Purpose, region, state, effective time | Restrict activation when missing |
Govern schemas as product contracts
Store schemas in a registry with owner, description, examples, classifications, compatibility policy, and lifecycle. JSON Schema can validate structure and constraints; registries such as Snowplow's Iglu demonstrate versioned schema organization. Structural validity is not semantic validity, so test business rules too: currency and amount agree, status transitions are legal, and identifiers come from an allowed namespace. Producers own correctness and consumers declare which versions they support.
Prefer additive compatible changes and explicit major versions for changed meaning. Never repurpose a field or silently change units. A new optional field is compatible only if absence has a defined interpretation. Deprecation needs consumer inventory, dual-production or translation where necessary, a deadline, and evidence that old versions no longer arrive. Store the schema reference with every event so historical replay does not reinterpret old bytes using today's model.
Represent identity as evidence, not a magic customer ID
Events may carry anonymous device IDs, authenticated account IDs, email addresses, CRM contacts, loyalty IDs, household links, or advertising identifiers. Define namespace, issuer, verification method, scope, and observed time for each. A login can create stronger evidence than two records sharing an email string. Keep the original identifiers and the resolution decision so false merges can be split and downstream effects traced.
Treat link, unlink, merge, split, and identifier-rotation as governed events. Set deterministic rules before probabilistic ones and establish confidence thresholds by use case. A weak match may be acceptable for aggregate measurement but not for sending sensitive personalization or fulfilling a deletion request. Shared devices, recycled phone numbers, family emails, and account transfers need explicit policies. The profile should expose uncertainty rather than collapse it into one permanent identity.
Carry consent, purpose, and policy context with data
A single consent boolean cannot govern a multi-channel customer profile. Store the subject or device, purpose, channel, jurisdiction or policy region, state, collection source, notice or policy version, effective time, expiry where applicable, and proof reference. Distinguish consent from other legal or contractual bases determined by the organization's counsel. The CDP should evaluate the applicable state at collection, profile computation, audience creation, and destination delivery.
Consent changes are events with priority. Revocation must invalidate future activation promptly and trigger downstream suppression, deletion, or restriction workflows according to policy. Preserve evidence of the change without continuing prohibited use. When identity resolution joins two profiles, do not automatically choose the most permissive state. Apply defined precedence and purpose rules, flag conflict, and keep source context available for audit and correction.
Build profiles as reproducible projections
The unified profile should be a versioned projection from immutable or correction-aware events, identity links, reference data, and policy. Record each attribute's source, observed time, computation, confidence, and expiry. Separate asserted facts such as a declared preference from inferred features such as predicted affinity. A profile update should be explainable: which event or rule changed the value, and what downstream audiences were affected?
| Profile element | Source rule | Conflict rule | Retention behavior |
|---|---|---|---|
| Contact channel | Verified account or CRM event | Prefer latest verified claim | Expire after policy-defined inactivity |
| Consent state | Consent ledger event | Purpose and region precedence | Retain minimum proof and revocation |
| Lifecycle status | Authoritative business event | Use state machine, not last-write-wins | Keep transition history |
| Audience feature | Versioned computation | Recompute from eligible inputs | TTL based on decision need |
| Identity link | Evidence and resolution rule | Confidence and manual exception | Support reversible split |
| Suppression | Risk, service, or preference event | Restrictive state wins by policy | Propagate until explicitly cleared |
Design replay, correction, and deletion before launch
At-least-once delivery, late events, source backfills, and consumer outages are normal. Require idempotent event IDs, define ordering per subject, and distinguish event occurrence from ingestion. A replay must preserve original metadata and be marked as replayed so operational metrics do not confuse it with new customer behavior. Consumers should produce the same state when processing the same valid event set, or document why external effects are not repeatable.
Corrections should reference the original event or business entity and explain what changed; mutating history in place breaks reproducibility. Deletion is a distributed workflow across raw events, profiles, features, exports, and destination copies, constrained by retention and other lawful obligations. Maintain a destination ledger and acknowledgements. Test deletion and identity split using seeded records before trusting vendor claims, including backups, failed exports, and delayed consumers.
Create a contract for every destination
An activation contract names destination owner, allowed purposes, permitted attributes, identity type, audience minimums if needed, region, consent mapping, delivery cadence, encryption, retention, deletion interface, and incident path. Transform data to the minimum necessary payload at the boundary. Do not allow a destination connector to browse the complete profile simply because the platform makes that convenient.
Record audience definition version, policy decision, member count, export time, destination response, and any rejected records. Re-evaluate membership when source facts, identity links, consent, suppression, or model versions change. A cached audience is not exempt from revocation. Monitor delivery lag and reconciliation between intended, sent, accepted, and deleted records. Suspend a destination when acknowledgements or policy enforcement are unreliable.
Evaluate vendors against the contract, not feature labels
Build a proof of concept with duplicate events, late arrivals, schema evolution, conflicting identity evidence, consent revocation, profile split, replay, destination failure, and deletion. Ask the vendor to show provenance and exact policy decisions, not only the final profile. Test APIs, export, observability, regional processing, encryption and key options, access controls, audit logs, throughput limits, and total latency. Confirm how custom logic is versioned and moved across environments.
Model total cost across events, profiles, storage, computed traits, destinations, data egress, sandboxes, implementation, and ongoing schema and identity stewardship. Contract for data and configuration portability, including raw events, identity links, profile lineage, audience definitions, consent evidence, and destination logs. A lower ingestion price can become expensive if correction, replay, or export requires proprietary services or cannot preserve semantics outside the platform.
Key takeaways
- Begin with customer and business decisions, then identify the minimum events and freshness they require.
- Use a standard envelope, versioned schemas, semantic tests, and immutable schema references.
- Model identity links as reversible evidence and vary confidence requirements by use case.
- Carry consent and purpose context through collection, profile computation, audience creation, and activation.
- Test vendors with replay, correction, deletion, conflict, and destination-failure scenarios using portable contracts.
Frequently asked questions
Must events be immutable? Preserve what was asserted and use explicit correction or retraction events where practical. This supports replay and audit. Retention and deletion requirements may still require removal or cryptographic erasure under the organization's policy.
Can the CDP own the canonical customer record? It can own a derived engagement profile, but systems such as account, commerce, and consent ledgers should remain authoritative for the facts they create. The profile needs provenance back to them.
How many events should be standardized before procurement? Standardize a representative vertical slice covering identity, consent, a core journey, correction, and activation. The goal is enough contract depth to expose platform fit and operating cost, not a multiyear enterprise taxonomy.
Conclusion
A CDP is valuable when it can preserve meaning and enforce use across a changing customer-data estate. Event contracts, identity evidence, consent context, reproducible profiles, and destination obligations are the durable architecture. Defining them first turns vendor selection from a feature comparison into a test of whether the platform can operate the customer-data system the organization actually needs.