Achieving a single customer view is not a one-time project. It's an ongoing process that requires constant adaptation. Marketing leaders must recognize the dynamic nature of customer data and adjust their strategies accordingly.

The “single customer view” (SCV) is a phrase that every CDP vendor loves to throw around. Some alternative phrases that are tossed around are “unified view”, “golden record”, “unified profile” and some other combinations of these.

It sounds simple. There is one magical dashboard where you can see everything about a customer.

The reality is more complicated. In fact, SCV (and all other phrases) is not one single problem. It is two distinct problems that get conflated in vendor marketing.

The “Who” Problem: Identity Resolution

The first challenge is figuring out who this person actually is. That means stitching together multiple identifiers that could belong to the same person:

• Email addresses
• Device IDs
• Loyalty program numbers
• Social handles
• Cookies and session IDs

This is messy work. People change devices. They clear cookies. They use different emails for different contexts. You rarely have a perfect match. Identity resolution is often probabilistic. At best, you get a confidence score, not absolute certainty.

This step is upstream of any “view” of the customer. If you get this wrong, everything downstream is flawed.

Where ID Resolution Lives in the Enterprise

In large enterprises, identity resolution often happens upstream of your CDP, inside a data warehouse, MDM, or dedicated identity service. Sometimes it is in a dedicated identity graph.

Why?

• It needs to serve every consuming platform, not just marketing.
• It requires tight governance and sometimes human stewardship.
• It shouldn’t be reinvented in every application that needs to know “who’s who.”

But in practice?

• Few enterprises have a live, governed identity graph.
• CDP vendors will happily tell you they do it all and often build their own graph to stay sticky.
• You end up with multiple “golden records” such as one in the CDP, one in CRM, one in the DWH and all slightly different.

The “What” Problem: Building the View

Once you know who you are talking about, you still need to assemble a usable view of that customer. That means:

• Pulling in data from multiple systems
• Normalizing formats
• Reconciling conflicting values
• Presenting the right attributes in a way that is actually helpful for activation

This is not just a dashboard exercise. The “view” has to be built for the specific use case, whether that is customer service, campaign targeting, or analytics. A marketing team may need a different “view” than the service desk. So, a marketing SCV is not the same as a service SCV or an analytics SCV. They’re all valid, and they all differ.

This is a data aggregation and presentation problem. It is separate from identity resolution, but it depends on it.

Where The SCV Lives in the Enterprise

The CDP may consume the resolved IDs, but it does not necessarily perform the resolution itself.

The “view” is typically built within the CDP or activation layer, which has more context on the use case. This is where the Single Customer View lives: a rolled-up, activation-ready profile of attributes, events, and engagement history.

The SCV is:

• Purpose-built for the use case (e.g., activation vs. analytics vs. service)
• Often assembled inside the CDP or activation layer for marketing execution
• Fed by the upstream identity graph; if you have one

Of course, most CDP vendors will happily tell you they do both. Some actually do. Many do not. The challenge is that marketing messages blur these boundaries, making it sound like one clean capability.

The Real Story

The real myth is that “SCV lives in one place.”

In a large enterprise, identity resolution and SCV assembly are separate (and should be). One is a governance-heavy who’s who, the other is a context-specific what we know.

If you try to cram them into the same function, you either:

• Slow down execution while waiting on upstream governance, or
• Erode trust by having each team’s SCV stitched differently

If you believe SCV is just one feature in a CDP, you will overestimate what you are buying. You may also end up with redundant or conflicting capabilities across platforms.

Separating identity resolution from SCV assembly lets you:

• Buy the right tool for each job
• Avoid duplicate data processing
• Keep each capability close to where it is best executed

What to Do

• Clarify roles: Who owns the identity graph vs. who assembles the SCV?
• Expect multiple SCVs: Align them where it matters, but avoid forcing a single, false truth.
• Challenge vendor claims: Ask, “Are you resolving identities, assembling SCVs, or both and how?”

Because in the real world, your “single” view will always be a moving target. The goal isn’t one canonical profile forever; instead, it’s the right profile, in the right place, at the right time.

Every vendor claims to deliver the perfect SCV. At RSG we know the reality is more complicated. If you want a clear-eyed take on your options, let’s talk.