Server-side tagging: moved, not gone

The list of third-party requests gets short, the cookie inventory manageable, and where the network tab used to show a handful of foreign domains there is now a single one: a subdomain of the website itself. On paper that looks like a tidy setup.

What actually changed is mostly the route the data takes. Server-side tagging moves the forwarding to Google, Meta and other services out of the browser and onto a server you run yourself. The operation that consent hangs on stays exactly where it was.

In the classic setup your page loads scripts from googletagmanager.com, google-analytics.com, connect.facebook.net and other hosts. Each of those scripts then talks directly to its vendor's server.

Server-side tagging adds a stop in between: a second container that does not run in the browser but on a server instance – with Google Tag Manager typically in a cloud environment, reachable under an address of your own such as metrics.example.com or under a path on your main domain. The browser now sends its events only there. The server then decides what it forwards to which platform.

One thing matters for understanding this: in most setups the browser container does not disappear. It keeps collecting events, keeps reading values off the page and keeps sending them away – just to a different address.

Anyone being sold server-side tagging as a privacy measure should know this list. It holds the operations the consent rule addresses – and none of them moves to the server:

Article 5(3) of the ePrivacy Directive, and Germany's § 25 TDDDG implementing it, tie consent to storing information on the user's terminal equipment and to gaining access to information already stored there. Both happen in the browser, no matter which address the result is sent to. An intermediate server of your own changes nothing about that operation – it is the recipient, not the place of access.

The European Data Protection Board's Guidelines 2/2023 on the technical scope of Article 5(3), final version adopted in October 2024, describe this technology-neutral reading at length and cover cases where no file is stored at all. On IP addresses the Board draws a fine line: access is covered where the information originates from the user's terminal equipment. How that applies to a specific setup is a question for your privacy counsel – what is technically observable at first is only that the request happens.

In the Google setups the consent state therefore travels along as a parameter: with Consent Mode active, tags append values such as gcs and gcd to their requests, and the server container reads them to decide what it forwards. That check is real and it works – but it happens after the data has left the device.

This is where server-side tagging genuinely changes something technically. A cookie written by JavaScript through document.cookie is a different thing from a cookie a server sends in the Set-Cookie header of its response. The Google Tag Manager server container uses a cookie of its own for this, named FPID, set by the server and flagged HttpOnly: no script in the browser can read it. For purposes that do need script access – recognising a visitor across two domains, for instance – Google additionally writes an FPLC cookie, a short-lived matching value lasting a few hours.

Arguments about lifetime often rest on an outdated rule of thumb. The claim that Safari caps JavaScript cookies at seven days across the board was correct until 2022; since then the expiry ceiling is gone. Instead WebKit treats script-writable storage uniformly: it gets deleted when a website sees no interaction across seven days of active browser use.

Server-set cookies fall outside that rule – with one exception that ties the advantage to a condition. Since Safari 16.4 in April 2023 the browser checks whether the address setting the cookie belongs to the site being visited. If the tagging server resolves to an IP address whose first half does not match the website's IP address, Safari reads this as a disguised third party and limits the cookie to seven days – whatever expiry the Set-Cookie header names. Durability therefore hangs on an infrastructure detail, not on server-side tagging as such.

For an audit the setup is inconvenient but not opaque. It stays recognisable because the browser still sends requests, and the paths of those requests are dictated by the software, not by the domain:

Alongside this, Google has built out a second route that needs no container of your own. With Google tag gateway for advertisers the Google tag is served through your own infrastructure – via a CDN, a load balancer or your own web server, offered with Cloudflare, Akamai, Fastly and Google Cloud among others. The Google Cloud variant has been generally available since June 2026, after a beta that started in January.

From an audit perspective this sharpens the same effect: script and measurement requests run under a path on your own domain, and there is no external domain left for a filter or a blocklist to catch. What gets measured and forwarded does not change. It is a question of delivery, not of data processing.

The testing model stays the same: look once before any interaction with the banner, once after rejecting, once after accepting. What shifts is only the question – from “which foreign domains get contacted” to “what does the browser send to my own address, and what does that address do with it”.

The first half is still measurable: requests before consent, identifiers written, cookies set – all visible in the browser. The second half is no longer measurable but a matter of documentation. Which platforms the server container serves, which fields it passes on and which it drops sits in its configuration and in the contracts behind it, not in the network tab. Running server-side tagging means taking on a piece of evidence work the vendor used to handle.