Revisiting the Experience Cloud ID Service

01 Jun 2025 » Platform

I was in the process of writing a blog post on the FPID and I realized that my post on the Marketing Cloud ID was very outdated. Even that name has not been used in many years. So I decided that I needed an update to this feature. If you are familiar with it, I do not think I will explain anything new to you. However, if you are just starting with the Adobe ecosystem, this post is for you.

Visitor vs Person

Before diving into the details of the Experience Cloud ID (ECID) service, it is important to explain a key concept, one of the rules of the Internet.

Marketers always want to know who is interacting with the company’s property. However, this is impossible. As long as the law permits, technology will allow you to remain anonymous. Only when you provide your credentials does a company know who you are.

With this premise in mind, I can attempt a basic definition for visitor and person:

  • A visitor is an individual who is interacting with a website or mobile app without providing any information that can uniquely identify him or her. As we will see later, this definition is just a starting point.
  • A person is an individual, often a customer of the company, who has identified him/herself while interacting with a website or mobile app.

For the rest of this post, I will only refer to visitors.

The Era of Independence

Online tracking tools need a way to identify visitors and link all events from the same individual. Before the Adobe Experience Cloud (AEC), each tool had its own identifier, which were completely disconnected:

  • Adobe Analytics (AA) had the s_vi cookie, although it supported other identifiers.
  • Adobe Target (AT) had the mbox cookie.
  • Adobe Audience Manager (AAM) had the demdex cookie.

These identifiers are still used today, although they are only relevant for isolated implementations.

An ID to Rule Them All

As Adobe tools became more integrated, a common identifier was needed. This led to the creation of the ECID service.

The ECID is a random, unique value that identifies a visitor, and is shared across all Adobe tools:

Other tools like Adobe Campaign also support the ECID. This makes it possible for all tools to share visitor data among them, as there is a common key.

The Lifecycle of the ECID

Managing ECIDs involves four steps: generation, storage, access, and deletion.

Generation

A new ECID is generated when a visitor interacts with a web or mobile app and no ECID is available. This occurs for first-time visitors or if the ECID has been deleted.

Let’s explore now the two ways to generate the ECID.

The first option is usually for the case when you are not using AEP, where you can use the legacy ID Service API. This approach relies on AAM to generate the ECID via a call to dpm.demdex.net. Here is an example response:

{
    "d_mid": "90118992779512484750418347061211614812",
    "id_sync_ttl": 604800,
    "d_blob": "6G1ynYcLPuiQxYZrsz_pkqfLG9yMXBpb2zX5dvJdYQJzPXImdj0y",
    "dcs_region": 7,
    "d_ottl": 7200,
    "ibs": [
        {
            "id": "411",
            "ttl": 10080,
            "tag": "img",
            "fireURLSync": 1,
            "syncOnPage": 1,
            "url": [
                "//cm.everesttech.net/cm/dd?d_uuid=90491266071992917220381119861073162061"
            ]
        }
    ],
    "subdomain": "ags059",
    "tid": "9C89AwmqTBo="
}

Notice the d_mid parameter: this is the ECID. For the curious minds, MID comes from the days when it was called Marketing Cloud ID.

the second option is recommended if you have AEP or want the features offered by AEP’s Edge Network. In this scenario, you should use the Web SDK or the Mobile SDK. These libraries call AEP’s Edge Network, which generates and returns a new ECID if the call does not include one. Note that the ECID is generated during the invocation, not before. Since Web and Mobile SDKs are very chatty, for the example I will only show the relevant part of the response (ignore the CORE namespace):

{
    "requestId": "a688e4ae-b764-42f5-953c-ccfc9cdaf9f8-8ee2eabe8d3c4c80",
    "handle": [
        {
            "payload": [
                {
                    "id": "85876247190619965311149449127327118836",
                    "namespace": {
                        "code": "ECID"
                    }
                },
                {
                    "id": "90491266071992917220381119861073162061",
                    "namespace": {
                        "code": "CORE"
                    }
                }
            ],
            "type": "identity:result"
        }
    ]
}

Storage

Once an ECID is generated, it must be stored for subsequent calls. The Mobile SDK stores it in the application’s storage space. I do not have much more information about this.

The Web SDK and ID Service API store the ECID in a cookie. The cookie name starts with AMCV_, commonly referred to as the AMCV cookie. Its value includes the ECID, along with other parameters. Here is an example of how the ID Service API library stores it:

359503849%7CMCMID%7C90118992779512484750418347061211614812%7CMCAAMLH-1749396731%7C7%7CMCAAMB-1749396731%7C6G1ynYcLPuiQxYZrsz_pkqfLG9yMXBpb2zX5dvJdYQJzPXImdj0y%7CMCOPTOUT-1748799132s%7CNONE%7CMCAID%7CNONE%7CvVersion%7C5.0.1

If you URL-decode this string, split it using the pipe (|) as a separator, and find the MCMID string, the next string is the ECID: 90118992779512484750418347061211614812.

The Web SDK stores only the ECID and does not URL-encode it:

MCMID|85876247190619965311149449127327118836

Before continuing, let’s clarify a few things about storage:

  • Browsers do not share cookies. For example, Google Chrome and Microsoft Edge keep their own cookie storage (I like to call them cookie jars). This means that if you use the same computer to browse the same website through different browsers, you will get one ECID per browser.
  • Each mobile application in your device has its own storage, which is not shared with other applications. Consequently, two applications with Mobile SDK installed will get two different ECIDs.
  • Many browsers allow the creation of profiles and private browsing or incognito mode, which effectively creates new cookie jars within the same browser. A new ECID will be generated for each cookie jar.

Access

You should not need to manually retrieve the ECID from the cookie. The ID Service API library, Web SDK, or Mobile SDK provide methods to get it. However, unless you have a specific use case, you do not really need to retrieve it. All modern Adobe client-side libraries will automatically read the ECID from the cookie/storage and include it in all calls.

Deletion

Generally, you do not want to delete an ECID. It should be a durable identifier. However, it will be deleted under the following circumstances:

  • The user actively deletes cookies
  • The user actively deletes the mobile app storage or the app itself
  • The AMCV cookie expires
  • The browser deletes tracking cookies, like Safari with its ITP rules
  • The OS automatically deletes the mobile app storage after a long period of inactivity
  • The user browses in private mode or incognito window

Visitor Metric

So far, I have explained the basics of the ECID service. There are nuances and edge cases, but those are for another day.

However, there is one problem you need to know. If you have been paying attention, you may have noticed that the definition of visitor is inaccurate. There are many cases where a single person behind a computer generates multiple ECIDs. As a result, counting visitors by ECIDs will always yield an inflated number.

Adobe is replacing the concept of unique visitors with unique devices. While this is still not a perfect name, as you may have multiple apps or browsers on the same device, it is a step towards moving away from the visitor metric.

Server-Side

Having written many posts on server-side digital marketing, I want to conclude with a comment on this case. If you plan to use the Edge Network Server API, you will need to replicate most of what the Web SDK does regarding the ECID lifecycle. You must store the ECID after it is generated for the first time and send it again with subsequent calls. If you are making calls on behalf of multiple individuals, you will need to manage one ECID per individual.

 

Photo by cottonbro studio

Related Posts