Digital marketers and analytics practitioners are likely familiar with the term “Signal Loss.” It’s a multi-faceted problem that has only gotten more difficult to solve over the last decade as the cat-and-mouse game of tracking prevention and subsequent innovations have played out, especially ramping up over the last few years. While there is not a single panacea to signal loss, there are strategies that your business can adopt to ensure you are getting the best possible marketing signal efficacy that can be gained today.

But First- What Is Signal Loss?

Signal Loss refers to the diminishing availability of data that marketers rely on to track user behavior, measure campaign effectiveness, and optimize marketing strategies. This data, often collected through cookies, pixels, and other tracking mechanisms, is essential for understanding how users interact with online content and advertisements. When these signals are lost, it becomes challenging for marketers to make informed decisions, leading to less effective marketing strategies and potentially lower returns on investment.

What Effect Does Signal Loss Have on Digital Marketing and Analytics?

The impact of signal loss on digital marketing and analytics is profound. Without accurate data, marketers face several challenges:

1. Diminished Targeting Precision: Marketers rely on data to segment audiences and target ads effectively. Signal loss reduces the granularity of this data, making it harder to reach the right audience with the right message.
2. Reduced Attribution Accuracy: Attribution models help marketers understand which channels and touchpoints drive conversions. With less data, these models become less reliable, making it difficult to allocate budgets effectively.
3. Decreased Campaign Effectiveness: When data is incomplete or inaccurate, optimizing campaigns for better performance becomes a guessing game. This can lead to wasted ad spend and lower overall campaign effectiveness.
4. Challenges in Personalization: Personalized marketing relies on detailed user data. Signal loss hampers the ability to deliver personalized experiences, potentially leading to lower engagement and conversion rates.

The Primary Causes of Signal Loss

Several factors contribute to the growing issue of signal loss in digital marketing. Understanding these causes is crucial for developing strategies to mitigate their impact.

• Browser-Based Restrictions: Modern browsers are increasingly implementing measures to protect user privacy. For example, browsers like Safari and Firefox have introduced Intelligent Tracking Prevention (ITP) and Enhanced Tracking Protection (ETP), respectively. These features limit the lifespan of cookies and block third-party trackers, reducing the amount of data available to marketers.‍
• Ad Blockers: Ad blockers are software tools that prevent ads from being displayed on web pages. While their primary function is to improve user experience by reducing unwanted ads, they also block tracking scripts and pixels that marketers use to collect data. The widespread use of ad blockers means that a significant portion of user data is not being captured, contributing to signal loss.‍
• User Consent Opt-Outs: Privacy regulations like the General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) in the United States have empowered users to control their data, giving them the ability to opt out of tracking. Most marketers should already be well aware of tracking consent regulations’ impact, especially in Europe where high opt out rates have caused significant signal loss.

A Detailed View: Browser Tracking Restrictions

Browsers’ abilities to restrict cookie usage in tracking has been widely discussed especially in relation to Chrome’s (now indefinitely postponed) deprecation of third-party cookies. The following table describes various strategies for blocking tracking cookies:

3rd Party Cookies

It looked like 3rd party cookies would eventually be on their way out the door- Safari and Firefox had already blocked them, while Google had been aiming to deprecate them for years. That changed when Google announced they would be walking back their push to deprecate third-party cookies. These cookies have typically fallen under the most scrutiny, as they most often are associated with cross-site tracking. They can also be set by any tracking script that a domain’s owners install on their site.

Even though third-party cookies are now here to stay, Google may still deal a significant blow to the third-party data ecosystem by introducing a new consent mechanism within Chrome:

Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing, and they’d be able to adjust that choice at any time. We're discussing this new path with regulators, and will engage with the industry as we roll this out.

If this shapes up anything like Apple’s App Tracking Transparency (ATT) feature, opt out rates could significantly decline, reducing third-party cookie efficacy over the long run, rather than on a set deprecation date.

1st Party Cookies

Following Apple’s restrictions on third-party cookies, marketers began shifting to setting first-party cookies where possible. These are different from third-party cookies because they can only be set by domains that users actually visit in a first-party context- therefore, the cookies they set are considered “first-party.” It’s important to note that Safari is the only major browser to make a push towards restricting first-party cookies in any respect. This is largely because first-party cookies are typically associated with login tokens and other functional roles for websites, meaning that restrictions could cause some issues with core website functionality.

Given that Safari represents ~30% and ~20% of web traffic in the United States and Europe respectively, and it is on the leading edge of browser restrictions, it’s important to understand how this browser is limiting first-party tracking. To do this, we first need to understand a few key basics on DNS records, as they’re at the heart of Safari’s latest rounds of tracking restrictions.

What Are DNS Records?

Whenever you type a website address into your browser, like “example.com,” your computer needs to figure out where that website lives on the internet. This is where DNS (Domain Name System) comes in. Think of DNS as the internet’s phone book. It helps translate the website name you entered into an IP address, which is like the actual “street address” for that website’s server. DNS records are the entries in this phone book that help direct your browser to the right place.

The Difference Between CNAME and A Records

There are different types of DNS records, each serving a specific purpose. Two of the most common are A records and CNAME records.

• A Record (Address Record): An A record points your website’s domain name directly to an IP address. It’s like saying, “If you want to visit ‘example.com,’ go to this exact address.” This is the most straightforward way to direct traffic to a specific server.
• CNAME Record (Canonical Name Record): A CNAME record is a bit different. Instead of pointing directly to an IP address, it points one domain name to another domain name. It’s like saying, “If you want to visit ‘blog.example.com,’ just go to ‘example.com,’ and they’ll take you to the right place.” CNAME records are useful when you want one domain to act as an alias for another.

In simpler terms, if DNS is the internet’s phone book, the A record is like a direct number to the website, while the CNAME is like a forwarding number that redirects you to the correct number.

Why Are DNS Records Relevant to Safari Tracking?

DNS records play a crucial role in how websites and trackers operate online, and they’re particularly relevant when it comes to Safari’s efforts to protect user privacy.

CNAME Cloaking and Tracking

One of the key ways DNS records come into play is through a technique known as CNAME cloaking. Imagine a tracking company wants to monitor your activity across different websites. Instead of directly using a domain like “tracker.example.com” (which might be blocked by privacy tools), they could set up a CNAME record so that a domain like “news-articles.example.com” actually points to “tracker.example.com.” This makes it appear as though the tracking is happening on a legitimate, first-party site rather than a third-party tracker.

Safari and CNAME Cloaking

Safari’s Intelligent Tracking Prevention (ITP) is designed to block cross-site tracking. To counteract CNAME cloaking, Safari inspects DNS records to see where a domain is truly pointing. If Safari detects that “news-articles.example.com” is actually redirecting to “tracker.example.com,” it treats it as a third-party tracker, even though it might initially look like it belongs to the same site you’re visiting.

Tracking with Cookies Set by A Records vs. CNAME or Third-Party Domains

Cookies set by A Records can be particularly advantageous compared to CNAME or third-party domains for several reasons:

• ‍First-Party Perception: A Record-based tracking is treated as if it belongs to the first-party domain, which means it benefits from more lenient handling by browsers like Safari. When an A Record is used, it directly maps the first-party domain to an IP address of the server where tracking is being performed, without involving redirection. This first-party perception allows cookies to persist longer than those associated with third-party domains, which are typically blocked or restricted by privacy features.‍
• Avoiding Detection: CNAME cloaking, where a subdomain of a first-party site points to a third-party tracker, can be detected and blocked by browsers like Safari. However,  This makes it harder for the browser to detect the tracking, as it looks like a straightforward, legitimate connection.‍
• No Restrictions for HTTP Cookies: HTTP cookies set by domains resolving through A Records are not subject to the same restrictions as third-party cookies or those set via CNAMEs. In Safari, these cookies can persist without the 7-day limit imposed on JavaScript cookies set by first-party CNAMEs and A Records.

The Difference Between HTTP Cookies and JavaScript Cookies Set by A Records

• ‍HTTP Cookies vs. JavaScript Cookies: HTTP cookies are set by the server during the HTTP response and are automatically included in subsequent requests to that server. They are generally less restricted in usage and are often used for tasks like maintaining login sessions or tracking user behavior across visits. JavaScript cookies, on the other hand, are set and managed by JavaScript running in the browser. While they offer flexibility and are useful for dynamic, in-page interactions, they can be more restricted, especially in privacy-focused browsers like Safari.‍
• Safari’s Handling: In Safari, HTTP cookies set by domains through A Records can persist indefinitely, meaning they are not subject to the 7-day limit that applies to JavaScript cookies. On the other hand, JavaScript cookies set by first-party CNAMEs or A Records are allowed to track users for up to 7 days, after which Safari automatically deletes them. Third-party domains, however, often see their cookies blocked outright or limited to very short lifespans, usually no more than 24 hours.

Safari has tried to limit cookies set by A Records as well, which we’ll explain in the next section.

Safari Private Browsing 2.0, A Records & IP Heuristics

Safari’s Private Browsing 2.0 introduces an IP address heuristic to detect and limit tracking URLs that resolve to IP addresses which do not appear to be associated with a website’s server.

Heuristic Criteria:

• IPv4 vs. IPv6: Safari considers two IP addresses to be from different parties if one is IPv4 (e.g., 192.0.2.1) and the other is IPv6 (e.g., 2001:db8::1). This is based on the fundamental difference in address types, which generally indicates different sources.
• Subnet Mask Length for IPv4: For IPv4 addresses, if the shared subnet mask length is less than 16 bits (half of the full 32-bit address), Safari treats them as different parties. For example, 192.0.2.1 and 198.51.100.1 have a common subnet mask length of less than 16 bits and would be considered different parties.
• Subnet Mask Length for IPv6: For IPv6 addresses, a shared subnet mask length of less than 64 bits (half of the full 128-bit address) indicates different parties. For example, 2001:db8:abcd:0012::1 and 2001:db8:abcd:5612::1 would be treated as different parties if the first 64 bits do not match.

Cookie Cap Application: When Safari identifies two IP addresses as belonging to different parties based on the above criteria, it applies a 7-day cap to the expiry of cookies set in responses from these cloaked third-party IP addresses. This limits the ability of these cookies to persist and track users over long periods.

Impact for Trackers: This heuristic makes it more difficult for trackers to use IP aliasing to bypass restrictions. The 7-day cookie cap significantly curtails the effectiveness of tracking by limiting the lifespan of cookies set through cloaked IP addresses.

Impact for Non-Tracking Services: The use of this heuristic needs to be carefully balanced to avoid affecting legitimate services, such as CDNs, which might use multiple IP addresses for performance reasons. Safari aims to minimize false positives by carefully applying this heuristic only in clear-cut cases of tracking.

Safari’s approach aims to protect user privacy at all costs. By focusing on IP address patterns that are indicative of tracking, Safari can enforce enhanced privacy protections, but risk painful complications for non-tracking services that rely on separate IP addresses.

TL;DR

• Safari and Firefox are the only widely-used browsers to limit tracking.
• Both Safari and Firefox block third-party cookies.
• Safari limits any cookies (including HTTP and javascript) set by CNAME records to a 7 day cap.
• Safari’s strictest limitation on HTTP cookies set by A records, using an IP address heuristic, is only live within Private Browsing and beta environments.

‍