Intro

Performance marketing relies heavily on accurate signals to inform ad platforms' decisions on ad placement and bidding. As privacy tools and ad blockers become more prevalent, maintaining tracking accuracy has become a significant challenge for marketers. This guide explores practical approaches to optimize your tracking setup in this evolving digital environment.

We'll focus on two key strategies: leveraging first-party context for data collection and using a server-side proxy. These methods aim to improve data accuracy and the overall effectiveness of your performance marketing efforts, working within the constraints imposed by modern privacy tools and ad blockers.

An important note is that this guide is not about circumventing consent. Everyone should follow the regulatory requirements regarding tracking and consent. The strategies discussed here are designed to optimize tracking within the bounds of user preferences and privacy regulations. 

We should also respect that apart from legal, there are ethical considerations at play. Some people might consider that if a user has an Ad Blocker or uses a Privacy Focused browser like Brave, this is part of their preferences and we should not try to go around that. So proceed with caution.

How Browsers and Extensions block tracking

To understand potential solutions, it's crucial to first grasp how tracking blockers and privacy-focused browsers impede tracking. Let's visualize the browser as a "box" in which your website code, including tracking scripts, operates:

This simplified representation illustrates the basic concept, but a few important technical points should be noted:

1. Integration of content: In reality, there's no distinct separation between website content and tracking scripts. Tracking code is typically loaded and executed alongside other website content and scripts.
2. The role of tracking platforms: We've introduced the concept of a "tracking platform" here, which will primarily refer to tools like Google Tag Manager throughout this guide. However, the principles apply equally to other tag managers and Customer Data Platforms (CDPs) such as Segment or RudderStack.
3. Direct implementation: While not strictly necessary, tracking platforms are commonly used in modern implementations to centralize and distribute various tracking scripts. However, it's important to note that tracking scripts can also be implemented directly in the website's code.
4. Execution environment: All scripts, whether for core website functionality or tracking purposes, execute within the same JavaScript environment provided by the browser.

When tracking scripts or platforms operate, they make network calls to specific URLs. Here's how this process typically works:

1. Initial Load: When a user visits your website, the browser loads the website content.
2. Tracking Platform Load: If you're using a tracking platform like Google Tag Manager (GTM), it loads its core library first.
3. Container Load: Once the GTM library is loaded, it fetches and loads the GTM container, which contains configurations for various tracking scripts.
4. Individual Script Execution: The GTM container then loads and executes individual tracking scripts as defined in its configuration. Each of these scripts may make additional network calls to their respective endpoints (e.g., Google Analytics, Facebook Pixel).

You can observe these call by opening up the Developer Tools of your browser, navigating to the Network tab, and searching for the destination of choice (e.g. Facebook):

Tracking Blocker Intervention:

Tracking blockers can "see" these network calls and decide to block them based on predefined rules. They can intervene at multiple points:

1. Total GTM Block: Prevent GTM from loading entirely, blocking all managed scripts.
2. Selective Script Block: Allow GTM but block specific script loads or network calls from individual tracking tools.

For example:

• A blocker might allow Google Analytics but block Facebook Pixel
• It could permit Intercom for customer service but block advertising-related scripts

Or:

Enhance Tracking Resilience Against Blockers

Given that tracking blockers primarily operate by intercepting network calls based on URL patterns and request types, we can employ two key strategies to enhance the resilience of our tracking setup:

1. Move as much of your destination implementation outside your browser and into a server-side proxy.
2. Load your tracking platform via a first-party proxy and mask the request.

Server-Side Destination Implementation

When marketers hear about Server-Side tracking or Conversions API, they usually have in mind that the destination platform is hooked up to the company’s backend which sends events directly to the tool (e.g. Facebook CAPI). 

However, in most cases, and in at least in the context of this article, this is not the case. The reality is that a better wording would be something like “Server-Side Proxy via Client Forwarding”.

This strategy involves moving a significant portion of your tracking infrastructure outside the browser environment to a server-side proxy. Here's how it works:

1. Instead of the browser sending data directly to various tracking platforms, it sends all tracking data to a single server-side endpoint.
2. This server-side proxy then distributes the data to the appropriate tracking platforms using their server-side APIs.

This implementation has the following advantages:

1. Any tracking blocker rules specific to a destination are nulled, as the browser and extensions cannot “see” where the data are going.
2. Less libraries are loaded and generally calls are made on the frontend, reducing the page load of the site.

However, the client-to-server calls still happen to a third party domain defined from your hosting provider of choice (in this case AWS). This still leaves the possibility of a blocker stopping the calls from passing through, and creates further problems with tracking entities, for example first-party cookies not working properly given the third-party context of the server. 

An improvement here is to proxy the server-side container to a first-party subdomain of the domain of the originating website, (xyz.yoursite.com):

Client-side GTM Library Proxy

As you can see from our latest visual, there is still a “red” network call that happens to an external hostname and, if blocked, basically stops any tracking from going ahead. 

To improve on this further, we can actually get the tracking platform library itself to load from our proxy first-party server. Tracking platforms offer this option, for example Google Tag Manager or Segment. 

So now the full tracking setup is first-party. All that browser entities see is calls happening to a first party subdomain. Technically, they can still block that based on the format of the call, so as an extra advanced implementation you can actually change the format to mask it further, making it even harder to spot.

Additionally, in reality there are still destinations that do not offer server-side endpoints, or destinations that recommend a dual setup with deduplication mechanisms as a fallback in case the server is down or faces issues. So the full scaled setup would look like something like this:

Closing

Throughout this guide, we've explored the simplified concepts of how tracking blockers operate and strategies to mitigate their impact on data accuracy. The effectiveness of these approaches can vary significantly depending on factors such as visitor demographics, geography, and device usage. However, as a broad indicator, implementing these strategies could potentially lead to an accuracy improvement of around 30% in tracking and conversion data.

It's crucial to reiterate that while these techniques can enhance data accuracy, they should never be used to circumvent user consent or privacy preferences. The power of server-side implementations, while significant in terms of data collection capabilities, comes with increased responsibility. The reduced transparency inherent in server-side tracking is not an excuse to obscure data collection practices from users. Maintaining clear communication about data usage and providing easy-to-use opt-out mechanisms remain paramount.

Furthermore, we must acknowledge the ethical considerations at play. A user's choice of browser or decision to install privacy-enhancing extensions may be a deliberate expression of their privacy preferences. As marketers and technologists, we should carefully weigh the balance between our need for accurate data and respecting these user choices.

Regardless of where you stand in this ethical debate, I hope this guide has shed light on the technical considerations and approaches from both perspectives. The intention is to foster constructive conversations about the future of web tracking, user privacy, and the evolving landscape of digital marketing.