
Short answer
Quick answer: deduplicating and stitching your own users → your CDP's resolution or a warehouse-native build. Matching your users against the ad ecosystem's identifiers → LiveRamp-class graphs, priced accordingly. Pricing shapes September 2026 — enterprise identity is quoted; verify everything live.
The job: recognize that the anonymous visitor from Tuesday, today's app login, and the support email from last month are one person, and maintain that mapping as evidence accumulates — including when it turns out to be wrong. The output isn't a dashboard; it's the profile every downstream system trusts. Get it wrong quietly and every "personalized" message, every metric, every audience inherits the error — which is why the merge rules deserve a written log, not a vendor default. Our identity merge decision log is that artifact.
| Tool | Size class | Best for | Pricing shape |
|---|---|---|---|
| Segment Unify | CDP-native | Teams already on Segment | Bundled, MTU-scaled |
| mParticle IDSync | CDP-native | Mobile-heavy enterprises | Quoted with platform |
| dbt identity models | Warehouse-native | SQL-auditable resolution | Engineering time |
| Hightouch | Warehouse activation | Syncing resolved profiles out | Destination/row tiers |
| LiveRamp | Enterprise graph | Cross-company ad matching | Enterprise contracts |
| Neustar (TransUnion) | Enterprise graph | Brand/agency ecosystems | Enterprise contracts |
CDP-native (Segment Unify, mParticle IDSync): if a CDP already collects your events, its resolution layer is the default answer — the graph lives beside the data, merge rules are configurable, and no second vendor appears. The audit question: how do merges get reviewed, and what does un-merging do downstream? Demo that before trusting it; our CDP comparison carries the fuller demo script.
Warehouse-native (dbt models + Hightouch activation): resolution as SQL you own — deterministic joins over login keys, emails and device tables, versioned in git, auditable by anyone who reads SQL. It's the composable answer, and its honest cost is that engineering owns an identity model forever. Hightouch then syncs the resolved profiles to the tools that act. Strongest where warehouse discipline already exists; a science project where it doesn't.
Enterprise graphs (LiveRamp, Neustar): these match your customers against identifiers you don't hold — publisher audiences, ad platforms, offline data — via contracts and clean rooms. Genuinely necessary for large advertisers; genuinely irrelevant for deduplicating your own signups, which is the mis-purchase this section exists to prevent.
Downstream of all three sizes: activation platforms consume the resolved profile. Questera runs lifecycle journeys on one contact graph and inherits whatever identity quality you feed it — which is why we publish the merge-log guide instead of pretending resolution is a solved input. Garbage identity in, confidently personalized garbage out, on any platform including ours.
Deterministic matching (shared verified keys) is precise, explainable, and incomplete — it can't join what never shared a key. Probabilistic matching (inference from device and behavior signals) closes coverage gaps and introduces a real error rate that lands as someone else's receipts in a stranger's inbox at the tail. For first-party lifecycle messaging, default deterministic and accept the coverage gap; reserve probabilistic for advertising reach where a wrong match wastes an impression, not trust. Whatever you choose, write the choice down with its review rule — that single page outlives every vendor in this post.
What is the best identity resolution software?
Your CDP's graph or a warehouse-native build for first-party identity; LiveRamp-class graphs only for cross-company advertising problems. Size the problem before the purchase.
Deterministic or probabilistic?
Deterministic for lifecycle messaging (auditable, safe); probabilistic where coverage beats precision (ads). Mixing them without a written policy is how wrong merges become support tickets.
Do I need to buy anything at all?
Maybe not — most teams' identity problem is merge rules and discipline inside tools they already run. Buy new software when the problem outgrows the rules, not before the rules exist.
See it in action

