A single customer view (SCV) is a unified, comprehensive profile that consolidates all of an organization’s customer data into one coherent, addressable identity — built from coordinated layers rather than a single table, as the section below explains. A single customer view data platform can be helpful in multichannel and omnichannel marketing, since it provides an organization with a complete picture of customers as they engage across channels, media, and contexts.
Single customer view is also referred to as Customer 360 View (C360) and Unified Customer View (UCV). It contains all personally identifiable information about customers, such as name, mobile number, address, age, purchase history, loyalty program activity, and previous communications.
Why is Single Customer View Important?
Customers engage with brands using many channels, like web, mobile, telephone, SMS, in-store, radio, television, and more. Multiple profiles can be generated if information on these channels isn’t tracked and associated with a single unified profile for each customer. This failure to connect the dots can lead to lost sales. It can also result in experiences that are frustrating to customers.
Brands can better segment and target customers by connecting these channels and pieces of an identity into a single customer view. As a result, brands can delight customers and grow revenue.
For example, a customer might open an email, click through to the website, add a product to the shopping cart, then decide to try items on in-store. If brands don’t have tools to connect these touchpoints and create a single customer view, they can send ineffective marketing offers, or lose track of customers before finalizing a sale.
The Five Layers of a Single Customer View
A single customer view is not one table with more columns. It is five layers that have to agree with each other, and most of the work of building one is keeping them aligned as source systems change underneath.
Identity layer. The identifiers that resolve to the same person: emails and hashed emails, phone numbers, loyalty numbers, account IDs, mobile advertising IDs, and cookies. This layer is a graph rather than a field list — it records which identifiers are linked, on what evidence, and when.
Attribute layer. Descriptive fields about the person: name, postal address, contact points, demographics, account status. Source systems routinely disagree on these, so the layer works only when a survivorship rule decides which value wins and the profile records which system supplied it.
Event layer. The time-ordered behavioral record: page views, app sessions, transactions, returns, service contacts, message opens, store visits. Events are append-only and belong to the person through the identity layer, not through a key written into the profile itself.
Derived layer. Values computed from the three layers above — lifetime value, recency and frequency bands, propensity and churn scores, send-time preference. These are the fields teams actually segment on, and each carries a refresh interval that decides how current any segment built from it is.
Permission layer. Consent state, channel opt-ins and opt-outs, purpose limitations, retention clocks, and outstanding deletion requests, resolved against the same identity graph as every other attribute. A view that carries the first four layers and not this one is complete and unusable: nothing built from it can be activated without a manual legal check.
Creating a Single Customer View with CDP
Top CDP vendors vary in how effectively they provide a Single Customer View. Differences include the information they include, how they present the information, and how easy it is to look at the information. While demographics such as phone number and address are a given, some single customer view platforms are weak in entry consent information, which details customers’ privacy preferences and how they want their information used.
Unified Profile
A Unified Profile provides a comprehensive record of all customer data and interactions. Brands use numerous platforms and systems to engage with customers across channels. These systems capture data and generate their own set of analytics. Customer Data Platforms (CDP) create unified profiles of customer data.
CDPs aggregate data from web interactions, social media, CRM, loyalty programs, in-store purchases, third-party data, and mobile apps. A CDP can associate multiple identifiers with each customer, stitching together a persistent identity retained according to the organization’s retention policy — not indefinitely, per the permission layer above.
Golden Profile
A Golden Profile, also known as a Golden Customer Profile, uses AI-assisted techniques to create a unique, master profile of each customer. It uses AI-assisted identity resolution to combine several different customer databases, including internal and external data, into a single customer profile.
CDPs create an identity master for all users, and it scales to handle millions of customers. The single customer view database adds several key attributes for segmentation, attribution, and user conversion. These attributes include cookie ID, global cookie ID, IP address, UTM parameters, custom attributes, website metadata, and more.
How a Single Customer View Gets Assembled
Vendors describe this differently, but the pipeline behind a single customer view runs the same six stages in every architecture. What separates implementations is latency, not capability — the same stages run overnight in one deployment and in seconds in another.
1. Collection with identifiers attached. Data ingestion pulls records from CRM, web and mobile SDKs, point-of-sale, contact center, loyalty, and batch files. What matters here is not volume but which identifiers each record carries: a transaction captured without an email, phone number, or loyalty ID has no path into any profile.
2. Standardization. Identifiers and attributes are canonicalized before matching runs — emails lowercased and plus-addressing normalized, phone numbers converted to E.164, addresses parsed to a postal standard, hashes aligned to one algorithm across every source. Without this stage the graph fails to connect identifiers that are the same value written two ways.
3. Identity resolution. Deterministic rules match exact identifiers; probabilistic models score likely matches from device, location, and behavioral signals; transitive logic extends a link along a chain, so a device seen with a known email inherits that person’s loyalty ID. The output is a graph of identifier clusters, each cluster representing one person.
4. Merge and survivorship. Records inside a cluster collapse into one profile. Survivorship rules decide the winner per attribute — most recent for a self-reported field like a shipping address, system-of-record priority where a billing or CRM system owns the field — and merge lineage is kept so any merge can be explained or reversed. Derived-layer values and permission-layer state are computed and resolved against the merged profile as their own downstream jobs, not as part of the merge itself, which is why each carries its own refresh interval rather than inheriting this stage’s cadence.
5. Profile serving. The profile is materialized where its consumers read it: a low-latency key-value store for real-time lookups such as in-session personalization or an AI agent reading a profile mid-conversation, and a columnar table for audience building and analysis. Sub-second point reads and analytical scans are different access patterns, which is why a real-time CDP maintains both and keeps them in sync.
6. Activation and write-back. The profile reaches channels and applications through APIs, audience syncs, and triggered messages — the data activation stage — and the outcomes return as new events. Without that return path the view records everything the customer did and nothing about how the business responded.
Stage 5 is one place where “real-time” quietly dies, and the most common one: teams often instrument the write path, confirm that events land within seconds, and never measure the read path that a campaign tool or service desk actually queries — which in many deployments is a copy refreshed once a night. Stages 2 through 4 can just as easily be the batch bottleneck; a fast write path feeding a stale, nightly-refreshed serving copy is the specific failure this stage names, not proof that earlier stages are never where the latency is lost.
Common Single Customer View Design Mistakes
The patterns below are design decisions rather than execution errors. Each one produces a profile that passes review, looks complete on screen, and then misleads whoever reads it. Sequencing errors during a build are a separate list, covered in the five-step build guide, as is the funding case in single customer view benefits.
Anonymous history discarded at sign-in. Many customers browse, compare, and abandon carts before they ever identify themselves. When the anonymous identifier is dropped at the moment of login instead of merged, the profile starts at account creation and the most predictive weeks of behavior — the research phase — are gone from every model trained on it. Fix: keep anonymous identifiers in the graph as first-class nodes and back-stitch their event history to the known profile at identification.
Events written onto the profile instead of referenced from it. Every interaction gets appended as a profile attribute, so the record grows without bound, lookups slow as it does, and segment builders present marketers with thousands of near-identical fields nobody can choose between. Fix: keep events in the event layer and expose them to the profile as bounded, named aggregates — last purchase date, sessions in 30 days, open rate by channel.
Fields with no freshness contract. A postal address observed five years ago sits beside a purchase from yesterday with identical authority, and a churn score computed once at import is still labeled current. Nobody reading the profile can tell which values still describe the customer, so each team applies its own private guess. Fix: stamp each attribute with an observation timestamp and source, publish a refresh interval for every derived field, and expose both to the systems that read the profile.
One payload for every consumer. The service desk, the ad platform, and an AI agent all receive the same full profile. The ad platform gets personally identifiable information it has no reason to hold, the agent parses several hundred fields to answer one question, and permissions are enforced by whoever happens to be reading. Fix: define a projection per destination — the minimum field set that destination needs — and bind consent and access rules to the projection, not to the underlying record.
Only the individual entity is modeled. A person-level view cannot answer who the buying unit is. B2B accounts have committees, households share subscriptions and delivery addresses, and family plans put four people on one payment method. Treating each as an unrelated individual splits purchase history that belongs together and produces both duplicate outreach and missing context. Fix: model account and household as first-class entities with their own resolution rules, linked to but distinct from the person graph.
Match confidence hidden from the systems that read the profile. A probabilistically merged link and a verified login-based match look identical once they reach the profile. A marketer sending a broad offer and a service agent confirming an order then act on evidence of unequal strength, and a wrong merge costs far more in the second case than the first. Fix: carry match method and a confidence score on the profile, and let high-risk uses — service interactions, financial data, sensitive categories — require deterministic links only.
How to Select a CDP for Single Customer View
Some CDP vendors allow you to customize SCVs so they contain the information most important to your business. Ask any potential single customer view data platform vendor if they will enable you to customize views and whether they provide easy tools to help you do that.
Other questions to ask when considering CDP vendors for single customer view platforms:
- Is the information provided sufficient for your business’s basic needs?
- Are they easy to look at? Is the user interface intuitive and easy to understand?
- Can you get a good picture of an individual customer in a segment?
- Can you search on any or all fields, or are you stuck with “fill-in-the-field” search capabilities?
- Does the CDP provider offer easy-to-use tools and code for quick customization?
- Are you able to see or search for event, behavioral, or journey data, such as purchases, visits, or emails?
- Can you see segment inclusion data?
- Can you access machine learning data such as the best time to engage, best channels, and propensities?
FAQ
What is the difference between a Single Customer View and a Customer 360?
Single Customer View (SCV) and Customer 360 (C360) are used interchangeably in most marketing technology discussions, and both refer to a unified profile of all customer data in one place. The distinction is one of scope. A Single Customer View is the technical achievement — one unified record per customer, built through customer data unification and identity resolution. Customer 360 goes further: it is the strategic application of that view, adding enrichment, historical context, predictive insight, and the activation capabilities that let teams act on it in real time. Reaching a Single Customer View is the prerequisite for a true Customer 360.
How does identity resolution work in creating a Single Customer View?
Identity resolution connects multiple identifiers (email addresses, device IDs, phone numbers, cookies) to a single customer profile by matching data patterns and linkage rules. CDPs use deterministic matching (exact identifier matches) and probabilistic matching (statistical likelihood based on behavioral patterns) to stitch together fragmented customer data. AI-assisted techniques analyze billions of data points to resolve identities accurately even when customers use different devices or channels.
Can a Single Customer View work across online and offline channels?
Yes, modern CDPs create Single Customer Views that unify both online and offline data, including in-store purchases, call center interactions, website behavior, mobile app usage, and email engagement. This requires integrating point-of-sale systems, CRM data, loyalty programs, and digital touchpoints into a central platform. The unified view enables true omnichannel marketing by recognizing customers regardless of how they interact with your brand.
Related Terms
- Customer 360 — The strategic layer built on top of a Single Customer View
- Golden Record — The authoritative master record created through data unification
- Customer Data Unification — The process of merging data sources into one profile
- Data Enrichment — Adds third-party or derived attributes to unified profiles
- Identity Graph — Maps all identifiers belonging to a single customer
- CDP vs CRM — CDP vs CRM: Learn how Customer Data Platforms and CRM systems differ in data scope, identity resolution, and use cases for marketing and sales teams.
- Customer Digital Twin — A customer digital twin is a dynamic, data-driven virtual model of an individual customer used to simulate behavior and optimize marketing strategies.
This article is also available in: シングルカスタマービュー（SCV）とは？CDPでの作り方 · Single Customer View (SCV): o que é e como criar · Référentiel client unique (RCU) : définition · Single Customer View: Aufbau, Abgleich und Nutzen