Caution: Same as part 01 and part 02, 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 third part in a 3 part series, Why CNAME?! I strongly recommend everyone who does not read Part 01 (here) and Part 02 (here) to navigate and go through the basic concepts before getting on with this discussion. If already done, why wait? Let’s jump right into the topic.
What is CNAME in Adobe Analytics?
In simple terms, CNAME is a way of spoofing adobe’s Data Collection Server (DCS) with our own domain server. Rather than sending the requests/information to adobe domain servers (adobedc.net, 2o7.net, or omtrdc.net), we will be sending the requests/information to our own domain server, which will in turn route the same to adobe domain servers. We could also presume that adobe domain servers will be hidden behind our servers so that it will appear to be the same domain server for the browsers.
To implement CNAME for terrynwinter.com, I need to create a subdomain resembling my domain (stats.terrynwinter.com or metrics.terrynwinter.com) and assign it to adobe for data collection routing. Information to configure and implement CNAME is already available in adobe’s documentation. If you are still unsure, you can contact Adobe Customer Care with your IT team and they’ll be happy to help you out!
Pretending I have configured CNAME with tracking domain stats.terrynwinter.com, let’s see whether it can help us get beyond the limitations of third-party cookies and cross-origin requests.
Tracking without Experience Cloud ID Service
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 for visitor identification or send tracking information to the domain server, however, the domain server is now stats.terrynwinter.com instead of the usual Data Collection Server (adobedc.net, 2o7.net, or omtrdc.net). Since now the request is sent to my domain (Parent domain is terrynwinter.com), the request is considered as Same-Origin Request i.e. terrynwinter.com sends the request to terrynwinter server (spoofed) and set the cookies on the tracking domain terrynwinter.com those are referred as First-Party Cookies i.e. The website you are currently visiting is terrynwinter.com and the cookies are also placed on the same domain terrynwinter.com. Hurray! CNAME implementation helped us to overcome the limitations of third-party cookies and cross-origin requests by setting everything in the first-party context.
However, will it enable cross-domain tracking for adobe? In the case of distinct domains, the answer is apparently no! Pretend I have one more domain tehyver.com and you are visiting the website after visiting terrynwinter.com. Upon page load, adobe can access the cookies set on the tracking domain terrynwinter.com previously (Because the tracking server is stats.terrynwinter.com), and thus you are identified. Here first-party cookies are used in a third-party context and adobe terms this as customers visiting ‘main entry site before they navigate to other domains’ in their CNAME documentation.
If tehyver.com is visited first, as the tracking server is stats.terrynwinter.com, the request/information to the server is considered as Cross-Origin Request i.e. tehyver.com sends the request to terrynwinter domain server and set the cookies on the tracking domain terrynwinter.com those are referred as Third-Party Cookies i.e. The website you are currently visiting is tehyver.com but the cookies are placed on the different domain terrynwinter.com. Thus the limitation continues if the cross-origin requests and the third-party cookies are blocked especially when there is no main entry site.
Adobe recommends everyone to use domain-specific CNAMEs (Multiple CNAMEs based on the domain) if we have multiple domains which in result can overcome the limitations of cross-origin requests and third-party cookies by setting everything in the first-party context, but never the cross-domain tracking. This is because the cookies set on individual domains are considered first-party and cannot be accessed by the different domains i.e. Cookies set on terrynwinter.com can never be accessed by stats.tehyver.com tracking server and vice versa. In short, cross-domain tracking is still difficult without third-party cookies.
Tracking with Experience Cloud ID Service
We already know that Experience Cloud ID Service would set the cookies only on the organization’s domain (First-Party Cookie). Since we have configured the tracking domain as stats.terrynwinter.com, adobe will no longer send requests to default Data Collection Servers (adobedc.net, 2o7.net, or omtrdc.net) eliminating the limitations of cross-origin requests. Adobe still sets a cookie on dpm.demdex.net for cross-domain tracking and if the cookie is blocked, cross-domain tracking is not possible. There are ways to switch the domain dpm.demdex.net to our own domain, but then again the cross-domain tracking will not be resolved. Using a reverse proxy, Frederik Werner came up with a way to implement Adobe Analytics in the first-party context even without CNAME configuration (Link here). As we know, it is impossible to enable cross-domain tracking by just setting everything in first-party context.
Note that we can also exchange visitor IDs between distinct domains using the function ‘appendVisitorIDsTo’ when the browsers block third-party cookies, but the visitor should navigate between the distinct domains and not access them independently. When visitor browses to other distinct domains, the function appends the visitor ID as a query parameter in the URL redirect from the visiting domain to destination domain. Experience Cloud ID Service code on the destination domain now extracts the visitor ID from the URL instead of sending a request to adobe to continue the visitor journey.
The forthright answer
In order to make it easier for everyone to comprehend the findings of the discussions, I have compiled them into a simple table along with pointers.
- Implementing CNAME on Adobe Analytics tracking without Experience Cloud ID Service will overcome the limitations of cross-origin requests and third-party cookies.
- Implementing CNAME on Adobe Analytics tracking with Experience Cloud ID Service can only overcome the limitations of cross-origin requests, as the cookies set by Experience Cloud ID are already first-party cookies.
- Implementing CNAME for both methodologies will not allow cross-domain tracking for distinct domains (Possible only between parent domain and sub-domains or when there is a main entry site/domain as stated earlier).
So, plan well and implement! Lastly, don’t ever believe that first-party context will solve everything. In November 2020, Apple updated its policies so that the limitations were also applied to the cookies set via CNAME or Experience Cloud ID Service i.e. First Party Cookies. First-Party Cookies set on Safari using server-side or client-side via Javascript are limited to a seven-day (ITP 2.1) or 24-hour (2.2) expiry under ITP. Therefore, if we return to a website after a day, or after seven days, based on ITPs, we are classified as new! Happy understanding and exploring!
