ÃÛ¶¹ÊÓƵ

Transcript

Hi, I’m excited to give you this quick overview of Identity Graph Linking Rules in ÃÛ¶¹ÊÓƵ Experience Platform. This feature helps data architects build quality identity graphs and customer profiles for ÃÛ¶¹ÊÓƵ Experience Platform applications like Real-Time Customer Data Platform, Journey Optimizer, and Customer Journey Analytics. It helps avoid graph collapse, which is when the identity graphs of two people unintentionally merge together. When people engage with your brand, data flows into ÃÛ¶¹ÊÓƵ Experience Platform datasets. If those datasets are enabled for profile, identity graphs form and profile fragments are stored. If two individual people end up sending data with common identities, their identity graphs files can merge and give you an inaccurate representation of your customers. This can easily happen when people share devices, enter fake information, or through unintentional implementation errors. Let’s take a look at the interface. From the left navigation, select Identities. There are two components of the feature, Graph Simulation and Identity Settings. It can be tested and configured entirely in the interface and doesn’t require any code changes elsewhere. To fully use it, you need permissions to view and manage identities. I’ll start in the Graph Simulator. The simulator has several examples you can load to get started, which correspond to common scenarios that could lead to graph collapse. Let’s take a look at the shared device example. At the top of the screen, we have Events, and at the bottom is the namespace configuration. Events represent any data ingestion event containing two or more identities, which is the minimum required for graph construction. These can be XDM Experience events or ingestion events containing XDM individual profile data. You can add events using a UI dialog or paste text events using the Text option. Events just need to contain pairs of identity namespaces and values. The algorithm configuration is the heart of the identity graph linking rules. You can prioritize namespaces by dragging and dropping, and declare uniqueness by checking the box. The priority impacts the order of rule evaluation, and uniqueness means that only one value for the namespace is allowed per graph. Hit the simulate button to see how your configuration will play out on the events. Here you can see that although John and Jane shared a device and had a common ECID, they end up with separate identity graphs because the hashed email identity was declared unique, and the rules removed the link between them. Without configuring identity graph linking rules or without using the unique setting, their graphs and profiles would merge, which I can simulate by unchecking the uniqueness box and hitting the simulate button again. The graph simulation is a great tool to test out complex scenarios using events and namespaces representative of your own implementation. Once you’ve determined the priority and uniqueness settings you need for your implementation, you can set up the final configuration on the settings screen, which you can get to by clicking on the settings button. This screen is similar to the namespace configuration portion of the simulator. It pulls in all of the identity namespaces in your sandbox, and you can change the priority and uniqueness settings. The highest priority namespace must be unique. Once you activate your rules, your existing graphs will remain, but will be recreated as graphs are updated by new events ingested into platform. That’s a really quick overview. It’s a simple feature to configure, but because identity graphs resonate throughout so many services in Experience Platform, especially the profile service, it’s important to configure it with consideration. Thank you.