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:
- What is server-side tracking?
- What are the benefits of server-side tracking?
- Is there a difference between cookies managed on the server side and server-side tracking?
- Does server-side tracking mitigate ITP 2?
- Should you consider migrating to server-side tracking?
Before we jump into the meat of the article, here are some quick definitions:
- Web browser: a tool/software (Chrome, Safari, Firefox), installed on your PC, that allows you to navigate the internet
- Web/browser cookie: a web browser feature that allows a website to store data for a certain period of time, such as an anonymous user ID, user preferences, etc.
- Web server: infrastructure that hosts a website (ex., adviso.ca) and serves web pages to a web browser
- Marketing/analytics pixel: a piece of code installed on a website that allows marketers to track conversion events and build audiences
- Analytics and ad servers: a set of infrastructure that allows vendors (Google, Facebook) to receive, store, and transform the data sent by their users (marketers)
Here is an simplified illustration of a website architecture:
How is server-side tracking different than client-side tracking?
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).
What are the benefits of server-side tracking?
These are the key advantages of migrating your client-side tracking implementation to the server side:
- improved accuracy due to fewer lost user events/conversions caused by page load time or ad blockers;
- increased security since the data is hidden from the web browser;
- improved web page performance given that fewer tags and pixels are loaded on your website.
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.).
Is there a difference between web cookies managed on the server side and server-side tracking?
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:
- The client side (web browser)—for example, an analytics or marketing pixel loaded into your web browser creates the cookie;
- The server side (web server)—for example, when a web page is requested, the web server creates a cookie and sends it to the web browser while returning the page. These cookies are often used to store sensitive data about your login status, website preferences, etc. Most of the time the content of these types of web cookies can’t be accessed by analytics or marketing pixels (i.e., JavaScript, for technical readers). Therefore, these cookies are considered more secure. The Safari team (at Apple) encourages the use of these specific types of cookies. When we say that cookies are managed on the server side, we’re referring to these types of cookies. This explanation has been purposely oversimplified for this blog post.
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.
Does server-side tracking mitigate ITP 2?
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.
Should you consider migrating to server-side tracking?
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:
- Do you want to improve your web page performance?
- Do you want to hide sensitive data?
- Do you want to improve data accuracy?
- Do you have easy access to a group of web developers?
- How will you handle user consent on the server side (preventing tags from running before user consent)?
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.
