Server-Side Tagging in Google Tag Manager: What It Changes

This guide is based on Google's developer documentation for server-side Tag Manager: Server-side tagging, An introduction to server-side tagging, Set up server-side tagging with Cloud Run, Custom domain configuration and Implement consent mode with server-side Tag Manager, plus the others linked below, as they read in November 2026. Containers, tags, triggers and Preview are explained in our Google Tag Manager guide, and serving Google's scripts from your own domain is in our Google tag gateway guide; this page covers only the server container.

What changes with a server container

In a normal set-up, the Tag Manager web container runs in the visitor's browser and each tag sends its own request to its vendor: one to Google Analytics, one to Google Ads, one to each other platform. A server container sits in between. Google's introduction puts it this way: a server container "doesn't run in the user's browser or on their phone. Instead, it runs on a server that you control." The browser sends one stream of data to your tagging server, and the server decides what goes on to which vendor.

Google says the server runs in your own Google Cloud project or another environment you choose, and "only you have access to the data in the server until you choose to send it elsewhere." One caveat from the manual setup guide: the owner of the server environment, whether a cloud provider or your own hosting, may have access to your data, so their terms apply.

Server containers use the same tag, trigger and variable model as web containers. What is new is the client, covered below, and the fact that the container needs a server you pay for and look after.

The reasons Google gives, and the limits

Google's server-side tagging fundamentals course gives three reasons to use it:

• Privacy controls. In the server container you can "validate, parse, anonymize, or even block" requests before they reach marketing partners. Vendors see a request from your server, not from the visitor's browser, so details such as the IP address and other HTTP headers can be hidden from them.
• Performance. Instead of the browser sending several near-identical requests to different vendors, it sends one stream to your server, and fewer libraries need to load in the page.
• Data quality. On your own domain the server can set cookies with the HttpOnly flag, which Google describes as "more durable and more secure", and it can add data the browser should never see, such as API secrets or profit margins.

What it does not do: it does not replace your cookie banner or consent mode (see consent below), and it does not remove the web container. The page still loads a Google tag or a Tag Manager web container to build the requests. It is also not the same thing as Google tag gateway: the gateway serves Google's scripts from your domain, while a server container receives the data and processes it before it is passed on. The two can be combined (see your own domain below).

Clients, tags and transformations

A client is the adapter between the visitor's device and the container. Google's introduction says the client "receives measurement data from a device, transforms that data into one or more events, routes data to be processed in the container, and packages up the results to send back to the requester." Each incoming request is offered to the clients in priority order, highest first; the first client that recognises the request claims it, and the others do not run. Per the introduction, a new server container comes with two clients: Google Analytics and Measurement Protocol.

After a client turns a request into events, triggers check each event and fire tags, which send the data to a vendor. The Google Analytics: GA4 tag in a server container takes its settings from the event the GA4 client produced, so in Google's example you create the tag and leave its fields at their defaults. To use an extra parameter in other tags, Send data to server-side Tag Manager says to create an Event Data variable with the parameter name as its key path.

Transformations control which event parameters tags can see. Google's transformations page lists three rule types: allow only named parameters, add or edit parameters, and exclude parameters. A rule can apply to all tags, to a tag type or to selected tags, and can have matching conditions. Google warns that an Allow parameters rule removes every parameter you did not list, "even values required by Google tags", so check what your tags use first.

Where the tagging server runs

You create a server container in Tag Manager (Create Container, target platform Server), then deploy a tagging server. The overview gives two routes:

• Automatic provisioning, which Google recommends: Tag Manager creates a new Google Cloud project with the container on Cloud Run. Google says this default deployment "restricts the amount of resources available and is recommended for testing limited traffic volumes only." The fundamentals course adds that it is created in the us-central1 region; changing region means creating a new service. The Cloud Run guide lists what you need for it: a Google Cloud account, a billing account, and the Project Creator and Billing Account User roles.
• Manual provisioning on other infrastructure. The tagging server is "a Node.js server inside of a Docker image", and you run two parts from the same image: a preview server for Tag Manager's Preview mode, and the server-side tagging cluster that handles live requests.

Once the server is live you add its URL in Tag Manager under Admin, Container Settings. Before live traffic, Google recommends adding instances for redundancy. Its pages give slightly different numbers: the overview says "a minimum of 3 instances per container", while the Cloud Run guide recommends at least 2 and says autoscaling from 2 to 10 servers should handle about 35 to 350 requests per second, depending on the number of tags and what they do.

What Google says it costs

Google publishes rough figures. The table quotes them; your own bill depends on your traffic, so treat them as Google's estimates, not a quote.

Logging is the cost people miss. The Cloud Run guide says every request is logged by default, and above roughly a million requests a month that "may incur significant logging charges"; it shows how to exclude request logs in the Logs Router. Google also suggests a billing alert. One warning from the planning chapter: if you set a budget to disable billing, every service on that billing account stops when the threshold is reached, including your tagging server.

Putting the server on your own domain

A new tagging server gets a default address on run.app. Google "strongly" recommends pointing a subdomain of your website at it, so the server can read and write HttpOnly cookies that scripts on the page cannot see. The custom domain page compares the options for a site on www.example.com:

The planning chapter notes that Cloud Run's built-in domain mapping has limits depending on the region, and that "in many cases, using a load balancer is the best option, even though it adds cost and complexity to your setup." Once the domain is in place, Google's first-party script serving page shows how to load scripts such as gtm.js through a CDN or the tagging server as well.

Sending data from your site

Google recommends sending web data with the Google Analytics tag or the Google tag. With gtag.js, the introduction's example adds one setting, server_container_url, pointing at your server's address; in a Tag Manager web container, Google's course adds a server_container_url configuration setting to the Google tag. The send-data page lists the transport methods the tag may use (image pixel, Fetch, XHR and a service worker in an iframe from your server domain) and says your Content Security Policy must allow the server URL in img-src, connect-src and frame-src, and X-Frame-Options must not block that iframe.

Apps and server-to-server sources can send events to the container with the Measurement Protocol, which the built-in client accepts. Our GA4 Measurement Protocol guide covers that API.

Google's course on configuring the Analytics data stream advises against switching your live tracking straight away. Keep the current set-up, send server-side hits to a new GA4 property, and copy tags across one by one; only move fully once the server-side data matches. It also notes that sending some data directly and some through the server "is very common".

Consent mode with a server container

Consent works through the web container. Per Google's consent mode page, the banner passes the visitor's choices to the Google tag, the tag adds consent parameters to each request, and Google's tags in the server container adjust what they send. Google's key point: "you only need to set up consent mode in the web container." Server containers support basic and advanced consent mode; with advanced mode and region-specific settings, the tagging server must also be set up for regions.

For Google Ads conversion tags in the server container you also need a Conversion Linker tag there. When ad_storage is denied, Google Ads cookies are not written or read. A server container gives you more control over data, but whether you may collect it is still decided by the visitor's consent and the law that applies to you; our cookie consent guide covers the banner side.

Testing and busy periods

• Preview. Click Preview in the server container; if the preview page loads, the Cloud Run guide says the set-up is correct. Google's introduction adds that requests and events appear on the left as you browse your site.
• Health check. Open your server container URL with /healthy on the end; a working server returns ok.
• Peak events. Google's guide to traffic spikes says to raise minimum instances before big sales, check max-instance limits and quotas, and update the Docker image beforehand. It warns that without enough servers "hits will be lost and data won't be retrievable." For Black Friday and Cyber Monday it suggests preparing from one week before Thanksgiving until two days after Cyber Monday.
• Updates. The tagging server image needs updating over time; both setup guides cover keeping its version current.

Before you switch

This checklist is our suggestion, built from the points above:

• Is there a reason (data control, page speed, cookie durability) worth a monthly server bill and someone to maintain it? Google's planning chapter asks whether you have Cloud Run skills in-house.
• Plan the domain first: subdomain or same-origin path, and who changes DNS.
• Upgrade from the test deployment to at least the instance count Google recommends before live traffic.
• Turn off request logging you do not need and set a billing alert.
• Run server-side hits into a separate GA4 property until the numbers match.
• Check that consent mode is set up in the web container and that tags respect it.

Frequently asked questions

What is server-side tagging in Google Tag Manager?

A server container that runs on a server you control instead of in the visitor's browser. The page sends one stream of data to it, and the container's clients, triggers and tags decide what to send on to Google Analytics, Google Ads and other vendors.

How much does server-side Tag Manager cost?

Google says the default test deployment is free in most cases. For live traffic its pages estimate about $30 to $50 per server per month on Cloud Run, with at least 2 or 3 servers recommended, plus network and logging costs.

Do I still need a web container?

Yes. The page still needs a Google tag or a Tag Manager web container to build the requests and send them to the server container, and consent mode is set up in the web container.

Why put the tagging server on my own subdomain?

On the default run.app address the server runs in a third-party context and can only use JavaScript cookies. On your subdomain or a path of your site it can set HttpOnly cookies, which Google says are more durable and secure.

Is server-side tagging the same as Google tag gateway?

No. Tag gateway serves Google's scripts and measurement through your own domain; a server container receives the data and processes it before passing it on. They can be used together: Google documents serving its scripts through the tagging server or a CDN.

Tracking is only useful when the site behind it works. See our website development and website maintenance services and all our services, or email [email protected].