Cookies, IDs, and the Experience Cloud

In January 2008, when I joined a company called “Omniture” and started working as a consultant on a product called “SiteCatalyst”, ìt (like most web analytics tools at the time) relied on cookies quite a lot.

There was one cookie, specifically, which was important. It was called “s_vi”, and it held what we called the “visitor ID“, a random string of numbers that was used by the tool to re-identify “visitors” on subsequent tracking calls.

At the time, we had the possibility to set that cookie either on the Omniture-owned “2o7.net” domain — we called that “3^rd party cookies”, or on some CNAME, owned and administered by the site owner (“1^st party cookies”).

If a visitor would not accept one or the other, SiteCatalyst would fall back to calculating a visitor ID based on IP address and HTTP User Agent.

Ah… life was easy back then…

More Options

Even back then, it was possible to set your own visitor ID. Very few customers did (or do) that in practice. Those who tried came to the conclusion that it was more complicated than they had expected, and ultimately not worth it.

In January 2013, version H.25.3 of the s_code.js introduced a fallback ID, based on Javascript and a new cookie called “s_fid”.

By that time, browsers were systematically blocking 3^rd party cookies, a fallback was necessary.

People started to use Analytics (as it was known by then) and Target in tandem, which required duplication of data at the time.

In April 2014, version 1.3 of the AppMeasurement.js added support for the Marketing Cloud ID Service, which provides a unified visitor ID that can be used in the other solutions — the Marketing Cloud ID, or MID.

The solution called Audience Manager had always worked with the concept of a “declaredID”, and in June 2015, with Marketing Cloud ID Service’s VisitorAPI.js version 1.5, “customerID” was added, creating the basis for a cloud-wide way to track customer IDs. The idea, just as with AAM: capture customers, not visitors. People, not browsers.

For those who tried to create their own visitor IDs and gave up, this was the new way to go.

The change from “declaredID” to “customerID” wasn’t really a big change. In a sense, the Marketing Cloud ID Service contains a subset of AAM functionality, and migrating the “customerID” into the MCIDS made it available to the other solutions.

Fast forward to August 2017, and a short but urgent project that would force me to understand quite a bit more than I ever wanted about AAM’s “DIL code” and the “Audience Manager Module” for AppMeasurement.js.

After literally years of shying away from the whole “visitor ID / customer ID complex”, it turned out that the ID conundrum is actually pretty easy to understand by now.

So here goes.

One ID, to eventually rule them all

If you implement today, you should really use the Marketing Cloud ID Service, no matter what other solutions you deploy.

The Marketing Cloud ID Service has its own DTM Tool, which makes it very easy to deploy. For those of you deploying differently:

• Marketing Cloud ID Service needs to load first.
• The other solutions can be configured to use the MID that MCIDS returns.
• If you want, and if you have customer IDs visible on your site, you can use the customer ID plus logged-in/logged-off state with the Marketing Cloud ID Service.

Analytics, Target, and Audience Manager should be loaded after the Marketing Cloud ID Service, and instead of sending their traditional visitor IDs, they will send the Marketing Cloud ID provided by the MCIDS. This is what allows the sharing of segments between the solutions.

For Analytics, you can enable a grace period. This is useful, if you have deployment cycles or restrictions and are unable to enable the MCIDS across all your sites in one fell swoop.

You need to do that, so that during the grace period, Analytics will still send both visitor IDs, allowing it to follow a visitor across parts of your site that do and don’t use MCIDS.

The solutions can also receive the customer ID, and handle it any way they want. I’m pretty sure we’ll see some interesting ideas over the next few years.

But to restate how simple usage is: load MCIDS first, then all other tools, each of them configured to use the MID. That’s all it is.

IDs, IDs, IDs

So, how does the Marketing Cloud ID Service sets IDs?

When a page loads, you’ll notice it loads an iFrame from dps.demdex.net/dest5.html.

The Marketing Cloud ID Service does that so it can set a cookie on the demdex.net domain. This domain came to Adobe with the Demdex acquisition (the solution now known as Audience Manager).

MCIDS puts a “demdex ID” into that cookie, which it’ll randomly assign the first time it sees a visitor.

Using the demdex ID and your Adobe Org ID, it can then calculate the Marketing Cloud ID, the MID.

You read that right: the MID is calculated.

MCIDS will by default store it in a cookie called “AMCV_xyz” with “xyz” being your Adobe Org ID, but if that cookie is deleted, it can still reconstruct the MID as long as the demdex.net cookie is present.

Since January 2017, with the change to VisitorAPI.js 2.0, the Marketing Cloud ID Service will now send an extra call to cm.everesttech.net, the Media Optimizer domain, in order to improve match rates.

I’m sure the story doesn’t end here at all. Browsers evolve all the time, and Marketing Tools both evolve and adapt. I’ll write a new article about this subject in 2020, perhaps.

(2020 update: I did! See Edge Nodes, Data Centres & other Updates)