Identity Graphs 101: MAID-to-HEM, CTV IDs, and Household Resolution

"Identity graph" spans a simple email-to-MAID lookup and a thousand-node resolution engine with confidence scoring. Buyers who cannot tell the difference overpay for lookup tables or underbuy measurement infrastructure. This guide explains what graphs do, deterministic vs probabilistic resolution, household linkage, and evaluation: referencing MAID Feed, Global Mobility identity layers, Euclidean Feed, and CTV/ACR. Pair with MAID identity graph diligence and cross-channel measurement for privacy-first advertisers.

The Atomic Units: HEM, MAID, CTV ID

HEM is a one-way hash of an email from login or purchase. MAID is IDFA/GAID per device: one consumer may have several. CTV ID is household-scoped from ACR or streaming SDK: it represents the TV, not the viewer. Mature graphs add IP fingerprints, postal household IDs, and declining cookie bridges where they still exist.

Activation without documenting which ID type powers each workflow creates compliance and performance drift. Map permitted use per identifier in the DPA before production sync.

Deterministic vs Probabilistic Resolution

Deterministic resolution uses shared authentication (same email on mobile app and TV app) typically 0.95+ confidence. Probabilistic fills gaps via IP overlap, device-graph co-occurrence, postal targeting at 0.4-0.7. Serious graphs expose scores so buyers threshold by risk:

• Suppression: 0.6+ often sufficient.
• Brand targeting: 0.7+ common.
• Measurement/attribution: 0.85+.
• Regulated outbound: deterministic-only unless counsel approves probabilistic.

The Household Resolution Layer

Household layer answers who lives together: postal anchor, home IP co-occurrence, device co-location, panel validation. It unlocks CTV attribution: living-room impression tied to kitchen-table mobile search. Without household linkage, cross-channel measurement fragments. See CTV ACR 101 for exposure mechanics.

Euclidean Feed provides deterministic CTV ↔ MAID ↔ HEM crosswalks at household grain for buyers who need production joins, not flat-file experiments.

Evaluating an Identity Graph

Three practical tests beat marketing slides: (1) scale against your audience. US MAID-to-HEM depth plus international coverage where you activate; (2) hashed CRM seed match by ID type and confidence tier; (3) activation surface. DSP, CDP, clean room vs S3-only files. Run seed match testing before contract signature. In a MAID-to-HEM identity graph, confidence tiers and last-seen timestamps make those tests more informative than a single count of resolved identifiers.

Winning 2026 deployments: deterministic-first graph, disclosed probabilistic tiers, household layer validated against panels, hooks into every channel, not a dormant file. Cross-read B2B contact database evaluation for CRM-side discipline.

Consent, Refresh, and Compliance Posture

Graphs joined to location or health outcomes need sensitive-category exclusions and documented consent chains, FTC location orders set buyer expectations. Require weekly refresh for activation cadences; quarterly refresh underperforms when MAIDs churn. Review sourcing methodology and data brokers post-FTC orders in procurement.

Read the Cluster Size Distribution

A graph is a set of clusters, each grouping identifiers believed to belong to one person or household, and the distribution of cluster sizes tells you more about quality than any headline match rate. Clusters that are too small mean the graph is failing to connect identifiers that belong together, so the same person is reached repeatedly as several strangers. Clusters that are too large mean it is merging people who should be separate, which is the more damaging error because it carries messaging and suppression across household or personal boundaries.

Ask for the distribution rather than an average, and pay particular attention to the largest clusters, which are where over-merging concentrates. Then sanity-check the shape against what you know about real households in your target population. A graph whose typical cluster is far larger than a plausible household is resolving something other than households, and no match-rate figure will reveal that.

One practical consequence follows from all of this: ask how a graph handles a household that changes. People move, join, and leave, and a cluster built over years will keep an identifier attached long after the relationship ended unless something actively retires it. Ask what evidence causes a link to be removed rather than only added, and how quickly. A graph that only ever accumulates links will show excellent match rates and slowly drift away from describing anybody in particular.

Read the Cluster Size Distribution, Not the Headline Match Rate

The three practical tests all reward a graph for finding more links, and none of them punishes it for finding links that are not there. Over-linking raises the match rate and lowers accuracy at the same time, which makes it invisible in a single number. Ask for the distribution of cluster sizes rather than an average, covering MAIDs per HEM, HEMs per household, and devices per CTV ID, then read the tail. Clusters far larger than a plausible household or a plausible person's device set usually mean the graph stitched through shared infrastructure such as office wifi, building-level NAT, or a resold handset, and every audience built from those clusters carries strangers.

The mirror test is a decoy set. Seed your file with records that should not resolve, such as addresses you know changed hands, devices you know were wiped, and mailbox addresses that have never been used anywhere. Deterministic tiers should return almost nothing against them. Probabilistic tiers will return something, and the confidence attached tells you how the vendor's scores behave when there is no true link to find. A graph that hands a decoy the same confidence it hands a login bridge is tuned for coverage, and the thresholds you set by use case will not mean what you think they mean.

Then measure stability. Run the same seed twice, spaced by the vendor's refresh cycle, and diff the identifiers returned for each row. Some churn is real, since devices reset and mailboxes go dormant. What you want to know is whether a link disappeared because its underlying signal expired or because a model re-ran and reached a different answer. Ask whether links carry first-seen and last-seen dates, and whether retired links are tombstoned rather than dropped, because suppression and frequency capping both fail quietly when an identifier leaves the graph without a trace. Seed match testing covers running one cohort through a vendor more than once.