Server-side tagging and consent: how it works and what it doesn't fix

Standard Google Tag Manager (GTM) runs in the browser. When a page loads, GTM's script downloads, evaluates your container, and fires tags directly from the visitor's device. That means ad blockers can intercept it, Safari's Intelligent Tracking Prevention (ITP) caps the cookies it sets, and browser privacy extensions can identify and block individual tags.

Server-side tagging addresses those problems by moving tag execution off the device entirely. The browser sends one request to your own server; your server processes it and forwards the relevant data to Google Analytics, Google Ads, Meta, or wherever it needs to go. Ad blockers see a request to your own domain. ITP cannot cap cookies your server sets via HTTP headers the same way it caps JavaScript-set cookies.

It is a meaningful improvement for data quality. It is not a way around consent law.

How it actually works

With server-side GTM, you run a GTM container on a server - Google Cloud Run is the typical choice, though any server that can handle HTTP requests works. You configure your browser container to send events to your server container's URL (usually something like t.yourdomain.com) rather than directly to Google.

The data flow looks like this:

1. The user loads your page. Your browser container fires.
2. Instead of sending directly to GA4 or Google Ads, it sends an event to t.yourdomain.com/gtm/....
3. Your server container receives the event, applies any transformations, and forwards it to GA4, Google Ads, and any other vendors configured in the server container.

The browser sees a first-party request to your domain. Your server handles the fan-out to third parties. The practical results: better cookie resilience, lower client-side JavaScript payload, and more control over exactly what data leaves your infrastructure.

The consent question

Here is where many implementations go wrong: server-side tagging does not mean you can skip consent.

Consent requirements exist because of what happens to personal data - who receives it, what they do with it - not because of where the code runs. Moving a tracking pixel from the browser to your server does not change the fact that you are sending a user's behavioural data to a third party for advertising purposes. That still requires consent under GDPR and the ePrivacy Directive.

The correct approach is:

1. The browser's consent mechanism (your Consent Management Platform, or CMP) captures the user's choices as usual.
2. The browser container reads those choices and only fires the server-side request if consent has been granted for the relevant purpose.
3. The server container receives the request - which by this point has already been gated on consent - and forwards to vendors.

The consent gate lives in the browser container, not the server container. Some implementations skip step 2 and fire the server-side request unconditionally, planning to apply consent logic on the server. This is a mistake. The server has no reliable way to determine the user's consent state independently - it depends on what the browser sends.

Passing consent signals to the server

If you are using Google Consent Mode (GCM) with server-side GTM, the consent state needs to travel from the browser to the server container with each event. GTM's built-in Consent State variable can be included in the event payload, and the server container can use it to decide whether to forward data to individual vendors.

In practice, this means:

• Your browser container should only send events to the server when the relevant consent has been granted, or your browser container should include the consent state in every event and your server container should check it before firing each tag.
• Either approach works. The important thing is that the server container is not making assumptions about what the user agreed to.

Google's own server-side consent documentation covers the mechanics. The short version is that consent signals from GCM v2 can be forwarded in the x-gtm-additional-data header, and the server container's tags can be configured to respect them.

What server-side tagging does not fix

Ad blockers at the DNS level. Tools like Pi-hole or NextDNS block requests by domain name. If t.yourdomain.com becomes associated with tracking, it can be added to blocklists. Server-side tagging makes this harder but not impossible.

Safari's ITP applied to cookie content. Server-set cookies via HTTP headers do get better treatment from ITP than JavaScript-set ones, but ITP still classifies domains. If your tagging subdomain is identified as a tracker, restrictions still apply.

The legal basis for processing. Moving data processing to a server you control does not create a new lawful basis. If you need consent to send data to GA4 from the browser, you need consent to send it from your server too.

Analytics for non-consenting users. Some organisations implement server-side tagging hoping to recover analytics data from users who declined cookies. This does not work legally, and platforms like Google will discard data sent without valid consent signals where they can detect it.

Is it worth the effort?

For most small and medium-sized sites: probably not yet. Server-side GTM requires a server to run (ongoing cost), technical setup that goes beyond standard GTM, and ongoing maintenance. The data quality benefits are real but marginal for sites where the majority of traffic is not on Safari or not using ad blockers.

For sites with significant iOS/Safari traffic, high-value conversion tracking, or audiences that are heavy ad-blocker users - typically tech, finance, and media - the investment is more justified. The same applies if you are already dealing with the attribution gaps described in our Apple ITP guide, since server-side tagging addresses those directly.

The consent setup, however, is non-negotiable regardless of your tagging architecture. Whether your tags run in the browser or on a server, users in the EEA need to have agreed before their data moves to third parties.

Where ConsentScout fits

ConsentScout scans from the browser, so it observes what your browser-side setup does on first load: whether non-required cookies are set before consent, whether GCM signals are present, and whether a CMP is detected.

If you have moved to server-side tagging correctly - with consent gating in the browser container - a ConsentScout scan should show no pre-consent cookies from analytics or advertising vendors, because the browser container never fires those tags without consent. If you see unexpected cookies despite a server-side setup, it usually means the browser container is still firing some tags directly, or that CMP integration is incomplete.