CDP architecture and warehouse-native customer data platforms: identity resolution, unified profiles, consent-aware audience activation, and build-vs-buy advice.
Bought a CDP, still cannot answer the question
The common failure is buying a CDP before resolving identity. The tool arrives, the same customer still exists as four records across ecommerce, email, support, and ads, and now that fragmentation is being synced outward to every channel at cost per profile. Meanwhile the analytics team keeps working from the warehouse, so there are two competing definitions of a customer. The unification problem was never a tooling problem.
What we architect
- Identity resolution logic with deterministic matching first and documented probabilistic rules where needed
- A unified customer profile model in the warehouse: attributes, events, and computed traits
- Audience definitions built as version-controlled, testable SQL rather than clicks in a UI
- Reverse ETL activation into ad platforms, email, and CRM with suppression and exclusion handled
- Consent and preference state carried through to every destination, so opt-outs actually propagate
- A build-versus-buy assessment with real cost modeling before any commitment
How we work
Profile your existing customer data and measure how badly identity is actually fragmented
Resolve identity in the warehouse and validate against known duplicates
Model profiles and traits in dbt so analytics and activation share one definition
Activate to one destination, prove the loop, then expand
Typical stack
Frequently asked questions
If your data already lives in a warehouse and you have analytics engineering capability, composable is usually cheaper and far more flexible, because audience logic becomes reviewable SQL rather than UI state. Packaged CDPs earn their cost when you need event collection SDKs, real-time personalization, or a non-technical marketing team owning audiences directly. We model both against your actual volumes rather than arguing it in the abstract.
Deciding, with rules you can defend, when two records are the same person. Deterministic matching on email, phone, and customer ID comes first and covers most cases. Probabilistic matching on device and behavior fills gaps but introduces false merges, so we document the rules and keep them tunable rather than hiding them in a black box.
Consent state lives on the profile and is enforced at the point of activation, not left to each destination. Suppression lists propagate on every sync, so an opt-out or deletion request removes the person from downstream audiences rather than lingering in a platform-side list.
Yes, and it often improves it. We resolve identity and model profiles in the warehouse, then feed clean, unified profiles into the CDP as a source. You keep the activation tooling your team knows and stop paying to sync fragmented records.
Go deeper
Architect your customer data layer
Tell us where customer data lives today and we will assess identity fragmentation before recommending build or buy.
Start a project