Caution: Same as part 01, people who are technically sound should excuse me (Sorry people), because I am going to explain the principles in layman terms to ensure that everyone understands what, why, and when CNAME is needed for an organization with respect to Adobe Analytics.
This is the second part in a 3 part series, Why CNAME?! I strongly recommend everyone who does not read Part 01 (here) to navigate and go through the concepts of third-party cookies and cross-origin requests before getting on with this discussion. This part explores the fundamentals of how Adobe Analytics identifies its users for the organizations with and without Experience Cloud ID Service and how would it overlaps the concepts of third-party cookies and cross-origin requests.
Tracking without Experience Cloud ID Service
Pretend I have implemented Adobe Analytics on my website terrynwinter.com, upon page load, the browser sends the request to my domain server (terrynwinter) so that it can process the request and return an HTML page. In consequence, adobe will also make the request to its own servers (adobedc.net, 2o7.net, or omtrdc.net) for visitor identification. In response to the request, adobe will provide you with the visitor ID, which is then stored in a cookie (‘s_vi’) of the same tracking domain (adobedc.net, 2o7.net, or omtrdc.net) so that adobe can identify you again on your next visit. Even if we consider that the visitor ID is generated randomly at the page level using JavaScript code, adobe should transmit the tracking information to its own servers (adobedc.net, 2o7.net, or omtrdc.net) and place the randomly generated code on the cookie (‘s vi’) of the same domain (adobedc.net, 2o7.net, or omtrdc.net) to identify the visitors on returning.
Here, you have loaded my website terrynwinter.com in your browser, the browser made the request to adobe domain server to fetch the required information or send the tracking information for my page which is treated as Cross-Origin Request i.e. terrynwinter.com sends the request to adobe domain servers (adobedc.net, 2o7.net, or omtrdc.net) and set the cookies on its own domains (adobedc.net, 2o7.net, or omtrdc.net) those are referred as Third-Party Cookies i.e. The website you are currently visiting is terrynwinter.com but the cookies are placed on the different domains (adobedc.net, 2o7.net, or omtrdc.net).
Because of what we have mentioned in the previous post, if the browser decides to block the third-party cookies from adobe, you are considered a new visitor every time you visit my website i.e. No cookies on the browsers to recognize you again. And, if the browser or browser extensions prevent cross-origin requests (here, cross-origin request is for tracking), there will be no tracking for the visitor. Both aren’t good!
However, to support the legacy code and for historic reasons, adobe will place a fallback cookie (‘fid’) on H.25.3 or newer, or AppMeasurement for JavaScript if the default cookie (‘s_vi’) is blocked and the analytics tracking server is set up as a third-party tracking server (adobedc.net, 2o7.net, or omtrdc.net). The fallback id will be placed on the organization’s domain (here, terrynwinter.com) and thus considered as First-Party Cookies. Still, the point on cross-origin requests remains unresolved, as well as the visitor identification across domains. Since because the visitor ID cookie placed on my own domain cannot be retrieved by adobe domain servers (adobedc.net, 2o7.net, or omtrdc.net), cross-domain tracking is not possible. To know more about the order of operations for analytics IDs, you can go through this link later.
Also, it is the same when you’re loading the tags through Tag Manager. Tags rendering will be prevented if your browser or browser extensions block the cross-origin requests from adobe’s host server (assets.adobedtm.com) or any other external servers.
Tracking with Experience Cloud ID Service
It is important to note that while using Experience Cloud ID Service, cookies are always placed on the organization’s domain and not on its own domain (adobedc.net, 2o7.net, or omtrdc.net). Upon page load, the browser initiates the request to adobe’s Data Collection Server (DCS) at dpm.demdex.net. In response to the request, adobe will provide you with the visitor ID, however, the cookie (‘AMCV’) carrying the ID is now placed on my domain terrynwinter.com rather than its own domain (adobedc.net, 2o7.net, or omtrdc.net). In addition to the cookie on my domain, adobe will also place an additional cookie (‘dpm’) on the domain dpm.demdex.net, but this is used for cross-domain tracking to regenerate the same visitor ID across domains, not as a standalone visitor ID.
Here, you have loaded my website terrynwinter.com in your browser, the browser made the request to adobe domain servers (adobedc.net, 2o7.net, or omtrdc.net along with dpm.demdex.net) to fetch the required information or send the tracking information for my page which is treated as Cross-Origin Request i.e. terrynwinter.com sends the request to adobe domain servers (adobedc.net, 2o7.net, or omtrdc.net along with dpm.demdex.net) and set the cookies on my domain terrynwinter.com those are referred as First-Party Cookies i.e. The website you are currently visiting is terrynwinter.com and cookies are also placed on the same domain terrynwinter.com.
This time, there are no difficulties with visitor identification, as the cookie used to identify the visitor is placed on my own domain (i.e. First-Party Cookies). However, the point on cross-origin requests again remains unresolved, as well as the visitor identification across domains. Since because the visitor ID cookie placed on my own domain cannot be retrieved by dpm.demdex.net domain server (different domain), the additional cookie placed on dpm.demdex.net will be used to regenerate the same visitor ID even if the visitor domains are different. In order to better understand how the Experience Cloud Identity Service requests and sets IDs, you can visit this link at a later point. But if the cookies on dpm.demdex.net are blocked (Considered as third-party cookies i.e. The website you are currently visiting is terrynwinter.com but the cookies are placed on a different domain dpm.demdex.net), regeneration of the same visitor ID is not possible and therefore no cross-domain tracking is enabled.
Also, when I mention cross-domain tracking, I’m referring to distinct domains, not parent domains with subdomains. If there is a parent domain and several sub-domains, Experience Cloud ID Service can set the cookie directly in the main domain with few configuration tweaks. Assume I have a parent domain, terrynwinter.com, and two sub-domains, blog.terrynwinter.com & training.terrynwinter.com. Experience Cloud ID Service can place the ‘AMCV’ cookie directly on the main domain terrynwinter.com regardless of domains visited (terrynwinter.com, blog.terrynwinter.com, or training.terrynwinter.com) so that the cookies can be accessible by all domains for visitor identification.
Finally, it is now time to explore how CNAME can address these problems, not in this post, but in the next one. As said earlier, quickly go through how the Experience Cloud Identity Service requests and sets IDs before continuing the next one, and if you have already covered it, click here to start reading the next post on Why CNAME? Part 03 (The forthright answer).
