The Adobe Experience Platform Identity Service is a core component of the new Adobe solution but it may be underestimated because it is not mentioned as much as the Data Science Workspace, or the Query Service.
This is mainly because it is not something that you can play a lot with, but it is what makes Adobe Experience Platform very fast, very useful and the core mainframe for activation on real time and at scale for your company.
I will try to dig a bit on what the Identity Service is and how you will be using when working with Platform.
Graph Database
Identity Service is mainly a Graph Database that is enabled on Platform.
There is a very good explanation of this here: https://www.adobe.io/apis/experienceplatform/home/profile-identity-segmentation/profile-identity-segmentation-services.html#!api-specification/markdown/narrative/technical_overview/identity_services_architectural_overview/identity_services_architectural_overview.md
But why we are at this, I think it is a good time to understand what a Graph Database is. It will help you understand what it is possible and what is not from it, what are they good for and what are they not so good.
To put it simply, and I am not a database expert so I will keep it simple, Graph database are sort of a NoSQL database. NoSQL database can have different setup, depending the type of tasks that you would like to realize.
When you are trying to optimize for very large amount of data and you try to optimize your time requesting for the data, the most common setup that you are using is the key-value pair approach. The search for a key is an operation that always take a constant time (O(1)), independent of the size of that approach (see my article on O notation).
You can imagine that the identity that you are going to use on your request (ECID, CRM ID, etc…) is the key that will link all of the attributes of your users and the different events that has been realized.
So a key-value pair system is a correct way to start.
However this doesn’t end up here, as you start growing your use-cases for tracking purposes, you will encounter multiple possible entity for a user. As described above, you can enter his ECID, CRM ID, or EMAIL to recognize him.
In a key-value pair system each key will attached the attributes you have tracked to itself but you want to combine these attributes together so you can have a 360° view of your customers.
In that case, you need to link the different keys together and this is where your NoSQL key-value pair approach turns into a graph database.
Benefit of Graph database
Having the database set as a graph comes with several benefits that are very handy for application like Platform.
Adobe Experience Platform will be using its capability to automatically set the relation between the different user identities.
Normal database store data into table and you are realizing JOIN operation to combine the table together. This is OK because it is efficient and quick when done for your analysis, but when you try to do that thousands of time per minute (for customer) and for millions of records at the same time (for Adobe infrastructure), it starts to be an issue. It doesn’t really scale that well.
The data (nodes) and the connection (edges) are created and set at run-time. Some you don’t have to recreate them afterwards when you are querying the data.
Some people asked me what type of Graph database is being used for Adobe Experience Platform (Neo4j ? Agens ?), I have no idea.
What I know is that there is a specific query language that is being used when using the graph database.
That language is named PQL. It is not public facing and it is used mostly by the services of AEP. When Segmentation, Decisioning Service and others services of Adobe Platform are running, they will use this language to request the data and ensure that the service is using the Unified view of the customer.
Enabling your Identity Service in Platform
In order to create your identity graph, you will need to, obviously, create a schema and more importantly define an identity that is being used at run-time for your data collection.
Adobe Experience Platform provides different Identity Namespace where you define the context of these identities (CRM, EMAIL, etc…). You can create your own context if the predefined namespace don’t suit your setup. At the moment, by default there is no CRM ID namespace, so you can create this to upload your CRM data and attached the user id to its appropriate Graph key.
Once you have created your schema, you will need to enabled it and its dataset with the Union Profile capability.
This is a basic switch that is actually quite powerful. Starting the moment you have enabled that option, you cannot do destructive change to your schema anymore.
At the same time, every record you are sending to your dataset will be ingested and create a new key or add information to an existing key in your graph in real time.
So you will really start to build your graph starting the moment you have turned on that switch.
I already mention that before on my data model article but this option is only going to be available when you have created your schema based on the XDM Individual Profile Class or the XDM ExperienceEvent Class.
Any other class being used won’t be ingested in your own Graph and won’t participate in your Identity profile.
Activation of your unified profiles
I will do a separate post on that but you will activate your data, and therefore your unified profiles by using segmentation.
In a way the segmentation is working the same way that Adobe Audience Manager where you build your audience data. Then you can use that segment to pull all of the users that are qualified by the condition of your segment.
The segmentation engine will use the unified profile to define the users that are qualified on your segmentation.
There are 2 way to use the segmentation engine, you can set the segment and then run it in order to calculate the population that is matching the condition.
By default the segment won’t return anything, it will just start adding the person that match the condition on real time.
Therefore, if you have already ingested the data before creating the segment, you will ned to run a segment job.
The other way is already described, you segment will match all of the users that are matching your condition(s) based on your unified profiles on real-time. So when you are using your segment on your activities, you will be able to activate your Identity Service.
As explained before, I will provide a different blog post on Segmentation. For the persons familiar with Audience Manager, it will feel very similar.
I hope this article gave you a better overview on the Identity Service and how crucial it is for AEP.