Server-Side GTM: Build It In-House or Hire It Out?

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London who sets up GA4 and server-side tracking for agency and in-house clients most weeks.

Most guides to server-side GTM stop at the setup and skip the question that actually decides the project: who is going to run this thing once it is live? This post covers what a server-side Google Tag Manager (GTM) container involves, where you can host one, what it really costs, and how to choose between building it in-house and hiring it out. We build and run these setups for clients most weeks, so this is the decision framework we use. If you want the step-by-step setup itself, our GA4 server-side tracking walkthrough has the container-by-container instructions; this one is about the decision around them.

What is server-side GTM?

Server-side GTM is a second Google Tag Manager container that runs on a tagging server you host, usually on a subdomain of your own site such as data.yoursite.com, instead of in the visitor’s browser. The browser sends one request to that server, and the server decides what to forward on to GA4, Google Ads, Meta and every other destination. You move the tag logic off the visitor’s device and onto infrastructure you own.

The point of doing that is first-party data collection. Safari’s Intelligent Tracking Prevention caps cookies set by client-side script to seven days, so a returning visitor can look brand new after a fortnight. A cookie set by your own server, on your own subdomain, sits outside that cap, and ad blockers that match vendor domains have a harder time spotting a request to your domain. That recovered signal is the whole reason server-side exists. The mechanics of setting it up are covered in the setup walkthrough; what matters here is that this recovered signal comes with a server you now have to run.

What running a server-side GTM container actually involves

The build is the small part. A tagging server, a subdomain and a GA4 client take a focused weekend to stand up and verify. The work that decides the project is what happens after launch, and it looks like this:

• Keeping the host current. The server runs software that needs patching, and the container image needs updating when Google ships changes to the server-side tagging runtime.
• Watching for silent failure. When a client-side tag breaks, someone usually notices a number drop. When a tagging server falls over, the data just stops arriving, with no error in anyone’s face. You need monitoring that tells you before the monthly report does.
• Managing consent correctly. Consent Mode runs in the browser, before any request reaches your server, so a server-side setup does not sidestep UK or EU consent rules. Treat the server as a new destination for already-consented data.
• Deduplicating across destinations. Once Meta’s Conversions API sits on the server alongside the browser Pixel, both send each purchase, and they must share an event_id or Meta double-counts. We cover that failure in why a Meta CAPI setup under-reports.

None of this is hard for someone who owns it. All of it is a problem when nobody does.

Where can you host a server-side GTM container?

There are three routes, and they differ mainly in who carries the running of the server, not in what data reaches GA4. The events that arrive are the same; the question is where the operational burden lands.

Route	What you run	What it costs	Best fit
Self-host on Google Cloud	The server, scaling, patching and monitoring, all yourself	The Google Cloud compute bill, no licence fee	Teams with engineering or DevOps capacity to own infrastructure
Managed host (Stape)	Nothing; the host provisions and runs the server	A monthly fee per container	Teams who want server-side without running infrastructure
Agency or partner run	Nothing; a partner builds it and keeps it running	A project fee or a retainer	Teams with no one internally to own the upkeep

The self-hosted route gives the most control and the lowest hosting bill at scale, but it hands your team a small production service to keep alive. The managed route, with a host like Stape, trades a monthly fee for not touching the infrastructure. The partner route puts both the build and the maintenance on someone whose job it is. Pick the one that matches the capacity you actually have, not the one with the lowest sticker price.

What does server-side GTM cost?

Server-side GTM has two cost lines, and teams usually price only the first one. The visible cost is hosting: a managed host charges a monthly fee, and a self-hosted Google Cloud setup runs a compute bill that stays modest for most traffic. Neither blocks a rollout on its own.

The cost that gets missed is the time to run it. A tagging server is production infrastructure, so it needs someone to keep it patched, watch it, and fix it when data stops. On a small in-house team that person is often the same one shipping everything else, and the tagging server quietly slides to the bottom of the list until it breaks. Price the upkeep, not the hosting alone, because the upkeep is what makes the build-versus-hire call for you.

Should you build server-side GTM in-house or hire it out?

Build it in-house when you have someone who can own a small piece of production infrastructure and will still own it in six months. That person needs enough comfort with servers, DNS and monitoring to notice a silent failure and fix it, plus the time to do so alongside their other work. If that describes your team, self-hosting on Google Cloud gives you the most control at the lowest hosting cost, and the setup is genuinely a weekend of focused work.

Hire it out when no one can own the upkeep, which is the more common situation than the build guides admit. An unmaintained tagging server does not announce its problems; it drops data until a report looks wrong weeks later, by which point the gap is unrecoverable. Hiring the work out, either to a managed host for the infrastructure or to a partner for the whole thing, buys you the one thing a weekend of setup cannot: someone accountable for the server still working next quarter. The honest test is not whether your team can build it. It is whether your team will run it.

One rule holds either way: get client-side tracking right first. Server-side GTM recovers signal that browsers drop; it does nothing for a duplicate event or a conversion that stopped firing after a checkout change. Moving a broken setup to a server just adds a layer between you and the fault. If your GA4 numbers already look off, start with why a cookie banner can cut GA4 sessions before you re-platform.

When does a server-side tracking agency make sense?

A server-side tracking partner makes sense when the recovered signal is worth real money and no one in-house can own the server that recovers it. That is the overlap where hiring pays: meaningful ad spend on Meta or Google Ads, or an iOS-heavy audience, on one side, and no spare engineering capacity on the other. The partner builds the container, maps the subdomain, and wires up deduplication across destinations, then sets it to run on a managed host so no one in-house has to babysit the infrastructure.

For agencies, there is a second case. If you sell measurement to your own clients but do not want to build and staff a data team for each of them, Dolphin works as a white-label analytics partner so you can offer server-side tagging under your own name. We set up, audit and fix GA4 and GTM tracking for agency and in-house clients most weeks, and the checks we run before trusting any setup sit on the tracking pillar.

Deciding your next step on server-side GTM

Start with what is actually firing on your site before you commit to a server. You can run a free one-click scan with Sonar, which reports the tags, pixels and consent setup it can prove from the outside, so you know your client-side baseline first. If you would rather talk through whether server-side is worth it for your traffic and your team, use the tell us what’s broken, or book a call. And if you already know you need server-side GTM but not who will run it, the tracking pillar is where we set it up, audit it, and get it running on a managed host, so the upkeep sits with the host rather than your team.