“Server-side” tagging: Should I go or not?

With the rise of issues related to Data, Privacy and “First Party” in digital marketing, the subject of “server-side” tagging often comes up. The underlying question, from the piloting side, is: “Do I go or do I not go?” or even, “Do I go now or later?” In this article, we will attempt a synthetic approach to help with the decision.

Summary: 

Useful definitions: 

  • Cookie 1st party: a cookie that is associated with the same domain name as the website visited. 
  • 3rd party cookie (or third party cookie): a cookie that is associated with a different domain than the website visited (often a domain of an advertising platform).
  • ITP (Intelligent Tracking Prevention) : Privacy feature introduced by Apple on Safari in 2017.
  • TMS (Tag Management System): tag management system

3 main issues

First, let's lay out three main issues that are often raised in the context of a server-side strategy. For each of these issues, we will discuss their impacts, and what server-side technology can bring.

Problem 1: Trust in Data (data quality)

Important decisions are made based on the results observed in Web Analytics reports. Advertising campaigns are also set and optimized based on collected data. La data reliability so is a major issue.

In recent years, various technical or regulatory events have impacted data collection:

  1. GDPR (regulatory) : we lose some of the data.
  2. ad blockers (technical) : we lose another part of the data.
  3. Safari / iOS / Firefox(technical) : we are still losing data (with ITP, a tracking prevention system that significantly restricts the use of cookies)
  4. Chrome 3rd party cookies (technical): on standby for the moment, but we expect future developments which will certainly lead to further data losses 

Let's look at these different points a little more closely: 

1 – GDPR

On the regulatory side, some visitors do not give their consent. This is normal, it is a fact. And it is better to be clear from the beginning, the idea of ​​server-side is not to bypass consents !

️️  In France, it is estimated that around 35% of Internet users do not give their consent.
(source: Credoc Digital Barometer – 2022)

⚠️ Impact: Some of the data is not collected. The volume KPIs of Web Analytics reports lose their meaning (the proportions and changes remain usable). The advertising targeting features are a little less precise.

2 – Ad blockers

A significant proportion of users equip their browsers add-ons, called Ad blockers (ad blockers). The role of these tools is mainly to hinder the functioning of marketing/advertising processes on visited sites. Sometimes, these tools can even go beyond this objective, going so far as to prevent Tag Manager from loading altogether.

As we said, basically, it is of course about respecting the user's choices in terms of GDPR. For this, your website is probably already equipped with a consent manager (Axeptio, Cookiebot, Didomi, etc.). 

But by loading a Tag Manager, running tags and collecting data in compliance with regulations, you are simply doing your job as a website operator, and you can legitimately aim to not let your compliant tools be hindered.

️️  In France, around 30 to 40% of Internet users (desktop) use ad blockers

⚠️ Impact: an additional part of the data is not collected. The impact of the previous point (GDPR) is amplified.

3 – ITP (Safari / Firefox…)

The ITP (Intelligent Tracking Prevention) system, launched in 2017, is designed to restrict the use of cookies. It is present in Safari and Firefox browsers, among others.

In particular, it blocks third-party cookies, and purges first-party cookies after 1 days.

️️  In France, around 32% of Internet users use Safari (source Statista)

⚠️ Impact: Here, it is mainly the targeting capabilities or attribution models of third-party advertising systems that are impacted (third-party cookies blocked). On the Web Analytics side, they can no longer recognize a recurring user effectively (1st party cookies purged within 1 to 7 days).

4 – Blocking 3rd party cookies on Chrome

Same idea here: After first mentioning a Third-party cookie depreciation postponed to 2025, Google recently announced that Third-party cookies on Chrome may not be deprecated after all (22/07/24). Despite everything, this blocking of third-party cookies remains an issue to be addressed. Even if the upcoming developments of Chrome will not consist of a pure and simple blocking, we can expect that they will leave more control to users with, as a consequence, an alteration of the current functioning.

It is the buzz around this point in particular that is generating a recent increase in interest in server-side technologies.

️️  In France, around 57% of Internet users use Chrome (source Statista)

⚠️ Impact: This will amplify the impact of the previous point (ITP) on third-party cookies. So especially for what will concern the targeting of advertising campaigns and attribution models (drop in return on advertising investments or ROAS).

In short, by reducing the amount of data collected, the statistical mass is naturally weakened. Confidence in the data is shaken and marketing strategies lose some of their precision and effectiveness. 

Server-side contributions to trust in data: 

On this first issue, a server-side implementation will make it possible to reduce the impact of technical limits:

  • Reduce the impact of Ad blockers (depending on the technical solution used).
  • Reduce the impact of limitations on Safari/Firefox (ITP).
  • Reduce the impact of 3rd party blocking on Chrome.

⚠️ Please note that there are different ways to implement server-side, ensuring more or less efficiency. We will discuss our recommendations in this area at the end of the article.

👍 With server-side, data collection will be broader and more qualitative, which will be favorable for optimizing marketing campaign strategies and improving the quality of audience analysis.

 

Problem 2: Controlling the data collected (data governance)

On the client-side, tag scripts can collect certain data without it being completely transparent and controlled. Indeed, it is quite difficult to verify what is actually captured and sent by the tag.

On the server-side, the implementation of tagging involves a process in which each data captured client-side and sent to the server-side tags is defined.

Contributions of the Server-side on Data governance: 

On this second issue, the server-side provides: 

  • Full visibility of data carried by tags
  • Full control of this data transmitted by the tags (anonymization / modification of personal data)
  • Vendors (Meta, Google, etc.) only access the data configured on the tags in the Tag Manager.

👍 The server-side allows you to regain control of the data involved in Web Analytics and Digital Marketing processes.

 

Issue 3: Maintaining website performance

In a client-side tagging system, tags are loaded and executed by the user's browser.

Some tags, taken individually, are already quite heavy (e.g. Facebook Pixel). But taken all together, we sometimes have significant and impactful load accumulations for visitors.

© Smile

Contributions of Server-side on Website Performance: 

On the performance issue, the server-side provides: 

  • An optimization/limitation of the quantity of elements processed on the Client side.
  • Favorable for user experience (UX).
  • Good for SEO.

👍 Server-side promotes website performance and SEO.

 

The “server-side”, kézako?

But Jamy, what is a “server-side” tag?

Usually a tracking tag is executed on the client's browser. The data exchange is direct between the visitor's browser and the marketing or analytics platform. This is called a "client-side" tag.

On the client side: 

  • Each tag is loaded/executed by the browser.
  • Each tag collects its data (often the same as other tags).

In the case of a server-side tag, information is transmitted from the client-side to another container hosted on a server in the cloud, through a single tag that acts as a “transporter”. Tags are then executed with this data from the server to the marketing or analytics platforms.

On the server side: 

  • Only one collection tag is loaded by the browser.
  • A single collection tag takes the data to make it available to server-side tags.

© Smile

Ok, but what is it for?

Due to the fact that the tags are executed from a server instead of the browser/client, the following characteristics are achieved: 

  • A server-side tag does not place third-party cookies on visitors' browsers.. However, cookies placed by the server become first party. 
  • A server-side tag can only send data received by the single entry point from the client.
  • A server-side tag does not execute on visitors' browsers. 

This then provides these main advantages: 

  • Improving data quality
    By limiting the impact of Ad blockers or limitations related to third-party cookies, more data is collected.
  • Control of the data collected
    By managing the data pipe to server-side tags, you regain control of what is sent and therefore collected.
  • Optimization of loading times
    By running tags server-side, we lighten the browser's workload. This goes in the direction of improving the user experience, and SEO optimization.
  • More sustainable method
    The evolution of regulations and technologies tends to increase the interest of the server-side. By taking the train early enough, we can hope for good sustainability, as opposed to everything that revolves around cookies and the client-side

 

Some preconceived ideas

  • Server-side allows to bypass Ad blockers

In my opinion, this is a bit true and a bit false: cThis is not the primary purpose of the server-side. However, it is true that

This is not the primary purpose of server-side. However, indeed, logically by sending server-side tags, they will no longer be hindered.

But to make server-side tagging work, your site must still continue to use a Tag Manager client-cide container with tags that link to the server-side. These “bridge” tags can remain blocked by an Ad blocker. In this case, we cannot say that the server-side bypasses the Ad blocker. Same thing if the Ad blocker blocks the Tag Manager outright.

In summary, server-side in itself is not enough to bypass Ad blockers.

We will discuss later in this article how advanced implementation techniques can limit the impact of Ad blockers.

  • Server-side allows nothing to be loaded on the client side

Here too, it is necessary to qualify and pfor the same reason: In fact, most of the time when we talk about server-side tagging, we are actually talking about “Client to Server to Server”. Note that there is an advanced type of implementation that allows Server to Server (with the Measurement Protocol, reserved for experts).

To make a “classic” server-side tagging work, your site must still continue to use a client-side Tag Manager container with tags that act as a “bridge” to the server-side. As a result, in all cases, there are still processes on the browser/client side.

But in fact, some tags will be transferred to the server side. 

In summary, server-side (classic) can reduce client-side loads, but not eliminate them completely.

  • Server-side is good, but it's expensive

So, on the subject of cost, everything is relative (again!?): If we just look at the direct costs of the solutions and the expert time needed for implementation, it can be off-putting (otherwise we do nothing and we spend nothing more).

But of course, I'm going to suggest broadening the thinking a little here: I did a quick calculation on a corner of a tablecloth (ok... I used a spreadsheet) that I'd like to share with you: 

Let's start with the hypothesis of an e-retailer who runs SEA campaigns using retargeting. We have some KPIs available:

  • He spends €5/month in SEA.
  • Its average CPC is €1,5/click.
  • Its average basket is €140 with a gross margin of 40%.
  • He observes an average conversion rate from SEA at 3%.

All is well in the best of all possible worlds and everything is humming along with around 100 conversions per month and a total gross margin generated of €7/month. The direct benefits of SEA are positive at +€000/month (gross margin – CPC-spending). And then one “fine day”, its targeting capabilities are reduced because of a Chrome update that blocks third-party cookies… From there, his campaigns being a little less effective, he sees his conversion rate drop to 2%. He then loses €2 of margin per month, just for -1% conversion rate… 

I'll let you plan for what comes next and imagine other scenarios. But in summary, when you put server-side costs into perspective, it's generally quite reassuring. What's likely to be expensive is doing nothing.

How do we do ?

So, this is a pretty broad question. Since I've already used up a lot of your valuable time (and there are already excellent resources from experts far more experienced than I on the subject), I'll try to summarize my perspective in a concise and simplified way:

  • Method 1: “old school”

The client opens a server instance in the cloud (often on Google Cloud Platform because it is directly offered by Google Tag Manager), we put everything in place to transport the data from the client-side to the server-side… We do the tests, we see the server-side tags leaving… everything is fine. We are doing server-side!

But... without noticing it immediately, we have client-side 'bridge' tags blocked by adblockers... we have client-side container tag managers blocked by Ad blockers... we may have a problem on the Google Cloud instance for a billing issue that the client has not managed... we may have problems with poorly collected data... etc.

We quickly find ourselves with a strong risk linked to the lack of monitoring and a 'black box' effect. In short, we get there, but hey, it's full of little hassles, often quite sneaky and impactful for the performance of your "server-side" operation.

  • Method 2: Rely on an expert solution/partner

And then, one day, we discover on a data/marketing forum, or in a blog article, that a French company offers a platform and services that respond to these issues.

You are no longer alone, real experts support you. Tools greatly simplify implementation. The platform evolves regularly.

In short, the whole thing far outclasses the “old school” method.

This technological partner is Addingwell. And no, I have no shares in them (which is a shame). There really is a gap (which is not illogical, by the way). We quickly see that they know their subject very well and that everything they put in place directly responds to concrete problems. We save a lot in terms of implementation time, possibilities and reliability.

Conclusion

Should I go or not?

  • Go for it! Given the data and performance issues that already exist, and those to come, you need to position yourself on this technology (unless you don't do any traffic acquisition/advertising at all).

Should I go now or later?

  • You see it, but don't wait too long: When the next developments of Chrome related to third-party cookies arrive (2025?), there may be a traffic jam of requests for server-side implementation.

And what do I do?

  • You call UX-Republic (randomly).
    • We will study the need and possibly suggest to our partner Addingwell to join us in putting together a suitable project for you.

    In any case, we do not recommend going there without being accompanied. The complexity of setting up server-side tagging is a notch above a client-side implementation (which can already be quite tricky).

 

 


Laurent Neuville, Senior Web Analytics Consultant at Smile