Identity Graph Construction
The problem an identity graph solves
A single real person generates dozens of disconnected identifiers across your systems: a GA4 user_pseudo_id (cookie-based, resets on cookie clear), a CRM contact ID, an email-platform subscriber ID, a device advertising ID, a logged-in user_id once they create an account. Without something linking these together, 'this customer' doesn't actually exist anywhere in your data — you have five separate partial views of the same person. An identity graph is the data structure (and pipeline) that resolves these scattered identifiers into clusters representing a single real individual.
Identifiers and edges
An identity graph is conceptually a graph: identifiers (cookie IDs, emails, phone numbers, device IDs, loyalty card numbers) are nodes, and an observed co-occurrence between two identifiers (the same browser session that had cookie ID X also submitted a form with email Y) creates an edge. Resolution is then a graph-clustering problem: group all identifiers connected by sufficiently strong edges into a single identity cluster, and assign that cluster a stable internal key — often called a universal ID or golden record ID — that every downstream system can reference.
-- Edges are built from observed co-occurrence events across source systems
CREATE TABLE identity_edges AS
SELECT DISTINCT
cookie_id AS identifier_a,
'cookie' AS type_a,
email_hash AS identifier_b,
'email' AS type_b,
'form_submission' AS edge_source,
MIN(event_timestamp) AS first_observed
FROM form_submission_events
WHERE cookie_id IS NOT NULL AND email_hash IS NOT NULL
GROUP BY 1, 2, 3, 4, 5Shared devices and household effects corrupt naive graphs
Deterministic edges vs probabilistic edges
Deterministic edges come from an exact, high-confidence match — the same hashed email appearing in both your CRM and your email platform, or an authenticated login event linking a cookie ID directly to an account ID. Probabilistic edges are inferred from behavioral or environmental similarity (same IP range, similar device fingerprint, similar browsing pattern) without any exact shared identifier, and always carry a confidence score rather than certainty. Most production identity graphs use deterministic edges as the backbone and probabilistic edges only to extend reach into cross-device scenarios where no deterministic link exists.
Resolution as an ongoing process, not a one-time build
New identifiers and edges arrive continuously, so identity resolution has to run incrementally: new edges either extend an existing cluster, merge two previously-separate clusters (discovered to be the same person after new evidence arrives), or occasionally force a cluster split (evidence surfaces that a cluster incorrectly merged two different people). Merges are usually safe to apply immediately; splits are riskier and often require a higher evidence threshold, since splitting a cluster that downstream systems have already built personalization or suppression logic on top of can cause visible, confusing behavior changes for end users.
What the resolved graph actually powers
Once stable, the universal ID becomes the join key for cross-device attribution (crediting a conversion on mobile to an ad click that happened on desktop), suppression (not re-targeting someone who already converted, regardless of which device they're currently using), and unified personalization (a logged-out browsing session recognizing a returning customer once enough signal accumulates). None of this is possible against isolated per-system IDs — it only exists once those IDs are resolved into a shared identity layer.
What's Next?
Identity resolution is the foundational layer beneath nearly every other cross-device and cross-channel capability in modern marketing — the specific techniques for stitching activity across a user's phone, laptop, and tablet are a direct extension of the graph-building principles covered here.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.