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.
We implemented the Experience Cloud ID service in Adobe DTM using two web properties. Both web properties use the Experience Cloud Organization ID, tracking server, secure tracking server, and library version.
We did not add anything to the General Settings or Customer Settings fields in the Experience Cloud ID Service Settings section of Adobe DTM.
Adobe Analytics is managed in Adobe DTM for Domain B, but in another tag manager for Domain A.
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.
When Domain A is visited first, an AMCV cookie appears with Domain A as the domain.
When Domain B is visited after Domain A, two AMCV cookies appear: one on Domain A and one on Domain B. Both have the same Name. These cookies have different MIDs.
When examining Domain B's cookies, the cookie set on Domain A has the MID value we would expect to see (i.e. the same as when we visited Domain A), but the MID that appears in the Adobe debugger for Domain B is the value from the AMCV cookie set on Domain B.
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.
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.
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.