How to Set Up Server-Side Tagging and Get Your Server Tag

You already decided to go server-side. Good. Now you are staring at Google Tag Manager wondering where the actual “server tag” is and why nobody explains the steps in plain language.

I run a UTM and link tracking tool, so I sit with teams making this move every week. Most of them get the concept fine. Where they stall is the setup: which container to create, how to stand up the tagging server, and how to get the server URL that GA4 needs. This guide is that walkthrough.

If you still want the background on why teams move tracking to the server, I wrote the what and why of server-side tagging separately. This piece skips the theory. Here you learn how to set up server-side tagging end to end, and how to get a server tag for your server that actually works.

What You Need Before You Start

You need five things in place before the first click. Skip any one and the setup breaks halfway through.

• A GA4 property with your Measurement ID (starts with G-). This is your destination.
• A GTM web container already running on your site. Server-side does not replace it. It sits behind it.
• A GTM account with permission to create a new container. You will make a second, server-type container.
• A domain you control, so you can point a subdomain like metrics.yourbrand.com at the server. First-party is the whole point.
• A hosting path: either a Google Cloud billing account, or a managed host like Stape if you would rather not touch cloud infrastructure.

One honest limitation here. If you do not own DNS for your domain, stop now. The custom subdomain is what makes server-side tagging resist Safari’s cookie caps and ad blockers. Without it, you are paying for a server that gives you little the browser did not.

What Is a Server Tag (and the Tagging Server URL)?

A server tag is a tag that fires inside your server container instead of the visitor’s browser. The thing most people mean when they say “get your server tag” is the tagging server URL: the address of your server container that GA4 and your web container send data to. In GTM settings it is called the server container URL, and in code it becomes the transport_url.

So there are really two pieces. There is the server container itself, reachable at a URL you own. And there is the GA4 tag configured inside it that forwards events onward. You get the URL when you provision the server. You create the GA4 tag inside the container after.

Keep the terms straight and the rest of this is simple. The “server tag” you are hunting for is your container URL plus a GA4 client and tag living behind it. Everything below builds those two pieces.

The limitation worth stating early: a server tag forwards data, it does not clean it. If the events arriving are junk, the server forwards junk faster. More on that near the end.

How to Set Up Server-Side Tagging: Step-by-Step

Here is the full setup in seven steps. I am using server-side Google Tag Manager because it is the path most teams take and the one Google documents. Do these in order.

1. Create a server container. In Google Tag Manager, click your account, then create a new container. Choose the container type “Server” (not Web). Name it something clear like “yourbrand – server”. This is separate from your existing web container.

1. Provision the tagging server. GTM will offer two options: “Automatically provision tagging server” (spins up Google Cloud infrastructure for you) or “Manually provision tagging server” (you deploy it yourself on Google Cloud Run or App Engine). For most teams the automatic path on Cloud Run is the right call. Connect a Google Cloud billing account when prompted.

1. Get your server tag (the container URL). Once the server deploys, GTM shows you a default tagging server URL. It looks like https://xxxx.run.app or a similar cloud address. Copy it. This is the raw server tag. It works immediately, but you should not ship it as-is, because a .run.app address is not first-party to your site.

1. Map a first-party subdomain. Point a subdomain you own, like metrics.yourbrand.com, at the tagging server. You do this in your DNS settings and in the server provisioning config. Now your server tag lives on your own domain. This is the step that makes server-side tagging worth the money, because the endpoint is same-site with your pages.

1. Add the GA4 client in the server container. Back in the server container, GTM includes a “GA4” client by default. Confirm it is active. The client is what receives incoming requests and parses them into events the container understands.

1. Add the GA4 tag in the server container. Create a new tag of type “Google Analytics: GA4”. Point it at your Measurement ID. This is the tag that forwards parsed events to GA4. Publish the server container.

1. Point your web container at the server URL. In your GA4 configuration (in the web container or the GA4 tag settings), set the server_container_url (also shown as the transport URL) to your subdomain from step 4. Now your browser tag sends data to your server first, and the server forwards it to GA4.

Publish both containers. That is the working spine of a server-side setup.

How to Get a Server Tag for Your Server Without Google Cloud

You can get a server tag without ever opening Google Cloud by using a managed host like Stape. This is the shortcut I recommend for teams without a cloud engineer on hand.

The trade-off is straightforward. Self-hosting on Cloud Run gives you full control and can be cheaper at very high volume, but you own the provisioning, scaling, and maintenance. A managed host spins up your tagging server in minutes, hands you a first-party subdomain, and handles the infrastructure, for a monthly fee.

Here is how the two paths compare.

Factor	Self-Hosted (Google Cloud Run)	Managed (Stape)
Setup time	Hours to a day	Minutes
Cloud knowledge needed	Yes	No
Server tag URL	You provision it	Provided for you
Custom subdomain	You configure DNS + config	Guided setup
Ongoing maintenance	You handle scaling and updates	Handled for you
Cost model	Pay cloud usage directly	Flat monthly fee
Best for	Teams with dev resources	Marketers without a cloud team

With a managed host, getting your server tag looks like this: create an account, create a container, paste your GTM server container config, and the host returns a tagging server URL on a subdomain. You still create the GA4 client and tag inside GTM exactly as in the steps above. The only part that changes is who runs the box.

The honest limitation: a managed host is another vendor, another bill, and another dependency. If they have an outage, your server-side tracking pauses. For many teams that is a fair trade for skipping cloud ops. For a team that already lives in Google Cloud, self-hosting is usually cleaner.

How to Test and Verify Your Server Tag

Test before you trust a single number. A server-side setup can look published and still forward nothing. Three checks confirm it works.

First, use GTM Preview mode on the server container. Preview shows incoming requests hitting your server tag in real time. Load your site in another tab, trigger an event, and watch it appear in the server container’s debug view. If nothing shows, your web container is not pointing at the server URL. Recheck step 7.

Second, confirm the GA4 tag fires inside the server. In the same Preview view, click the incoming request and check that your GA4 tag ran and returned a success status. A request that arrives but does not forward means your GA4 tag or Measurement ID is misconfigured.

Third, check GA4 Realtime. Open Reports, then Realtime, and confirm your test event and traffic source appear. This is the end-to-end proof that data traveled browser, to server, to GA4.

One limitation to plan around: DNS changes for your subdomain can take time to propagate. If your custom URL fails right after setup but the raw .run.app URL works, wait for DNS rather than tearing the config apart.

Common Server-Side Tagging Setup Mistakes

Most failed setups come from the same handful of errors. I have watched every one of these more than once.

• Skipping the custom subdomain. Teams ship the raw .run.app URL and wonder why cookie lifespans did not improve. The first-party subdomain is not optional if resilience is the goal.
• Forgetting to set the transport URL. The server publishes fine, but the web container never points at it, so data still flows client-side only. Nothing moves to the server until step 7 is done.
• Two containers, one confusion. People edit the web container when they meant the server container, or vice versa. Name them clearly and check which one you are in.
• Assuming consent is handled. Server-side tagging does not bypass consent law. If a visitor denies tracking, you still honor that on the server. Anyone who tells you otherwise is handing you legal risk.
• Under-provisioning the server. A single tiny instance can drop events under real traffic. For production, follow Google’s guidance and run enough capacity for your peak.

Fix these and your setup is stable. Miss the consent one in particular and a working pipeline becomes a liability.

Get Clean Inputs Before You Trust the Server

Here is the part that decides whether any of this pays off. A server tag improves how reliably your data reaches GA4 and your ad platforms. It does nothing for the quality of what goes in.

Think about the order of operations. If a visitor lands on an untagged link, the browser has no campaign information to send. Your shiny server container then forwards a session with no source, no medium, no campaign. Server-side or not, it lands in unassigned traffic. The plumbing was perfect. The water was dirty.

That input is your UTM parameters. They live inside the URL, so they survive cookie blocking, ad blockers, and consent denial. A tagged link arriving at your page carries utm_source and utm_medium no matter what the browser allows the scripts to do. That is exactly the kind of durable, first-party signal a server-side stack is built to protect.

This is where clean link discipline earns its keep. Every campaign link tagged consistently means the events reaching GA4 actually describe where traffic came from. That is the job my team built linkutm to handle: enforce naming conventions so the source of truth entering your server is correct before you spend a dollar on infrastructure.

The limitation, stated plainly: linkutm does not run your server container for you. It makes sure the data your server forwards is worth forwarding. Different jobs, same goal.

Frequently Asked Questions

How do I set up server-side tagging in GTM?

Create a new “Server” type container in Google Tag Manager, provision a tagging server (automatically on Google Cloud Run or manually), copy the server container URL, map it to a subdomain you own, then add a GA4 client and GA4 tag inside the server container. Finally, set your web container’s transport URL to the subdomain so browser events route through the server first.

How do I get a server tag for my server?

Your “server tag” is really the tagging server URL. You get it when you provision the server container in GTM: after deployment, GTM displays a default URL like https://xxxx.run.app. Copy that, then map a first-party subdomain such as metrics.yourbrand.com to it so the endpoint lives on your own domain.

Do I need Google Cloud to set up server-side tagging?

No. Google Cloud Run is the default, but managed hosts like Stape stand up a tagging server for you without touching Google Cloud. You still create the GA4 client and tag inside GTM the same way. The only difference is who runs and maintains the underlying server.

What is the server container URL or transport URL?

The server container URL is the address your tagging server answers on. In your GA4 configuration it is set as the server_container_url or transport URL. Once set, the browser sends events to that URL instead of straight to Google, and your server forwards them onward. It should be a subdomain you own for first-party benefits.

Does server-side tagging work without a custom domain?

It runs, but you lose most of the benefit. The raw cloud URL is not first-party to your site, so it does not escape Safari’s cookie caps or ad-blocker filtering the way a subdomain on your own domain does. Mapping a custom subdomain is the step that makes server-side tagging worth the cost.

Do I still need UTM parameters with server-side tagging?

Yes, more than ever. Server-side tagging improves delivery, not input quality. UTM parameters live in the URL and survive blocking and consent denial, so they remain the source of truth for where a visit came from. An untagged link still lands as unassigned traffic no matter how good your server setup is.

Start With Clean Data, Then Build the Server

Setting up server-side tagging comes down to a clear sequence: create a server container, provision the tagging server, get your server tag URL, map a subdomain, add the GA4 client and tag, and point your web container at it. Test in Preview and GA4 Realtime before you trust the numbers.

But remember the order that actually matters. Clean inputs first, infrastructure second. A server tag that forwards untagged links is expensive plumbing for the same leaks you started with.

The fastest first step costs nothing. Make sure every campaign link is tagged correctly before you invest in server infrastructure. Run your URLs through the UTM builder so the data arriving at your server is clean from the start.