Adobe ECID explained: the Experience Cloud ID and server-side customer ID sync

If you run Adobe Analytics, Target or Audience Manager, almost everything about a visitor hangs off one identifier: the Experience Cloud ID, or ECID. It is the reason a visit in Analytics and an audience in Target refer to the same person. It is also one of the more fragile parts of an Adobe setup.

What the ECID is

The ECID (previously the Marketing Cloud ID, or MID) is a persistent, anonymous visitor ID issued by Adobe’s Experience Cloud Identity Service. It is scoped to your Adobe organisation, which is identified by an IMS Organization ID in the form 1234567890ABCDEF@AdobeOrg. Every Adobe solution that supports the identity service reads the same ECID, which is what lets data join up across products.

Where it lives

With the older Visitor API library, the ECID is stored in a first-party cookie named after your organisation (AMCV_ followed by the org ID). With the Experience Platform Web SDK, it lives in an identity cookie written by the SDK. In both cases the cookie is usually set by JavaScript in the browser.

That is the weak point. Safari deletes cookies set by JavaScript after 7 days without a return visit, and the identity service’s own calls are commonly blocked by privacy tools. When the cookie disappears, the next visit gets a new ECID, and Adobe sees a new visitor: returning-visitor rates fall, journeys split in two, and Target audiences forget people.

Adobe’s own answer for the cookie problem is a first-party device ID set by your server, which the Web SDK can use to derive a stable ECID. The principle is the same one that fixes every vendor cookie: set the identifier from your own server, on your own domain.

Customer ID sync: linking ECID to a known person

An ECID is anonymous. When a visitor logs in, signs up or identifies themselves, you can tell the identity service which known customer the ECID belongs to. This is customer ID sync. Each customer ID is sent with:

• an integration code naming the data source it belongs to (for example your CRM ID, or a hashed email);
• the ID itself;
• an authentication state: 0 (unknown), 1 (authenticated) or 2 (logged out).

In the browser this happens through the Visitor API or the Web SDK identity map, which means it only happens if the library loaded and the call was not blocked.

Syncing customer IDs from the server

Adobe also documents a direct integration with the identity service: a GET request to dpm.demdex.net/id with d_-prefixed parameters. That makes server-side sync possible:

GET https://dpm.demdex.net/id?d_orgid={org_id}&d_ver=2
      &d_mid={ECID}
      &d_cid_ic=email_sha256%01{sha256 of the e-mail}%011
      &d_cid_ic=crm_id%01{user ID}%011

Each d_cid_ic carries the integration code, the ID and the authentication state, separated by the %01 control character Adobe specifies.

Datafly Signal sends this sync from your server whenever a visitor identifies, logs in or signs up. Email is trimmed, lower-cased and hashed with SHA-256 inside your infrastructure before it is sent, so the raw address never leaves your deployment. Nothing is sent until you configure at least one integration code.

Setting it up

1. Find your IMS Organization ID in the Adobe Admin Console. 2. In Audience Manager or the Experience Cloud, create the data sources you want to sync (a hashed email source and/or a CRM ID source) and note their integration codes. The email source must expect SHA-256. 3. Add the Adobe Identity Service integration in Datafly Signal with the org ID and integration codes. 4. Validate against a non-production Adobe organisation before going live.

Why it is worth doing

Customer IDs that reach Adobe reliably mean known customers stay joined up across devices and sessions, even when the browser blocks the identity service, and Analytics, Target and audience activation all work from the same person.

Read the Adobe Identity Service integration docs, or see how identity works in Datafly Signal.