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.
Changes to the Analytics ID process
An HTTP response from a web server sets cookies in a browser. This is how the
s_vicookie is set. The
s_vicookie 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_vicookie. 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.comand your data collection server is
mysite.omtrdc.net, the cookie that is returned in the HTTP header from
mysite.omtrdc.netmight 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
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.
AMCV_###@AdobeOrgcookie 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.
However, there are a few situations where setting the cookie in the HTTP header is beneficial for cross-domain tracking, which is described in Data Collection CNAMEs and Cross-Domain Tracking .
Custom Analytics IDs
Setting a customer ID using
s.visitorIDis a method of identifying users in Analytics. However, integrations in which Analytics data is exported or imported using the ID Service will not function when a visitor is identified using
This includes, but is not limited to, shared audiences, Analytics for Target (A4T), and Customer Attributes. For these integrations, setting a custom Analytics ID is not supported.
Analytics Visitor ID Order
After you deploy the visitor ID service, there are five ways a visitor can be identified in Analytics (listed in the following table in order of preference):
Query Parameter (collection method)
s.visitorID is set
mid (AMCV_ cookie set by Experience Cloud visitor ID service)
The visitor's browser accepts first-party cookies
A browser doesn't accept third-party cookies and the Analytics tracking server is set up as a third-party tracking server.
fidis a legacy identifier and is not used if you've implemented the ID service on your site. In this case, the
fidis not needed because the first-party, AMCV cookie makes it obsolete. It has been retained to support legacy code and for historic reasons.
The visitor's browser does not accept cookies.
In many scenarios you might see 2 or 3 different IDs on a call, but Analytics will use the first ID present from that list as the official Experience Cloud ID. For example, if you are setting a custom visitor ID (included in the "vid" query parameter), that ID will be used before other IDs that might be present on that same hit.