What is server side consent?

Q: What is server-side tracking?

If you want to track and collect passive data about a visitor on your website, you can use one of two methods: a client-side setup or a server-side setup.

Q: So, does the deprecation of the third-party cookie not have anything to do with it?

It is one of several factors that can impact a company’s wish to move things server-side since the third-party cookie deprecation affects your ability to work with ads-retargeting.

Blog

Lars Krarup Olesen

22/04/2024

Browser restrictions and data protection regulations beg the question: What is server-side consent, and how do you set it up?

To understand server-side consent, let’s first clarify what server-side tracking is, how it differs from client-side tracking, and why it is gaining traction today. Let’s begin with the latter.

Defining some key concepts

Server-side tracking: When you collect user data on the server.
Server-side tagging: When you implement tracking tags on the server instead of embedding scripts directly in the HTML code of your website. It is easier to do server-side tagging with a tag manager.
Server-side consent: Ensuring user consent is respected when tracking is controlled from the server.
Server-side hybrid setup: Combining server-side data collection with cookies set on each user’s browser (on the client).

Why is server-side tracking a thing now?

If server-side tracking was a stock one could trade, it would probably be a sound long-term investment because of 3 key forces impacting the World Wide Web and the online market we as digital marketers depend on:

Advanced browser restrictions.
Broad adoption of ad blockers.
Strong data protection regulations.

These variables or forces can make it challenging to work with web analytics, retargeting, etc., from the client side—the opposite of the server side.

In addition, tracking things from the server side is considered more secure and controllable. So why is that?

What is server-side tracking?

If you want to track and collect passive* data about a visitor on your website, you can use one of two methods: a client-side setup or a server-side setup.

*Passive data is information automatically collected about users without their active input, such as browsing behavior and device details.

Client-side tracking has been the most common method to track your visitors. It means that data is transferred directly from your visitors’s client (a.k.a. web browser) to the endpoint, meaning different vendors you have allowed to process visitor data. You know, by implementing tags for analytics or other services on your website. Other services could be Instagram, Facebook, Hubspot, etcetera.

Server-side tracking, on the other hand, has an extra layer (a server) between the endpoint services you want to use for data processing and the website your visitor is on. Endpoint, as stated above, refers to the services or products you use to process data, such as Google Analytics.

As a website owner and digital marketer, this extra layer gives you a way to better control what data is transferred over to the services or vendors you use, such as web analytics tools like Google Analytics 4 or Piwik PRO. A server-side setup can sometimes be considered a more reliable method of collecting data because it is not as affected by ad blockers or browser restrictions. But it depends on what kind of server-side setup one has.

Are there different ways of doing server-side tracking?

Server-side tracking has been with us since the birth of the World Wide Web. In the early 1990s, for example, website analytics meant you recorded visitor hits on so-called log files on the server. Another early server-side tracking method is gathering information about users within apps or server backends using APIs or dedicated server-side tracking libraries.

The latter method is still used but it is complex and requires significant development resources.

In the last few years, we have had access to more convenient ways of going server-side. One of the most accepted methods is using Google Tag Manager, which can handle both client-side and server-side tracking. In a hybrid setup, GTM is implemented on the client side, allowing for initial client-side data collection followed by server-side data processing.

This hybrid solution is well-established and facilitates integration with your Consent Management Platform (CMP). This integration ensures that consent signals from the cookie banner can effectively communicate with the server-side setup.

While some server-side tracking setups enable you to avoid ad blockers and browser restrictions, they do not exempt you from ensuring you have legal grounds for tracking and collecting personal data from your visitors and users. Hence, you are obliged to have a CMP, which can transmit consent signals in a server-side setup.

Okay, so there are different ways of doing server-side tracking, with hybrid being a common practice. How, then, do we ensure we collect consent in a hybrid-server-side setup?

How do I collect consent server-side?

First, note that a hybrid server-side solution still involves cookies being set on the client, meaning in the visitors’ browsers. The cookies are, however, not set from scripts you would otherwise have inserted into the source code of your website but from the server your website is hosted on, thus giving you a more controlled way of setting cookies and collecting data.

But can this really be defined as server-side consent?

It can be defined as collecting hybrid client-server consent. Cookies are still stored on the client or browser, but they are stored using server-side techniques.

The most manageable and easy way to do this is using a tag manager, such as Google Tag Manager (GTM). But instead of setting up the tag manager container on your web, you would set it up on the server so that it could do its magic, a.k.a. handle server-side tagging, from the server.

Collecting server-side consent with Google Consent Mode v2

If you have Google Consent Mode v2 installed through your Google Tag Manager (GTM), the process of ensuring that both you and your server-side setup respect users’ consent signals becomes very easy.

Why?

Because the consent signals are automatically sent to your server from the Consent Management Platform (CMP), such as Cookie Information. The CMP can do this by leveraging the Google Consent Mode v2 API integrated into your Cookie Information CMP.

Pretty neat.

Please note that getting Google Consent Mode v2 is mandatory if you want to get the most out of Google Ads and Analytics. If you still need to implement it, you can get it by signing up here.

If you want to learn how this is done, please look at this video, where Lars Friis from MCB walks you through step-by-step how to set up hybrid server-side consent by leveraging your Cookie Information CMP with Consent Mode v2.

But what if you want to avoid using Google Consent Mode v2?

Collecting server-side consent with Google Tag Manager only

If you do not need to or want to use Google Consent Mode v2, you can still use your Google Tag Manager to ensure you collect consent and send consent signals to/via your server-side setup.

Then, you create a variable in Google Tag Manager where you ask your Cookie Information-CMP if it has permission to set cookies for the different categories—i.e., marketing cookies, functional cookies, and statistical cookies.

In both cases (with or without CMv2), when a user consents or revokes permissions for cookies, this status is captured by the GTM variables, which then adjusts the behavior of tags accordingly, ensuring that only the cookies the user has consented to are put into action—enabling you to respect each of your visitor’s preferences.

The principle is the same if you use a tag manager from a vendor other than Google.

Should you implement a server-side solution?

Whether a (hybrid) server-side setup is proper for you depends on your circumstances. However, one thing that needs to be clarified is that the deprecation of the third-party cookie alone should not be the sole reason you leap.

So, does the deprecation of the third-party cookie not have anything to do with it?

It is one of several factors that can impact a company’s wish to move things server-side since the third-party cookie deprecation affects your ability to work with ads-retargeting.

Also note that Google is replacing the third-party cookie in Chrome (2024) with some new, allegedly privacy-friendly APIs. These APIs are derived from the joint venture called Privacy Sandbox. The new logic in Chrome after the deprecation of the third-party cookie can be used to state that the need to move things server-side is less necessary.

It is a general misconception that browsers blocking third-party cookies renders a need to go server-side. Rather, it is how some browsers, like, for example, Apple’s Safari, put restrictions on how long first-party cookies can be stored in the browser that motivates website owners to move things server-side.

And then there are the cost issues. Even though the costs for the server can be negligible, the time and effort required by the IT and marketing team are considerable in setting up and maintaining it in the long term.

Leverage transparency and gain trust with consent management—regardless of your tracking setup

One of argument for going server-side is the level of control it gives you. On the con-side there are the cost issues.

Regardless of whether you choose to go server-side or not, ensuring that you respect your visitor’s consent choice is easy.