In recent weeks, I have received several questions related to server-side tracking from some of our clients. In this blog post, I will try to demystify this technical concept. The plain truth is that with the end of third-party cookies, the shortened lifespan of first-party cookies (on Safari) and the increased need for privacy, decision makers are becoming more concerned about the accuracy of their advertising data. The release of Google Tag Manager Server-Side and Facebook Conversion API have piqued the curiosity of many marketers.
I have selected a set of questions that I will try to answer in simple terms:
Before we jump into the meat of the article, here are some quick definitions:
Here is an simplified illustration of a website architecture:
Client-side tracking
Typical analytics and marketing tracking implementations are done using a pixel (a piece of code). The pixel is installed on the website. Once a user enters the website, in this example for the first time, this pixel is loaded in the web browser of the user. The pixel will set a web cookie (point 1 on the graph below) in the user’s browser, where an anonymous ID will be stored to identify the user during their interactions with the website (browsing pages or clicking links). Every time the user interacts with the website, the pixel will send an event to the analytics/ad servers and attach the anonymous ID stored within the web cookie (point 2 of the graph below). This anonymous ID will allow the vendor (Google, Facebook, etc.) to link these events to a user. The graph below illustrates the process. We will call this process client-side tracking (from your browser to the vendor’s analytics server).
Server-side tracking
When vendors (Google, Adobe, Facebook, etc.) talk about server-side tracking, they are usually referring to the process of sending the data server-to-server: from your website server to theirs. This process is invisible for the web browsers—it is usually a cookieless way of tracking users. The user identification (anonymous ID or any identifier) is still required, but it can be generated on the server side or passed from the browser to the server. Server-side tracking is not new and has been used for several years. Many vendors offer server-side functionalities (tracking APIs that can be implemented on the server side). The graph below illustrates the concept. The web server sends the data directly to the vendor’s servers (from your website server to the vendor’s analytics server).
These are the key advantages of migrating your client-side tracking implementation to the server side:
One of the disadvantages of server-side tracking is that it requires more work on the implementation side. You are responsible for collecting some of the client-side data (browser data, IP address, etc.).
This is probably the most confusing question. Migrating your tracking to the server side doesn’t necessarily mean that you are managing (creating or deleting) your website cookies on the server side. Similarly, you can manage your web cookies from the server side without migrating your full implementation to the server side. Let’s first take some time to explain some important facts about cookies.
Web cookies can be created from:
You can read the following post to learn more about how Web cookies are managed on the server side.
As explained at the beginning of this post, server-side tracking is simply the process of sending data server-to-server, as opposed to browser-to-server. A word of caution: Be careful about assuming that server-side tracking automatically includes web cookies managed on the server side. The next section will explain why I am making this distinction.
If you are new to the impacts of ITP 2 on web measurement, I invite you to read my colleague’s blog post on the impact of ITP 2 on your web performance indicators.
ITP 2 specifically targets web cookies. As a result, if your server-side tracking implementation doesn’t manage cookies on the server side, then it won’t mitigate ITP 2. At the time of writing, the lifespan of first-party cookies, set on the server side, isn’t shortened by Safari. Traditionally a company would embark on server-side tracking to improve web page performance and data accuracy. The growing interest in cookies managed on the server side started with ITP 2.
Assessing if server-side tracking is a good fit for your business should be a thorough process. You should start by asking yourself the following questions:
Managing cookies on the server side should not be the only reason for wanting to migrate your data collection to the server side. The reason for this is pretty simple: If ITP 2 starts affecting these cookies, you will have invested all these resources (both time and money) for nothing.
Server-side tracking requires a certain level of expertise and is not as easy as traditional tracking. You will need a bit of engineering (which means web developers). Google Tag Manager, Adobe Launch, Facebook Conversion API and Segment offer their versions of server-side tracking. All of them have specific ways of implementing server-side tracking. I would call Google Tag Manager Server-Side and Adobe Launch Server-Side hybrid versions of server-side tracking since they still rely on client-side technologies.
I hope this post has helped you get a better understanding of the complex concept of server-side tracking. If you have any questions, feel free to contact us.