Sign in Subscribe

Stop Resolving Identity in the Wrong Place

Stop Resolving Identity in the Wrong Place

An AEP Architecture Framework for Getting That Decision Right

By Stephen Tettey | Multi-Solutions Architect, Adobe Experience Platform and Adobe Journey Optimizer

Part 3 of 3 in the Identity Graph Linking Rules series

Parts 1 and 2 of this series covered how Identity Graph Linking Rules work, when to use them, and what a real multi-brand enterprise implementation looks like when the standard configuration is not enough. If you have not read those posts, they provide useful context. But this post is designed to stand alone.

It addresses a question that sits upstream of any configuration decision: where does identity resolution actually belong in your architecture?

Most teams never make this decision deliberately. They make it by default, usually by starting in the tool they already have access to and building from there. The result is identity logic that is scattered across systems, duplicated in places, missing in others, and nobody is entirely sure which system is the authoritative source of truth. When something breaks, and it will, diagnosing the problem requires understanding three or four systems simultaneously.

This post offers a framework for making that decision on purpose rather than by accident.

The Boundary That Matters Most

There is one distinction that should anchor every identity architecture conversation, and it is one that gets blurred surprisingly often in AEP implementations.

Adobe Experience Platform is not an identity provider. It is not a Master Data Management system. It is a customer data platform built to ingest, unify, segment, and activate customer data. Its identity capabilities, including the identity graph and linking rules, exist in service of that core purpose. They are designed to resolve identity well enough to build accurate profiles and reliable segments. They are not designed to be the system of record for enterprise identity governance.

This is not a criticism of AEP. It is a description of what the tool is built to do. An MDM system is built for something different: managing the canonical representation of an entity, whether a customer, a product, or an account, across all systems in an organization. A Customer Identity and Access Management platform is built for something else again: managing authentication, authorization, consent, and credential lifecycle. A web data layer is responsible for capturing and structuring identity signals at the point of interaction before they enter any downstream system.

Each layer has a job. The architecture question is which layer should own which part of the resolution problem.

Four Layers, Four Responsibilities

Think of identity resolution as a stack with four distinct layers. Each layer can perform some degree of resolution. The mistake most teams make is either collapsing all four into one or leaving the boundaries undefined so that each layer resolves identity independently with no coordination between them.

Layer 1: The Web Data Layer and Tag Management

This is where identity signals are first captured. The web data layer, typically implemented through Adobe Experience Platform Web SDK or a tag management system such as Adobe Experience Platform Tags, is responsible for collecting the ECID, any authenticated identifiers that are available at the point of interaction, and any consent or preference signals tied to that session.

Resolution at this layer is limited but important. The data layer should be configured to pass authenticated identifiers alongside the ECID whenever a user is logged in. It should never pass placeholder or invalid identity values. It should enforce the identity namespace conventions that have been defined for your AEP implementation so that every event arriving in AEP carries identities in the correct format and namespace from the start.

Poor identity architecture at the data layer creates problems that no downstream system can fully correct. Garbage in, garbage out applies with particular force to identity data.

Layer 2: Customer Identity and Access Management

A CIAM platform manages how customers authenticate with your digital properties and how their credentials and consent are maintained over time. Platforms in this category handle things like single sign-on, multi-factor authentication, password management, account linking when a customer has multiple login methods, and consent lifecycle.

The resolution responsibility at this layer is narrow but authoritative. When a customer logs in through your CIAM platform, that platform should be the source of truth for whether the authenticated identity is valid and which canonical identifier it corresponds to. If a customer has multiple login methods, say an email login and a social login, the CIAM platform should resolve those to a single canonical customer identifier before that identifier is passed downstream to AEP.

If your CIAM platform is performing this resolution correctly, AEP should be receiving a clean, pre-resolved person identifier on every authenticated event. That changes the role of AEP's linking rules considerably. They become a safeguard against edge cases rather than the primary resolution mechanism.

Layer 3: Master Data Management

An MDM system manages the canonical record of your customer entities across all systems in the organization. Not just digital touchpoints but CRM, billing, customer service, loyalty, and any other system that holds customer data. The MDM is where duplicate detection, golden record creation, and cross-system identity matching happen at an enterprise scale.

The resolution responsibility at this layer is the broadest of the four. An MDM that is functioning correctly should be producing a clean, deduplicated, canonical customer identifier that can be shared across all downstream systems, including AEP. When AEP receives data from your CRM, your loyalty platform, your call center system, and your e-commerce platform, all of those records should already carry the same canonical customer identifier that your MDM has assigned.

If your MDM is doing this job, AEP's role is not to resolve identity across those systems. It is to ingest the pre-resolved identities and build profiles from them. Linking rules in this scenario are a backstop for edge cases, device-based identity, anonymous sessions, and real-time events that have not yet passed through MDM reconciliation.

If your organization does not have an MDM, or if your MDM is not producing clean canonical identifiers for all the data sources feeding AEP, then AEP will inevitably be asked to perform resolution work that it was not designed to own. It can do some of this work reasonably well through linking rules and merge policies. But it will do it without the governance infrastructure, the duplicate detection logic, and the cross-system visibility that an MDM brings to the problem. Know the difference between what AEP is doing and what an MDM would do, and make sure your stakeholders know it too.

Layer 4: Adobe Experience Platform

AEP's identity resolution capabilities are designed to operate on the data it receives after the upstream layers have done their part. The identity graph links identifiers across events and profile fragments to build a unified view of the customer. Linking rules constrain that graph to prevent collapse. Merge policies govern which data wins when fragments conflict.

The resolution AEP performs is fundamentally additive. It is not checking your CRM for duplicates. It is not validating credentials. It is not managing consent lifecycle. It is taking the identifiers it receives, linking them according to the rules you have configured, and assembling a profile from the resulting graph.

This is powerful for what it is designed to do. It is limited when asked to compensate for work that should have happened in a layer upstream.

How to Make the Decision

The framework is straightforward in principle. For each identity resolution problem you are trying to solve, ask which layer is closest to the source of truth for that problem.

Authentication identity belongs in your CIAM platform. If a customer has multiple login methods and you need to resolve them to a single canonical person, that resolution should happen in your CIAM before the identifier reaches AEP.

Enterprise entity identity belongs in your MDM. If you need to reconcile a customer record across your CRM, your loyalty platform, your billing system, and your call center, that reconciliation should happen in your MDM. AEP should receive the output of that reconciliation, not perform it.

Real-time behavioral identity, meaning the problem of linking anonymous device sessions to authenticated profiles in real time, belongs in AEP. This is the problem AEP is specifically built to solve. The identity graph, the ECID, and linking rules exist precisely for this purpose.

Cross-channel profile assembly belongs in AEP. Once upstream systems have produced clean canonical identifiers, AEP's job is to assemble the full customer profile from all the data sources that carry that identifier and make it available for segmentation and activation.

The corollary: if you are using linking rules to compensate for problems that should have been solved upstream, your implementation will work but it will be more fragile, harder to maintain, and more likely to produce edge cases that are difficult to diagnose. Linking rules are not a substitute for CIAM-level account linking or MDM-level deduplication. They are a complement to those capabilities for the specific resolution problems that belong in the CDP layer.

It is also worth noting that this principle applies broadly across CDPs and identity platforms, not just AEP. The same resolution layer logic holds regardless of which customer data platform your organization uses. The specific feature names change. The underlying architectural discipline does not.

The Sandbox Architecture Decision

Part 2 of this series closed with a note on sandbox architecture that deserves to be developed further here, because sandbox strategy and identity strategy are the same decision viewed from different angles.

The question of whether multiple brands, business units, or markets should share an AEP sandbox is not primarily a technical question. It is a data governance question. The technical answer is that a shared sandbox creates shared identity infrastructure, shared namespace configuration, and shared profile volume. Everything that touches identity in AEP is shared when the sandbox is shared. As the multi-brand implementation in Part 2 demonstrated, that shared infrastructure can produce identity collapse that is extremely difficult and expensive to remediate after the fact.

The governance question is: does the organization need real-time cross-brand identity resolution, or does it need cross-brand insight?

These are different needs that point to different solutions.

If the organization needs to resolve identity across brands in real time, meaning it needs to know in the moment that the customer browsing Brand A's website is the same person who made a purchase on Brand B last week, and it needs that knowledge to influence the active session, then a shared sandbox with a carefully designed tiered namespace architecture is a reasonable approach. The complexity is real, as Part 2 documented, but the business requirement justifies it.

If the organization needs cross-brand insight for analysis, reporting, and campaign planning, a shared sandbox is not required. Adobe Customer Journey Analytics can connect to data from multiple separate AEP sandboxes, synthesize it, and produce cross-brand analysis without requiring those brands to share identity infrastructure in production. Each brand maintains its own clean sandbox with its own identity configuration. The analytical value of cross-brand visibility is preserved. The identity complexity of shared sandbox operation is eliminated.

Costs play a role in this decision as well. Separate sandboxes have licensing implications. Shared sandboxes have remediation costs when identity architecture goes wrong. Neither cost is zero, and the right answer depends on the organization's specific contract structure and risk tolerance.

The point is that this decision should be made deliberately, with full understanding of the identity architecture implications on both sides, not inherited as a default from an initial implementation that was never designed with multi-brand scale in mind.

A Practical Decision Checklist

Before finalizing your identity resolution architecture, work through these questions with your implementation team and your key stakeholders.

Does your organization have an MDM system? If yes, is it producing clean canonical customer identifiers for all the data sources that will feed AEP? If the answer to the second question is no, document what AEP will be asked to resolve that the MDM is not handling and evaluate whether that is the right long-term state.

Does your organization have a CIAM platform? If yes, is it resolving multiple login methods to a single canonical person identifier before that identifier reaches AEP? If not, AEP's linking rules will be asked to do account-linking work that belongs upstream.

How clean is your identity data at the point of ingestion? If your data layer is passing invalid or placeholder identity values into AEP, no amount of linking rule configuration will fully compensate. Fix the data layer first.

Are multiple brands, markets, or business units sharing an AEP sandbox? If yes, has the identity architecture been explicitly designed for that shared environment, with brand-specific namespaces and a verified cross-brand anchor identifier? If not, the risk of profile collapse across entities is significant.

Is the need for cross-brand or cross-entity data primarily analytical or operational? Analytical needs point toward CJA with separate sandboxes. Operational real-time needs may justify shared sandbox complexity.

Closing the Series

These three posts have covered a lot of ground: the mechanics of a feature, a real enterprise implementation that pushed that feature beyond its documented limits, and the architectural framework that should precede any configuration decision.

The thread running through all three is the same. Identity resolution is not a configuration problem. It is an architecture problem. The configuration decisions matter, and getting them right requires the kind of detailed, scenario-based work that Part 1 and Part 2 described. But the configuration decisions are downstream of the architectural ones. Knowing which layer owns which part of the resolution problem, and making that decision deliberately before anyone opens a configuration UI, is what determines whether your implementation is maintainable, accurate, and resilient over time.

Get the architecture right first. The configuration follows from that.

References

Stephen Tettey is an Adobe Certified Multi-Solutions Architect with five years of hands-on experience implementing AEP, Real-Time CDP, Adobe Journey Optimizer, Adobe Analytics, and Customer Journey Analytics across financial services, travel, loyalty, and cybersecurity industries.

Comments ()