Can you please tell me what are the main arguments against using Email Address as Subscriber Key in SFMC? I have been getting requests from our internal stakeholders to use the email as Subscriber Key instead of looking for another type of ID, which I always recommend, but in the end I always lack a number of 'bullet-proof' arguments as to why using email as SK is not best-practice in Marketing Cloud. The only arguments I have used so far is that SF recommends against it, and that when a subscriber's email address is changed his/her SK would be still showing the "old" email address as SK.
I see four main points, when advising clients on what to use a Subscriber/Contact key. The details are indeed very much up to the individual scenario, but these points are universal. The Contact Key should be:
- Unique (daaah!)
- Channel agnostic
I have put a parentheses around number 4, I'll get back to that. So, your suggestion for using email address is failing 2 out of 3 checks. I don't think I need to explain why it's a good idea, that a Contact Key should be unique, so I will focus on the remaining points:
We want the same ID to follow our subscribers/customers throughout their entire lifetime. This should apply to all the systems in your landscape. At least systems which to higher or lesser degree exchange data with Marketing Cloud (see item 4 below). Email address CAN be persistent, but as it is provided by the customer, it is nothing which we can ensure, and people tend to change their email addresses, especially in a B2B context. You don't want to see yourself map each update of email addresses to the initial email address provided by the person 5 years ago. This will easily lead to confusion and poor data quality.
3. Channel agnostic
There are markets around the globe, where emails is not a predominant communication channel. Mobile text messages are very widespread in e.g. Asia and Africa, and relying on email address as a contact key will make it difficult for you to create consumer identities from other channels than email. Also for app push notifications, you should not see the email address as a prerequisite. You might use phone number and a one off code sent in a text message for authentication purposes. Here, we also can't guarantee presence of an email address in the context of creating a new contact.
Especially in complex system landscapes, where we are working with systems of various capabilities, it is not given that all of them have the knowledge of customer's email address. Another key is probably utilised, and hopefully there is an IdP solution in place, which has the central responsibility for managing the core identity details, such as names, contact information (phone number, home address, one or even more email addresses), and map all of this into a single identifier, which is then propagated across all the relevant applications.
There is another detail to keep in mind, in case you are using Marketing Cloud along with Service/Sales Cloud and utilising the Marketing Cloud Connector. In order to use the standard functionality it offers, of a.o. Synchronised Data Extensions and Salesforce Data Entry Event in Journey Builder, you need to use either Contact-/Lead- or User ID as your Contact/Subscriber Key. There are ways to work around that limitation, especially if you have a global IdP in place, and/or have only a limited subset of your contacts in Service Cloud, but this is beyond the scope of this post.
I hope this gave you some more background on what to be aware of, when deciding on Contact/Subscriber Key.