Profile Collapse
30 Oct 2022 » Platform
One of the main purposes of Adobe Experience Platform (AEP) is to create a 360-degree view of your customers. In more technical terms, this is what we call the unified profile. While this is a conceptually sound capability, there are certain cases when this unified profile could be wrong, with information from other profiles which should not be there.
Expected behavior
As I have explained a few times, through the use of an identity graph, AEP finds all fragments that correspond to the same individual and, after applying the merge policies, you get a profile.
This is how we want AEP to work. However, unfortunately, the path to this goal has some landmines that we need to avoid.
When things go wrong
AEP is maniacally obsessed with finding common identities within the datasets. It is so ingrained in its core, that there are no exceptions, no ifs, and no considerations. Most importantly, once two identities are linked in the device graph, AEP offers no way to delete this link. If two profiles that you want to keep separate, for any reason, have the same ID in the same namespace, they are automatically and forever merged. This is what we call profile collapse. From that moment in time, you will not be able to distinguish the two individuals and they will be treated as one. This means that they will always get the same personalization and communications. It is therefore very important that the data ingested in AEP does not fall into this trap. A careful analysis during the design phase of an implementation project is required before we can build an Experience Data Model (XDM) and define the identities.
In my experience, this is an important point of friction with some customers. They expect that AEP will know when to merge profiles and when not or that complex merge policies can be provided. If you are going to face this situation, be prepared to give many explanations and offer solutions.
In case you were wondering, here you have some examples of when this can happen. This is by no means an exhaustive list.
Shared devices
Although some predictions of the past stated that all devices will be used by a single user, the reality is that, more often than expected, devices are shared. Let me explain why this is a problem. The browser, when accessing your website, will get an ECID. This ECID will be shared by all users. However, assuming that each user has a separate account on your website, when they log in, they will get a different customer ID.
| User | ECID | Customer ID |
|---|---|---|
| Alice | 1234567890 | a1b2c3d4e5f6 |
| Bob | 1234567890 | z9y8x7w6v5u4 |
In this scenario, if both ECID and Customer ID are set as identities, AEP will combine the two profiles into one. There will be no more Alice and Bob as separate entities.
What will this new profile look like? This depends on the merge policies, but, in the general case:
- For Individual Profile XDM schemas, the last fragment processed by AEP will prevail for each XDM schema.
- For Experience Events, the combination of all events from all users.
While the next table is not completely correct, it gives an idea of how this new profile will look like:
| User | ECID | Customer ID |
|---|---|---|
| Alice+Bob | 1234567890 | [ a1b2c3d4e5f6, z9y8x7w6v5u4 ] |
We could assume that an email address is unique per person so that we can safely assume that it is a good identifier… and we would be wrong.
A typical scenario of email sharing is when a parent needs to create accounts for their children and themselves in some system. To keep things simple for the parent, it is very common that they use their own email address on all accounts, both their own and their underage children. Another scenario is somehow the opposite: grandchildren managing their grandparents’ online accounts, while the grandchildren keep a separate account for themselves. As we know, our grandparents struggle with technology and need our help. Again, for simplicity, the grandchildren may use their email address in the grandparent’s account.
I am sure you are already seeing where I am heading to. When ingesting these profiles in AEP, AEP will collapse all profiles with the same email address. The situation is the same as above, except that instead of ECID we now have an email address.
Telephone number
What is more personal than a telephone number? In reality, it is not that personal. Mobile operators recycle the numbers that are no longer in use. I guess they wait for a grace period after receiving a cancellation and then assign these unused numbers to new customers. I have experienced it myself.
The problem, in this case, is that CRM databases always have outdated information. An individual may have supplied a telephone number a few years ago, canceled the number later, the operator assigns the number to another person and, finally, this other person supplies this number when creating a profile in the same CRM database. When AEP gets these records, since the telephone number is the same, both profiles will be collapsed. In this case, it is even worse than the previous cases, as the individuals have no relationship and do not know each other.
Tolerances
Before going into some potential solutions, I would ask one question: how much profile collapse are you willing to tolerate?
The answer will depend a lot on the case. Let me show a couple of examples:
If you need to send institutional messages to all members of your entity, you will probably not tolerate a profile collapse based on email addresses. You want each individual to receive their personalized email. If you are using AEP only with paid media and Adobe Target, you may be fine with an error rate of 1%. It is not a big deal if some people get the wrong message, as long as the majority get it right.
I suggest you analyze your CRM or loyalty databases before sending the data to AEP, to see how many profiles will collapse. Then, based on the results of this analysis, decide what to do next.
Potential solutions
As with most problems in life, there is no universal solution. There are many variables to consider and each case is different. However, I will provide three options that you can explore to avoid profile collapse:
- Use your own identity. If you have an identity namespace that you control, like a CRM ID or IdP ID, and it is present in all your data sources, you should stick with it. In this case, you do not need to set the email address or the phone number as an identity and keep them just like regular profile fields.
- Concatenate parameters. Sometimes you can concatenate various parameters to generate a truly unique ID. You can use data prep functions for this. This may be useful in case of a collision of email addresses: you could prepend or append other parameters, like the first and last names.
- Hash functions. Although this is not a solution on its own, you may have cases where the profile attributes that are needed to generate unique identities, cannot be used for any reason. In these cases, you could evaluate generating an SHA hash of these parameters, as this may allow you to use them.