We recently migrated to the Experience Cloud ID service. One of the drivers behind this was to enable cross-domain tracking, and after reading Data Collection CNAMEs and Cross-Domain Tracking we opted to enable CNAME support.
We own two domains, Domain A (our flagship domain) and Domain B, and are using two Adobe DTM web properties to manage the Experience Cloud ID Service. We want to know how many visitors reach Domain B after seeing Domain A independently, i.e. not through a link on Domain A. For this reason we did not focus on setting up the appendVisitorIDsTo function, since there are limited opportunities to navigate between Domain A and Domain B via a direct link.
When third-party cookies are enabled we see the same Experience Cloud ID (MID) in Domain A and Domain B, which is the expected outcome. When third-party cookies are disabled we see different MIDs. This is an unexpected outcome based on what we read in Adobe's CNAME documentation.
We looked at Chrome DevTools to see how the AMCV cookies were being set, paying specific attention to what happened when third-party cookies were disabled.
Right I guess you already read this: How the Experience Cloud ID Service Requests and Sets IDs . but have a read once again.
To be able to do cross-domain tracking using the same MID, third party needs to be supported. The visitor ID services generates the MID based on the Adobe Org ID that you in your implementation and the ID from the demdex cookie set as third party cookie. As long as both Adobe Org ID and ID from demdex cookie are identical, Adobe Visitor ID services will always set the same MID.
If third party cookie is not enabled then Visitor ID services will not be able to generate the same Visitor ID as demdex cookie will be missing.
The AMCV cookie is always set as first party cookie, this means that you will have the same cookie name on each root domain and same MID value stored in it as long as you have same Adobe ORG id and same demdex cookie.
The CNAME only helps to serve the AMCV_ cookie not the demdex one.
Demdex one will always be as third party cookie, that is why you need to use solutions provided ot pass MID via URLto next page if demdex is blocked
We were relying on what Adobe outlined on Data Collection CNAMEs and Cross-Domain Tracking, specifically that the CNAME approach "allows you to track visitors between a main landing domain and other domains in browsers that do not accept third-party cookies." It seems that this doesn't work with the Experience Cloud ID service as indicated when third-party cookies are disabled, since this results in the demdex cookie being blocked.
We have considered whether ITP could be having an impact, but have been hesitant on identifying this as the sole reason because Adobe has somewhat conflicting documentation (Data Collection CNAMEs and Cross-Domain Tracking and Intelligent Tracking Prevention (ITP) and Adobe Analytics).
It is important to note that we were testing cross-domain tracking in Chrome rather than Safari. It would make sense if Safari were the only browser where we experienced this issue, since that's what ITP directly impacts.