Identity Graph Linking Rules
10 Aug 2025 » Platform
One of the most painful issues that all our Adobe Experience Platform (AEP) customers have faced is the profile collapse. The only comment I received on that post started with: “This is a giant problem.” Well, the wait is over — a solution has been implemented and is now generally available: Identity Graph Linking Rules. If you have suffered from this issue, keep reading.
Pre-Requisites
To understand the solution, you first need to understand how AEP works internally. There are two main concepts that are prerequisites to the explanation in this post. I recommend you review them if you are not familiar with these concepts before continuing.
- AEP Identities, in particular the concept of namespaces.
- Profile Projection, especially how the identity graph is used.
How Identity Graph Linking Rules Work
The concept behind this feature is very simple: break links within the identity graph if more than one identity from a given namespace is present in that graph.
Let me explain with a simple scenario, where Alice and Bob share the same device. I will use the email address as an identity for illustration purposes; in general, it is not recommended to use it in real scenarios.
-
Alice uses the shared device and logs in to your website. An ECID is generated on the landing page and, after logging in, AEP links Alice and the ECID.
-
Now Bob wants to access the same website using the shared device. After he logs in, AEP links Bob to the same ECID from the previous step, resulting in a profile collapse — there is now a single graph containing both Alice and Bob.
-
With identity graph linking rules enabled and configured, the oldest email address is removed from the graph, as it violates the rule of having only one email address per graph.
The end result is that we now have two identity graphs:
- Alice has only her email address.
- Bob has his email address and the ECID.
The ECID Trade-Off
You may have noticed there is a catch with the ECID. Since the ECID is now always linked to only one profile, all anonymous events are tied to that profile. In the previous example, anything Alice did before logging in will be attributed to Bob.
Some may argue this is an issue, but I would counter that there is no guarantee that anonymous events belong to the next person who logs in. While it could be an educated guess, it could just as well be the case that Bob used the shared device anonymously, and then Alice logged in afterward. There is no reliable way to determine who was behind the device before a login.
One way to address this issue is to create a merge policy that does not stitch identities (ID stitching set to “None”) and use it as the Active-On-Edge Merge Policy. With this configuration, anonymous events will not be combined with events after login. As always, do not immediately apply such configuration changes without fully understanding their implications and testing them in a development environment.
Beyond The Basics
I strongly recommend spending time reviewing the full documentation on Identity Graph Linking Rules, including the accompanying videos. I have explained only the simplest case, with two identity namespaces. If you have more than two, and a collapse could occur in different parts of the hierarchy, you must clearly understand what happens in each scenario. The possibilities grow exponentially with each namespace and each potential identity combination, making it impossible to document every case here.
To help visualize the behavior of this functionality, Adobe provides a Graph Simulation tool. I find this tool incredibly useful — you can load different scenarios and see exactly how the graphs will behave. Use it extensively in a development sandbox, testing all options and configurations until you find the optimal setup. Only then you should replicate it in your production environment. Client feedback on this tool has been very positive.
A customer recently asked if there was a rollback mechanism to restore the state from before enabling linking rules. The short answer is no. This is another reason why the simulation tool is so important.
Exceptions
While this solution works very well for many of Adobe’s clients, it is not the solution for all cases. I have worked with customers who are hesitant to enable Identity Graph Linking Rules because of the consequences for their identity strategies. As mentioned above, my recommendation is to use the simulation tool to analyze your specific use cases before making a decision. If it creates more problems than it solves, do not use it.