What it is.
A server container uses the same tag, trigger, and variable model as the web container you already know. The difference is where tags run: your browser sends one request to your server, and the server distributes data to the destinations.
Google names three gains: better page performance because vendor scripts leave the page, more detailed control over what data goes where, and better data quality.
Setup means standing up a tagging server, usually on Cloud Run, then mapping a custom domain to it so requests come from your own hostname.
What you get.
- Vendor tags moved off the page, so fewer third-party scripts load in the browser.
- One control point for deciding which data reaches which destination.
- The same tag, trigger, and variable model as your web container.
- A first-party hostname for measurement requests.
- Preview and debug tooling for the server container.
How to set it up.
Create a server container in Tag Manager, alongside your existing web container.
Stand up the tagging server, with Cloud Run as the standard option.
Map a custom domain to the server so requests come from your own hostname.
Point your web container at the server container and send one data stream to it.
Rebuild destination tags inside the server container, one vendor at a time.
Use preview and debug to confirm each destination receives what you expect before removing the browser tag.
Use cases
Take scripts off the page
Move vendor tags to the server so fewer third-party files load.
One place to decide what leaves
Control which data reaches which vendor from a single container.
Speed up a heavy page
Cut the browser work on a template weighed down by tags.
Best for
Pages slowed by tags
Marketing tags are often the largest third-party weight on a landing page.
Tighter data control
A server container is the one place you can decide what a vendor receives.
Measurement teams losing data
Browser-side collection loses events to blockers and privacy settings.