Data Schema and Architecture
The CDP data model determines what marketing can do. This module covers schema design, computed properties, multi-tenant architecture, and the governance that makes the system maintainable.
What you will learn
- The CDP data model: entities, events, profiles, audiences
- Profile schema design
- Event schema design and naming conventions
- Computed properties and predictive scores
- Audience definition: SQL vs UI vs hybrid
- Schema evolution and versioning
- Multi-tenant and multi-brand data architecture
- Data residency and regional compliance
- Performance and scale considerations
- Documentation and discoverability
- Schema governance
1. CDP data model
The standard model includes:
- Entities: Customers, accounts, products.
- Events: Behavioral actions (page_viewed, product_added, purchase_completed).
- Profiles: Unified customer records with attributes.
- Audiences: Filtered subsets of profiles.
- Journeys: Multi-step orchestration of audiences.
2. Profile schema
- Identity attributes: email, phone, customer_id, device_ids.
- Demographic attributes: age range, gender (where appropriate), location.
- Behavioral attributes: most recent purchase, lifetime value, lifecycle stage.
- Predictive attributes: churn risk, propensity scores, segment.
- Consent attributes: marketing consent, channel preferences.
3. Event schema
| Layer | Properties |
|---|---|
| Standard | event_name, timestamp, user_id, session_id |
| Context | page, device, app version, referrer |
| Event-specific | product_id, value, quantity |
| Custom | Business-specific properties |
4. Computed properties
Most CDPs compute properties on top of raw events: total lifetime value, days since last purchase, count of category purchases, segment membership. These computed properties become the primary audience inputs.
5. Audience definition
- SQL-defined: full flexibility, requires SQL competence.
- UI-defined: limited but accessible to marketers.
- Hybrid: SQL-defined "computed properties" that marketers reference in UI.
6. Schema evolution
Schemas change over time as products and events evolve. Versioning practice:
- Backward-compatible additions are safe.
- Breaking changes require coordinated migrations.
- Version field on events.
- Documented deprecation cycles.
7. Multi-tenant / multi-brand
Holding companies with multiple brands face an architecture choice:
- Separate CDP per brand.
- Single CDP with brand-scoped audiences and governance.
- Hybrid: shared identity layer, separate activation layers.
8. Data residency
GDPR and other regional rules may require EU customer data to stay in EU. Most major CDPs offer regional data residency. Confirm at vendor evaluation.
9. Performance and scale
- Profile lookup latency (real-time use cases).
- Audience computation time (large audiences may take minutes).
- Event ingestion throughput.
- Storage costs (events accumulate; archival strategy matters).
10. Documentation
CDP documentation should include: schema reference, event catalog, audience inventory, lifecycle definitions, computed-property definitions. Without documentation, the CDP becomes a black box.
11. Schema governance
- Schema change-request process.
- Review by data and marketing teams.
- Impact analysis on downstream consumers.
- Versioning and migration plans.
- Annual schema audit.
Sources & further reading
- Segment Academy
- mParticle documentation
- RudderStack documentation
- Tealium documentation
- CDP Institute
- Books: Martin Kihn, Customer Data Platforms; Bill Inmon, Data Modeling in the Age of Data Lakes
- Snowflake data modeling blog
- dbt data modeling
- Holistics modeling resources
- IAB data clean rooms
- GDPR data residency
- Data & Policy journal
Part of the Customer Data Platforms series · RGM Training