How to build a customer 360

A customer 360 is a single, queryable record of everything known about a customer — purchases, support tickets, marketing touches, product usage, loyalty status — even though that information lives natively in a dozen unconnected systems. The promise is simple to state and genuinely hard to deliver, because the hard part isn't storage, it's matching: deciding that the "[email protected]" in the CRM, the anonymous device ID from last week's app session, and the loyalty card scanned in-store are the same human being.

Identity resolution is the actual problem

identity resolution is the process of deciding which records, across sources that don't share a common key, refer to the same person. It runs on a spectrum from deterministic (an exact match on email, phone, or a shared login ID — high confidence, but misses anyone who used a different email in a different system) to probabilistic (statistical matching on behavioral or device signals — catches more, with a real and non-zero false-match rate). identity stitching is the ongoing version of this: as new events and records arrive continuously, the system has to decide, in near-real-time, whether each one belongs to an existing profile or starts a new one, and occasionally has to merge two profiles that were wrongly kept separate, or split one that was wrongly merged.

The practical implication: before evaluating any customer-360 platform, know which identifiers you actually have in common across your systems (login ID, email, phone, loyalty number, hashed identifiers) and how consistently they're captured. A platform with excellent matching technology can't stitch together systems that never captured a shared identifier in the first place.

Two architectures for the same goal

Purpose-built customer data platforms (CDPs) collect events and records into their own profile store, apply identity resolution, and expose the result to downstream marketing, support and analytics tools. mParticle positions itself as governed infrastructure between an app's event stream and the rest of the martech stack, with schema validation and PII filtering applied before data reaches any destination — useful when many downstream tools need consistent, compliant data rather than one team owning a single activation channel. Tealium grew out of tag management and extended the same governed collection layer into a full CDP, which suits organizations already using it for tagging. Treasure Data is a long-standing enterprise CDP built around identity resolution across a very large number of connected sources, now layering AI-assisted campaign generation on top of the same unified-profile core.

Warehouse-native platforms treat your existing data warehouse as the single source of truth rather than building a separate proprietary profile store. RudderStack collects events via SDKs, loads them into your warehouse, and can sync data back out to business tools from the same pipeline (reverse ETL), with a self-hosted open-source core available for teams that want to run it themselves. This architecture keeps the unified record in a system your data team already controls and queries with SQL, at the cost of needing that data team to build and maintain the identity-resolution logic that a purpose-built CDP would otherwise provide out of the box.

When you need external identity, not just internal stitching

Internal identity resolution only connects records you already hold. Two other categories exist for going further:

• A platform built specifically for messy, multi-source consumer identity. Amperity uses probabilistic and deterministic matching without requiring a fixed identity schema upfront, aimed at retail, hospitality and travel brands with many overlapping identifiers (POS, loyalty, e-commerce, call center) and no clean shared key across them.
• Connecting your customer 360 to identifiers held by outside partners — publishers, ad platforms, data providers — for measurement or audience purposes beyond your own systems. LiveRamp's RampID resolves your own records into a pseudonymous identifier that can be matched against the same identifier held by partners, without either side exchanging raw personal data directly.

What actually makes this hard

• Source coverage, not platform sophistication, is usually the bottleneck. A brilliant identity-resolution engine fed by three of your twelve customer-touching systems produces a 360 view of a quarter of the customer, confidently labeled as complete.
• Data governance has to be designed in, not bolted on. Consent status, data retention rules, and regional privacy requirements (which data can be merged, which must stay separated) need to be enforced at the point profiles are built, not audited afterward once merged records already exist everywhere downstream.
• Probabilistic matches need a confidence threshold someone actually chose. A platform that merges two people's records because they share a device (a shared family tablet, a work computer) will produce a "unified" profile that's simply wrong, and wrong customer data is often worse for trust than no unified view at all.
• The record needs owners on both the input and output side. Someone has to own what counts as a valid new source to onboard, and someone has to own what downstream teams are allowed to do with the merged profile.

A shortlist by situation

• Many downstream tools need the same governed, compliant event stream. mParticle.
• Already using a tag-management layer and want to extend it into a full CDP. Tealium.
• A mature enterprise wanting identity resolution plus AI-assisted activation on top. Treasure Data.
• Want the warehouse to be the single source of truth, potentially self-hosted. RudderStack.
• Retail, hospitality or travel with messy, multi-source customer records and no clean shared key. Amperity.
• Need to connect internal customer records to external advertising or measurement partners. LiveRamp.

Questions to ask before you commit

• What identifiers do we actually share consistently across our source systems today?
• Deterministic, probabilistic, or both — and what's the vendor's documented false-match rate for probabilistic matching?
• How does the platform handle a merge that turns out to be wrong — can it be split back apart without losing history?
• Where does consent and retention enforcement happen — at collection, at merge, or only at activation?
• What is the real cost of adding each new source system, in engineering time as well as license fees?

Common mistakes

• Treating a customer-360 project as a platform purchase rather than a source-integration and governance project the platform supports.
• Merging records on weak probabilistic signals without a documented confidence threshold, producing profiles that are unified but wrong.
• Building the unified profile without designing consent and retention enforcement into the pipeline from the start.
• Declaring victory after connecting the easiest three systems and calling the view "360" when most customer touchpoints are still missing.

For segmenting the customers this unified record makes possible, see how to segment customers. Browse customer data platform tools and identity resolution tools for the full field.