Every firm that buys a Customer Data Platform is sold the same picture: one screen, one customer, everything you know about them in a single view. Then the platform goes live, and the picture is stranger than promised. Your best client shows up three times. Your entire website audience shows up as a wall of anonymous cookies that never quite connect to anyone. The “360° view” is 360° for the customers you already had nailed down, and roughly zero for everyone else.

This isn’t a configuration mistake. It’s the nature of the problem, and almost nobody explains it honestly before you’ve signed the contract. So here is the honest version.

Identity resolution is not one problem. It is two, with two completely different key regimes, and the tooling papers over the seam between them. One half — your account and CRM data — is a strong-key, near-solved problem that regulation basically does for you. The other half — your digital and behavioural data — is keyless, cookie-based, and mostly unresolvable, no matter what you spend. A platform like Salesforce Data Cloud (marketed as Data 360), Adobe Real-Time CDP, or any of their peers doesn’t magically resolve identity. It materializes the joins you define — and the single most valuable join, from your known customers to your anonymous traffic, is a fragile bridge that most of your traffic never crosses.

Understand where that bridge is, and where it can’t exist, and you can build a resolution programme that works. Miss it, and you’ll spend a year and a seven-figure budget being surprised.

First, the vocabulary — because most confusion is a vocabulary problem

A record is a single row from a single system: one account, one contact, one web session. A person is the real human several records point to. Identity resolution is the work of collapsing many records into the one person behind them. Sounds trivial; the entire difficulty is in how you decide two records are the same person.

You decide it on keys. A strong key is an identifier stable and unique enough to match on by itself — a tax ID, a verified account number. If two records carry the same strong key, they’re the same person, full stop. That’s a deterministic match. A soft signal is an attribute that hints but can’t stand alone — a name, an address, a date of birth. Two “R. Smith at 14 High St” records might be one person or two unrelated people in the same building, so you never merge on a soft signal by itself; you AND several together and hope, which is fuzzy matching.

When the platform decides two records match, two different rules fire. A match rule decides whether they’re the same person. A reconciliation (or survivorship) rule decides which value wins when the matched records disagree — if one says “Bob” and the other says “Robert,” which name lands on the final record. The output is the golden record (Salesforce calls it the Unified Individual): one row per person, with the conflicts resolved and the loose data attached.

Hold those apart — strong vs soft, deterministic vs fuzzy, match vs reconcile — and everything below stays clear.

The maturity ladder, written as data footprints

It helps to name the levels of resolution, because they are genuinely different capabilities, not degrees of effort. The trick is to define each one as a footprint you can write in a single sentence — which fields, from which sources, at which cadence, matched by which method — rather than as an ambition like “single view.” The levels are cumulative: each contains the one below.

Everything that follows is really about two things: doing L1 and L2 properly on the account side, and understanding why the digital side refuses to behave like either.

Part A — the account world, where resolution is (almost) easy

Start with your CRM and account data, because this is the half that works. In a regulated business — a wealth manager, a bank, a broker — every account carries a verified strong key, because the law made you capture it. KYC/AML rules mean a validated tax ID (an SSN in the US, an NI number in the UK) sits on every account you ever opened. That single fact makes L1 almost mechanical. Here is the whole process:

1. Pull every account record from every system — each custodian feed, the portfolio system, the CRM. You now have a messy pile, one row per account. Robert appears five times because he has five accounts.
2. Find the strong key on each row — the verified tax ID that KYC captured.
3. Normalise it — strip dashes and spaces so the same number looks identical everywhere.
4. Group every row that shares the same key — this is the actual resolution. Five rows carrying Robert’s tax ID become one group.
5. Build one golden record per group — “Robert Smith, these five accounts, £850k total.”
6. Refresh on a schedule — re-run steps 1–5 nightly, because accounts open and balances move.

That’s L1. It resolves each person to themselves. Note its two hard boundaries, because they define everything L2 has to do: it cannot connect different people (a household shares no single key), and it cannot see anyone with no key at all (a prospect who never opened an account).

L2 picks up both of those. It assembles the household — spouse, trust, dependants — who each carry their own separate tax ID and so look like unrelated strangers to L1. Crucially, L2’s anchor is still deterministic, not fuzzy: the edges that bind a household are recorded facts nobody ever rolled up — two people named on one joint account, the grantor and trustees on a trust, a beneficiary designation, a verified email shared between a prospect record and a client. You match on those exact edges first; fuzzy signals (shared surname plus address) are only the residue that mops up what no recorded edge reached. L2 also reaches the linkable prospect — the lead who left a real email — and ties their history to the client they became.

That’s the account side. Two clean, powerful levels, both running in batch, both anchored on hard facts. If your business is entirely account-based, this is most of the job.

How a platform actually builds the golden record

It’s worth seeing the machinery, because the mechanics answer questions people get wrong — especially who triggers resolution and when. I’ll use Salesforce Data Cloud as the worked example; the shape is the same across vendors.

Data arrives through data streams — connectors that pull each source system in. It lands raw, keeping all its columns, in the data lake. Then you map each source’s fields into a shared data model — but only the fields you map make it in, and they’re placed by meaning, not dumped into one wide table. Tax ID from every stream maps to the one identifier object; email to the one email object; balance to the account object. Fields you don’t map simply stay in the lake, queryable but outside the profile.

Then the identity-resolution ruleset does the work: a match rule (“same person when the tax ID matches exactly”) and reconciliation rules (“when they disagree, the custodian’s value wins”). It groups the matched records and writes a Unified Individual — the golden record — with a unified ID that everything else points to.

Now the part people misunderstand. Nobody triggers this per record. An administrator configures the ruleset once and sets a schedule — typically every 24 hours. The platform then runs the match-and-merge automatically on that cadence, and you can also kick it off on demand. Data ingests continuously; resolution reconciles in scheduled batches. The unified profile is best understood as a materialized view: a computed, stored, periodically-refreshed result. The nightly job is the refresh. The fast profile lookups your dashboards and advisors use are cheap reads off that already-materialized result — they never re-run the match. This is exactly why L1 and L2 are “batch,” and why serving the profile live in-session (L3) is a separate concern: L3 just reads the materialized record quickly; it doesn’t resolve anything in the moment.

A worked example, two streams, three fields each

Make it concrete. Two sources:

Map by meaning: both SSNs to the identifier object (the match key), both Names to the name field, Email to the email object, Balance to the account object. The match rule sees the same SSN on both rows and links them into one Unified Individual. Only one field actually conflicts — Name — so a reconciliation rule picks the winner (say the custodian is authoritative → “Robert Smith”). The result:

One person, the conflict resolved to a single value, the unique fields from each stream attached. Not six columns glued together — one golden individual with related data hanging off the key that matched. That is L1 in miniature.

Part B — add the web stream, and watch the model break

Everything above is tidy because every record carried a strong key. Now bring in the website — Adobe clickstream, or any behavioural feed — and three assumptions collapse at once.

Web data is a different kind of data. The CRM and custodian rows were profile data: one row per person. Web data is engagement data: one row per click, millions of rows, append-only. It maps to a different part of the model — engagement objects, stored as a time-series hanging off a profile — and it never reconciles into golden fields. There is no “winning value” for a page view; events just accumulate.

Its key is a cookie, not a tax ID. Each web row carries an ECID — a device/cookie identifier — and no tax ID, no email, nothing that reaches a person. So your L1 match rule cannot touch it. On its own, a cookie ID forms a little anonymous device profile that sits completely apart from your golden records. The clicks are in the system; they’re just not attached to anyone.

It only joins a person through a bridge. The link forms at exactly one moment — when the visitor logs in or submits an email — producing a record that carries both the cookie and a known identifier:

That email already sits on Robert’s golden record. So a match rule on email links the cookie to Robert, and at the next resolution run every event under that cookie — including the earlier anonymous page views — attaches to him. Notice the match chained cookie → email → person, never cookie → tax ID. Web data can only ever join through a soft identifier that also appears on the known profile. That is the whole game, and it is fragile.

This is also the moment that creates the pull toward real-time. Attaching a visitor’s history overnight is still batch — fine. But the reason firms ingest web data is to act on it in the session (“this client is on the transfer-out page right now — flag it”). Acting live means resolving and serving the profile at the instant of the click, which is real-time — L3, a genuine re-architecture, not a bigger L2.

The gotchas — this is the part worth printing out

Everything above is mechanics. The following are the traps that turn a well-funded programme into a disappointment, and every one of them comes from mismanaging the seam between the two worlds.

The denominator trap. The first instinct is to measure coverage against all traffic — “we resolve 4% of visitors, the project failed.” That number is meaningless, because most of that traffic is one-time anonymous visitors who will never identify themselves and never could be resolved by anyone. Measure coverage against the linkable population — records carrying at least one resolvable identifier — not against raw hit volume. Get the denominator right or every metric you report is noise.

The false-merge trap. It is tempting to rank resolution work by how much coverage it lifts. Wrong axis. Precision is the gate; lift is only the ranking. A rule that lifts coverage but occasionally merges two different people is pulled regardless of its lift, because in regulated data a false merge isn’t a rounding error — it mis-states a client’s assets, breaks householded billing, and can expose one person’s holdings to another. That’s a data-protection incident. Always show lift and precision together, and keep discriminators (different DOB, different advisor) that block a merge, not just ones that make it.

Cookie instability. Even the resolvable web data fights you. One real person is many cookie IDs — a phone, a laptop, a cleared cache, Safari’s tracking prevention capping cookies at seven days, the death of third-party cookies entirely. So a single person’s behaviour is scattered across a dozen device profiles, and only the ones where they logged in ever get stitched. The behavioural data is fragmented against itself before you even try to tie it to a person.

Consent gating. Under GDPR and PECR, collectable is not the same as usable. If the visitor didn’t accept marketing cookies, much of that behavioural data either isn’t collected or can’t be used for targeting. Your addressable digital pool is smaller — and legally fenced — than the raw volume suggests.

The anonymous-majority reality. Say it plainly, to yourself and to your stakeholders: the bulk of digital traffic is structurally unresolvable. There is no key, now or ever, to tie a one-time anonymous visitor to a person. This isn’t a coverage failure to fix; it’s a boundary to accept. Resolve the linkable slice, treat the rest as aggregate analytics, and stop counting the unresolvable majority as a miss.

The batch-versus-real-time scope creep. The single most common way an identity programme misses its date is confusing “attach the history overnight” with “act on it in the moment.” The first is batch and you already have it. The second is a streaming re-architecture with its own cost and risk. Decide which live decisions genuinely need real-time — very few do — and hold everything else in batch.

And the meta-gotcha: buying the platform is not doing the work. A CDP gives you the machinery to materialize joins. It does not decide which joins are correct, what precision bar to hold, which denominator to measure against, or what a resolved profile is allowed to be used for. That judgment is the actual project. The platform is necessary and nowhere near sufficient.

What good actually looks like

The sequence matters, and it runs in one direction. Resolve the known base first — L1, on the strong key regulation already handed you; it’s the cheapest, highest-certainty win and everything else depends on it. Then extend to the household and the linkable prospect — L2, on recorded edges, precision-gated. Then bolt on the engagement layer and let it attach at the identify-moment — accepting that the anonymous majority stays anonymous. Only then, and only where a live decision truly demands it, go real-time — L3.

Measure the whole thing as lift held at precision, against an honest denominator. Not “single view,” not “360°” — a number, against a baseline, with the precision bar beside it.

The industry sells identity resolution as a product you switch on. It’s not. The platform materializes the joins; the judgment about which joins, at what precision, over which population, under which governance, is the work — and it’s the work no vendor can do for you. Get that judgment right and the 360° view is real for everyone it can possibly be real for. Skip it, and you’ve bought a very expensive way to see your best customer three times.

Frequently Asked Questions