Introduction
Server-side tracking has been an increasingly popular term in the world of marketing and web analytics over the recent year(s) and especially months. This article provides an overview of the concept of server-side tracking in the marketing and analytics space, lays out different variations that exist in production today, highlights benefits and use cases as well as the downsides linked to server-side tracking.
Variations in server-side tracking
Server-side tracking is presented as an interchangeable solution for client-side tracking and makes it almost look like a binary choice. The reality is that server-side tracking can be seen as just another element in the toolbox of an organisation in order to construct its stack according to its needs. To show you the modularity of server-side tracking as a concept and stack component we will run you through a couple of different scenarios.
In these examples the following components are used to draw up the reference architecture:
Browser aka the client - This is your web browser. Think of Chrome, Mozilla, Safari, Edge, etc. Each time you type in a URL in your address bar the browser makes a request to something called a (web) server. Amongst others, browsers have two primary roles:
Render HTML files received from web servers
Execute javascript (eg. Facebook pixel)
(web) server - The server holds the content of your website. When a user requests a URL through a browser, that request is sent to the web server. The web server then responds by sending through the requested information.
Tag Management System - Tag Management Systems (TMS) are used by marketers to deploy marketing tags, analytics tags and other tags that need to be deployed on the website. Examples of TMS’s are Google Tag Manager, Tealium IQ and Piwik PRO. In short, a TMS tells the browser which tags to execute and when to execute them.
3rd party platform - This refers to any 3rd party platform. Examples are Google Ads, Facebook, etc.
Server-side Tag Management System - A server-side Tag Management system seeks to move the TMS from the browser or client to a server. An example is Server-side Google Tag Manager.
Scenario 1 - Client-side tracking
The following image illustrates the typical Tag Management Setup today.
A browser requests a page to the web server.
The web server responds, sends through the information (eg. HTML, javascript) and the browser renders the visual content. Within the content that is being loaded resides the script that launches the Tag Management System.
As soon as TMS code has loaded the TMS starts collecting the required info, populates the required tags and fires them. The tags that have been fired through the TMS, in the user’s browser, sends all required information to the advertising platforms’ servers.
A variation of this scenario is the usage of Segment’s client side deployment where the CDP deploys the libraries throughout the Segment tag at which point it acts as a TMS.
Scenario 2 - Server-side tracking only
The following image illustrates a world in which all 3rd party platform providers would allow immediate server-side interactions. An example of such a solution is Facebook’s conversion API. This means they resolve the complex matter of replacing the cookie functionality (most 3rd party) that lives in the browser with another server side functionality in order to resolve measurement and user identification.
A browser requests a page to the web server.
The web server responds, sends through the information and the browser starts loading the content. In parallel it sends the info meant for 3rd party providers , that would in scenario 1 be collected by the TMS, immediately to the 3rd party provider’s servers. This concept is called server-to-server tracking.
For this solution to work and to omit a TMS as a whole we assume that every 3rd party provider allows for direct server-to-server integrations. That is why this scenario is called server-side tracking in an ideal world.
Scenario 3 - Server-side tracking using the browser as a starting point
The following image illustrates a scenario where server-to-server integrations start from the browser.
A browser requests a page to the web server.
The web server responds, sends through the information and the browser starts loading the content.
The browser sends data to an intermediary server. A TMS might be involved, or not.
This server accepts, organises, sorts, qualifies the data and sends it through to the 3rd party platform’s servers.
The example above may seem odd. But there are quite a few technologies that work this way. An example is Segment’s server-side-tracking capability. All information is captured using Segment’s javascript library and sent to Segment’s servers. From Segment’s servers information is accepted, organised, sorted and qualified for it to be sent to the servers of the third party applications. Less exotic is the common implementation to send data to server-side Google Tag Manager using an adaptation of the transport_url and using a single request to decrease egress.
The case for server-side tracking
The question you might raise now is - “what’s the point of tracking things server side?” There are 2 major reasons why server-side tracking makes sense:
Speed - Even though TMS’s usually deploy tags asynchronously there’s still an impact on website loading times. Therefore the removal of a TMS on the website and replacing it by server-side TMS solutions or direct server-side integrations brings down website loading times and improves overall website performance.
Security - Moving information from the browser to the server means that it’s no longer available in the browser. Information that isn’t available in the browser can’t be exposed. More specific use cases such as optimization in advertising platforms towards profit (or POAS) can now be executed without exposing profit data in the datalayer.
Data quality controls - Creating server-to-server connection means there are extended possibilities to ensure the quality of the data flowing through the data pipeline is accurate.
The downsides of server-side tracking
Each new technology comes with both upsides and downsides. Some of the downsides include:
Control is moving back to the IT side - TMS’s were brought into life to make marketing departments independent from IT departments. Instead of deploying every tag individually, IT departments simply had to deploy a TMS snippet. Marketers took care of the rest through the TMS itself. Server-side integrations are more technical and require the help of IT. This means a reduction in flexibility and an increase in deployment / go-to-market.
Costs - Most server-side solutions aren’t free. Server-side GTM for instance requires a couple of hundred dollars per month to operate.
Blind spots - Only a limited set of events can be identified because the server only knows when a page is requested but is not aware of events such as clicks, videos plays etc.
No access to 3rd party cookies - Information stored in 3rd party cookies can’t be accessed from the server.
Conclusion
Server-side solutions are definitely on the rise due to the increasing complexity of tech stacks and the need for increased security. Moreover, the user’s expectation for faster and more performant websites together with more advanced information gathering techniques drives organisations towards server-side solutions. As you can see however, there’s no one-for-all solution. Server-side methodologies are simply another tool in the organisation’s toolbox. How you use it and to what extent is up to every organisation individually to decide.
Need help with your server-side tracking deployment? Feel free to reach out !