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.

Diagram of a typical web environment

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

 

Diagram showing two visitor scenarios

Note:

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.

    Checking for cookies
  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.

    Network request is made

    Note:

    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. 

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

    Response with uuid and 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.

    Checking to see if a legacy Analytics ID exists

    Note:

    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.

    Browser does contain legacy 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.

    ID service sets an AMCV cookie

    Note:

    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.

    Page loads and Adobe solutions 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.

    Scenario 2 -- same browser visits
  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.

    Check to see if AMCV cookie exists
  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.

    ID service requests an ID
  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.

    Server receives the request and generate a 'mid' value
  14. The browser sends the 'mid' value back to the page in the request response.

    Browser sends 'mid' value back to page
  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).

    ID service code -- final check if cookie exists
  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).

    Call is made to metrics.siteA.com
  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

    Writing an AMCV cookie on the current domain
  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.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy