Before You Go Server-Side: What You Actually Need to Get Started With Server-Side Tagging

Someone sent me a great question recently, and it’s one I’ve heard some version of from a lot of people. They’re looking at server-side tagging for their clients and want to know: is the setup different if a client only has GA4, compared to a client who already has GA4 and GTM? What about BigQuery, do I need to do anything with that first? And just generally, people are feeling overwhelmed with all the information out there and they aren’t sure where to start.

If that’s where you are, you’re in good company. Server-side tagging is one of those topics where the terminology itself is the barrier. Half the confusion isn’t about the work, it’s about which thing you’re even talking about!

Before we get into the explanations, a quick word on why people want to do this in the first place. Simo Ahava wrote a fantastic explanation of why you might want to add on server-side tracking and I recommend reading that. To summarize: yes, going server-side can recover tracking data that ad blockers would otherwise strip out, extend how long your cookies stay alive in privacy-focused browsers, pull vendor scripts out of the browser to improve page performance, and give you a place to clean up or enrich data before it goes out to each vendor. But ultimately what it does is give you control over your data and what happens to it. Whether any of that matters enough to justify the setup effort is exactly the question the rest of this post is here to help you think through.

So let’s untangle it. In this post I’ll walk through the five pieces that get conflated, answer the GA4-only vs. GA4-plus-GTM question directly, clarify where BigQuery and Google Tag Gateway fit, and help you figure out whether you’re actually ready to start.

What is server-side tagging, exactly?

Server-side tagging is a setup where measurement data from your website gets routed through a server you control before it reaches the analytics and ad platforms you’re using. Instead of the visitor’s browser sending events straight to Google, Meta, and everyone else, the browser sends events to your server first, and your server decides what goes where. Some people call this “server-side tracking,” which is the same idea with different wording.

Before we get into whether you should do it, let’s separate the five things that tend to get lumped together in these conversations.

• Google Analytics (GA4) is the destination. It’s where your data lives and where you do your reporting. Google Analytics doesn’t care how the data gets to it.
• Client-side GTM is the tag manager that runs in the visitor’s browser. It fires tags based on what’s happening on the page. This is what most people mean when they say “GTM.”
• Server-side GTM (sGTM) is a separate container type that runs on a server you control.
• Google tag gateway for advertisers (GTG) is different from sGTM. GTG is about serving Google tag scripts from your own domain, through a Content Delivery Network (CDN), load balancer, or web server, so the browser loads those scripts from you instead of from googletagmanager.com. It’s a first-party serving layer, not a full tagging server. I’ve got a dedicated breakdown of GTG vs. sGTM coming soon and I’ll update this post once that’s published.
• BigQuery is a data warehouse. It’s where Google Analytics (and other tools) can export raw event data. Structurally, BigQuery has nothing to do with server-side tagging. They’re parallel capabilities, not dependent on each other.

When you’re talking to your team or clients, typically “server-side tagging” means setting up a server-side GTM container. Google Analytics itself doesn’t “go server-side,” because GA4 is just the destination. What changes is the route your data takes to get there. And GTG changes where your scripts load from.

I want to start by being very clear on what actually changes when you “go server-side,” because that’s the piece that tends to be fuzzy in most explanations.

In a standard client-side setup, here’s the flow:

1. A visitor lands on your site.
2. Tags in client-side GTM (GA4 config, Meta pixel, Google Ads, whatever else you’re running) fire on page views and interactions.
3. Each of those tags sends a request directly to the corresponding vendor.
   1. GA4 events go to google-analytics.com.
   2. Meta events go to facebook.com.
   3. Google Ads conversions go to googleadservices.com.

The browser is talking to each vendor individually, and each vendor is receiving their data straight from the visitor’s device.

Going server-side changes where those events go. Here is the new flow:

1. A visitor lands on your site.
2. The browser sends the event to your own server-side GTM endpoint, which lives on a subdomain of your site (something like sgtm.yourwebsite.com).
3. Your server receives it, processes it however you’ve configured sGTM to process it, and then forwards the event on to GA4, Meta, Google Ads, and anywhere else it needs to go.

The result of this is that the browser isn’t talking to the vendors anymore. It’s talking to you. And you’re talking to the vendors on the browser’s behalf.

What’s still in the browser is whatever’s doing the job of capturing events and shipping them to your server. The vendor-specific tags (Meta pixel, Google Ads conversion, LinkedIn Insight, and so on) come out of the browser entirely and get recreated as tags inside your sGTM container. Your server fires them from there, over its own server-to-server connection with each vendor. So the client-side container doesn’t disappear, but it gets a lot slimmer. What used to be a dozen vendor scripts loading in the browser becomes one event stream going to your server.

Here’s what this can look like in practice. The GTM container loader script, which is the snippet that loads GTM into the browser, can also be served from your own subdomain instead of from googletagmanager.com. In a standard client-side GTM setup, the loader script looks like this:

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-ABCDEFG');</script>

In a server-side setup that’s serving the container from your own subdomain, it looks like this:

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://sst.analyticsplaybook.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-ABCDEFG');</script>

The only difference is the domain the container loads from.

Why this impacts how you start “going server-side”

Your path to implementing server-side tagging will depend on what you have set up already.

If you have GA4 plus client-side GTM: You already have a container in the browser that can capture events and send them somewhere. Moving to sGTM is a matter of stripping out the vendor-specific tags you don’t need in the browser anymore (Meta pixel, Google Ads conversion, LinkedIn Insight, and so on), adding those to your client-side container, then adding a tag to send data to your sGTM endpoint. The container doesn’t go away. It gets noticeably slimmer, and its job becomes narrower: capture events in the browser, hand them to sGTM, that’s it.

If you’re GA4-only (gtag.js): You don’t have a client-side GTM container at all. Your events are firing through Google’s gtag library, which sends data directly to Google’s endpoints. Before sGTM can do useful work for you beyond basic GA4, you’ll need a client-side event-capture layer that can send structured events to the server. The one I recommend adding is client-side GTM, for reasons I’ll get to in a second.

Could you point gtag.js itself at an sGTM endpoint and skip client-side GTM entirely? Technically yes, but I’m not going to walk through that path because it doesn’t hold up for anyone who’ll want to do more than basic GA4 over time. The moment you want Meta CAPI, Google Ads enhanced conversions, LinkedIn Insight, a TikTok conversions API call, or any custom logic, you need a proper event-capture layer in the browser that can push structured events to sGTM with the right parameters. Client-side GTM is the tool built for that job. If you skip it, you still end up having to set it up later, usually at a worse time and with more pressure.

So for a GA4-only configuration, the pre-work is: add a client-side GTM container, migrate the GA4 gtag setup into it as proper GTM tags, make sure everything’s firing cleanly, and then start the server-side work.

The work after the pre-work

Once you’re past that step, the server-side work itself looks about the same regardless of where you started. This typically involves:

1. Creating a server-side container in GTM
2. Hosting that container somewhere (more on that in the next section)
3. Configuring a custom domain so the browser can reach your server
4. Setting up a client in the server container to receive incoming events
5. Updating (or adding) a Google Tag in your client-side container to send to your sGTM endpoint
6. Then, as you recreate vendor tags on the server side (Meta CAPI, Google Ads, LinkedIn, and so on), you remove the corresponding client-side tags from the browser.

The end state is a browser that’s doing less, a server that’s doing more, and a client-side container that’s considerably slimmer than it started.

That part of the work is roughly the same whether the client-side container has been in place for three years or three weeks.

The important prep work revolves around tagging health, knowing why you want to do this, and picking where your server is going to live.

Here’s what actually matters before going server-side:

1. Your client-side tagging is clean. Server-side tagging amplifies whatever you’re already sending. If your events are messy, duplicative, or mis-fired, you’ll ship those same problems to the server side, now with more infrastructure. Audit your client-side setup first.
2. You know why you want to do this. First-party cookie support? Performance improvements? Data enrichment before it hits GA4? Consent mode and privacy reasons? Reducing ad blocker impact? Each reason changes how you’d approach the setup. “Server-side is the new best practice” isn’t a reason by itself, and it’s how you end up with infrastructure you don’t actually need.
3. You have hosting figured out. sGTM has to run somewhere, and you’ve got two main paths:
   • Managed hosting (Stape, Addingwell, and similar services): someone else runs the infrastructure, you get a dashboard. Predictable monthly pricing, typically $20 to $100+ per month depending on traffic. Managed SSL, auto-scaling, no Google Cloud console work.
   • Self-host on Google Cloud Run: this can be significantly cheaper at high volumes (roughly 3M+ monthly requests) if you have DevOps resources. Variable pricing based on traffic and processing. Full control, more setup effort, and you own the ongoing maintenance.
4. You have stakeholder buy-in. This is infrastructure work, and someone’s going to ask, “why does this cost money now when it didn’t before?” Have that answer ready before you start. Managed-hosting predictability helps this conversation, because it’s easier to defend a fixed monthly line item than a variable cloud bill.

What does server-side GTM cost?

Beyond the time it takes to set things up, you’re looking at $20 to $100+ per month, depending on traffic and whether you self-host or use a managed provider. Managed hosts like Stape start around $17 to $20 per month at the low end and scale up from there. Self-hosting on Google Cloud Run typically runs $20 to $60 per month for sites under 500K monthly sessions, climbing to $80 to $150+ at 1M+ sessions. Self-hosting gets much cheaper at very high volumes (around 3 to 5 million monthly requests and up), but that advantage mostly disappears once you factor in DevOps time.

As for hosting, we recommend Stape. We chose them because Stape works well for most of the agency clients we work with. The fixed monthly cost is easier to budget than variable Google Cloud billing. Stape’s Custom Loader handles ad blocker bypass cleanly. And when something breaks at midnight, we’re not the ones getting paged.

For clients with a technical team that wants full infrastructure control, Cloud Run is a good choice. The trade-off is setup time, ongoing maintenance, and a bill that changes with traffic. For most of the agencies and in-house teams I talk to, the “predictable monthly cost, not my problem when SSL renews” path is absolutely worth it.

Let’s bring this back to the original questions. Neither setup is inherently “easier” to take server-side, though GA4-only clients usually have more pre-work. BigQuery is unrelated, though it’s worth auditing for its own reasons. Google Tag Gateway is a separate thing that often gets confused with sGTM. And the prep work is less about infrastructure alone, more about knowing what you have and why you want to change it.

Server-side tagging is one of those topics where the hardest part is just getting the path figured out. Once you know how the process works and what path to choose, the actual decisions become much more manageable. And remember, analytics will never be perfect. You’re not trying to build a flawless setup, you’re trying to build one that works and that you can maintain over time.

This is just the start of my posts on server-side topics. I’ll be writing about hosting trade-offs across managed and self-hosted options, what migration actually looks like, what ongoing maintenance involves, and a dedicated comparison of Google Tag Gateway vs. server-side tagging. If you have a question about anything server-side, please send it in so I can cover it in a future resource.