Setting Analytics and Experience Cloud IDs

The Experience Cloud Identity Service replaces the legacy Analytics visitor ID methods.

After the ID service is implemented, this code executes before AppMeasurement. The ID service retrieves the Experience Cloud and Analytics IDs so these values are ready when AppMeasurement loads.

When AppMeasurement loads, the Experience Cloud and Analytics IDs values are requested from the ID service and are sent to data collection with each server call. Since the ID service determines the visitor ID and simply passes it to AppMeasurement, the ID service must be included and implemented on each page before your AppMeasurement JavaScript file.

Changes to the Analytics ID process

The primary change when migrating to the Experience Cloud ID service is that the ID cookie is set using JavaScript, instead of in the HTTP header that is returned from the data collection web server. To understand this change, the following sections describe how cookies are set using these two methods.

HTTP Header

An HTTP response from a web server sets cookies in a browser. This is how the s_vi cookie is set. The s_vi cookie identifies Analytics visitors. After a cookie is set, it is sent with all subsequent HTTP requests to that server.

When a request is sent to the Adobe data collection server, the header is checked for the s_vi cookie. If this cookie is in the request, it is used to identify the visitor. If the cookie is not in the request, the server generates a unique Experience Cloud ID, sets it as a cookie in the HTTP response header, and sends it back with the request. The cookie is stored in the browser and is sent back to the data collection server during subsequent visits the site. This enables the visitor to be identified across visits.

However, some browsers, such as Apple Safari, do not accept third-party cookies. These are cookies set in the browser from domains other than the current website. Additionally, Safari blocks cookies on third-party domains if a visitor has not been to that domain before. For example, if you are on mysite.com and your data collection server is mysite.omtrdc.net, the cookie that is returned in the HTTP header from mysite.omtrdc.net might be rejected by the browser.

To avoid this, many customers have implemented CNAME records for their data collection servers. This can be an effective part of a first-party cookie implementation strategy. If a CNAME record is configured to map a hostname on the customer’s domain to the data collection server (e.g., mapping metrics.mysite.com to mysite.omtrdc.net), the Experience Cloud ID cookie is stored because the data collection domain now matches the domain of the website. This increases the likelihood that the ID service cookie will be stored. However, this does introduce some overhead because you need to configure CNAME records and maintain SSL certificates for the data collection servers.

JavaScript

JavaScript can read and write cookies set in the first-party domain (the domain of the current website). The Experience Cloud ID service uses this method to set the AMCV_###@AdobeOrg cookie that contains all of the visitor IDs, so the domain of the tracking server no longer needs to match the domain of the website in order for the visitor ID cookie to be stored. In most circumstances this is the preferred way to set the ID service cookie because it eliminates the overhead of CNAME records and SSL certificates.