How the Adobe Visitor ID Service requests and sets IDs how-the-experience-cloud-id-service-requests-and-sets-ids

An overview of the ID request and response process. These examples cover ID assignment on individual sites, across different sites, and for sites managed by different CX Enterprise customers with their own IMS org IDs.

Requesting an ECID section-0b5e261fbd0547d9b9a1680e5ce536cc

The following examples demonstrate how the Visitor ID Service requests and receives the ECID. These examples use two fictitious companies, the Food Company and the Sports Company, to demonstrate data flows for ID requests and responses. Each company has a unique IMS org ID and has implemented the Visitor ID Service code on all of their sites. These use cases represent data flows for a generic Visitor ID Service implementation without Analytics, legacy IDs, or browsers that block third-party cookies.

First request

In this example, a new visitor comes to the pizza site managed by the Food Company. The Food Company has Visitor ID Service code on the pizza website. When the pizza site loads, the Visitor ID Service code checks for the AMCV cookie in the pizza domain.

First response

In the response, the DCS returns the ECID and the demdex cookie. The Visitor ID Service code writes the MID value to the AMCV cookie. For example, say the DCS returns a MID value of 1234. It would be stored the AMCV cookie as mid|1234 and set in the first-party, pizza domain. The demdex cookie also contains a unique ID (let’s call it 5678). This cookie is set in the third-party, demdex.net domain, which is separate from the pizza domain.

As you’ll see in the next example, the demdex ID and IMS org ID allows the Visitor ID Service to create and return the correct MID when our visitor moves to another site belonging to the Food Company.

Cross-site request and response section-15ea880453af467abd2874b8b4ed6ee9

In this example, our Food Company visitor navigates to the tacos site from the pizza site. The Food Company has Visitor ID Service code on the tacos website. The visitor has never been to the tacos website.

Given these conditions, there is no AMCV cookie on the tacos site. And, the Visitor ID Service can’t use the AMCV cookie set on the pizza site because that it is specific to the pizza domain. As a result, the Visitor ID Service must call the DCS to check for and request a visitor ID. In this case, the DCS call includes the Food Company’s IMS org ID and the demdex ID. And remember, the demdex ID is picked up from the pizza site and stored as a third-party cookie under the demdex.net domain.

After the DCS receives the IMS org ID and the demdex ID, it creates and returns the correct MID for our site visitor. Because the MID is derived mathematically from the IMS org ID and the demdex ID, the AMCV cookie contains the MID value, mid = 1234.

ID requests from other sites section-ba9a929e50d64b0aba080630fd83b6f1

In this example, our visitor leaves the Food Company sites and navigates to the soccer site owned by the Sports Company. When the visitor comes to the soccer site, the ID checking and request process works the same way as described in the previous examples. However, because the Sports Company has its own IMS org ID, the Visitor ID Service returns a different MID. The new MID is unique to the domains controlled by the Sports Company and lets that enterprise track and share visitor data across solutions in CX Enterprise. The demdex ID remains the same for this visitor because it’s contained in a third-party cookie and persists across different domains.