Identity graph linking rules is currently in Limited Availability. Contact your Adobe account team for information on how to access the feature in development sandboxes.
Learn how to use the graph simulator to test out identity graph linking rules in Adobe Experience Platform. Experiment with different scenarios and play with “unique per graph” and priority settings to verify what rules you need for your business to avoid graph collapse. For more information, see the Graph Simulation UI guide.
Let’s talk about an important feature in Adobe Experience Platform called Identity Graph Linking Rules, presented in the interface as graph simulation and identity settings. This feature helps data architects avoid graph collapse, which is when the identity graphs of two people unintentionally merge together. I’m going to assume you already know how profiles are constructed from profile fragments joined by identities. This video covers the graph simulation tool, and another video will cover the identity settings configuration. From the left navigation, go to Customer Identities. You’ll need permissions to view and edit identity settings to see this option and fully configure the feature. Now go to Graph Simulation. Let’s start by loading an example of a common graph collapse scenario. These are the three most common, shared device, non-unique phone numbers, and bad identity values. Let’s load the shared device scenario. I’m actually going to simplify this example a little bit. We only need to look at these two events. In the first event, John is on a web browser, and he’s assigned this experience cloud identity value of 111. ECIDs are cookie IDs, which are set on every browser when someone goes to your website with a web SDK or even older Adobe libraries implemented. John is also logged in, and his hashed email address is also used as an identity. Both identities are passed in this event sent to platform. In the second event, Jane is now on the exact same device and web browser. The ECID is a cookie ID, so that same value of 111 still exists. But since she’s logged into her own account, her hashed email address is sent to platform as that additional identity. Let’s look at what happens if you don’t use the identity graph linking rules feature. I’m just going to remove this extra namespace to keep things simple and uncheck the unique per graph setting. And then I’ll click Simulate. Without the feature, what would happen is that John and Jane will merge into a single graph because they share that same ECID. And since real-time customer profiles are constructed using the identity graph, their profiles would also merge. So this is how a shared device scenario causes the problem of graph collapse. I can use identity graph linking rules to address this issue by choosing an identity namespace to best approximate a living, breathing individual and declare that any graph should only have one value for that namespace. Here, the hashed email is my best option. And I’ll select the unique per graph option. I run the simulator again. And now I have this red dashed line representing a removed link. That one graph is split into two graphs. And John and Jane will have separate profiles. John’s identity graph contains his hashed email. And Jane’s contains her hashed email and the ECID. Why does Jane own the ECID? Because Jane owned the last event associated with this ECID. John owned it at first. And then Jane took ownership. Let’s look at another example. Here is the invalid or non-unique phone number. Also common is a non-unique email address. Here you have two individuals. And they’ve both given you the same bogus phone number. Without using this feature, the identity graphs and profiles will merge. By using the unique per graph setting, you can split the graphs and profiles. And remember, just because you collect phone numbers and email addresses doesn’t mean you have to label these as identities in Experience Platform. Do so only if you really need to. And do as much verification as possible to make sure that they are legitimate values owned by the person entering them. The third scenario is the bad identity value. Here, what’s happening is that the mobile SDK implementation is accidentally setting the IDFA identity value as a text string, user underscore null, instead of a true null value, which would get filtered out. So Platform sees user null as a valid identity value. And all of these profiles would merge. By declaring the hashed email namespace as unique, the graphs and profiles can be split. So this simulator is pretty cool. You can add events both using the menu option and through the text entry advanced option mode. I prefer the text entry mode. And I save my examples in a text editor. You can also use your own identity namespaces and values. You can test out very complicated and unique examples related to your business. There are a lot of examples in the documentation, which come from real world scenarios, which you can copy and paste into the simulator. So try things out and see what happens with different algorithm configurations to make sure you get the desired result for your business. So that’s a graph simulator. In another video, I’ll show you how to define your rules and actually turn the feature on.