Unified identity downstream: what every other surface inherits | Cleon

Identity resolution in Data 360 (formerly Data Cloud) produces one thing — the unified individual — and then steps out of sight. The other four pages in this subcategory cover how that profile gets built: match rules, reconciliation rules, the keys you resolve on. This page is the other half of the story: what reads the unified individual once it exists, and why each of those readers inherits whatever identity resolution decided, correct or not.

That's the thread worth naming up front. Query, Calculated Insights, Segmentation, activation, and the agents you ground on the model do not each re-resolve identity. They all sit on top of the one resolution the ruleset performed, and they all break the same way when it's wrong — silently, and downstream, far from the rule that caused it. "Everything depends on this" is not a slogan here; it's the literal data dependency. This page traces it surface by surface, and links into the sibling subcategories rather than re-explaining them.

Query: which object you count is the first inheritance

The unified-vs-source distinction is most visible the moment you write SQL, because the two individual objects sit right next to each other and return different numbers on purpose.

ssot__Individual__dlm — the source individual. One row per individual per source. Counts records.
UnifiedIndividual__dlm — the resolved individual. One row per real person, after identity resolution. Counts people.

Every count you run inherits that choice. SELECT COUNT(*) FROM UnifiedIndividual__dlm answers "how many people do we know?"; the same count over ssot__Individual__dlm answers "how many records do we hold?" — and the second number is larger by exactly the duplication identity resolution collapsed (the relationship and the traversal are the spine of the unified individual). Pick the wrong object and the metric is wrong everywhere it's read, with no error to tell you.

And you cannot shortcut between the two. Source-to-unified is never a direct join — there is no modeled relationship from ssot__Individual__dlm straight to UnifiedIndividual__dlm. You always traverse the IndividualIdentityLink__dlm bridge in two hops, exactly as the spine page shows. That rule doesn't relax because you're now "just reporting" — a hand-written = on some shared field downstream returns an unverified mapping just as wrong in a dashboard as in a pipeline.

For the dialect itself — the namespaced identifiers, the IS NOT DISTINCT FROM nullable-key join, and how a join only resolves where the relationship is modeled — see Data Cloud SQL. The point here is narrower: the count distinction it warns about is not a query-layer quirk. It is identity resolution, surfacing at the first place you read the data.

Calculated Insights: identity is the grain underneath

A Calculated Insight is an aggregation with a declared grain — dimensions you group by, measures you compute at that grain (principle 7, compute once, retrieve many). When the dimension is the person — lifetime value per customer, orders per individual, an engagement score per person — the grain is the unified individual. The CI is only as correct as that resolution.

This is where a quiet identity failure becomes an expensive one. If one person fragmented into three unified individuals (over-split), a per-person CI computes their lifetime value three times, on three partial histories, and every consumer retrieves three wrong numbers as if they were three customers. If two people merged into one (over-merge), their orders sum into a single inflated profile. The CI did its arithmetic perfectly; the grain it ran on was wrong before it started. Recomputing the insight doesn't fix it — only fixing identity does, and then reprocessing.

That's the leverage and the risk of "compute once": the whole org retrieves the same number, so when the grain under it is wrong, the whole org is wrong in the same direction at once.

Segmentation: membership is counted in resolved people

Building a segment starts with the Segment On choice — the object each member of the resulting list is. For the audiences Cleon builds, that's almost always the unified individual, so "5,000 customers" means five thousand resolved people, deduplicated by identity, not raw source rows.

That makes segment membership a direct inheritance of identity resolution, and the failures map straight across:

Over-split inflates the audience. One person fragmented across three unified individuals can satisfy a rule three times and enter the segment three times — three sends, three frequency-cap slots, three of one human in a "unique reach" number that is now a lie.
Over-merge leaks across people. Two humans merged into one unified individual become a single member; a rule meant for one can pull in the other, and personalization or suppression built on that profile crosses a boundary it shouldn't.
Suppression depends on the same grain. "Exclude anyone who opted out" only works if the opt-out and the target are the same unified individual. Fragment the person and the suppression misses the fragment that didn't carry the flag.

A segment built on the unified individual is the payoff of resolution done right — one person, every contact point any source contributed, targetable across channels from one profile. A segment built on a broken resolution is the same machinery pointed at the wrong count, and nothing in the segment builder flags it.

Activation: keyed on the unified individual

Activation is where the model meets the world (principle 8), and what it sends out is keyed on the resolved profile. The unified individual is the audience member that activates, carrying the contact points its source records contributed — so a single resolved person can be reached on every email and phone any source knew, from one entry in the activation, instead of as several disconnected source copies.

Which means activation inherits identity last and most visibly. Over-split sends the same person the same message several times, because each fragment activates as its own member. Over-merge sends one person content — or a channel — meant for someone they were wrongly merged with, which is the moment a silent resolution error becomes a customer-visible one. The activation target was configured correctly; the individual underneath it was resolved wrong. (Consent rides the same profile, which is why it has to be modeled on the unified individual and not bolted on at the edge — see Data 360 principles, principle 9.)

Agent-readiness: a coherent profile is the prerequisite

The most demanding reader of the unified individual is an agent (principle 10). Ask an agent "what's this customer's lifetime value, and what did they last buy?" and it answers from the resolved profile — the same unified individual every other surface reads, with the same CIs retrieved and the same contact points attached.

So agent-readiness is not a feature you add after the model is built; it is the downstream consequence of identity being right. If a human analyst can get a single coherent answer about a customer from the unified profile, so can an agent grounded on it. If identity is broken — the person fragmented across three unified rows, or two people merged into one — neither can, and no prompt engineering rescues an answer assembled from a profile that resolved wrong underneath. The agent inherits the exact same resolution Query counts, CIs aggregate, segments target, and activation ships; it just inherits it under the brightest light, because it has to speak the answer back in one sentence.

The unified individual — what resolution produces, the IndividualIdentityLink__dlm bridge, and the source-vs-unified count this page traces downstream
Data Cloud SQL — the dialect where the count distinction first surfaces, and the traversal that is never a direct join
Calculated Insights — the per-person metric whose grain is the unified individual
Building a segment — membership counted in resolved people, inheriting identity directly
Data 360 principles — identity as a business decision (4), activation (8), consent (9), and agent-ready as a property of the model (10)

Reference: