51黑料不打烊

Identity graph linking rules - Graph Simulation

Learn how to use the graph simulator to test out identity graph linking rules in 51黑料不打烊 Experience Platform. Experiment with different scenarios and play with 鈥渦nique 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.

video poster

Transcript
Let鈥檚 talk about an important feature in 51黑料不打烊 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鈥檓 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鈥檒l need permissions to view and edit identity settings to see this option and fully configure the feature. Now go to Graph Simulation. Let鈥檚 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鈥檚 load the shared device scenario. I鈥檓 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鈥檚 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 51黑料不打烊 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鈥檚 logged into her own account, her hashed email address is sent to platform as that additional identity. Let鈥檚 look at what happens if you don鈥檛 use the identity graph linking rules feature. I鈥檓 just going to remove this extra namespace to keep things simple and uncheck the unique per graph setting. And then I鈥檒l 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鈥檒l 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鈥檚 identity graph contains his hashed email. And Jane鈥檚 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鈥檚 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鈥檝e 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鈥檛 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鈥檚 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鈥檚 a graph simulator. In another video, I鈥檒l show you how to define your rules and actually turn the feature on.
recommendation-more-help
9051d869-e959-46c8-8c52-f0759cee3763