The pattern that defines how new edges land in the identity graph: synchronous at the point of resolution, deferred in a downstream job, or some hybrid that prioritizes load-bearing edges. The write semantics determine whether the rest of the stack can trust the graph at decision time, and most stacks default to deferred-batch in a way that fails the use cases that motivated the graph in the first place.
The capability a stack needs to run this pattern, and the vendors that provide it, on Martech Stack Builder.
Resolve individual visitors to the account they belong to, so the buying committee shows up as one account rather than scattered anonymous leads
Connect the same person across phone, laptop, and tablet using signals you can stand behind, with an honest fallback when you cannot
Run identity resolution behind one service rather than each downstream system maintaining its own join logic, so a single resolution rule survives the next stack change
Merge the customer records that drifted apart over time, with the matching rules, the merge decisions, and the rollback path that lets a wrong merge be undone
Normalize email at capture so [email protected], [email protected], and [email protected] all resolve to the same person, before they become three records
Emit a server-set first-party identifier the brand controls, so the customer can be recognized after Safari ITP, third-party cookie deprecation, and the next round of browser changes still to come
Resolve several people at one address into a household where the buying unit is the household, without letting one member's data quietly drive another's experience
Use probabilistic signals when deterministic identifiers are absent, carrying the confidence bound forward so the systems acting on the match know whether they are reading a high-confidence resolution or a guess