Issues with cross-domain tracking when third-party cookies disabled

[brentrad]

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.

Background

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.

Findings

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.

Questions

• Did we misinterpret how using the CNAME would allow cross-domain tracking according to Data Collection CNAMEs and Cross-Domain Tracking ?
• Should we add configurations to the General Settings and Customer Settings fields in the Experience Cloud ID Service Settings section of Adobe DTM (Experience Cloud ID Service Settings for DTM )? 
• Are we missing other key settings that would allow cross-domain tracking to work properly?
• Should we remove the getInstance() function from the AppMeasurement library used for Domain A, which is not managed in Adobe DTM? This was mentioned on Experience Cloud ID Service.
• Could a timing delay in when Adobe scripts run on Domain B cause an issue? We seen that the Experience Cloud ID service fires much faster on Domain A.

[Kunal_Gaba_]

You might be seeing this behavior because of ITP feature from Apple. Check this link  - Intelligent Tracking Prevention (ITP) and Adobe Analytics

[brentrad]

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.

[Alexis_Cazes_ · Accepted solution]

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.

[brentrad]

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.

[Alexis_Cazes_]

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

[acookie4rachel]

Hi @Alexis_Cazes_ , could you share what are the possible solutions to pass MID if demdex is blocked?