Server-side tagging and consent: why sGTM still needs a banner

Server-side tagging does not remove the need for consent. With server-side Google Tag Manager, the visitor's browser still runs a script and sends a request with information from the device, now to a tagging server on your own subdomain instead of straight to Google or Meta. The ePrivacy rule is about that access to the device, so analytics and advertising still need consent in the EU and the UK. What server-side tagging changes is where the data goes after it leaves the browser, which can help you send less of it, as long as consent travels with every request and every tag in the server container respects it.

What is server-side tagging?

In a classic setup, the web container in the browser loads each vendor's tag, and each tag sends data directly to its vendor. With server-side tagging, Google describes a server container that runs on a server you control, such as your own Google Cloud project, and does not run in the visitor's browser. The website sends events to the container's URL, which Google recommends placing on your first-party domain (for example metrics.example.com). Inside the container, clients receive the requests and turn them into events, and server tags forward those events to Google Analytics, Google Ads or other vendors. Google's introduction notes that only you have access to the data in the server until you choose to send it elsewhere.

Why does it still need consent?

Three reasons.

1. The browser still does the collecting. A script on the page reads information (page, referrer, identifiers, device details) and makes the browser send it. Article 5(3) of the ePrivacy Directive covers storing or accessing information on the device, and the EDPB's Guidelines 2/2023 on its technical scope apply it to techniques such as tracking pixels and URL tracking, not only to cookies.
2. Cookies are still cookies. A first-party cookie set by your tagging server on your domain is stored on the visitor's device like any other. The domain changes, the rule does not.
3. The purpose is unchanged. If the server forwards the event to an advertising platform, the processing is advertising, and the GDPR requires a legal basis for it, which for tracking is consent.

Hiding a tracker behind a first-party subdomain so that ad blockers or banners do not see it does not make it lawful. If anything, it makes the consent record more important, because an authority will ask how you made sure the server forwarded nothing for visitors who refused.

How does consent reach the server container?

Through the web tag. Google's guide on consent mode with server-side Tag Manager says the banner on the website collects consent, the Google tag adds the consent state to each request it sends to the server container, and you only need to set up consent mode in the web container. Server containers support both basic and advanced consent mode.

So the order of operations from the Consent Mode guide still applies: defaults set to denied before the Google tag runs, an update on every choice, and the web tag pointed at your tagging server.

Which server tags respect consent on their own?

Google says its product tags in the server container are consent-aware:

Tags for other vendors are a different matter. A server tag that forwards events to Meta, TikTok, LinkedIn or a data warehouse fires whenever its trigger fires, unless you add a condition. In the server container, build that condition from the consent state carried by the request, or send events for those vendors only from web tags that already wait for consent.

What can server-side tagging do for privacy?

Used with consent, it can reduce what each vendor receives:

• remove or truncate IP addresses and user agents before forwarding;
• drop query parameters, e-mail addresses or IDs that should never reach a vendor;
• send fewer third-party requests from the browser, which also helps page speed;
• keep a single point where you can see and document every data flow.

Those are good reasons to adopt it. They are not reasons to skip the banner.

How do you set it up correctly?

The steps below assume a web container and a server container already exist. The Google Tag Manager platform guide covers the web container side with a consent banner.

How do you test it?

Use Tag Manager's preview mode for both containers, and the browser test from checking cookies before consent. Before any choice, the requests to your tagging server should carry the denied state, and the server container's preview should show non-Google tags not firing. After Reject all, the same. After Accept all, everything fires.

Where does a consent banner fit?

It stays exactly where it was: in the browser, before the Google tag. Cookiequiet's script sets the Consent Mode defaults to denied before any Google tag runs and updates them on every choice, so the web tag passes the right state to your server container. It also pushes a cq_consent dataLayer event with per-category flags that web triggers can use. Setup is one script tag placed before your other scripts, with Consent Mode v2 switched on in the snippet the dashboard gives you; the free plan covers one website, Starter is €3 per website per month (see pricing).