Implementation guide for Identity Service
Last update: Tue Jan 23 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
CREATED FOR:
- Developer
- User
- Admin
- Leader
This document provides with information on how data provided to Adobe Experience Platform is processed prior to being used by Identity Service to build an identity graph for a given customer.
Decide on identity fields
Depending on your enterprise data collection strategy, the data fields you label as identities determine which data is included in your identity map. To get the maximum benefit of Experience Platform and the most comprehensive customer identities possible, you should upload both online and offline data.
-
Online data is data that describes online presence and behavior, such as usernames and email addresses.
-
Offline data refers to data that is not directly related to online presence, such as IDs from CRM systems. This type of data makes your identities more robust and supports data cohesion across your disparate systems.
Create additional identity namespaces
While Experience Platform offers a variety of standard namespaces, you may need to create additional namespaces to properly categorize your identities. For more information, read the guide on creating custom namespaces for your organization.
Identity namespaces are a qualifier for identities. As a result, once a namespace has been created, it cannot be deleted.
Include identity data in Experience Data Model (XDM)
As the standardized framework by which Experience Platform organizes customer data, Experience Data Model (XDM) allows data to be shared and understood across Experience Platform and other services interacting with Experience Platform. For more information read the XDM System overview.
Both record and time series schemas provide the means to include identity data. As data is ingested, the identity graph will create new relationships between data fragments from different namespaces if they are found to share common identity data.
Label XDM fields as identity
Any field of type string in schemas that implement either record or time series XDM classes can be labeled as an identity field. As a result, all data ingested into that field would be considered identity data.
Identity fields also allow for the linking of identities if they share common PII data.
For example, by labeling phone number fields as identity fields, Identity Service automatically graphs relationships with the other individuals found to be using the same phone number.
- Array and map type fields are not supported and cannot be marked and labeled as identity fields.
- The namespace of resulting identities is provided at the time the field is labeled.
For more information, read the guide the guide on defining identity fields in the UI.
During the streaming ingestion process, Identity Service automatically extracts identity data from record and time series data. However, before data can be ingested, it must be enabled for Identity Service. Read the tutorial on configuring a dataset for Real-Time Customer Profile and Identity Service using APIs for more information.
Ingest data to Identity Service
Identity Service consumes XDM-compliant data sent to Experience Platform either by batch ingestion or streaming ingestion.
The following video is intended to support your understanding of Identity Service. This video shows you how to label data fields as identities, ingest Identity data and then verify that the data has made it to the Adobe Experience Platform Identity Service Private Graph.
The Experience Platform UI shown in the following video is out-of-date. Please refer to the documentation for the latest UI screenshots and functionality.
Hi, in this video, we’ll show you how to label data fields as identities, ingest identity data, and then verify that the data has made it to the Adobe Experience Platform, Identity Service private graph. This slide represents data that we bring into Experience Platform for our demo brand, Luma. In a previous video, you saw how we modeled this in the Schema Editor, and then use batch or streaming ingestion to load the data. Now, we’ll focus on labeling the data to build a private identity graph. Key elements, are the different disconnected datasets. For example, loyalty data, CRM data, and analytics data.
Here we are in the Platform interface. I’ll go to the Schema list and open my Luma CRM Schema. In this example, we have data coming from the Luma CRM system. In this system, the crm_id is the primary way to identify the records, however, any data field that could identify a customer as an individual, for example, email address or phone number, can be labeled as an identity to build a more extensive graph. It’s this selection of identities that powers the joining of datasets. In that other video, we created a schema for our Loyalty ID system with email labeled as an identity. Now, we’ll label the email field in our CRM schema as an identity, so we can join the two datasets together in the realtime customer profile. Be sure to work with your legal and privacy teams to determine which identity you should be collected and use dual labeling to protect the consumer’s privacy. When you select any field that’s a String type, you’ll see an option on the right-hand side to label it as an Identity. Once you label a field as an identity, you need to choose a namespace. The namespace, refers to the system of record or the type of identity. For example, if you have a driver’s license, the system of record for it is the Department of Motor Vehicles. For an email address, there isn’t really a system of record, so you’d use the Type, which is Email. A bunch of standard namespaces are provided by default, if you don’t find the namespace you need, you can create one. I need to create one for my crm_id, so I’ll go to the Identities page and click on Create Identity Namespace. This opens up a widget, where I’ll enter a display name, a shorthand code, and click Create. Once you’ve created a new ID namespace, you can associate the XDM field to this newly created ID namespace.
Note this other option I’m given when I check the Identity box, should this identity be considered a Primary Identity? You can only choose one primary identity per dataset. If the schema is like a database table, think of the primary identity as the primary key. The primary identity plays a special role in the realtime customer profile. You can use it to both update and lookup a profile. In my example, the crm_id should be the primary identity, so I’m going to check that box. Once all of the identity fields have been labeled in this schema, I need to make sure the schema is Enabled for Unified Profile. Next, I can upload my Luma CRM dataset, making sure my dataset is also Enabled for Unified Profile. When a dataset is ingested via batch or stream, the identity fields are ingested into the private graph, populating your graph with more and more identities. Post ingestion, you can use the Monitoring and Identities pages, to confirm if the data was successfully ingested into the private graph or not. So those are the simple steps to label identities, ingest identity data, and populate the private graph. Thanks for watching and have a great day.