Third-Party Cookies: Why CNAME in Adobe Analytics?

Do you frequently stumble upon the term ‘CNAME’ when browsing the Adobe Analytics Forum? Especially in discussions around third-party cookies or cross-domain tracking. You might be under the impression that a CNAME implementation for Adobe Analytics will magically bypass all the issues associated with third-party cookies and enable cross-domain tracking. But is that always true?

The short answer: perhaps not always. Let’s dive deep to understand what CNAME truly means, why you should consider implementing it, and when it’s best to do so.

Third-Party Cookies and Cross-Origin Requests: A Brief Overview

Third-Party Cookies: These are cookies stored in your browser by domains other than the one you’re visiting.

Cross-Origin Requests: These are requests made from your browser to domain servers other than the one you’re visiting.

Breaking It Down: A Practical Example

Imagine you’re browsing a website – let’s call it “nextrow.com”. You click on a blog post link from Twitter, and your browser begins to fetch the page content. During this process, the server for “nextrow.com” delivers the webpage content and determines whether to set cookies in your browser. For instance, a cookie named ‘visitor id’ might be placed with a unique identifier for visitor tracking.

In this scenario, your browser requests content from “nextrow.com” and receives cookies from the same domain. This is a classic example of a Same-Origin Request, and the cookies in this case are termed First-Party Cookies.

Now, let’s add a twist. Suppose “nextrow.com” uses images hosted on another website, let’s name it “nextrow.net”. Even though you’re on “nextrow.com”, your browser fetches a picture from “nextrow.net”. During this process, “nextrow.net” might also set its own cookies in your browser. Here, the image request to “nextrow.net” is a Cross-Origin Request, and the cookies set by “nextrow.net” are Third-Party Cookies.

Fast forward to your next visit. Your browser remembers and sends the cookie information to “nextrow.com” and “nextrow.net”, helping these sites offer personalized content. However, cookies remain domain-specific. This means that “nextrow.com” can’t access cookies set by “nextrow.net” and vice versa. It’s crucial to remember this domain specificity, as it plays a significant role in digital tracking and personalization.

Potential Concerns with Third-Party Cookies and Cross-Origin Requests

1. While third-party cookies benefit organizations by allowing them to target users effectively, there are privacy concerns. Even if cookies for personalization are harmless, some websites might expose sensitive user data to external parties. Given these vulnerabilities, browsers like Safari, Brave, and Firefox have grown increasingly wary of third-party cookies. Google Chrome has even announced that it will phase out third-party cookies by 2023.
2. Similarly, cross-origin requests face scrutiny. Secured browsers and browser extensions are increasingly blocking these requests, especially if they’re primarily for tracking, rather than essential page content like images.
3. As the digital age continues its rapid expansion, understanding visitor behaviors is critical. This understanding is hinged on the accuracy of tracking methodologies employed by analytics platforms. Adobe Analytics, a titan in the world of analytics, has two key methods for identifying visitors. Let’s dissect them to grasp the intricacies involved.

Tracking without Experience Cloud ID Service

Imagine NextRow has implemented Adobe Analytics on its website. When a visitor lands on the website, a flurry of interactions begins:

Request & Response:

Upon page load, the browser communicates with NextRow’s domain server. Almost simultaneously, Adobe sends a request to its servers, which may be adobedc.net, 2o7.net, or omtrdc.net. Adobe’s primary goal here? Visitor identification. The system then sends back a visitor ID.

Storage:

This visitor ID is stored in a cookie (‘s_vi’) within Adobe’s tracking domain. This ensures that when you return, Adobe recognizes you.

Third-Party Cookies & Cross-Origin Requests:

The process introduces us to the world of third-party cookies and cross-origin requests. When you, the visitor, access NextRow’s website, your browser reaches out to Adobe’s domain server for required tracking information. While you’re on NextRow’s domain, cookies from Adobe’s domains (like adobedc.net) are set. These are third-party cookies.

The catch? Browsers may block these third-party cookies. If they do, every visit to NextRow feels like the first time – there’s no digital memory of you. Worse, if the browser blocks cross-origin requests, tracking is entirely disabled. Adobe does have a backup plan: a fallback cookie (‘fid’). If the primary cookie is blocked, this backup cookie is placed on NextRow’s domain, becoming a first-party cookie. However, cross-origin requests remain a conundrum, and so does identifying visitors across multiple domains.

And for those wondering, this remains true if tags are loaded via a Tag Manager. Any prevention of cross-origin requests hinders tag rendering.

Tracking with Experience Cloud ID Service

The Experience Cloud ID Service changes the game. Here’s how:

Domain-Based Cookies:

With the Experience Cloud ID Service, cookies are set on NextRow’s domain, not Adobe’s tracking domains. The browser sends a request to Adobe’s Data Collection Server (DCS) at dpm.demdex.net, which responds with a visitor ID. This ID, stored in an ‘AMCV’ cookie, now rests on NextRow’s domain.

Cross-Domain Tracking:

Adobe also sets an additional ‘dpm’ cookie on dpm.demdex.net. This is essential for tracking a visitor across different domains. While the primary cookie ensures that Adobe recognizes the visitor on NextRow, the ‘dpm’ cookie allows Adobe to regenerate the same visitor ID even across varied domains.

First-Party vs. Third-Party:

As visitors browse NextRow’s website, they communicate with Adobe servers. Now, the cookies are first-party, being set on the same domain they’re browsing. This guarantees accurate visitor identification. But, if the ‘dpm’ cookie (a third-party cookie in this context) on dpm.demdex.net is blocked, cross-domain tracking is off the table.

To clarify, when we discuss cross-domain tracking, we’re talking about distinct domains, not subdomains under a parent domain. For instance, if NextRow had subdomains like blog.nextrow.com, Adobe’s Experience Cloud ID Service can set the ‘AMCV’ cookie on the main domain, ensuring uniform accessibility across all domains for visitor identification.

In Nutshell

While CNAME offers promising solutions within Adobe Analytics, it’s crucial to grasp its underlying mechanisms and potential limitations. This knowledge empowers organizations to make informed decisions that not only optimize their analytics strategies but also respect user privacy.

Both methods—CNAME and traditional third-party cookies—come with their own set of advantages and drawbacks. As we navigate this complex terrain, adapting and employing the right strategies becomes increasingly vital.

NextRow can serve as your trusted partner in navigating this complex terrain. With decades of experience in personalized MarTech solutions, we blend creativity with strategy to offer tailored content strategies that align with your unique business goals, strengthening customer connections along the way. Our track record of assisting numerous organizations demonstrates our expertise and updated skills, making us the ideal choice to help your organization thrive.

Join hands with NextRow to unlock the potential of Adobe Analytics and chart your path to success. Our commitment to innovation and client satisfaction has earned us a spot on the Inc 5000 list, a testament to our dedication to helping businesses like yours excel in the ever-evolving digital world.