Adobe Analytics: Google Announcement And Cross-Domain Tracking

Google Chrome to ‘phase out’ third-party cookies within two years is a passive announcement unlike Firefox and Safari blocking the third-party cookies starkly. While Google is designing the work around, the same would have no choice whatsoever on current Adobe Analytics Tracking. Though the decision won’t affect enterprise organizations with a single domain, multi-domains do.

Multi-domain tracking is challenging for the digital legends when the third-party cookie is blocked by the browser. With the support of Experience Cloud ID Service, Adobe handles the multi-domain tracking where third-party cookie is placed in the domain demdex.net. Organizations still using legacy Adobe Visitor IDs (s_vi or fid) should first migrate to the Experience Cloud Visitor ID i.e. Marketing Cloud ID (MID).

Because Experience Cloud Visitor ID Service sets first-party cookies (AMCV) to identify users, no impact on a single domain will be seen. It also uses third-party cookies set in the domain demdex.net to connect multiple domains to a visitor. The architecture below will help you understand how Marketing Cloud ID Service maintains a consistent Marketing Cloud ID across domains in a browser that accepts cookies from third-parties (Thanks to Adobe Blog).

If a browser blocks a third-party cookie, there will be no synchronization of ids between multiple domains resulting in disrupted Adobe Analytics tracking. So, Google will join Safari and Firefox sooner to ‘phase out’ third-party cookies resulting in disrupted Adobe Analytics tracking across domains. Have you ever validated Marketing Cloud ID across domains on the browsers those block cookies from third-parties? If never, I would recommend you to check out.

Then, wonder how Adobe would synchronize the visitor ids across domains on the browsers those block cookies from third-parties? By using the function appendVisitorIDsTo. You must have introduced the Experience ID Service and owned the source & destination domains to use this function. Function appends the MID as a query parameter in the URL redirect from the original domain to the destination domain. The Experience ID Service code on the destination domain extracts the MID from the URL instead of sending a request to Adobe for that visitor’s ID. Thus there is no need for third-party cookie to synchronize the ID whenever internal cross-domain navigation occurs.

Sadly, implementing the function is manual now i.e. If internal cross-domain navigation happens, we need to enforce the function on the pages or through Tag Manager. Even though most of the multi-domain organizations were familiar with this method, they are reluctant for the change because of the implementation efforts. Since the total market share for Firefox and Safari combined was less than 20 per cent, there was a less concern. Nevertheless, the recent announcement from Google will drive multi-domain organizations and developers to reconsider the internal cross-domain tracking strategy.

So, how do we resolve this? What is the intermediate or immediate solutions?

Sorry, I won’t hand over the responsibility to organizations or architects this time rather to Adobe. In Adobe Analytics, we generally define internal domains and configure internal filters for the proper attribution of reports. The same concept should be used in Experience Cloud ID Service; if we list internal domains during Experience Cloud ID Service set-up, it should append the MID by default if internal cross-domain navigation occurs. If so, it will no longer be a head ache for the organizations or developers to deal with cookies from third-parties to an extent. Only to an extent? Why? Because the suggested solution works only if the customer navigates between the internal domains, but if the domain loading is independent, id synchronization will not occur.

I am sure Adobe is already working on the possibilities to tackle this situation, but the suggested solution is not a brainier for them to update with the forthcoming release versions of Experience Cloud Service. In the very least, this would eliminate the dependency on third-party cookies whenever internal cross-domain navigation occurs eliminating the manual implementation process.

We also seek to find a solution using ‘iframe’ whenever the domain loading is independent, which can be addressed in the posts to come.