Patterns from production
Architecture Patterns
Short, visual notes on customer-data decisions that become expensive once a CDP reaches production.
Map of the patterns
Map of the eleven architecture patterns over the customer data journey, in four stages plus a foundation band. First stage, identity, with two patterns: 01, split profiles, on identity as a contract with the source, and below it 08, people who do not add up, on the person you measure versus the person you activate. Second stage, profile and state, with three: 02, one object for all, on separating operational state from customer state; 03, writes that collide, on Profile writes as shared state; and 10, everything in Profile, on what goes into Profile and what stays in the data lake. Third stage, decision: pattern 06, duplicated eligibility, on modelling Decisioning inputs by consumption. Fourth stage, activation, with two: 05, every channel from zero, on reusing the data foundation across channels, and below it 11, another brand as sender, on the brand as a relationship rather than a person attribute. Below them, a foundation band crossing all four stages holds the three patterns that belong to no single stage: 04, temporary stays, on the exit path an MVP architecture needs; 07, only you can run it, on handover as architecture; and 09, a no that is not enforced, on consent as a chain. Each cell links to its page, and the full list with the long titles sits right below the map.
11 patterns
Identity → Operations- Identity
Identity is a source contract
A graph resolves evidence. It cannot invent relationships that sources never emit.
Read pattern → - Customer state
Separate operational state from customer state
Immediate orchestration and queryable facts do not need the same representation.
Read pattern → - Profile governance
Profile writes are shared-state engineering
Multiple writers turn the profile into shared operational state.
Read pattern → - Delivery
MVP architecture needs an exit path
Starting narrow is valid. Making temporary choices permanent by accident is not.
Read pattern → - Channels
Reuse the data foundation across channels
Add channels by reusing customer and decision foundations, not rebuilding them.
Read pattern → - Decisioning
Model Decisioning inputs by consumption
Decision inputs have different lifecycles, and they do not all belong in the profile.
Read pattern → - Operations
Handover is architecture
An architecture is not complete until someone else can operate it.
Read pattern → - Identity
The person you measure is not the person you activate
The identity graph decides whom to activate now. Analytics stitching rebuilds who it was. They are two answers, and each is designed on its own.
Read pattern → - Consent
Consent is a chain, not a field
It is decided in the CMP, travels through the SDK, is stored in the profile and enforced by each destination. It breaks at the link nobody designed.
Read pattern → - Profile and retention
Profile is for activation; the data lake is for memory
What goes into Profile and how long it stays is an architecture decision. It also decides what counts towards the licence.
Read pattern → - Multi-brand activation
A brand is a relationship, not a person attribute
In a multi-brand group, a main brand does not describe all of a person's relationships. Each send needs a brand and the relevant permission check.
Read pattern →
Architecture lens
One consistent way to read architecture
Every pattern answers the same five questions before recommending a solution.
- 01What breaks
- 02Where the state lives
- 03Who owns it
- 04What trade-off we accept
- 05How it evolves