Standing up a tagging server is only half the job; it does nothing until your GA4 data actually flows through it. Moving your tags across is the step that turns server-side GTM from a parked container into a working pipeline. Here is how to do it without breaking your reporting.

The two containers involved

Server-side tagging uses two GTM containers, and keeping them straight prevents most confusion. The web container lives in the browser and decides what to send; the server container runs on your infrastructure and decides where it goes. Moving GA4 server-side means the web side sends to your server, and the server side forwards to Google.

Step 1: add the GA4 client on the server

In the server container, confirm the GA4 client is present, since it is the component that receives and parses incoming GA4 requests. It ships by default in new server containers, but verify it exists before you send anything, or the server will not understand the hits it receives.

Step 2: repoint the web GA4 tag

In the web container, open your GA4 configuration and set it to send to the server container URL, which is the same subdomain you provisioned:

// Web-side GA4 config: route hits to your server container
gtag('config', 'G-XXXXXXXXXX', {
  server_container_url: 'https://sgtm.yourdomain.com',
  first_party_collection: true
});

In the GTM interface this is the server container URL field on the GA4 configuration tag, rather than raw gtag, but it does the same thing: the browser now posts to your domain instead of Google's.

Step 3: test both sides in preview

Open Preview on both containers at once and trigger an event. You should see the hit leave the web container, arrive at the server container, and be forwarded to GA4. Watching it on both sides is what confirms the handoff, and it catches a missing client or a wrong URL before real data depends on it.

Move gradually, not all at once

Resist flipping everything server-side in one publish. A safer rollout looks like this:

  • Start with GA4 alone, since it is the best-supported tag server-side.
  • Run server-side and verify numbers against your old client-side data for a few days.
  • Only then migrate other tags, such as Meta or Google Ads, one at a time.

Watch for the usual gaps

Two things commonly go wrong. Cross-domain and consent settings need to be re-checked, because they do not automatically carry over. And any tag that has no server-side equivalent has to stay client-side, so expect a hybrid setup rather than a fully server-side one. Reconcile your key events against the old data before you decommission anything.

Keep the same measurement ID

A common mistake is spinning up a fresh GA4 property or stream for the server-side setup, which splits your history and muddies comparisons. Keep the same measurement ID and route it through the server instead, so the data lands in the property you already report on. If you run client-side and server-side in parallel while testing, make sure only one of them ultimately sends each hit, or you will double-count during the overlap.

Decide deliberately what stays client-side

Not every tag has a mature server-side equivalent, so plan for a hybrid rather than assuming a clean sweep. GA4 and the major conversion APIs move over well; a niche vendor tag or a third-party script may have to stay in the browser. List your tags, mark which have server-side support, and migrate only those, so you are never surprised by a tag that silently stopped working after the move.

A tagging server is inert until your GA4 data runs through it, and repointing your tags is what brings it to life. Add the GA4 client, send the web tag to your server URL, test the handoff on both sides, and migrate gradually while reconciling numbers. Do that and the parked container becomes the working pipeline that carries your measurement from now on.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.