--- title: "Why Identity Resolution Projects Fail Despite Competent Delivery" url: https://www.axelerant.com/blog/why-identity-resolution-projects-fail-despite-competent-delivery published: 2026-08-05T14:53:21.726Z author: "Axelerant" source: Axelerant Thinking --- # Why Identity Resolution Projects Fail Despite Competent Delivery > Explore why identity resolution projects fail and how to fix the disconnect between single sign-on, data warehouses, and real-time activation. Identity resolution is one of the few initiatives that can be scoped well, delivered on time, and still not produce the thing it was funded to produce. This makes the post-mortem awkward because nobody did anything wrong. The vendor performed. The matching logic was sound and the merge rate looked good. Duplicate records were consolidated. And yet, a year later, the organization still cannot answer what a single member has done across its properties. The failure was upstream of the resolution work, in decisions made before the project was scoped. ## The Architecture of Fragmentation A global membership organization, backed by private equity, was 18 to 24 months into a board-approved digital overhaul. Despite having unified sign-on (SSO) in place, they lacked a common identity framework across 15 domains and five different technology stacks. Single sign-on and a customer view are often conflated, but they serve different purposes. SSO answers one question: is this person entitled to be here. It carries entitlement, not history. Without a resolution layer, the estate ends up with shared authentication and unshared observation. Every property knows who the visitor is; no property knows who the visitor has been. ### The Three Points of Failure - **Session and cookie scope:** Properties on separate domains hold their own cookies. Analytics opens a new session even for an authenticated member arriving from a sibling property. One journey is recorded as several. - **Profile fragmentation:** When attributes live in both the CRM and the property layer, they inevitably disagree. Both systems hold a partial authoritative record, and neither is fully correct. - **Missing resolution layer:** Authentication produces an identifier, but it does not stitch anonymous behavior to known behavior or reconcile duplicates. ## Why Initial Attempts Fail Failure is rarely due to incompetence; it is usually due to sequencing. Resolution operates on the records it is given. If an attempt runs while the estate is fragmented at the origin level, it is handed account records to deduplicate but never the behavioral signal to stitch. It produces a cleaner set of records describing a partial reality. Origin consolidation is an infrastructure decision, not a data decision. Because data teams rarely have the authority to propose it, the organizational gap causes the technical failure. ## The Warehouse Limitation A common move is to route everything into a warehouse. While a warehouse delivers excellent retrospective analysis, it does not deliver real-time personalization or journey automation. These require identity, consent, and behavioral signals connected at the moment of interaction, not reconciled on a nightly schedule. ## A Framework for Identity Resolution To address identity resolution effectively, organizations must follow a specific dependency order. ### 1. Unify the Origin Move properties from separate domains to path-based routes under one domain. Once properties share an origin, session continuity becomes an engineering problem rather than a cross-domain workaround. ### 2. Establish the Identity Layer Use a managed identity service to handle authentication and issue the identifier. Consent must be carried as an attribute of the resolved profile, not synced from a parallel system. This ensures that any system reading a profile sees the consent state in the same read. ### 3. Define Attribute Ownership Create a table mapping each attribute to one owning system. For example, if a member sets a preference in the account area and a service agent changes it in the CRM, the system must know which record is authoritative. Doing this before the platform lands prevents it from faithfully reproducing conflicts. ### 4. Choose the Resolution Layer Whether using a customer data platform (CDP) or a custom layer on a data lake, the choice should only be made after mapping which touchpoints produce and consume signals. Selection depends on whether real-time activation is required and if the team has the engineering capacity to maintain a custom layer. ### 5. Prioritize Activation In a mature architecture, the profile holds slow, verified truth (membership status, tenure), while the activation layer holds fast decisions (what to show in this session). This prevents temporary events from permanently rewriting the core profile and makes the system debuggable. ## The Business Case for Resolution Identity resolution is difficult to fund because it produces no immediate member-visible change. The argument should focus on what is blocked without it: - **Blocked Programs:** Milestone-triggered engagement and onboarding sequences cannot run without a resolved view. - **Attribution Accuracy:** If profiles conflict, campaign attribution is wrong. - **Waste Reduction:** Acquisition spend reaching existing members mislabeled as prospects is a quantifiable loss. ## A Simple Diagnostic Before commissioning another attempt, perform a manual reconstruction. Pick one authenticated member and reconstruct their last 90 days across every property by hand using existing systems. - If the trail breaks at a property boundary, you have an **origin problem**. - If attributes disagree between systems, you have an **ownership problem**. - If you cannot see what they consented to, you have a **placement problem**. None of these are solved by better matching logic or a second procurement. They are solved by architectural sequencing. --- Read on the web: https://www.axelerant.com/blog/why-identity-resolution-projects-fail-despite-competent-delivery