Email Address as Identity in AEP
14 Jul 2024 » Platform
One of the first tasks that you have to do when implementing the Adobe Experience Platform (AEP) is to select your identities. This is not a trivial decision, it will define how the identity graph will work, which, in turn, will have profound implications for the functioning of the tool. In all cases, the ECID will be one of the identities. The typical next candidate for identity is the email address. However, before you take this decision, read on.
Shared email addresses
You might think that an email address is used exclusively by one person. It took me some time to believe and accept that this is not a true statement. There are many cases, unfortunately, when email addresses are shared by multiple people. Here are some examples I have encountered:
- Parents, creating an account for their underage children, may use their personal email address for that account.
- Young people may manage online accounts for their grandparents, but use their email address.
- The leader of a group of fans may create an account for each individual, on their behalf, but all accounts will have the same email address.
- Spouses share the same email address.
In all these cases, the reason is the same: simplify the management of the accounts by centralizing all messaging in a single inbox.
I am sure you are already seeing where the problem is. If we use the email address as an identity in a situation like those above, we will get profile collapse. What can we do to avoid it?
Start with another identifier
I would contend that using the email address as an identifier in the first place is a bad idea. All systems that deal with customer data have their own identifiers:
- CRMs generate CRM IDs.
- Databases generate unique IDs per row.
- Loyalty software generates its own, unique ID per customer.
- Hashed credit card or current account numbers are supposed to be unique.
- IMEIs are usually unique worldwide.
- MDM systems assign a random, unique ID per identified customer.
Is there a way you can use any of these IDs or any other unique parameter as your primary identity?
If you cannot and are still stuck with email addresses, let’s explore other options.
Force unique email addresses
Many online services force you to use a unique email address. This is the case of, for example, Paypal. It is the cleanest solution from our side:
- We can use the email address as an identity. You can then combine data sources that only have this identity in common.
- An inbox will only receive messages intended for a single person. Think about the opposite situation: an inbox having multiple messages, with widely different personalizations.
- As a consequence of the previous two points, the expectation is that digital marketing efforts will be more successful.
You can also suggest to your customers to use the trick of adding a + and a random string to the email address. This trick does not create a new inbox, just a new email address that will land in the same inbox as the base address, for example, from [email protected] to [email protected]. Not all email providers support it and you will not get the benefits described in the second bullet above.
You also need to be aware of the downsides of this approach, i.e., not allowing duplicate email addresses:
- You are forcing your customers to interact with your company in a way that they may not like.
- If you already have a functioning service that works well with shared email addresses, you will need to invest in a transition and implement changes to force unique email addresses.
You need to evaluate whether this additional friction and investment will be compensated by better marketing performance. In any case, if you are creating a brand new service, I strongly recommend imposing unique email addresses per account.
Email address transformation
If you have to handle multiple accounts sharing the email address, and you cannot use any other identifier, the last option is to try to manipulate the email address to generate a unique identifier. This usually means concatenating the email address with another parameter so that the combination is unique. I would then recommend hashing the resulting string. I do not think there is a need to use a strong hash, as you should not be using these strings for security purposes.
I have heard of some AEP clients using this approach, but it is not a panacea and it is not always possible.
Final thoughts
I am afraid there is no magic bullet to solve this problem. Remember what I said at the beginning, selecting the identifiers is not a trivial endeavor. Take your time to explore multiple options before you select the best identifiers for your particular case and always try to avoid the email address.
Photo by: Sarah Pflug