Web Analytics · Server-Side & First-Party

Server-Side GTM & Cloud Setup

Standing the container up is the short part; running it every day is the commitment.

Standing up a server container means owning real infrastructure. We provision hosting, connect the custom domain, configure clients and routing, and hand over an environment your team can operate.

A working server-side GTM container on your domain, supported by monitoring and an operating runbook rather than a one-time tutorial.

Plan server-side setupAll Server-Side Tracking & First-Party Measurement tasks
A Zeo crew hoisting a server container onto a platform and routing a first-party pipe

Some of the 500+ brands we've worked with

See all references
  • Edenred
  • BNP Paribas Cardif
  • TransferGo
  • Jack Martin Menswear
  • Adore Mobilya
  • Bundle

How we run it

From topology decision to a runbook your team runs

We cover the infrastructure decisions that simplified server-side tagging tutorials usually leave out. Four stages move the setup from topology decisions to infrastructure your team can run day to day.

How we hold ourselves to it

  • Size the hosting to real traffic — We configure the cloud project, region, and autoscaling range around your actual traffic volume, sized to avoid both overpaying and falling over under load.
  • A subdomain that's genuinely yours — A subdomain you control points at the container, with certificates configured so every request resolves as first-party traffic on your own domain.
  • Clients that know where each request goes — GA4 traffic, GTM web-container data, and anything else arriving at the endpoint each need a configured client, and we route every one to the right tag.
  • Who can deploy, and what the endpoint accepts — We restrict deploy access to the container and lock the endpoint down to only the traffic it's actually supposed to receive.

  1. Design the topology

    We agree on hosting region, domain, expected traffic, and which flows move through the server container.

    Architecture plan

    AI assist
    Generates cloud infrastructure templates for App Engine or Cloud Run sGTM deployment.
    Human gate
    DevOps lead approves cloud provider provisioning, custom domain DNS, and budget caps.
    Owners
    Infrastructure Engineer, Cloud Contact, DNS Owner
    Illustrated figure sketching plans at a drafting table

  2. Provision infrastructure

    We set up the cloud project, container, domain, and certificates in a non-production environment first.

    Provisioned environment

    AI assist
    Drafts the provisioning checklist for the staging environment.
    Human gate
    You sign off before anything touches production traffic.
    Owners
    Infrastructure Engineer, Cloud Contact
    Illustrated figure stacking patterned building blocks

  3. Test with real traffic

    We shift a portion of traffic through the server path and confirm it reaches destinations correctly, at expected latency and cost.

    Traffic test log

    AI assist
    Flags latency or cost spikes during the traffic test.
    Human gate
    Engineering lead confirms latency and cost hold under full production traffic.
    Owners
    Infrastructure Engineer, Cloud Contact
    Illustrated figure reading an oversized measurement dial

  4. Cut over and hand off

    We move remaining traffic gradually, watch for issues, and hand you a runbook for day-to-day operation.

    Operating runbook

    AI assist
    Drafts the runbook from what we monitored during cutover.
    Human gate
    Your ops owner confirms the runbook is usable.
    Owners
    Infrastructure Engineer, GTM Admin
    One illustrated figure passing a relay baton to another

Provisioning the container is the easier half of the job

Automation generates the infrastructure templates, drafts the staging provisioning checklist, flags latency and cost spikes during the traffic test, and writes the runbook from what we watched at cutover. The gates are operational, so they belong to people: provisioning and budget caps get approved before anything is built, and nothing touches production traffic without a sign-off.

What you get

Evidence the container held up under real production traffic.

You receive production infrastructure together with the documentation needed to operate it.

  • Architecture document

    Architecture record

    What was provisioned, where, and why, domain, region, clients, and routing decisions.

    Accepted when

    Domain, region, clients, and routing are each recorded with the reason behind the choice.

    Cadence: Amended at every infrastructure change

  • QA notes

    Traffic test evidence

    What we tested during cutover and what latency, volume, and cost looked like.

    Accepted when

    Latency, volume, and cost are measured under production traffic, not a synthetic run.

    Cadence: Captured under production traffic

  • Runbook

    Operating runbook

    How to monitor the container, what to check when something breaks, and who owns what.

    Accepted when

    Your on-call can follow it without calling us.

    Cadence: Handed over at cutover

We call it done when: requests reach their destinations through the server path under real traffic, latency and cost hold against the estimate, and a rollback has been rehearsed.

Fit and readiness

Committing to a server container means running it long-term

Server-side isn't a weekend project. These few questions tell you if your team is ready to run one long-term.

A good fit when

  • Your server-container decision is made, but the cloud project, custom domain, clients, and routing still need a production-ready build.
  • Browser restrictions are affecting collection, and you want a first-party endpoint on your own domain.
  • Cloud costs and monitoring continue after launch, but the team taking over still lacks an operating runbook and a named operations owner.

Better handled as other work when

  • You haven't decided whether server-side tracking is worth it for your setup yet, that's First-Party Tracking Architecture.
  • Your browser-side GTM container is what needs work, not a server one, that's GTM Web Container Architecture.

If one of these is closer to your situation, start here instead: All Server-Side Tracking & First-Party Measurement tasks

We call it done when: the cloud provisioning, the custom domain, and the budget caps are approved by whoever will pay for and operate them.

People who build your measurement system

Zeo designs measurement systems that connect a business decision to governed collection and reporting you can check. The people shown here work on the part of that system this page covers.

Tools we use

Tools behind this work

  • Google Tag Manager

    where clients and routing get configured once the infrastructure underneath is standing

  • Stape

    the managed hosting option that removes the DNS and TLS work from the client's plate

  • Google Cloud Run

    the self-hosted alternative when the client wants the container on their own cloud account

Next step

Get a server container that's actually production-ready

Share your expected traffic and current setup. We will design and build the infrastructure, then hand it over with a practical operating model.
Plan server-side setup

Before we start

Questions teams ask before booking

Not automatically. Server-side tagging addresses specific needs such as ad blocking, first-party cookie durability, and control over data before it leaves your infrastructure. If those are not current problems, First-Party Tracking Architecture can help you weigh the added operational cost.