MCID Analytics visitor migration

This page illustrates how the Marketing Cloud ID Service migrates a visitor from the legacy Analytics ID to the Marketing Cloud ID. Some concepts have been simplified for general understanding.

Video: How MCID migrates legacy Analytics visitors

Environment

A typical web environment is shown below. On the left is a visitor's browser. In the center is a collection of websites owned by My Company Inc., both of which have successfully deployed the ID service. On the right and lower left, you see cylinders representing Adobe’s servers.

You can see that the user's browser has a s_vi cookie. The cookie looks to be set on the SiteA.com domain. If you're familiar with Analytics tracking, you know that this cookie contains the 'aid' value. Since this cookie is present, this user has been to at least one of the web properties owned by My Company Inc. previously.

Scenarios

Below, two different scenarios are discussed.

In the first, a user returns to SiteA.com for the first time since My Company Inc. has deployed the ID service. This scenario shows how the ID service migrates their existing ID from the legacy s_vi cookie to the AMCV cookie. The first scenario is shown in blue in the diagram.

In the second, the same user visits a second domain owned by My Company Inc. This domain also has the ID service deployed. This is the first time this user has ever been to this site. This site is utilizing the same Analytics tracking server as the first domain. This scenario shows the ID service retrieve the legacy ID from the tracking server while also maintaining the same ID service ID. The second scenario is shown in red in the diagram

 

Bemærk:

Multiple domains using the same Analytics tracking server is typically how cross-domain tracking was accomplished before the ID service.

Steps

  1. The user visits SiteA.com for the first time since My Company Inc. has deployed the Marketing Cloud ID service.

     

  2. The ID service code (VisitorAPI.js) loads as part of the page and a check is made to see if an 'AMCV' cookie exists on the current domain (SiteA.com). No such cookie  exists , so the ID service checks to see if a Demdex cookie exists on the demdex.net domain. There is also no demdex.net cookie.

  3. Since a Marketing Cloud ID doesn't currently exist within the browser, the ID service code requests an ID from the ID service servers (dpm.demdex.net). A network request is made to dpm.demdex.net with the Experience Cloud Organization ID.

    Bemærk:

    The Experience Cloud Organization ID is pulled from the page as part of your implementation and uniquely identifies each client company in the Adobe Experience Cloud. Each ID is similar to the following value: 016D5C175213CCA80A490D05@AdobeOrg

  4. The ID service server receives the request. Since the request does not contain a ' uuid ' value, the server generates one to be used in generating the Marketing Cloud ID or 'mid' value. Once the ' uuid ' value is generated, the server generates a 'mid' using the ' uuid ' and the Experience Cloud Organization ID. 

  5. The ID service responds to the request with both the ' uuid ' and the 'mid'.

  6. The ID service finally checks to see if a legacy Analytics ID exists. It does this by checking to see if a 's_vi' cookie exists on the Analytics tracking server domain. In this example, metrics.siteA.com is used as the Analytics tracking server.

    Bemærk:

    This check is necessary because Analytics uses the 'mid' value as its primary ID for visitors that don't already have a legacy Analytics ID or 'aid'. If the migration of an existing ID weren't completed, the user would become a new visitor and all historical data associated with the legacy 'aid' would not be associated with the new visitor.

     

  7. In this example, the browser does contain a legacy s_vi cookie on the tracking server domain, which means that the ID service can read this cookie and retrieve the 'aid' value from the cookie.

  8. Now that the ID service code has what it needs, it sets an AMCV cookie on the current domain (SiteA.com). Since there isn't already a demdex.net cookie, the ID service also sets a demdex.net cookie containing the UUID.

    Bemærk:

    The ID service writes its cookie on the current domain. This is different from the legacy Analytics identification where the cookie was written on the tracking server domain.

    Also, the Analytics tracking server domain does not always match the domain of the web page.

  9. After the AMCV cookie is written to the browser, the rest of the page loads and the Adobe solution beacons fire.

  10. In scenario 2, the same user with the same browser visits another web property owned by My Company Inc. where the ID service has been deployed.

  11. The ID Service code loads and as in step 2, a check is made to see if an AMCV cookie exists on the current domain (siteB.com). Since this is the first time this user has been to this site, no AMCV exists. Since no AMCV cookie exists, the next check is for a demdex.net cookie. A Demdex cookie does exist this time because it was set in step 8 of the previous scenario. The ID service reads the Demdex cookie and returns the ' uuid ' value.

  12. As in the first scenario (step 3), the ID service code requests an ID from the ID Service servers. However, this time, there is already a 'UUID' value from the Demdex cookie. The 'UUID' and Experience Cloud Org ID are sent with the request.

  13. The server receives the request and generates a ‘mid’ value using the ' uuid ' (ABC) & Org ID (1234), which were sent with the request. Notice that the ‘mid’ value is generated using the same Org ID and 'UUID' as the previous example. Since the same two parameters are used to generate the ID, the result is the same. This is how cross-domain tracking is achieved on the ID Service.

  14. The browser sends the 'mid' value back to the page in the request response.

  15. The ID service code does one final check to see if a s_vi cookie exists on the Analytics tracking server (similar to the first scenario to ensure that it doesn’t cliff any existing visitor data).

  16. Since the tracking server domain doesn’t match the domain the browser is currently visiting (siteb.com), a call is made to metrics.siteA.com so the tracking server can respond to the request. The tracking server responds to the request with the AID value, assuming it exists (it does in this case as you can see at the top of the figurative browser).

  17. Now that the ID service code has all the information it needs, it writes an AMCV cookie on the current domain. This time, the cookie is written on siteB.com. The AMCV cookie contains both the ’mid’ and the ‘aid’. Having both allows us to continue using all the data associated with the legacy ID while also giving us most of the benefits that come with having a cross-solution ID via the MID

  18. Finally, the rest of the page code executes and the Adobe solution beacons are fired

Questions?

This article gives a deeper look into how the Marketing Cloud ID service (MCID) operates. Some concepts have been simplified for general understanding. If you have additional questions, see the Marketing Cloud ID Service documentation. You can also ask a question on the community forums.