Experience Cloud ID Service & 3rd-party calls

It brings me great pleasure to introduce this guest post by my colleague Marko Kocic! He tackles an often-asked question about the Experience Cloud ID Service and how to manage 3rd-party network calls.

Let me start off by saying that this is a topic that appears with the tedious inevitability of an unloved season. And it’s often accompanied by expressions such as “Our security guidelines don’t allow for any 3rd party calls on this part of the website”, or sometimes “Ghostery tells me there’s Audience Manager on our website – but we don’t have that and need it turned off ASAP”.

So, why would the Experience Cloud ID Service (ECIDS), whose main task is to generate one Adobe visitor IDs for all the Adobe solutions in place on a website, even require 3rd party calls?

Origin Story

The ECIDS has its roots in the 2012 acquisition of Demdex and its Data Management Platform (DMP), which got rebranded into what’s known today as Adobe Audience Manager (AAM).

It offered Adobe not only a clean and robust way of managing and tying together the different, solution-specific device IDs / cookie IDs and associated profiles. It also gave the Experience Cloud cross-domain capabilities allowing it to recognize the same visitor across multiple domains belonging to the same company. They could simply leverage the DMP’s 3rd party cookie (demdex) for that.

With that in mind Adobe engineering developed a new Javascript library “VisitorAPI.js” that implemented a new cross-solution ID called “mid” or “MCID” (shorthand for “Marketing ID”, “Marketing Cloud ID”) using the demdex cookie and Adobe Cloud Org ID as the basis, updated the individual solutions to accept “mid” or “MCID” and built the Adobe profile and Adobe ID handling into the existing Demdex platform.

The solution nobody knew they needed

Since the common solution ID gave engineers a straightforward way of identifying the same visitor across Adobe solutions, this so called “Marketing Cloud ID Service” became the true backbone of the Experience Cloud.

Popular integrations and features such as Segment sharing, Analytics for Target (A4T) and the Analytics Destination were made possible because of it. And funnily enough many customers and partners were slow to realize the value this unassuming solution could bring them.

Over time the Marketing Cloud ID Service and the VisitorAPI.js took on even more functions, especially from Adobe Audience Manager (AAM).

Here’s a brief overview of all the things it does or helps other solutions do:

1. Recognize the same visitor across different domains belonging to the same Adobe Experience Cloud
2. Declare deterministic identifiers (e.g. CRM ID, hashed mail address) and login status to Adobe solutions for online use of onboarded CRM data
3. Handle Adobe tool opt-ins (Opt-in Service)
4. Helps AAM handle all cookie related functionality (dropping 3rd party cookies, performing ID syncs, Cookie Destinations)
5. Executing the URL requests from AAM URL Destinations

Handling ECIDS 3rd party calls

And as you may have already guessed, with the exception of 1) & 2) all those other features (yes Opt-in service as well) work via way of 3rd party calls for which there’s no CNAME option and where reverse proxification would break most of ECIDS AAM-related features (hint: there’s an excellent article from Frederik Werner that explains how you can setup Adobe Analytics & ECIDS in a 1st party context here ).

But luckily we can disable most of the 3rd party calls via simple configuration flags for VisitorAPI.js / the Experience Cloud ID Service Extension in Launch.

Option #1: Set “disableThirdPartyCookies” = True

What does it do?

• This blocks all 3rd party calls including most calls to demdex.net, all ID syncs that are configured for the specific AAM container on your website and stops AAM from returning, reading or setting 3rd party cookies (including the ones used by AAM and ECIDS to generate the ECID and to track across different domains of the same customer).
• It forces the ECIDS to generate a new random, client-side ECID even for existing visitors.

What it won’t do:

• Once you’ve enabled the Opt-in functionality as part of the ECIDS (see Jan’s earlier post) you’ll have at least one, read-only request to “dpm.demdex.net/optOutStatus” per session. VisitorAPI.js will receive a JSON response with the ttl of the Opt-in and without it the Opt-in Service won’t “release” any of the tools, even those you’ve opted-in to.
• This configuration flag won’t prevent AAM URL destinations from firing on the page. They would still need to be disabled in the Analytics Launch extension if you’ve implemented AAM alongside Analytics with the server-side forwarding (SSF) method (caution: the option to enable/disable URL destinations is a global option)

When to use “disableThirdPartyCookies” = True?

• When you only have one domain.
• When you absolutely must restrict 3rd party calls and cookies on your website or certain parts of your website.
• If you don’t mind not being able to send AAM audiences to any other marketing platforms (e.g. TTD, Google DV360, Flashtalking etc.)

Option #2: Set “disableThirdPartyCalls” = True

What does it do?

• This configuration flag blocks most 3rd party requests made by the ECIDS to .demdex.net, including the ones needed for generating the ECID.
• Newer versions of the VisitorAPI.js automatically switch to generating the ECID fully client-side.
• If you’ve implemented AAM using DIL code (also referred to as a client-side code AAM implementation) there won’t be any calls to your specific AAM subdomain and therefore no tracking or activation via Cookie or URL destinations.
• If you’ve implemented AAM using the SSF method (meaning AAM is leveraging Analytics tracking requests) then enabling this option will have AAM return no JSON response. Since Cookie and URL destinations rely on this JSON payload to run, you’ve effectively disabled these destinations.

What it won’t do:

• If you’re using the Adobe Opt-in functionality to control Adobe tools depending on user opt-ins, then this configuration flag still won’t stop calls to the Opt-In service. However, it’s a read-only request needed for the Opt-in to work and no actual tracking is taking place.

Conclusion

The ECIDS and VisitorAPI.js were built at a time when the Experience Cloud was in an early stage where it was important to go from point solutions to an integrated marketing tech stack, and where being able to identify visitors across different domains belonging to the same company was a competitive advantage against other marketing clouds. Of course, it was also a time when data privacy standards were much lower than today and the general public was unaware of 3rd-party calls and more importantly “3rd-party cookies” and what they are for.

With the current pace of change in terms of acceptance by the public, ad-blocking technology evolving past simple blocklists and Javascript blockers and the planned phase-out of 3rd-party cookies, it remains interesting to see how ECIDS functionality will evolve and how its technical flows will look like in future versions – especially when it comes to 3rd-party calls and what they’re used for.