Customer 360 Data Architecture
What 'Customer 360' actually means architecturally
'Customer 360' is a product-marketing phrase for a specific architectural pattern: a unified record per customer that aggregates data from every system that touches them — CRM, support ticketing, ecommerce orders, web/app behavioral events, email engagement, billing — keyed to a single resolved identity (see identity graph construction), kept reasonably fresh, and exposed in a form other systems can query or subscribe to. It's not a single product you buy; it's an architecture a CDP, a warehouse-centric 'reverse ETL' stack, or a custom pipeline can all implement differently.
The three architectural layers
A Customer 360 implementation has to solve three distinct problems, often with different tooling for each: Identity resolution — deciding which records across systems represent the same person. Data unification — actually pulling and reconciling the attributes and events from each source into one profile, including resolving conflicts when sources disagree. Activation — getting the unified profile back out to the systems that need to act on it (an ad platform audience, a support tool's customer context panel, an email platform's segment).
Where the unified profile physically lives
| Architecture | Where the 360 profile lives | Strength | Weakness |
|---|---|---|---|
| Packaged CDP (Segment, Twilio Segment, Tealium) | Vendor's own profile store | Fast to stand up, built-in activation connectors | Another system of record to reconcile against the warehouse |
| Warehouse-native (dbt mart + reverse ETL) | Your own data warehouse | Single source of truth, full SQL control, cheaper at scale | You build and maintain identity resolution and activation tooling yourself |
| Custom microservice | A purpose-built database/API | Maximum flexibility for complex business logic | Highest build and maintenance cost |
The warehouse-native pattern in practice
The increasingly dominant pattern: land raw data from every source via ELT, resolve identity and build a dim_customers_360 dbt mart as the single unified profile, then use a reverse-ETL tool (Hightouch, Census) to sync specific fields from that mart out to operational tools — pushing lifecycle_stage and predicted_ltv into Salesforce, syncing an audience of churn_risk > 0.7 customers into Klaviyo. This keeps the warehouse as the one authoritative source of truth, with every downstream tool receiving a derived, purpose-built slice rather than owning its own competing copy of 'the truth.'
Conflicting source data needs an explicit resolution rule, not a last-write-wins default
Freshness requirements vary wildly by use case
Not every field in a 360 profile needs the same freshness. A lifecycle_stage recalculated nightly via a batch dbt run is fine for most segmentation and reporting. A 'just abandoned cart' flag used for a real-time on-site message needs to be near-instant, which usually means it's computed by a separate, lower-latency event-driven path rather than waiting on the next batch run of the full 360 profile. Architecting a single pipeline to serve both needs at the strictest requirement wastes compute on fields that didn't need it; splitting by actual freshness requirement per use case is usually the right call.
What's Next?
A unified customer profile is only trustworthy if the organization has clear rules about which system owns which field and how changes propagate — which is exactly the discipline that master data management formalizes.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.