Adobe Experience Cloud IDs

Adobe Experience Platform Web SDK leverages Adobe Identity Service. This ensures that each device has a unique identifier that is persisted on the device so activity between pages can be tied together.

First-party identity

The Identity Service stores the identity in a cookie in a first-party domain. The Identity Service attempts to set the cookie using an HTTP header on the domain. If that fails, the Identity Service falls back to setting cookies with JavaScript. It is recommended that you set up a CNAME for your Edge Domain config.

Every hit coming from the Platform Web SDK has an ECID added to it by the Identity Service on the Edge Network. For first-time visitors, the ECID is generated and added to the payload. For repeating visitors, the ECID is retrieved from the kndctr_{YOUR-ORG-ID}_AdobeOrg_identity cookie and added to the payload.

The ECID is added under the identityMap field in your xdm. Using the browser’s dev tool, you can view the ECID in the response under the payload with the type: identity:result, but you cannot see the ECID in the request.

CNAME implementations allow you to customize the collection domain used by Adobe so that they match your own domain. This allows Adobe to set first-party cookies on the server-side instead of the client-side using JavaScript. In the past, these server-side first-party cookies were not subject to limits imposed under Apple’s Intelligent Tracking Prevention (ITP) policy on Safari browsers. However, in November 2020, Apple updated their policies so that these limitations were also applied to cookies set via CNAME. Currently, both cookies set on the server-side by CNAME and cookies set on the client-side by JavaScript are limited to a seven-day or 24-hour expiry under ITP. For more information on the ITP policy, see this Apple document on tracking prevention.

While a CNAME implementation does not provide any benefits in terms of cookie lifetime, there can be some other benefits such as ad blockers and less common browsers preventing data from being sent to domains they classify as trackers. In those cases, using a CNAME might prevent your data collection from being disrupted for users employing these tools.

3rd-party identity

The Identity Service has the ability to sync an ID with a 3rd-party domain (demdex.net) to enable tracking across sites. When this is enabled the first request for a visitor (for example, someone without an ECID) will be made to demdex.net. This will only be done on browsers that allow it such as Chrome) and is controlled by the thirdPartyCookiesEnabled parameter in the configuration. If you would like to disable this feature all together, set thirdPartyCookiesEnabled to false.

ID migration

When migrating from using Visitor API, you can also migrate existing AMCV cookies. To enable ECID migration, set the idMigrationEnabled parameter in the configuration. ID migration enables the following use cases:

• When some pages of a domain are using Visitor API and other pages are using this SDK. To support this case, the SDK reads existing AMCV cookies and writes a new cookie with the existing ECID. Additionally, the SDK writes AMCV cookies so that if the ECID is obtained first on a page instrumented with the SDK, subsequent pages that are instrumented with Visitor API have the same ECID.
• When Adobe Experience Platform Web SDK is set up on a page that also has Visitor API. To support this case, if the AMCV cookie is not set, the SDK looks for Visitor API on the page and calls it to get the ECID.
• When the entire site is using Adobe Experience Platform Web SDK and does not have Visitor API, it is useful to migrate the ECIDs so that the return visitor information is retained. After the SDK is deployed with idMigrationEnabled for a period of time so that most of the visitor cookies are migrated, the setting can be turned off.

Updating traits for migration

When XDM formatted data is sent into Audience Manager this data will need to be converted into signals when migrating. Your traits will need to be updated to reflect the new keys that XDM provides. This process is made easier by using the BAAAM tool that Audience Manager has created.

Server Side Forwarding

If you currently have server side forwarding enabled and are using appmeasurement.js. and visitor.js you can keep the server side forwarding feature enabled and this won’t cause any issues. In the backend, Adobe fetches any AAM segments and adds them to the call to Analytics. If the call to Analytics contains those segments, Analytics won’t call Audience Manager to forward any data, so there isn’t any double data collection. There is also no need for Location Hint when using the Web SDK because the same segmentation endpoints are called in the backend.

Retrieving the visitor ID and region ID

If you want to use the unique visitor ID, use the getIdentity command. getIdentity returns the existing ECID for the current visitor. For first-time visitors who don’t have an ECID yet, this command generates a new ECID. getIdentity also returns the region ID for the visitor. See the Adobe Audience Manager User Guide for more information.

alloy("getIdentity")
  .then(function(result) {
    // The command succeeded.
    console.log("ECID:", result.identity.ECID);
    console.log("RegionId:", result.edge.regionId);
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information.
  });

Syncing identities

Additionally, the Identity Service allows you to sync your own identifiers with the ECID using the syncIdentity command.

Syncing identities allows you to identify a device/user using multiple identities, set their authentication state and decide which identifier is considered the primary one. If no identifier has been set as primary, the primary defaults to be the ECID.

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "ambiguous",
          "primary": true
        }
      ]
    }
  }
});

Each property within identityMap represents identities belonging to a particular identity namespace. The property name should be the identity namespace symbol, which you can find listed in the Adobe Experience Platform user interface under “Identities”. The property value should be an array of identities pertaining to that identity namespace.

Each identity object in the identities array is structured as follows:

id

This is the ID that you want to sync for the given namespace.

authenticationState

The authentication state of the ID.

primary

Determines whether this identity should be used as a primary fragment in the unified profile. By default, the ECID is set as the primary identifier for the user.