Private self-check

CDP architecture review

Six decisions that locate friction across the data model, identity, the customer profile, consent, and activation.

Choose the description closest to the current state. There is no final score: you will get a list of priorities and a baseline worth preserving.

The review runs entirely in this browser. It does not send, store, or share your answers.

Every decision, and what to do with each answer

Why it matters: Without a shared contract, each integration changes data meaning and pushes exceptions into every consumer.

Each integration creates its own fields or attributes and nobody maintains a shared contract.

Next check: Choose one priority flow and document the source, meaning, format, owner, and consumers of each datum.
Shared models exist, but exceptions and transformations accumulate without review.

Next check: Inventory active exceptions and decide which belong in the contract, stay isolated, or should be retired.
Models, sources, and transformations have owners and documented uses.

Next check: Check that consumers validate changes before release and that a retirement path exists.
Contracts are versioned, validated during ingestion, and reviewed with their consumers.

Next check: Keep the control and measure which contracts generate the most incidents, exceptions, or operating cost.

Why it matters: Incorrect identity does more than fragment profiles: it can join different people and propagate wrong decisions.

Identifiers are declared from whatever each connector provides, without shared criteria.

Next check: Classify identifiers by source, authority, persistence, and risk before changing stitching rules.
Namespaces and rules exist, but some sources still lack enough evidence.

Next check: Find the sources with the most fragmentation or questionable joins and validate the evidence they actually send.
Each event family declares identifiers, authority, and expected persistence.

Next check: Use real samples to verify that each source follows the contract and failures leave an observable signal.
Fragmentation and questionable joins are monitored and have accountable source owners.

Next check: Maintain thresholds, owners, and periodic reviews when sources, SDKs, or authentication mechanisms change.

Why it matters: The shared profile is operating state: every added datum affects volume, precedence, activations, and ownership.

Sources are added to the profile by default or to solve one-off needs.

Next check: Inventory what writes to the profile, who consumes it, and what would happen if it became unavailable.
Informal criteria exist, but consumers, retention, or precedence are not explicit.

Next check: Document the authorized source, precedence, retention, and dependent activations for every critical attribute.
Every shared datum has a use, a precedence rule, and a lifecycle.

Next check: Validate that source, precedence, or retention changes have tests and owners before release.
Writes, volume, and consumers are reviewed before shared state is expanded.

Next check: Keep the pre-release review and add retirement criteria for attributes, sources, and consumers that fall out of use.

Why it matters: Capturing a preference is not enough: value comes when every consumer enforces the same decision traceably.

Each tool interprets consent separately and no traceable rule exists.

Next check: Trace one purpose from the CMP to a destination and record transformations, defaults, and enforcement points.
Consent is captured, but propagation or enforcement depends on the channel.

Next check: Compare the same state across web, apps, the customer profile, and destinations to find where it changes or stops being enforced.
Purposes, status, timestamp, and source reach the defined consumers.

Next check: Test revocation, unknown states, and out-of-order arrivals, not only the acceptance path.
Policies are tested in activation and failures leave a reviewable operating signal.

Next check: Maintain periodic tests by purpose and destination, with owners assigned to investigate deviations.

Why it matters: When every channel copies rules and state, the same person can receive incompatible decisions that are hard to explain.

Each journey or channel keeps its own copy of rules and attributes.

Next check: Choose one repeated decision and separate customer facts, configuration, request context, and observable outcome.
Some rules are shared, but the customer profile mixes stable facts with ephemeral context.

Next check: Find ephemeral attributes stored as profile data and decide whether they belong in configuration, request, or operating state.
Profile data, configuration, and request context have distinct boundaries and owners.

Next check: Validate that every decision records inputs, rule version, and outcome so it can be reproduced and explained.
The same decision can be reused across channels and each outcome is observable.

Next check: Preserve the separation and check that new channels reuse the decision without creating another copy of rules and state.

Why it matters: An architecture that only works while its author remains is unfinished and turns every change into a dependency.

Operations depend on specific people and documentation does not reflect production.

Next check: Choose a recent incident and test whether another person can diagnose it with current documentation, alerts, and access.
Procedures exist, but ownership, alerts, or retirement conditions remain implicit.

Next check: Assign owners, failure signals, and retirement conditions to the flows generating the most change or incidents.
Decisions, owners, boundaries, and failure response are part of the deliverable.

Next check: Test handover with a real change and update documentation with anything the team could not complete unaided.
The internal team tests changes, reviews debt, and can evolve the system without external dependency.

Next check: Maintain debt reviews, failure drills, and owner rotation so personal dependencies do not return.

Reading of your answers