{"id":60865,"date":"2025-01-31T22:34:17","date_gmt":"2025-01-31T22:34:17","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/agency-transparency-and-control-unsolved-problems-with-server-side-tagging\/"},"modified":"2025-01-31T22:34:17","modified_gmt":"2025-01-31T22:34:17","slug":"agency-transparency-and-control-unsolved-problems-with-server-side-tagging","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=60865","title":{"rendered":"Agency, Transparency, And Control: Unsolved Problems With Server-side Tagging"},"content":{"rendered":"


\n<\/p>\n

\n

I have been a strong supporter of server-side tagging<\/a>, in particular Google\u2019s server-side tag management solution<\/a>.<\/p>\n

I admire the way it seeks to readjust the balance of control<\/strong> that typically has been in favor of the marketing vendors whose JavaScript libraries<\/strong> have been free to wreak havoc in the user\u2019s browser.<\/p>\n

\n

<\/p>\n

\"Regular<\/p>\n

<\/a><\/p>\n<\/div>\n

By inserting a buffer<\/em> between the user and the vendor, the owner of the server-side tagging setup can take control<\/strong> over what data the marketing vendors can actually process of the user.<\/p>\n

However, for all the good it brings to an organization, there are still some unsolved problems with the technology.<\/p>\n

Unfortunately, these problems aren\u2019t things that a server-side tag management solution could solve in isolation.<\/p>\n

\n

<\/p>\n

\"Agency<\/p>\n

<\/a><\/p>\n<\/div>\n

In this article, I explore these problems with the purpose of inspiring discussion and, hopefully, more focus on features that would help with the trifecta of user agency<\/strong>, transparency of data flows<\/strong>, and control<\/strong> over what is processed by the server-side proxy.<\/p>\n


\n X<\/span><\/p>\n

\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n

\n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n

<\/span><\/p>\n

Agency: The user should have the final say<\/h2>\n
\n

TL;DR<\/strong> By making ad blockers less efficient<\/strong>, server-side tagging erodes the user\u2019s agency<\/strong> over their browsing experience!<\/p>\n<\/blockquote>\n

If you LARP as a fly in the ceiling in any sales or implementation pitch around server-side tagging, you\u2019ll soon hear what many consider to be the most persuasive argument:<\/p>\n

By running behind a custom domain name, server-side tagging can be used to avoid ad and content blockers from interfering with data collection<\/strong>.<\/p>\n

\n

I\u2019ll be using the term ad blocker<\/strong> to conflate all different types of ad\/content\/privacy blockers in the rest of the article copy.<\/p>\n<\/blockquote>\n

This is an undeniable outcome of replacing direct communications with vendor domains (e.g. facebook.com<\/code>) with a custom subdomain of the company\u2019s main web property (e.g. sgtm.mycompany.com<\/code>).<\/p>\n

Many blockers still use heuristics that primarily look at the URLs<\/strong> that receive network requests from the user\u2019s browser. If these URLs match patterns in their blocklists<\/strong>, the network requests are denied.<\/p>\n

By moving away from facebook.com<\/code> to sgtm.mycompany.com<\/code>, a key part of the pattern is obfuscated. It\u2019s very unlikely for a blocklist to have mycompany.com<\/code>, whereas it\u2019s almost certain ad blockers recognize facebook.com<\/code>.<\/p>\n

\n

<\/p>\n

\"Blocked<\/p>\n

<\/a><\/p>\n<\/div>\n

Yes, many blockers also look into other parts of the request such as the path<\/strong> or query parameters<\/strong>, but these are easy enough to obfuscate with the server-side tagging technology, too.<\/p>\n

Whether you do this intentionally (you actually want to prevent ad blockers from doing their job) or unintentionally (you want to move your data collection to first-party and blocking ad blockers is just a side effect of this), you need to respect the user\u2019s technology choices when engineering data collection<\/strong>.<\/p>\n

You have no way of knowing<\/em> why the user is using an ad blocker.<\/p>\n

They might use it because they don\u2019t want to be tracked<\/strong>.<\/p>\n

They might use it because they don\u2019t want to see ads<\/strong>.<\/p>\n

They might use it because they want the Web to be faster<\/strong>.<\/p>\n

They might use it without knowing they\u2019re using it<\/strong>, if they happen to use a browser such as Brave<\/a> that has built-in ad blocker functionality.<\/p>\n

Why is this a difficult problem to solve?<\/h3>\n

One of the main benefits of server-side tagging is data stream consolidation<\/strong>. You can reduce client-side performance woes and mitigate the privileges given to vendor JavaScript libraries by only collecting a single stream of data from the user\u2019s device to the server-side tagging endpoint.<\/p>\n

The server then takes this stream and fans it out<\/strong> to the marketing vendors. This way a single Google Analytics 4<\/strong> stream, for example, can be used to also collect data for Facebook, for Google Ads, for Taboola, etc.<\/p>\n

\n

<\/p>\n

\"fan<\/p>\n

<\/a><\/p>\n<\/div>\n

So now if the user is using an extension that blocks Facebook but not Google Analytics, you need to first check if the user\u2019s browser would block<\/strong> the Facebook stream, then pass this information<\/strong> to the server with the GA4 hit, and then in the server make sure the Facebook stream is blocked so that the user\u2019s choice is respected<\/strong>.<\/p>\n

This is awkward.<\/p>\n

Your site might also have a Content Security Policy<\/strong> in place which prevents you from making the mock request to facebook.com<\/code> in order to check if it would be blocked by an extension.<\/p>\n

What are the potential solutions?<\/h3>\n