Being able to identify your customer as they browse your websites within the Adobe Experience Cloud solutions brings lots of additional features. However, it is not as easy as it initially looks like. This customer identification process is a bit complex and I will explain here what you need to do.
What the MCID is not for
It goes without saying that the first pre-requisite is to deploy the MCID to your website. Before I continue, I need to debunk a myth.
A typical misconception I see in many of my customers about the MCID is that it magically detects who the user behind the screen is. In other words, after setting the MCID for the first time for a visitor, Adobe will
stalk follow this user everywhere. This means even after clearing cookies or switching to a new device, Adobe will assign him the same MCID value. As you know, this is not the case and it cannot be used for customer identification. There are some solutions to try to identify who the visitor is, but none of them is 100% accurate.
The only solution 100% accurate is to let the users identify themselves. The most common approach is by having a log-in page, where the user enters a username and a password or using social login. Most websites have one of those, although I know some verticals rarely have one. Banks are probably the most fortunate in this case as you must log in to do anything meaningful with the website. Retailers, travel agencies and similar websites will also have a high percentage of visitors logging in.
If you have a log-in page, the next thing you must do is add all the needed code to set a cookie or an entry in the data layer with the CRM ID. If you use the latter, you must make sure this value is persisted. This code will likely be both in the back-end and in the front-end. I will use from now on the “CRM ID” term as a placeholder for any unique ID you use internally for customer identification. It does not need to come from a CRM system, any database will do, but it needs to be unique per customer and must not contain any PII data. For example, using a social security number or the email address as this ID is unacceptable.
One final comment about the identification page. In many websites, there is a trend to allow anonymous users to purchase, hoping this will increase conversion. If this is your case, then you will not be able to uniquely identify your visitor. You will need to evaluate the business benefits and drawbacks of these two options.
Sending the CRM ID to Adobe
I assume that, by now, you have a log-in page and, once the user has identified himself, there is CRM ID available on all pages. The next step is to send this CRM ID to Adobe’s servers. If you wonder why you would like to do that, I will give some use cases in later posts.
Capturing this CRM ID with DTM is very simple. You first need to create a data element to read the CRM ID from wherever it is stored. In this example, I use a cookie named “externalId”:
Then, in the Marketing Cloud ID Service settings page, set a customer setting as follows:
The “Integration Code” comes from two different places, depending on the case:
- Customer Attributes: alias ID
- Adobe Audience Manager: data source (usually set as cross-device) integration code
If these last two concepts seem alien to you, I will explain them in the future. However, do not just use “crm_id” as the integration code, unless this is exactly your case.
The “Value” must be the data element you have just created and the Auth State should always be “Authenticated”.
"id": /* INSERT CRM ID HERE */,
You have the full documentation here: https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid_setcustomerids.html.
- Android: Visitor.syncIdentifier() (https://marketing.adobe.com/resources/help/en_US/mobile/android/mc_methods.html)
- iOS: + (void) visitorSyncIdentifierWithType (https://marketing.adobe.com/resources/help/en_US/mobile/ios/mc_methods.html)
In both cases, the parameter identifierType refers to the integration code.