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
Most stacks accumulate identity resolution by addition. The CDP runs one join, the email platform runs another, the ad-platform integration runs a third, the analytics warehouse runs a fourth. Each was correct at deploy time; each has drifted from the others as identifiers changed and rules evolved. The result is a stack that has the same person resolved to slightly different identities in each system, which means the audiences disagree, the reporting disagrees, the activation paths fire on subtly different states, and the team spends meetings reconciling rather than acting.
The architectural fix is the customer identity service: one service that owns the resolution logic, one graph behind it, and consumer systems that call the service rather than maintaining their own join logic. The service becomes the source of truth for "who is this person across the stack" and the downstream systems read the answer rather than computing their own. The recipe is high readiness because the build is substantial, the consumer migration is real organizational work, and the service becomes load-bearing infrastructure the rest of the stack depends on, which raises the operational stakes.
This recipe builds the service, the graph, and the migration that retires the per-system joins.
A single identity resolution surface that the downstream systems read, with measurable consistency across them. The metric is identity resolution consistency across systems: the share of customer-resolution calls that return the same identity for the same input across the systems that integrate, against a baseline of cross-system divergence measured before the service shipped. The value shows up in the audiences that finally agree, in the reporting that stops disagreeing because the joins were inconsistent, and in the operational discipline of having one place to fix a resolution rule rather than four.
The second outcome is the explicit dependency the rest of the stack now has on the service. This is partly a cost (a new component that has to be reliable) and partly a benefit (the dependency is visible and managed, where previously the dependency on the divergent local joins was invisible until something broke). The trade is favorable but only if the operational discipline matches the centralization.
A backend service that exposes the resolution API, sized for the call volume the activation paths need (read-heavy, with caching where the consumer can tolerate slight staleness). Composable stacks suit this because the service slots into the layer between the warehouse and the activation systems; packaged stacks may have a vendor-provided identity layer that conflicts with a brand-built one, and the question is which is authoritative. The capability that decides whether the recipe holds is the latency budget: a resolution call that takes 200ms is fine for batch audiences and broken for real-time decisioning, and the service has to meet the worst-case caller's latency target, or that caller falls back to its own join and the centralization falls apart on the slice that matters most.
Compare the tools on Martech Stack Builder
Data engineering owns the service itself, the graph behind it, the latency the consumers can tolerate, and the reliability posture the rest of the stack now depends on. Identity or CDP ownership owns the resolution rules, the canonical identifier strategy, and the deprecation path for the legacy joins that the service is replacing. Marketing ops owns the downstream consumer migration: each system that previously maintained its own join needs to switch to the service, and the per-consumer cutover plan determines whether the service ever becomes authoritative or runs alongside the legacy joins indefinitely. Infrastructure handles the deployment posture, uptime, and the dependency the rest of the stack now has on the service. The recipe takes quarters because the service is real software, the graph migration carries real data, and the consumer migration is per-system organizational work. The technical build is the smaller part; the harder part is convincing each consumer team to retire their local join in favor of a service call.
Work in this order. The graph is the source of truth; the service is its only read interface.
Identifier graph write covers step 1, anonymous-to-known stitching steps 2, 4, 5 and 6, consent state propagation across systems step 3, and audit trail generation at the decision point step 7.
The first failure is the consumer that never migrates. A single activation system that continues to maintain its own join logic produces the inconsistency the service was built to eliminate, and the silent fallback is the failure mode the team does not notice until a reporting reconciliation surfaces it. The deprecation path for legacy joins is the discipline; ships of "the service is the new way" without a hard cutover for each consumer end in indefinite parallel operation.
The second is the latency that does not meet the caller. A real-time activation path that needs resolutions in 50ms cannot tolerate a service call that averages 150ms with a 99th-percentile of 400ms, and the caller falls back to a stale local cache or to a fresh local join and the centralization breaks. The latency budget per caller has to be sized into the service design, with caching, read replicas, or per-consumer fast paths as needed.
The third is the service that becomes a single point of failure without the resilience to be one. The rest of the stack now depends on the service; an outage on the service means activation degrades to the legacy paths or stops entirely. The reliability posture (uptime, graceful degradation, the documented fallback for each consumer when the service is unavailable) is what makes the centralization a benefit rather than an exposure. A team that ships the service without the operational maturity to run it has built a more impressive version of the problem.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
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
Normalize email at capture so [email protected], [email protected], and [email protected] all resolve to the same person, before they become three records