Profile Projection
13 Apr 2025 » Platform
I have already written about the Unified Profile. In that post, I explained how the Real-Time Customer Profile (RTCP) manages profiles. However, I did not delve deeply into the internal process of how a profile is created or, more accurately, projected. This is a widely misunderstood topic and not easy to grasp. Therefore, I have decided to write about it again, with an emphasis on profile projection.
There Is No Profile
Let me start by sharing a surprising truth: the Adobe Experience Platform (AEP) does not store anything that resembles a profile in the traditional sense. In other words, nowhere in RTCP is there a database row that contains something identifiable as a profile (if we were using a relational database).
So, how can this be true? How can we always talk about profiles when they do not exist? Let me explain.
Building Blocks
To understand how AEP treats profile data, we need to start with its building blocks. As usual in this blog, I will use the following foundational architecture:
Identity Store
Also called the Unified Identity Store or Unified Identity Service (UIS), this is a database of identities. It works as explained in Understanding AEP Identities. As pairs of identities are received by AEP—whether through profile or event datasets—it builds an identity graph linking all identities that belong to the same individual. In other words, if a record contains two identities, UIS links them. At least two identities are required for linking; with only one identity, no link can be established.
Only attributes marked as identities are considered. For example, if you have an XDM field containing an email address but it is not marked as an identity, UIS will not use it.
Once a graph is built, passing just one identity in a request to UIS allows all other linked identities to be returned.
Profile Store
Also called the Unified Profile Store or Unified Profile Service (UPS).
As records in datasets are received, UPS stores them according to the following rules:
- Profile datasets: it keeps only the last ingested record per primary unique identifier within that dataset; this record is referred to as a fragment.
- Event datasets: it retains records until their TTL (Time-to-Live) expires.
This explains why I mentioned earlier that there is no profile. If you have multiple datasets (which is typical), they are processed and stored independently of one another. In other words, AEP only knows fragments of profiles.
One consequence of this behavior is that fragments can overlap across datasets. Let me try to explain this differently: you can receive the same branch of the XDM schema from various dataset. For example, in the image above, the orange fragment could represent the home address, which is provided by the web, app, mail and CRM datasets.
The Projected Profile
Now that we understand the building blocks, let’s go step by step through the process of projecting a profile.
1. Request Projected Profile
It all starts with a call to RTCP. This call can originate from any internal system or tools like Adobe Journey Optimizer (AJO), or via the Real-Time Customer Profile API. Key parameters for this call include:
- A merge policy
- One identity
- The namespace of this identity
2. Identity Graph
Next, RTCP calls the identity store, passing the provided identity and its namespace. UIS searches its database and retrieves all linked identities (with their namespaces), returning them to RTCP.
3. Profile Fragments
RTCP then queries the profile store using all identities retrieved from the previous step. The profile store searches across all fragments containing any of these identities and returns them.
4. Fragment Merge
The last step involves creating the projected profile by merging fragments based on merge policies. If you are unfamiliar with merge policies, there are two methods:
- Timestamp ordered: the fragment with the most recent timestamp prevails, regardless of dataset.
- Dataset precedence: an ordered list of datasets determines which dataset takes priority in case of conflict.
Continuing with our orange fragment example, merge policies determine which of the four orange fragments will be used. Consequently, different merge policies may produce different projected profiles for the same identity.
5. Return Projected Profile
Finally, RTCP returns the projected profile to the caller.
It is important to note that at no point during this process is the projected profile cached or stored permanently. RTCP immediately “forgets” it after returning it. If you repeat step 1 with identical parameters, the entire process will be executed again. As you can imagine, this is computationally expensive and should only be invoked when necessary.
Edge Network
I must admit I slightly misled you earlier when I said “the Adobe Experience Platform (AEP) does not store anything that resembles a profile.” The Edge Network does cache profiles temporarily for operational efficiency. When a new identity is encountered by the edge, it requests a projected profile from the hub and caches it locally. This caching ensures rapid processing of Web or Mobile SDK requests within milliseconds since querying the hub each time would introduce significant latency.
Here are some additional rules regarding profiles on edge:
- If an identity is not seen for 14 days, its projected profile is forgotten.
- The hub tracks profiles projected on edge and pushes updates as they occur.
If you are wondering about merge policies in this scenario—good catch! You must select one merge policy for the Edge Network; this setting corresponds to the “Active-On-Edge Merge Policy” checkbox you see when configuring merge policies.
Profile Collapse
I want to finish this post by reviewing the concept of profile collapse. If you have followed everything so far, you will understand why profile collapse happens. If UIS receives two customer IDs with the same ECID, all three identities will be added to the identity graph. Then, when the profile is projected, all identities will be retrieved, and fragments from both profiles will be merged.
The solution is also straightforward. If you can somehow recreate the identity graph for cases that lead to profile collapse, you can keep the identity graph clean. Different solutions have been created to address this issue in batch processes. The most promising approach is identity graph linking rules. Once this feature becomes generally available, I will write a dedicated post about it.
Photo by Thirdman