Identity Service overview

Last update: 2023-01-06
  • Created for:
  • Developer
    User
    Admin
    Leader

Delivering relevant digital experiences requires having a complete understanding of your customer. This is made more difficult when your customer data is fragmented across disparate systems, causing each individual customer to appear to have multiple “identities”.

Adobe Experience Platform Identity Service provides you with a comprehensive view of your customers and their behavior by bridging identities across devices and systems, allowing you to deliver impactful, personal digital experiences in real time.

With Identity Service, you can:

  • Ensure that your customers receive a consistent, personalized, and relevant experience through each interaction.
  • Stitch together several different identities from disparate sources and create a comprehensive view of your customers.
  • Utilize an identity graph to map different identity namespaces, providing you with a visual representation of how your customers interact with your brand across different channels.

Getting started

Before diving into the details of Identity Service, here is a brief summary of the key terms:

Term Definition
Identity An identity is data that is unique to an entity, typically an individual person. An identity, such as a log-in ID, ECID, or loyalty ID, is also referred to as a “known identity”.
ECID Experience Cloud ID (ECID) is a shared identity namespace used across Experience Platform and Adobe Experience Cloud applications. ECID provides a foundation for customer identity and is used as the primary ID for devices and as a base node for identity graphs. See the ECID overview for more information.
Identity namespace An identity namespace serves to distinguish the context or type of an identity. For example, an identity distinguishes “name@email.com” as an email address or “443522” as a numeric CRM ID. Identity namespaces are used to look up individual identities and provide the context for identity values. This allows you to determine that two Profile fragments that contain different primary IDs, but share the same value for the email identity namespace, are in fact, the same individual. See the identity namespace overview for more information.
Identity graph An identity graph is a map of relationships between different identities, allowing you to visualize and better understand which customer identities are stitched together, and how. See the tutorial on using the identity graph viewer for more information.
Personally Identifiable Information (PII) PII is information that can directly identify a customer, such as an email address or a phone number. PII values are often used to match. a customer’s multiple identities across different systems.
Unknown or anonymous identities Unknown or anonymous identities are indicators that isolate devices without identifying the actual person using the device. Unknown and anonymous identities include information such as a visitor’s IP address and cookie ID. Although unknown and anonymous identities can provide behavioral data, they are limited until a customer supplies their PII.

What is Identity Service?

Each day, customers interact with your business and establish a continuously growing relationship with your brand. A typical customer may be active in any number of systems within your organization’s data infrastructure, such as your e-commerce, loyalty, and help-desk systems. That same customer may also engage anonymously on any number of devices. Identity Service allows you to piece together a complete picture of your customer, aggregating related data that might otherwise be siloed across disparate systems.

Consider an everyday example of a consumer’s relationship with your brand:

  • Mary has an account on your e-commerce site where she has completed a few orders in the past. She typically uses her personal laptop to shop, where she logs in each time. However, during one of her visits she uses her tablet to shop for sandals, but does not place an order and does not log in.
  • At this point, Mary’s activity appears as two separate profiles:
    • Her e-commerce login
    • Her tablet device, perhaps identified by device ID
  • Mary later resumes her tablet session and provides her email address while subscribing to your newsletter. Upon doing so, streaming ingestion adds a new identity as record data within her profile. As a result, Identity Service now relates Mary’s tablet device activity with her e-commerce account history.
  • By the next click on her tablet, your targeted content could reflect Mary’s full profile and history, rather than just a tablet used by an unknown shopper.

Identity stitching on Platform

Essentially, Identity Service allows you to piece together a complete picture of your customer, aggregating related data that might otherwise be scattered across disparate systems. The identity relationships that Identity Service defines and maintains are leveraged by Real-Time Customer Profile to build a complete a picture of a customer and their interactions with your brand. For more information, see the Real-Time Customer Profile overview.

Use cases

Examples of Identity Service implementations include:

  • A telecom company may rely on the “phone number” value, where a phone number would refer to the same individual of interest in both offline and online data sets.
  • A retail company may use “email address” in offline data sets and ECID in online datasets due to the high percentage of anonymous visitors.
  • A bank may prefer “account number” in offline data sets, such as branch transactions. They may depend on “login ID” in online data sets, because most visitors would be authenticated during their visit.
  • Your customers may also have unique proprietary IDs, such as GUID or other universally unique identifiers.

Identity namespace

If you asked a person “What is your ID?” without any further context, it would be difficult for them to provide a useful answer. By the same logic, a string value representing an identity value, whether it is a system generated ID or an email address, is only complete when supplied with a qualifier that gives the string value context: the identity namespace.

Your customers may interact with your brand through a combination of online and offline channels, resulting in the challenge of how to reconcile those fragmented interactions into a single customer identity.

Understanding your customer across multiple devices and channels starts by recognizing them in each channel. Platform achieves this by using identity namespaces. An identity namespace is an identifier such as Email or Phone, used to provide additional context to customer identities. Identity namespaces are used to look up or link individual identities and provide context for identity values. See the identity namespace overview for more information.

Identity graphs

An identity graph is a map of relationships between different identity namespaces, allowing you to visualize and better understand what customer identities are stitched together, and how. See the tutorial on using the identity graph viewer for more information.

The following video is intended to support your understanding of identities and identity graphs.

 Transcript

In this video, we’ll go over the concepts of identity and identity graphs in Adobe Experience Platform. A big challenge in making great customer experiences is making them seamless across channels and devices. The average customer may have over a dozen touch points with your brand before a conversion even takes place. They may browse your website, open your mobile app, visit your brick and mortar store, and so on. Understanding where a single customer is in their journey is complicated as each touch point often uses its own unique identity. Furthermore, data associated with these identities gets siloed in enterprise systems, such as CRM, ERP, DMP, CMS, and marketing automation. These disconnected identities are a barrier to achieving a holistic view of the customer in order to serve the next best experience. Active management of identities via linking, resolving, governing, and actioning is time-consuming, process-heavy, and difficult. Fortunately, Experience Platform provides a rich set of identity resolution capabilities which are built from the ground up to handle these tasks. For each customer that interacts with your brand, Platform can link their disconnected identities into a versatile identity graph creating a single, holistic representation of each individual person. Experience Platform has three key identity resolution capabilities, identity collection, identity graphs, and the Identity Service API. Identity Collection happens whenever you ingest data into Experience Platform, either through batch ingestion, streaming ingestion, or a source connection. All data that is ingested into Platform must conform to a predefined experience data model schema. When developing your data model and defining your schemas, any fields that contain identity information should be marked as identity fields. This is how Platform is able to recognize identity information whenever new data is ingested under these schemas. The second major capability is the Identity Graph. Identity Graphs are maps of relationships between individual identities, and Identity Graph for a single individual can contain their email address, CRM IDs, device IDs, and more. While the contents of each individual Identity Graph will naturally vary between customers, the structure of how these identities relate to one another remains consistent. Experience Platform maintains a complete representation of the identity relationships that have been built based on your data. This representation is referred to as the Private Graph, and is visible only to your organization. The third major capability is the Identity Service API. Experience Platform’s identity capabilities are exposed through Adobe I.O., so developers can use the same API endpoints as the Experience Platform user interface. Using the Identity Service API, you can programmatically interact with your Platform Identity Graphs from your experience application. Let’s talk more about Identity Graphs. An Identity Graph is constructed by discovering relationships between identities among your customer experience data using deterministic algorithms. The deterministic algorithms establish relationships between identities based on your own observations. For example, when a visitor lands on your website, they’re assigned an anonymous visitor ID. If they log in using their account ID, that account ID can now be deterministically linked to the anonymous one. Identity Graphs are a key piece for creating a merged view of a customer in real-time customer profile. See the profile documentation to learn how to combine Identity Graphs and Merge Rules to stitch together a complete representation of each individual customer. Identity Graphs also extend Adobe’s commitment to privacy. Adobe, as a data processor, has launched Experience Platform services that allow you to label your data based on data usage policies and enforce those policies as potentially sensitive identity information moves through the system. See the documentation on Adobe Experience Platform data governance for more information. You’ve now been introduced to the major capabilities provided by Identity Service. To learn more, please review the official Identity Service documentation. Thanks for listening, and good luck building out your own Identity Graphs to power your personalization capabilities.

Supplying identity data to Identity Service

This section covers how data provided to Adobe Experience Platform is processed prior to being used by Identity Service to build an identity graph for each 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 Adobe 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, see the section on viewing and creating namespaces for your organization in the identity namespace overview.

NOTE

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 Platform organizes customer data, Experience Data Model (XDM) allows data to be shared and understood across Experience Platform and other services interacting with Platform. For more information see 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.

Marking 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.

NOTE

Array and map type fields are not supported and cannot be marked and labeled as identity fields.

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.

NOTE

The namespace of resulting identities is provided at the time the field is labeled.

Configure a dataset for Identity Service

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. See 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.

WARNING

The Platform UI shown in the following video is out-of-date. Please refer to the documentation for the latest UI screenshots and functionality.

 Transcript

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.

Data governance

Adobe Experience Platform was built with privacy in mind and includes a data governance framework to protect your customer PII data. Identity data under the “email” or “phone” namespace is encrypted by default, but in order to ensure sensitive data is encrypted before it is persisted, data usage labels can be applied to data as it is ingested or once it arrives in Platform. For more information, please read the Data Governance overview.

Next steps

Now that you understand the key concepts of Identity Service and its role within Experience Platform, you can begin to learn how to work with your identity graph using the Identity Service API.

On this page