A visual field note on the customer data platform
Build the data platform once.
The value of a CDP is not a bigger customer database. It is one governed path from every product interaction to every decision, audience, and experience.
Bird's-eye view
One journey from product behavior to customer experience.
The platform has three technical layers: collect, govern, and activate. The rollout starts by defining the outcome, then forms the team, establishes the contract, ships the client layer, protects the stream, and connects trusted data to action.
The opening conversation
Answer these questions before choosing the architecture.
Start with the business decision and customer experience. Work backward into activation, identity, events, and systems. A CDP is useful only when trusted data changes what someone can do.
Business problem
What pain prompted the work now, and which fragmented experience or unavailable capability matters most?
Decision or action
What should a person, product, or system be able to decide or do with more confidence?
Proof of value
What must be materially different in the first 90 days and after six months? Which metric will show it?
Ownership
Who sponsors the work, owns customer data, defines official metrics, approves schemas, and operates the platform?
Current ecosystem
Where does data originate, how is it collected and transformed, where does identity live, and which systems consume it?
Identity model
What is the canonical identifier? How do anonymous, authenticated, cross-device, and offline identities merge?
Trust boundaries
What consent, privacy, access, retention, deletion, quality, and change-control rules must the stream enforce?
Activation path
Which destination receives the trusted data, what happens there, and how does the outcome return as a learning signal?
Do not begin by asking what reports people want. Ask which decisions they cannot make confidently today.
Team and contract
Begin with the people who can build the road.
A small enablement team learns the platform deeply, agrees on the event language, and makes the first code changes itself. This team turns the CDP into a repeatable company capability.
Getting started, in a nutshell
Start with a small team that can learn and ship.
The fastest path is not a broad training program. Put a small group together that understands the codebase, learns the CDP deeply, agrees on the event contract, and implements the shared path itself.
Learn
Understand the platform's event envelope, identity rules, consent model, validation hooks, segments, and connectors.
Specify
Write one shared event spec with business definitions, required properties, owners, and allowed uses.
Wrap
Build your own SDK or library around the CDP so business meaning and platform mechanics live behind one stable interface.
Implement
Have the same small team make the first changes across representative clients instead of handing out integration instructions.
Verify
Route events through vendor checks and your own validation logic before they enter the trusted stream.
Activate
Resolve identity, create reusable segments, connect common destinations, and keep a warehouse exit for custom needs.
Client libraries and event design
One contract across every interface.
Web, mobile, connected devices, services, and offline systems should speak the same event language through a company-owned SDK or API. Product teams use business concepts while the shared layer handles CDP mechanics.
The collection principle
Instrument once. Route many times.
Applications should emit stable business events through a company-owned interface. The CDP then forwards approved events to analytics, messaging, experimentation, advertising, and personalization without exposing vendor mechanics to every product team.
Signal design
Do not confuse more events with more understanding.
Capture the critical business moments as discrete events. Summarize repetitive interaction noise when the detail will not change a decision. A page view, a save, or a completed step may deserve its own event. Ten low-value clicks may be better represented as one experience summary.
clicks: 4
section: gallery
scroll_depth: 82
primary_action: save
The contract
Names are infrastructure.
A tracking plan is a versioned contract, not a spreadsheet that disappears after launch. Every event needs an owner, a business definition, required properties, approved values, consent rules, and a retirement path.
- 01 Describe the customer action, not the UI control.
- 02 Keep shared properties consistent across products.
- 03 Consolidate repetitive interactions when a summary preserves the useful signal.
- 04 Version breaking changes and preserve lineage.
- 05 Reject unknown events by default.
{
"event": "vehicle_saved",
"source": "web",
"user_id": "known_or_anon",
"properties": {
"body_style": "suv",
"fuel_type": "electric",
"price_band": "35k_to_55k"
},
"consent": "personalization_allowed"
}Profile and identity
A profile should explain preference, not just identity.
Start with a stable, client-scoped anonymous ID. Attach declared or authenticated identifiers when they become available, then use explicit identity rules to connect activity across browsers and devices. Enrichment turns that history into preferences, intent, and lifecycle stage. Consent travels with the profile so every destination receives the same decision.
Data stream
Trust is built in the pipe.
Bad events should not quietly become dashboards, audiences, and automated decisions. Validate every event against the tracking plan before it enters the clean stream.
The quality gate
Pass, quarantine, repair, replay.
Use the platform's built-in checks, but do not stop there. Put a custom code hook in the stream for business-specific rules, sensitive fields, taxonomy lookups, and checks the vendor cannot know.
Why quarantine exists
A typo can become a data incident.
I have seen events that meant the same thing arrive with misspelled names and inconsistent values. The dashboards still rendered, but the outcomes became a nightmare to reconcile. If a dynamic value leaks into the event-name field, one bug can mint hundreds of event types before anyone notices.
falseBooleanValid"False"String and case driftQuarantine"fasle"String and typoQuarantinepage_view_{dynamic_value}
One intended event can become hundreds of accidental event types.
Allowlist event names, property types, enums, and required fields.
Reject case drift, misspellings, unknown names, and dynamic-name explosions.
Preserve the payload, error, owner, and replay token without polluting trusted data.
What gets checked
Quality is a product surface.
The gate should return useful errors to the team that owns the event. Quarantine is not a dead letter queue. It is an observable workflow with an owner and a safe path to replay corrected data.
Contract
Allowlisted event name, supported version, and required fields. Unknown names go to quarantine.
Shape
Strict types, ranges, enums, casing, and timestamps. Do not silently coerce typos.
Privacy
Consent state, sensitive fields, approved purpose.
Behavior
Duplicates, unexpected volume, order, and cardinality.
Ownership
Named team, service level, and repair route.
Governance
The tracking plan is the control plane.
Product team submits the business definition and intended uses.
Platform and privacy owners validate taxonomy, consent, and data minimization.
The approved contract becomes machine-readable and available to SDKs and services.
Quality, freshness, volume, and destination delivery stay visible.
Consumers migrate before the old version stops flowing.
Distribution and activation
Define once. Use everywhere.
A trustworthy event becomes more valuable each time it is reused. The same profile, segment, and metric definition should power analysis, experimentation, paid media, messaging, shopping, and personalized experiences.
The distribution layer
One governed profile. Many controlled exits.
Native connector
Use the CDP's managed integrations for common analytics, messaging, advertising, and experimentation destinations.
Custom connector
Build a focused adapter when a destination has no native route or needs company-specific transformation.
Warehouse stream
Land governed events and profiles in the cloud data warehouse for modeling and custom downstream integrations.
Personalization as activation
A recommendation system begins as a connector.
The CDP already has the approved interaction stream. A connector can send those events through Kinesis Data Firehose, transform them into a recommendation schema, and record them in Amazon Personalize. The model learns from behavior and returns ranked item IDs that an application API enriches and serves.
What the business gets
Activation without reinstrumentation.
See where journeys break.
Analyze funnels, retention, paths, and behavior with the same event definitions used everywhere else.
Build an audience once.
Target or suppress that audience across paid and owned channels with consistent consent rules.
Personalize the next step.
Use declared and observed preferences to rank content, products, offers, and messages.
Add context to support.
Bring important journey signals into the customer profile without exposing unnecessary detail.
Trust the same metric.
Give teams a governed semantic layer for KPIs, experiments, and operating reviews.
Ask instead of navigate.
Expose approved metrics and analyses through a controlled agent interface.
Platform recommendation
Prefer one platform that covers all three layers.
If collection, governance, analysis, experimentation, and activation live together, teams spend less time reconciling tools and more time improving the customer experience.
A practical rollout
Prove the path before expanding the map.
Contract
Choose one high-value journey. Define identity, consent, taxonomy, ownership, and quality rules.
Output: approved tracking planGolden path
Implement the shared collection layer on two representative interfaces. Add validation and quarantine.
Output: clean, observable streamActivation
Connect one analytics use case, one reusable audience, and one personalized experience.
Output: end-to-end valueScale
Publish templates, service levels, ownership dashboards, and an intake path for the next teams.
Output: repeatable operating modelThe agentic future
The next interface is an answer.
Self-serve dashboards are useful, but they still ask every employee to learn a complex interface. A governed data platform can expose its semantic layer to AI agents through MCP so people ask a business question and receive a traceable answer.
Which vehicle preferences are associated with a saved item, and where does that journey break?
Interest is strongest for electric SUVs in the mid-price band. The largest journey loss occurs after inventory results, before detail views.
Agent-ready by design
Make the semantics callable.
- 01 Stable event and metric definitions.
- 02 Permission-aware profile access.
- 03 Lineage attached to every answer.
- 04 Human approval for consequential actions.
- 05 Agent actions written back to the audit trail.
The decision
Build for trustworthy answers, not more dashboards.
Standardize collection. Govern the stream. Activate the same profile everywhere. Then give people and agents one safe way to ask what the data means.
Return to the top ↑
Written by Adib Kadir. Product and engineering executive focused on rolling out AI at enterprise scale.
Start a conversation