Visitor IDs in Adobe Experience Cloud

Introduction

DMPG provides consulting services for large and enterprise clients using best-in-class analytics, tag management and optimisation & personalisation tools. Due to the changes that have been made to the Adobe Experience Cloud over the last year or so and the increasing capabilities of the products within the cloud we have had many questions around the methods by which Visitor IDs are set and what the impact is on these methods. This article – which is written as a supporting document to some of our training courses – provides the detail behind Visitor IDs within the Adobe Experience Cloud.

Definitions

Depending on where you’re looking in the support materials or who you speak to at Adobe you might here the following phrases used to describe a Visitor ID:

Visitor ID or VID
Analytics ID or AID, Fallback ID or FID
Marketing Cloud ID, Experience Cloud ID, MCID, MID or MCVID

Essentially all of the above relate to setting a single binding key for the Visitor BUT only the third collection of names allows Adobe Experience Cloud organisations to benefit from the rich cross-device capabilities that are now on offer.

As we start to explore how Visitors are defined in the Adobe Experience Cloud we will be making use of the following terminology:

Visitor / User = an anonymous individual identified at the device level
Customer = an individual (or household) identified by some form of customer ID
Organisation = an organisation using the Adobe Experience Cloud
Client = an organisation working with DMPG

History

I’ll show my age here a little bit as when Adobe Analytics was first available – when it was called ‘Omniture’ – there were a few options for setting a Visitor ID:

Allow Omniture to do it – the default method was to use a 3rd party cookie that was set using an https method. This requires a server request and then a response which includes data to be set in a cookie against the domain it was requested from. They most likely used a 3rd party domain back then as iPhone and iPads did not exist and the amount of 3rd party cookie blocking – particularly in North America – was very small. They also likely used an https method over Javascript as not all browsers could handle JS that well back then!
Allow Omniture to do it via your own CNAME – if the previous method was acceptable BUT you wanted your cookie to be set against the domain the user was on you needed to define a CNAME (Canonical Name Record) that acted like an alias for the Adobe data collection domain. The recommendation was usually to have a domain like ‘metrics.domain.com’ and ‘smetrics.domain.com’ for the SSL version. This enabled the storing of the ID in a first party cookie.
You do it – in this case it didn’t matter what exact method you’d use but it would be up to you to set the ‘vid’ value that was used as the primary binding key and would therefore tracking ‘Visitors’ in your data.

Ultimately the Visitor ID would be used to allocate all behaviour. The more accurate your Visitor ID was the more accurate your data was but it presented several issues:

If a Visitor needed to be tracked cross-domain you had to use a CNAME but this would only work if they also accepted 3rd party cookies as you would need to define a primary tracking domain
If the Visitor authenticated mid-session and you wanted to update the Visitor ID to their authentication ID to be more accurate thereafter it would create a new Visitor ID record. This meant that any pre-authentication behaviour (e.g. marketing campaign referrals) would not get attributed to important performance data like sales

At some point – and I can’t remember exactly when – a distinction was made between an Adobe defined Visitor ID and an organisation defined Visitor ID. The Adobe defined one was referenced as the Analytics ID or AID. This did not really bring any new functionality but it did get coupled with a new method of setting an ID called the Fallback ID or FID.

The FID was required to deal with the sudden increase in iPhone and iPad usage. The FID set a 1st party cookie using Javascript and would therefore act as a fallback for instances where customers were still making use of the https cookie method without CNAMEs.

The next – and most significant change – was the introduction of the Marketing Cloud ID Service. This change was designed to allow increased capability of cross-domain and cross-device tracking without the use of CNAMEs as well as cross-product compatibility for the Marketing Cloud tools. The Marketing Cloud was later renamed to the Experience Cloud with subsets including the Analytics Cloud (Analytics, Audience Manager), Advertising Cloud (Media Optimizer Products) and Marketing Cloud (Target, Campaign, AEM, Primetime).

The Marketing Cloud ID Service sets a MCID Cookie using JavaScript from the JSON response it gets from the response to the demdex domain which is connected to a tool often referred to as Profiles & Audiences. This ultimately allows it to go through various different processes, which we will be covering, thus opening up the ability to do:

Cross-Domain tracking
Cross-Device tracking
ID synchronisation with 1st and 2nd party data-sets (primarily CRM systems)
ID Synchronisation with 3rd party data-sets

We understand that the AID method is being deprecated and as such only the VID and MCID method will be available for the primary key used.

How the MCID is set

Now that we have covered some of the history behind how the Visitor IDs have come to be we will focus on the Marketing Cloud ID Service only as it has the greatest consequences.

The MCID process is defined below but is not directly applicable to native mobile app implementations:

User accesses a website or other non-native mobile app that has the Marketing Cloud ID service running
If the MID value is not available a request is made to the demdex server
If the MID value is not passed to the demdex server, because it does not exist yet, the demdex server passes back a JSON string with the MID
The MID is then stored using JavaScript within a 2 year cookie with a name prefixed with the letters ‘AMCV’

It is possible to see this all happen using Developer Tools in a Chrome browser.

Developer tools in Chrome browser

In the above screen-shot the ‘mid’ value can be seen in the ‘d_mid’ property. The MID value is then stored in the cookie who name is prefixed with ‘AMCV’ and includes the Adobe Organisation ID:

The Organisation ID part is important as it is a facilitator for cross-domain tracking without the use of CNAMEs which we’ll look at later. The MID value can then be seen in the network request made to Adobe Analytics:

MID value

In addition to the MID returned by the demdex domain it also returns a Demdex ID (we think this is the ‘d_blob’ property in the JSON string). This is used for ID synchronisation where 3rd party cookies are enabled, a topic discussed later in this article.

For native mobile app implementations the process is a little different but the result is the same:

User accesses the app with the correct Adobe SDK version implemented
The Adobe SDK sets a Visitor ID which acts as an installation ID and will therefore persist as long as the app is not uninstalled
This Visitor ID is then appended to a URL – this method happens to be the same method used to handle cross-domain tracking in cases where the user does not accept 3rd party cookies (more detail below)
A Marketing Cloud Visitor ID is now requested from the Marketing Cloud Visitor ID Service that links VID and MCID

How the ‘Clever’ Stuff Happens

As previously mentioned the Marketing Cloud ID Service can be used to facilitate cross-domain and cross-device tracking along with synchronisation of IDs across 1st, 2nd and 3rd party data-sets. Below summarises how it does this:

Cross-Domain Tracking

Not Using ‘Append Visitor ID Helper Function’ – in this instance if an organisation owns several domains and they are all implemented within the Marketing Cloud ID Service using the same Organisation ID then ID synchronisation will be available if the user accepts 3rd party cookies. If a user access both domainA and domainB, when the demdex call is made on domainB it will know the Demdex ID from domainA and as such use this to define the MID.

This is very useful for situation where organisations want to track cross-domain activity but where the use doesn’t commonly move between domains in a single session or there is no gateway domain.

Using ‘Append Visitor ID Helper Function’ – means that the Visitor ID is actually passed in the link through from domainA to domainB. In this instance when the call is made on domainB to demdex the ‘AMCV’ will already be available and as such a new MID will not be required.

This is very useful for situations where organisations move between domains or there is a global gateway domain in use.

Cross-Device Tracking

There are two ways to do this with the MCID. The first is called ‘Device Co-Op’ which, as it suggests, is a co-operative of organisations using the Adobe Experience Cloud who have opted in to share information anonymously to benefit the wider group. The idea is that if Company A know who a person is on Device A and Device B that this will help Company B understand who the person is on Device A when they only know who they are currently on Device B. It can do this due to ID matching at the Device level and then providing a ‘People’ metric to all members of the Device Co-Operative as well as a ‘Visitor’ metric that is normally device-specific.

The potential pitfall (excluding the likely concerns about privacy) with this method is that it is not 100% accurate and may benefit certain members of the co-operative much more than others. For example, let’s say that a Bank and a Publisher were part of the co-operative. The majority of the Bank customers access the bank on their device in an authenticated state. As such the Device Co-Op service will be able to tie people to devices fairly easily. The publisher on the other hand has very little authentication data but could start to understand people across multiple devices from the data the bank shares with the co-op. In return the bank may get something but it’s unlikely to be much.

The second way cross-device tracking can happen is by authentication and ID synchronisation. Authentication is by far the most reliable and robust method for any business to understand cross-device behaviour. When a user authenticates on a device the Marketing Cloud ID service will need to be told the Customer ID and the authentication state. The authentication state can be one of 3 values, Unknown, Authenticated and Logged Out. Unknown is used by default when the authentication state is not provided.

When the Customer ID is provided and the authentication state is also known this will allow Adobe to match Customer IDs to the MCID. The impact this has varies by product as follows:

Analytics – if the authentication state is ‘Authenticated’ this will mean that hits in this state can be combined despite the MCID likely being different. This does not change the count of Visitors but will allow segments to be created with cross-device behaviour.
Target – as above this will also allow cross-device personalisation in the situation that a Visitor falls into an Audience that was created via Analytics and then shared with Target OR if a Profile Script was used to isolate a Customer Attribute (see 1st party data-set synchronisation)
Audience Manager – this provides options to target the Visitor based on whether they are currently authenticated or whether they have been authenticated before, making use of the ‘Logged Out’ authentication state

ID Synchronisation on 1st/2nd Party Data-Sets

There are two method for doing this depending on the tools you have access to from the Marketing Cloud. If you have access to Adobe Analytics then the method used is called Customer Attributes.

The Customer Attributes work in a similar fashion to SAINT text classification but are made available in real-time for tools within the Marketing Cloud such as Audience Manager and Target to make use of for personalisation. Analytics will be able to access the data for performance reporting. Typically this would be used to synchronise a CRM system with the Adobe Experience Cloud so could have data around a customer’s preferences, order history, communication preference etc etc.

The second method is very similar to the first but is managed as a data source via Adobe Audience Manager. This would only be relevant if the Audience Manager product was purchased without Analytics but we feel that the real value with these tools is how they work together is almost perfect harmony.

2nd party data-sets refer to data sets that an organisation would have access to but do not own. The method for ingesting the data is likely exactly the same as the 1st party data-set but could also be done using the 3rd party data-set method if the Customer ID is not the binding method.

ID Synchronisation on 2nd/3rd Party Data-Sets

If the data is anonymous and therefore not directly related to the Customer ID then synchronisation can only happen in the client. This allows the MCID to be connected to a 3rd party data provider by loading an iFrame on the page and calling a URL that redirects to a demdex domain carrying with it the partner IDs.

This is a capability that is only possible with Adobe Audience Manager and is instrumental in building traits to then define segments for profiling ‘look-a-like’ customers for ad targeting.

Closing Remarks

Hopefully this article have given you a better understanding of the purpose of the Marketing Cloud ID. It may be the case that it’s value is not immediately obvious if you’re not using more than just Adobe Analytics but we would still recommend upgrading to using the ID unless there is a specific reason for setting your own Visitor ID. Future developments across the Marketing Cloud will rely on this ID and even some of the core Analytics features such as video tracking (using heartbeats) relies on the adoption of this ID.

If you would like help upgrading to the Marketing Cloud ID or if you would like to discuss in more detail how it is leveraged across other Adobe Experience Cloud products please get in touch. Here at DMPG we have a team of specialist business and technical consultants who are striving to help clients get the most value from their digital data tools. We don’t just complete tasks for clients but partner with them to work towards a common goal of achieving the digital data objectives of the business.

References

DMPG University is coming soon

Recommended Training Courses

If you found this article interesting you may also be interested in the following courses:

If you or members of your organisation would like us to create a custom course for you then we’re happy to do so. We charge per day rather than per head so can normally create something of significant value very easily.

Contact us today to discuss your requirements

Get in Touch