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.
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.
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.
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.