Should you consider moving on to server-side tracking?

The traditional way of collecting data on the client-side is becoming restricted due to browser restrictions and data protection regulations. This inevitably is resulting in data loss and degradation. However, server-side tracking could address these issues.

In this blog post we will talk about the context of server-side tracking, explain what server-side tracking is and look at the challenges this technology can address, who it is aimed at and its costs.

Why server-side tracking is back in the spotlight

Data collection via analytics or advertising tools has been harmed in recent years. We have heard of several scandals (such as Cambridge Analytica and Facebook) and investigations by journalists and whistleblowers (such as Edward Snowden). As a result, people and governments around the world became aware of what was being collected on them, without their knowledge, and what was being done with that data.

As a result, consumer data protection has been strengthened by legislators. The introduction of the General Data Protection Regulation (GDPR) in 2018, the California Consumer Privacy Act (CCPA) in 2020 and many other regulations now limit the amount of data that can be collected.

Data protection systems have been built directly into browsers. Apple's Intelligent Tracking Protocol, Firefox's «strict mode» or «Privacy by default» in Brave and DuckDuckGo also disrupt the data that is collected. Not to mention the AdBlockers installed by users.

Finally, 3rd party cookies are going to be permanently removed from browsers (there is still Google Chrome, postponed until the 2nd half of 2024). It will therefore be more difficult for the online advertising industry to identify users and campaigns will become less effective. Also, there is the same fight on mobile with Apple's introduction on iOS 14.5 of a limitation of the use of the «IDFA», the cross-application identifier for advertiser. Android seems to be following with the addition of a similar feature for its «AdID» in Android 12.

We are thus faced with a significant degradation of data. And distrust of data quality can become a major obstacle to any data collection initiative. So how can you deal with all this protection and legislation? How can you get back on track and continue to collect representative data while respecting legal constraints and users' wishes?

This is where server-side tracking comes in. It provides answers to these questions. But first, how does server-side tracking work?

What is server-side tracking?

A request tale 

The basis of tracking is a request. As soon as a user performs an action that is measured, a request (HTTP) is sent to a tracking server (end-point) belonging to a service (Google Analytics, Facebook, Snowflakes). In other words, this request, sent from the browser, points to a URL that represents a tracking server of a specific service.

These tracking servers are configured in a way that they can read these requests, more specifically their payload as URL parameters. It is this payload that contains the data we want to collect. Identification data (from cookies) is also attached to the request to identify the sender, or the browser on a given machine. The tracking server then processes this data to add a line in an analytics tool or add a user to a remarketing list.

These requests can be sent from sources other than a web browser. This is where the distinction between client-side tracking and server-side tracking comes in.

The client-to-vendor model 

Client-side tracking – or client-to-vendor – is the classic tracking model. A client is the medium through which the user surfs the web, often a web browser. Requests are sent from this client to the tracking server(s) (vendors) like Facebook or Google Analytics.


But this model has some weaknesses


There is a correlation between performance and page weight. We know that long page load times have a negative impact on user experience and conversion rates.

For each 3rd party deployed on the website it is generally a JavaScript library or an App SDK (Software Development Kit - a library, but for mobile apps) that must be loaded. This library will then generate a request and send it to the tacking server of this vendor. These actions lead to an increase in network egress and can increase the weight of web pages. In the end, leading to a degradation of the loading time.

Data breaches

3rd party scripts run in the browser, without us knowing how they work. More importantly, we have no control over what may be executed, what query is generated on exit, and even less control over what data is sent to vendors. This forms a data security breach that can lead to a significant leakage of personal data.

Impacted by browser data protections

Many privacy protection methods exist and limit data collection. As we have no control over what the browser decides, client-side tracking is highly dependent on the rules applied within the browser and the ad-blockers installed.

So, while client-side tracking adds unnecessary load time to pages and can be an open door to security breaches, it does offer enough transparency to block or restrict tracking.

On the other hand, server-side tracking may offer better control over invasive and resource-intensive scripts and better management of incoming and outgoing data flows, but it will need to address the significant lack of transparency to end users.


That’s what we will examine now.

The client-to-server-to-vendor model

What we call «server-side tracking» is in fact not pure «server-side». That is, the communication of requests is not, as one might think, from server to server (vendors), but from client to server to vendors.

The choice of this communication model was made because it needs to rely on what is done on the client side: the storage of data in the data layer and the possibility of measuring user interactions on the site. All these elements are already in place on the client side and are orchestrated by a Tag Management System (TMS) such as Tealium, Google Tag Manager or Adobe Launch.

These tools allow data to be collected using so-called tags, which are triggered according to specific rules. Once triggered, these tags are responsible for sending the data to the vendors. All this takes place in the browser, on the client side.


With server-side tracking – or client-to-server-to-vendors – the request is not sent to the vendors' tracking servers. Instead, the request is sent to an intermediate tracking server.


You, as a company, own this tracking server. It is secure and usually hosted on a cloud platform. Inside this server, a Server-Side Tag Management System (SSTMS) (like the one on the client side) is installed to manage the reception and processing of requests.

In a nutshell, SSTMS processes each incoming request with all its associated data, then filters, enriches or transforms it before transmitting the results to the vendors.


Main benefits of server-side tracking

Reduce the performance issues 

The main advantage of server-side tacking is the streamlining of data flows. Instead of sending as many requests as there are vendors, a single request is sent to the SSTM, which will take care of sending the data to the other vendors.

As it is the SSTMS that takes care of this distribution of requests instead of the TMS running in the browser, the resources required for tracking are drastically reduced: fewer requests to send and fewer scripts to load. Also, optimising the loading time will be beneficial for SEO. Indeed, these actions will inevitably bring some improvement to Core Web Vitals and we know that these measures are important because Google has announced that the data will be rolled in as a ranking factor and the deployment of this update was done on the 15th of June 2021.

But this is only true if everything is moved to the server side. In reality, there are still some technological constraints, but also some nonsense. Such as Facebook asking to keep tracking on the client side to continue to collect as much data as possible and to deposit 3rd party cookies for its «LookaLike Retargeting» algorithm.


Regain control over the data 

Besides reducing the risk of breaches caused by the loading of 3rd party scripts in the browser, vendors will only be able to get the data that the SSTMS has chosen to send. They will no longer be able to use the data available in the browser, as in an all-you-can-eat buffet.

Furthermore, as all processing is done on the tracking server, we can perform real anonymisation and obfuscation tasks. Thanks to this technique, known as "Proxyfication", we can address the issue of data protection more effectively. We can really protect users because we choose what is sent, to whom and in what format. But the implementation of server-side tracking does not allow us to circumvent the law in any way, as consent is still required. Yet, if true anonymisation were implemented (the removal of any element allowing direct or indirect identification of a user), this would allow us to free ourselves from the consent need. But the degradation of the data will be such that we advise using measurement tools dedicated to the analysis of aggregated data.

Also, with the server-side approach, it is possible to bypass content blockers (AdBlockers). In fact, the request is sent to your tracking server, not to the vendors. It is thus undetectable by the plugins. For the moment, this is a boon for tracking, but if this detection were to adapt to this new tracking mode, we advise you not to find a way to bypass it. We advocate respecting the user's wishes. We always prioritise the maximum protection of user data.

Finally, it is also possible to make the tracking server communicate with other external services (APIs), such as a CRM or a PIM system, and thus be able to perform data enrichment. This would allow you, for example, to collect product data from the databases and thus lighten the data layer in the frontend.

You can find other benefits and drawbacks of server-side tracking in this complete blog post of Simo Ahava.

Who can benefit from this solution?

Server-side technology is a complex technology that can address many issues. It will be of particular interest to advanced analytics environments.  What qualifies as an advanced analytics environment is for example:

  • E-commerce websites
  • Digital ecosystems on several different platforms
  • Advanced acquisition strategies involving multiple traffic sources requiring the integration of many tracking systems
  • Legal and IT departments that have high security requirements,
  • The need to communicate data in a complex ecosystem (CRM, CDP, marketing automation tools, etc.)

In the end, companies that are concerned about data accuracy, user privacy and website performance have good reason to switch to server-side tracking. Furthermore, some platforms like affiliate networks make this a requirement.

But, as we will see, the switch to server-side tracking requires investment (human and financial) that can be substantial.

High investment 

Setting up a server-side tracking infrastructure is not something to be underestimated. It is more complicated to implement and maintain than a client-side infrastructure.

The first item that can generate costs is the transfer of what is done on the client-side to the server-side. On one hand, some elements, such as Hotjar, are closely linked to the client-side and cannot be transferred to the server-side. On the other hand, for the rest, it is necessary to estimate the number of vendors who have accessible APIs, which is not always the case. It will then be a matter of defining whether there are tag/client templates for these vendors in the SSTMS, which is also, for the moment, not very frequent. In fact, the fewer vendors there are with ready-made templates in the SSTMS, the more work it will take to create the tags that will transmit the data. And for all those who don't have accessible APIs, you will lose part of the advantage of server-side tracking because you will have to keep the pixel in client-side

Then there are the configuration and testing costs. Debugging on server-side is more complex than on client-side, precisely because server-side tracking is not transparent. As a result, the quality assurance steps take longer to validate.

Finally, there is the server rental. On Google Cloud with App Engine, the rental costs are about $150 per month. This may seem high compared to a free solution, but it is relatively low compared to what this solution can provide in the end.

Where to from here?

In summary, at this stage, the server-side has undeniable advantages and almost infinite possibilities, but at the cost of a large initial investment. Moreover, server-side offers us many tools to optimise the governance of our data, but this advantage can be reduced to nothing depending on the use made of it.

We believe that starting from scratch is the best starting point for server-side tracking. Whether it's during a migration or during a website redesign, analytics will have to be rethought and adapted. You might take advantage of this to integrate server-side tracking into your thinking.

In other cases, if you think that the server-side solution could bring a real benefit to your analytics infrastructure, don't hesitate and go for it. But here are two tips before you start:

  • Paying several thousand bucks for a migration and $150 more per month just for Facebook CAPI (Conversion API) is a bit expensive. You need to have a real need to move to server-side, don't let yourself be fooled by the pressure these vendors can put on you and take a step back.
  • An important point before moving to server-side tracking: make a perfect documentation of your current analytics infrastructure so that you can decide what should move to the server side and how, and what should stay on the client side. This will also make it easier to estimate migration costs.

Finally, if you would like to discuss server-side tracking, our web analytics team will be happy to answer your questions.

The team behind this project

Alexis Blanco -Web Analytics Lead in Switzerland

Would you be interested in getting in touch with our Analytics Team to support you in the implementation of these recommendations? Feel free to get in touch and we would be happy to talk to you about this in more detail. 

Get in touch with our experts

Send us an email