What is server-side consent?

Server-side tracking consent means the choice a visitor makes in your cookie banner travels with their data to a server you control. Google's tags on that server then adjust what they pass on to match what the visitor agreed to. The choice itself still comes from your banner: your server only follows the answer.

How server-side tracking differs from tracking in the browser

Tracking on a website is done with tags. A tag is a small piece of code that runs in the visitor's browser and sends data to a tool such as Google Analytics or an ad platform. This is client-side tracking. Each tool gets its own requests straight from the browser, and some tags, such as the one for Google Analytics, store cookies on the visitor's device.

With server-side tracking, the browser sends one request per event, such as a page view or a click, to a server container instead. That container doesn't run on the visitor's device. It sits on a server you control, and it sends the data on to each tool. In Google Tag Manager, the part in the browser is the web container and the part on your server is the server container. Because the data reaches your server first, you decide what each tool receives.

How does server-side consent work?

Server-side consent works by sending the visitor's choice along with their data, so your server knows what it may pass on. It starts in the browser. Your consent banner records whether the visitor accepts analytics or advertising cookies and hands that choice to the Google tag, a single tag on your website that sends data to Google products such as Google Analytics and Google Ads. The Google tag adds the choice to each request it sends to your server container. There, Google's tags read it and adjust which data they send to Google Analytics or Google Ads, and how much of it.

If your server container also sends data to tools outside Google, such as Meta, check whether each of those tags reads the consent signal too. Where one doesn't, ask your developer to set it to run only after the visitor has agreed. Otherwise a refusal could still reach that tool.

Google calls this way of passing on the visitor's choice consent mode. What happens when a visitor says no depends on how you set it up. In the basic set-up, Google's tags don't load until the visitor agrees, so no analytics cookies are set or read, in the browser or on the server. In the advanced set-up, the tags load on every page and adapt to the visitor's choice. When a visitor declines analytics cookies, Google Analytics still gets measurements, but without analytics cookies on their device and without third-party cookies, the cookies that belong to another company's domain rather than yours.

If you're not sure the advanced set-up fits what your banner and cookie policy tell visitors, start with the basic one. Google's tags then simply wait for a yes.

You set up consent mode once, in the web container. From then on, the server container follows the consent signal that arrives with each request. You don't need a separate consent server for this. Your server container does the job.

Do you still need a cookie banner with server-side tracking?

Yes. Consent mode doesn't provide a banner of its own. It passes on the answer your banner collects, so without a banner your server has no choice to follow.

In the UK, cookies fall under the Privacy and Electronic Communications Regulations (PECR), which set the rule on storing or reading information on a visitor's device. The personal data you collect with server-side tracking or without it falls under the UK GDPR and the Data Protection Act 2018. These rules decide whether your website needs a cookie banner, and which of your cookies it has to ask about.

Moving your tags to a server doesn't take the cookies off the visitor's device. Nor does it change the visitor's answer: in our view, a refusal still counts wherever the data goes next. We'd treat server-side tracking as a way to control what you share, not as a way around a visitor who says no.

What server-side consent gives you

Done properly, a server container helps you keep the promise your banner makes:

• You can check and change data in the server container before it goes to analytics and ad tools. Each tool can then get only the data that's necessary.
• You can remove personal information from the data before it reaches a marketing partner, so less of it leaves your hands.
• Your pages get lighter for visitors. With fewer requests to send, the browser has less code to work through.
• Your cookies can stay on your own domain. When the server container runs on your own domain, your website's cookies stay within that domain, and other companies can't read them as third-party cookies.

What you need to set up server-side consent

Every set-up starts with a consent banner that works with Google's consent mode. A consent management platform such as Termly shows the banner and supports version 2 of Google's consent mode. It also writes the cookie policy and privacy policy your banner points to.

To move your tags to the server with GTM server-side tagging, you need four more things:

• A web container and a server container. Both come from Google Tag Manager: the web container holds the Google tag in the browser, and the server container receives its requests.
• A Google Analytics client in the server container. This part of the container receives the data and the consent signal from your website, and a new server container comes with one already installed.
• Admin access to the Google tools you connect. You need it for Google Analytics, Google Ads or any other Google product you set up.
• A server for the container. You can use Google's Cloud Run service, or install the container yourself with Docker on another server, such as our virtual private server (VPS), which is unmanaged: you set up, secure and update it yourself.

If nobody on your team looks after servers, Cloud Run is the simpler choice, because Google sets the server up for you. A VPS suits you if you already run a server and are happy to keep it secure and up to date. Our guide shows how to install Docker on a VPS.

Set up the banner first. A developer then connects the Google tag on your website to the server container and sets up consent mode in the web container, following Google's guide to consent mode with server-side tagging. Before it goes live, ask them to test it as a visitor who declines, and to check that the server container passes on no more than that visitor agreed to.

Termly scans your website for cookies, creates your cookie banner, cookie policy and privacy policy, and keeps them up to date.

What server-side tagging costs

The cost comes from the server, its upkeep and the time to set it up. On Cloud Run you need a Google Cloud billing account, and you pay for the server resources the container uses. Cloud Run scales with the load on your website. To estimate the monthly cost, Google points you to its pricing calculator. Google recommends running at least two servers to reduce the risk of losing data if a server goes down, though you can run fewer. On a VPS, you pay for the VPS plan instead.

Once it's live, Google asks you to keep the version of your server container up to date. Unless you're comfortable setting up and looking after a server container yourself, budget for a developer's time. A consent banner with consent mode in the browser needs none of this.

Which should you choose: server-side consent or a consent banner alone?

Our advice: for most small business websites, start with a consent banner and consent mode. Server-side consent is worth it once you send data to several analytics and ad tools and want to decide exactly what each one receives. Until someone on your team, or a developer you work with, can keep the server container up to date, wait.

Whichever you choose, add Termly to your website to scan your cookies and show a banner that passes each visitor's choice on to Google's tags, today or as the first part of a server-side set-up later.