Sunday, May 6, 2018

Migrate legacy Adobe Visitor ID to Experience Cloud Visitor ID

The Adobe Experience Cloud ID Service (formerly known as the Marketing Cloud ID Service) has been around for more than three years now but there are some Adobe Analytics customers who are still on the legacy visitor tracking system. This post covers the various steps involved in migrating from a legacy Analytics tracking solution to the new Experience Cloud Visitor ID Service.

The Experience Cloud Visitor ID Service leverages a common and universal cookie identifier across all Adobe solutions that enables us to seamlessly integrate Adobe solutions with each other.


The Visitor ID service provides the following benefits:
  • As explained above, the ID service provides us with the benefit of seamlessly integrating all Adobe solutions which isn't easy to do with the legacy visitor tracking solution.
  • Visitor ID service enables the Adobe Experience Cloud Device Co-op which is a feature that allows subscribed customers to identify customers across devices and mobile apps. Device co-op also provides customers with the “People” metric that shows a deduplicated count of your users across multiple devices.
  • It enables Customer Attributes that allows customers to upload offline CRM data and tie it to online behavioral data.
  • Customers can leverage the latest video Heartbeat tracking that provides a lot of functionality to track media events across multiple video player formats.
  • It sets a first party cookie (AMCV) that is less susceptible to deletion. The legacy visitor tracking method (by default) sets a third party cookie that is more likely to be deleted by browsers, firewalls and ad blockers. This benefit may not apply to customers who leverage a CNAME as the tracking server where they set the cookie on their own domain.
  • It removes the need to get tracking servers migrated to a CNAME (E.g. metrics.companyname.com) which would otherwise require additional support from the network operations team. This benefit only applies to customers who are already on RDC (covered below).

Before we proceed, let's first take a look at the various cookies involved in this process. 
The following table shows which cookies & IDs come into play during the Visitor ID migration. Please click it to enlarge if you're unable to see it clearly.



Now that we've looked at the various cookies involved, let's go through the steps we need to follow to migrate to the new Visitor ID service.


Migrate Tracking Server to RDC

Visitor ID Service requires the tracking server to be migrated to RDC (Regional Data Collection) which is a network of data collection servers that are faster, safer and more reliable compared to the older data collection servers. RDC connects to the closest data center thereby reducing response times of image requests and incorporates load balancing to switch servers in case of a failure. 

The RDC domain is on "omtrdc.net" as opposed to the legacy "2o7.net" domain so it's always a good idea to check if you're already on RDC (omtrdc.net) or 2o7.net. The steps outlined in this Adobe article shows you how to check if your tracking server is on RDC or not.


If you're on the legacy 2o7.net domain then you will have to switch your tracking server entirely or if there are other domain change scenarios involved in your case, then follow the steps outline in this Adobe article to proceed.


If you're already on CNAME pointing to 207.net legacy servers and don't plan to change your tracking server, then you will follow the following steps:

  • Contact Adobe client care to request a migration to RDC by providing them with your existing CNAME based 2o7.net secure and non-secure tracking server names.
  • Customer services provides you with the new RDC tracking server hostnames which will end with omtrdc.net.
  • Contact your network operations team to redirect your CNAME tracking servers to now point to the new RDC (omtrdc.net) domain.
  • Finally, test your tracking servers by pinging them and validating if they're redirecting to the omtrdc.net domain as described in this article.

Setup Grace Period

A grace period typically setup for 30/60/90 days is put in place when customers want to continue leveraging the legacy analytics s_vi cookie in place of the new AMCV cookie set by the Visitor ID service. This is most commonly put in place if certain areas of the website have an older code version that cannot upgrade to the Visitor ID service and the implementation is leveraging a global report suite. The reason why it's necessary to put a grace period in place so that we don't see visitor "cliffing" or inflation in visitor & visit counts. That's because the Visitor ID service leverages a new cookie to track visitors and will probably count a repeat visitor as a new visitor. A grace period can also be setup for a company that wants to avoid visitor "cliffing" as they prepare to factor in the eventual visitor & visit inflation. 

To request a grace period, contact the Adobe client care team and provide them with the following information:
  • Experience Cloud or IMS Org ID
  • Company Name
  • Data Center
  • Date to start Grace Period
  • Grace Period Length (Up to 180 days but can be extended)

Setup Visitor ID Service

Once a grace period has been put in place by client care, work with your IT team to setup the Visitor ID service. Here's an example from the Launch by Adobe Tag Management tool to show the Visitor ID service extension. Notice that the we have to put in the Experience Cloud Org ID and populate the secure and regular tracking server fields (highlighted in Red) to setup the Visitor ID service which is required to get grace period to work and for the 'aid' parameter to appear.


Once the ID service is setup, you will start to see the new first party AMCV cookie and third party demdex cookie appear in your browser instead of the legacy s_vi cookie. However during a grace period, the s_vi continues to be set and is populated in the AMCV cookie to avoid visitor & visit inflation. Below is a visual that explains how cookies are set during a grace period.

Source: Adobe Blog

Validate

The next step is to validate the grace period. This is done by checking if the "AID" and "MID" parameters appear in the Analytics image request. The "AID" will contain the Visitor ID value from the s_vi cookie and will continue to be set till the grace period is active. This screenshot shows what the image request during a grace period looks like.



Prepare for the Inevitable

Finally, the most important step is for you to internally prepare your organization for this change as it's a revamped methodology to track visitors and at some point, you will have to confront the reality of visitor inflation when the grace period is turned off. Please note that this visitor "cliffing" will ONLY impact repeat visitors as new visitors will automatically get the new AMCV cookie. 

It might be a good idea to estimate how much impact this change will have on your visitors & visits based on your repeat visitors. If you're on the grace period for 180 days and turn it off after that, what % of your repeat visitors come back to your site or app after 6 months. This number will vary based on the kind of business you're in so all in all, you need to weigh the pros and cons and determine when you want to take the plunge.


So, that was it! If you're already on the Visitor ID service and don't have to deal with any of these outlined steps, then Congratulations. If not, then I'd highly encourage you to give a serious thought to proceeding with it as it will be worth it if you're an Adobe Experience Cloud customer.  

No comments: