The Identity Graph You License for Targeting Resolves the Same Person Differently Depending on Which Identifier You Start From

When media buyers evaluate an identity graph, the question that usually comes up first is coverage: how many people does the graph resolve, and across how many channels? That is a reasonable starting point, but it leaves out a structural detail that shapes every targeting and measurement decision downstream. A single real person can exist in the same identity graph as multiple, non-identical resolved records, depending on which identifier the system uses to begin the resolution process.

Understanding why this happens, and what it means practically, is useful before you commit a significant portion of your budget to any graph-dependent workflow.

How resolution paths work inside a graph

An identity graph links identifiers, things like hashed emails, mobile advertising IDs, IP addresses, and cookie values, into clusters that each represent one person. The clustering logic uses probabilistic or deterministic rules, or a combination of both, to decide which identifiers belong together.

The challenge is that graphs are queried from a starting point. When you onboard a CRM file, your records typically carry hashed emails. The graph walks outward from each hashed email to find associated device IDs, household signals, and other identifiers. When a publisher queries the same graph to match its logged-in users, it may start from a different identifier entirely, perhaps a first-party cookie or a phone number hash.

If the graph's linkage between those two starting identifiers is weak, probabilistic, or based on a path that passes through an intermediate identifier with low confidence, the two resolution paths may produce records that overlap imperfectly. The person your CRM describes and the person your publisher reaches may resolve into clusters that share some identifiers but not all, or that carry different attribute overlays, or that connect to different device footprints.

Why this matters for targeting accuracy

Consider a hypothetical example. Suppose your CRM file contains a hashed email for a customer who uses that email address only for account logins. The graph resolves that hashed email to a cluster that includes one mobile device ID. But that same person also browses the open web using a laptop, and the laptop's cookie has been linked to a different email address they use for newsletters. If the graph has not confidently bridged those two email identities into a single cluster, your targeting may only find that person on one device, while your frequency cap, your suppression list, and your attribution window each see a different slice of their actual activity.

From the campaign's perspective, this looks like a coherent record. The match happened, the impression was delivered, and the conversion window was applied. But the behavioral and identity data driving each of those decisions may have come from a slightly different version of that person inside the graph.

Where this shows up in measurement

Resolution path asymmetry is particularly consequential when you try to close the loop between a delivered impression and an outcome. Impression delivery logs carry the identifier that was live at bid time, often a device ID or a probabilistic cookie. Your conversion data arrives through a different channel, perhaps a pixel fire associated with a login event, or a CRM update tied to an email address. Stitching those together requires the graph to bridge two identifier types that may have entered the graph through different resolution paths.

If those paths produce clusters with a gap between them, even a small one, the join fails silently. The impression and the conversion both exist in your data, but they do not connect, and the conversion goes uncredited. This is one reason incrementality results sometimes look weaker than expected even when the campaign reached the right audience: the measurement infrastructure is working with a different resolved version of your audience than the targeting infrastructure used.

What to ask a graph vendor before you commit

Most graph vendors will show you reach numbers and match rates. Those metrics describe the output of resolution without describing the consistency of that output across different entry points. A few questions worth adding to your evaluation process:

First, ask how the vendor defines a resolved person record when the same individual appears to enter the graph from more than one identifier type. Do those paths always merge into a single cluster, or does the graph maintain multiple clusters that a downstream system must reconcile?

Second, ask whether the graph's resolution logic produces the same cluster membership if you start from a hashed email versus a mobile ID for the same individual. Vendors with strong deterministic linking, where a confirmed shared signal ties both identifiers to one person, will be able to answer this more precisely than vendors whose linking is primarily probabilistic at that junction.

Third, ask how the vendor handles identifier changes over time. A person who resets their mobile advertising ID, or who switches email providers, may fall out of a cluster and reenter the graph as a partially new record. Understanding the cadence at which clusters are refreshed tells you something about how stable your targeting population actually is across a multi-week flight.

A practical way to pressure-test your current graph

If you are already working with an identity resolution partner, a simple internal exercise can surface resolution path inconsistencies. Take a small subset of your CRM file, perhaps a few hundred records, and ask your vendor to resolve them twice: once starting from hashed email, and once starting from any associated device IDs you have collected through your own tag infrastructure. Compare the resulting clusters for that population. If the device footprints, household associations, or audience attributes differ meaningfully between the two resolved outputs, you have evidence that the graph produces materially different versions of the same person depending on where the resolution starts.

This is not a reason to abandon identity resolution. It is a reason to calibrate your expectations about what a match actually guarantees, and to be specific about which resolution path your targeting workflow, your suppression logic, and your measurement layer each use. When those three systems start from different identifiers, they may be working with different versions of your audience without any of them flagging an error.

The graph is not wrong in any single query. The complexity is that it can be consistently right in each individual lookup while still producing outcomes that do not align with each other across a campaign.