Navigating Adobe ECID Limitations and Embracing AdFixus ID for Enhanced Identity Persistence in FPID

In the ever-evolving landscape of digital experiences, Adobe's Experience Cloud Identity Service (ECID) plays a pivotal role in providing a common identification framework for Experience Cloud Applications and Services. However, the ECID faces challenges in persisting user identities across domains and in unauthenticated states, primarily due to browser privacy mechanisms. This blog post aims to delve into the intricacies of the Adobe ECID service, highlight its limitations, and introduce AdFixus ID as a solution to overcome these challenges and working with the new FPID.

Understanding the Adobe ECID Service

“The Experience Cloud Identity Service enables the common identification framework for Experience Cloud Application and Services. It works by assigning a unique, persistent ID known as the Experience Cloud ID (ECID) to a site visitor.”

“The ECID is derived from your OrgID and the Demdex ID. If these IDs remain constant, you get the same ECID value every time.”
[source]

The ECID service generates a value called “MID” (a.k.a “Experience Cloud visitor ID”) using two datapoints.  

1. Experience Cloud OrgID - Unique ID assigned to your Adobe Experience Cloud organisation. This is the same across your sites.

2. Demdex ID – User ID set on the users browser as a 3rd party cookie provided by Adobe Data Collection Servers (“DCS”). The “ECID service” makes a call to the Adobe DCS to get / set the Demdex ID value on the browser.

Therefore:  ECID = OrgID + Demdex ID

Limitations of Adobe ECID

Despite its efficacy, the Adobe ECID service encounters several limitations imposed by browser privacy mechanisms:

1. Cross-Domain Tracking: Third-party cookies are essential for understanding user activity across domains. However, on browsers where third-party cookies are blocked (e.g., Safari, Firefox), cross-domain tracking becomes unavailable.

2. ITP Policies Impact: Intelligent Tracking Program (ITP) policies affect all first-party cookies set by Adobe, including:

• “AMCV” cookies set by the Adobe Experience Cloud Visitor ID (ECID) service library.

• The Analytics legacy “s_vi” cookie when it is configured with first-party data collection using a CNAME.

3. The Analytics legacy “s_fid” cookie, which is the fallback cookie used when “s_vi” cannot be set.

First-Party Cookie Lifespan: While first-party cookies are generally permitted, Apple's ITP limits the lifespan of Adobe's first-party cookies. On Safari, cookies have a 7-day expiry, reduced to 24 hours for click-throughs.

CNAME Implementations: Even with the ECID service, CNAME implementations are impacted. Initially, ITP policies applied only to client-side cookies, but since November 2020, they extend to server-side cookies via CNAME implementations.

How to Test This On Your Own Domains?

Cross domain - Safari user with default settings (i.e., 3rd party cookies are disabled).

1. Go to yourdomain1.com -> Observed “MID” values - MID = “58936248630745680494328042083104786947”
   

2. Go to yourdomain2.com -> Observed “MID” values - MID = “74233199439302024212884947208296973575”
   

3. Result = ECID does not persist
   

Cross domain - Chrome user with 3rd party cookies manually disabled (i.e., all Chrome users by EOY 2024).

1. Go to yourdomain1.com -> Observed “MID” values - MID = “65149686489951960513103230532941539414”
   

2. Go to yourdomain2.com -> Observed “MID” values - MID = “86787776097041963991459955620790098034”
   

3. Result = ECID does not persist
   

Cross domain - Chrome user with 3rd party cookies enabled.

1. Go to yourdomain1.com -> Observed “MID” values - MID = “37619412855739077060297009041400122230”
   

2. Go to yourdomain2.com -> Observed “MID” values - MID = “37619412855739077060297009041400122230”
   

3. Result = ECID does persist

Only Scenario 3 (Chrome browser with 3^rd party cookies enabled) observed the “ECID” value to be persistent across the domains.

Adobe ECID + AdFixus ID Together

The AdFixus ID is:

• Fully 1^st party (not a 3^rd party cookie or a CNAME cookie) as accepted by all browsers.
• Provides an anonymous ID for all your web users (regardless of whether they are signed-in or unauthenticated) whilst not relying on PII or user / browser signals.
• Durable (on a rolling 12-month window basis).
• Cross-domain  

Adobe provides organisations with the ability to pass in their own customer IDs into Experience Cloud solutions. Currently, this feature is supported for:

1. Adobe Experience Platform (RT-CDP & CJO)

2. Adobe Analytics

3. Adobe Audience Manager

4. Adobe Target

This is achievable via a feature called “setCustomerIDs” which is available by default through the ECID Service you already have deployed on your site via Adobe Launch Tags.

By including the AdFixus ID as a Customer ID into your Adobe Ecosystem, you redefine the previous ECID formula for unauthenticated users across multiple domains:

• PREVIOUS: ECID = OrgID + Demdex ID
• FUTURE: AdobeUserID = AdFixus ID OR ECID (if AdFixus ID is not available)

Adobe’s recommendation - Generate first -party device IDs (FPID)

Adobe Experience Cloud applications have traditionally generated cookies to store device ids using different technologies, including:

1. Third-party cookies
2. First-party cookies set by an Adobe server using a domain name’s CNAME configuration
3. First-party cookies set by JavaScript

Recent browser changes restrict the duration of these types of cookies. First-party cookies are most effective when they are set using a customer-owned server using a DNS A/AAAA-record as opposed to a DNS CNAME. The first-party device ID(FPID) functionality allows customers implementing Adobe Experience Platform Web SDK to use device IDs in cookies from servers using DNS A/AAAA-records. These IDs can then be sent to Adobe and used as seeds to generate Experience Cloud IDs (ECIDs), which remains the primary identifier in Adobe Experience Cloud applications.

Reference - Generate first-party device IDs | Adobe Data Collection

‍

What does this mean for enterprises? There are two options:

1. Utilise an internally owned first-party ID that is durable for anonymous users across all domains.
2. Generate a server-side 1^st party cookie ID that is durable on a single-domain only.

Unfortunately, most enterprises do not hold an internal first-party durable ID.

This is significantly limiting your ability to run cross domain journey analysis for your anonymous audiences – if you have purchased or looking at purchasing Customer Journey Analytics (CJA) and have multiple domains then please reach out to discuss.

Introducing AdFixus ID as a Solution

To address these limitations and enhance identity persistence, organization scan turn to AdFixus ID.  

This innovative solution offers a robust framework that aligns with evolving browser privacy standards, ensuring seamless cross-domain tracking and overcoming ITP policies. AdFixus ID provides an alternative to 3rd party cookies, allowing organizations to maintain user identities effectively, even in the changing landscape of browser privacy. AdFixus customers such as carsales have adopted the AdFixus ID as the “common denominator identifier” to build their customer profile ecosystem within Adobe Experience Cloud.

Summary:

The Adobe Web SDK generates an Adobe Visitor ID (ECID) from the FPID.

• FPID + OrgID = Visitor ID

 An FPID is only as durable as the ID that is provided as the seed.

• FPID without AdFixus ID: Single domain persistent - Limited in browsers which block cname/aname cloaked cookies (e.g. Safari)
• FPID with AdFixus ID: Cross domain persistent - Not limited by browsers

In conclusion, while Adobe's ECID & FPID service forms a cornerstone of identity management, its limitations necessitate a proactive approach. AdFixus ID emerges as a promising solution, empowering organizations to navigate the evolving digital landscape while ensuring consistent and persistent user identities across domains. Embracing such solutions is vital for delivering a seamless and personalized user experience in an era of increasing privacy constraints.