Visitor ID Service migration considerations for Adobe Analytics
If your organization plans to move to the Visitor ID Service with an existing Analytics implementation, there are some important topics to consider. These considerations allow you to retain visitor identification integrity and understand how the Visitor ID Service operates in the presence of an existing Analytics implementation.
aid) and are moving towards using an ECID (mid). All Web SDK implementations use the Experience Platform Identity Service, which uses an ECID (mid) by default.How the Visitor ID Service interfaces with legacy Analytics visitor cookies
Because AppMeasurement has its own legacy method to identify visitors, some visitors might have existing Analytics cookies when an organization deploys the Visitor ID Service. The following list outlines how a visitor is identified under varying circumstances.
- No visitor cookies present: The Visitor ID Service assigns an ECID (
mid). - An
s_vicookie exists: The Visitor ID Service writes the existing legacy Analytics ID (aid) to theAMCVcookie in addition to an ECID (mid). Sinceaidis higher in the Order of operations, the legacy Analytics ID is the visitor identifier until theAMCVcookie expires or is cleared. When a grace period is enabled, the Visitor ID Service includes both themidandaidin its response. - A fallback cookie exists: The Visitor ID Service does not write the fallback cookie (
fid) to theAMCVcookie. Instead, visitors receive an ECID (mid) as if they were a new visitor.
Visitor ID Service grace period
If you have multiple implementations sending data to the same report suite and you can implement the Visitor ID Service on only some implementations, Adobe recommends configuring a grace period. For example, if the support section of your site is managed by a separate tagging solution, you might have the Visitor ID Service deployed on the rest of your site before the support section. Without a grace period, new visitors who view the support section receive a legacy Analytics visitor ID, causing two separate visitors to be counted. With a grace period, the Visitor ID Service issues both an ECID (mid) and a legacy Analytics visitor ID (aid) so that areas of your site without the Visitor ID Service remain consistent identifying visitors.
If you coordinate the deployment of the Visitor ID Service across all areas of your site, you do not need a grace period. To configure a grace period, contact Adobe Customer Care. Grace periods can be configured for up to 180 days, and can be renewed. Adobe recommends discontinuing the grace period once your entire property is configured to use the Visitor ID Service.
Cross-domain tracking
Some legacy Analytics visitor ID implementations might use “friendly third-party cookies”, where two domains share the same visitor cookie on a common domain like data.example.com. Since friendly third-party cookies are still third-party cookies, many modern browsers reject them, causing Analytics to rely on a fallback ID (fid) for visitor identification. Moving to the Visitor ID Service allows all domains to set the AMCV cookie in a first-party context, increasing their viability to retain a visitor ID.
While the Visitor ID Service attempts to set a third-party cookie for cross-domain tracking (the demdex cookie), it is often rejected by modern browsers. Consider using the appendVisitorIDsTo method to pass a visitor’s ECID (mid) between domains that you own.
Server-side tracking
You can call getMarketingCloudVisitorID to obtain the ECID (mid) and getAnalyticsVisitorID to obtain the legacy Analytics ID (aid). Adobe recommends checking for both to preserve visitor identification logic.