Server side tagging: how to set it up with Google Tag Manager

Server-side tagging means you no longer let all your tags run in your visitor’s browser. Instead, the browser sends one data stream to a server that you control. That server, a Google Tag Manager server container, processes the data and forwards it to GA4, Google Ads, Meta or other platforms. The result: fewer scripts on your site, more control over what you share and more durable first-party cookies. In this article you will read how it works, when it is worth the effort and how to set it up step by step.

What is server-side tagging?

With classic, client-side tagging, every tool loads its own script in the browser: the Google tag, the Meta pixel, the LinkedIn Insight Tag. Each script sends data to its own server. You have little visibility into what exactly leaves your site.

With server-side tagging, that route changes. The browser sends measurement requests to your tagging server. Google describes it in its documentation on server-side tagging as a container that runs “on a server that you control”, in your own Google Cloud project or another environment. Inside that container, so-called clients turn the incoming requests into events, after which tags forward those events to the platforms you choose. Until you forward something, only you have access to that data.

Client-side and server-side side by side

Server-side tagging or server-side tracking?

In practice, marketers use both terms interchangeably. Strictly speaking, server-side tagging is the technique (tags in a server container), and server-side tracking is the result (measuring via a server instead of directly from the browser). Anyone searching for “server side tracking” is usually looking for the same setup. For the specific Google Ads side, with enhanced conversions and offline conversions, read server-side tracking for Google Ads.

Why do companies choose server-side tagging?

Control over what you share

By default, every tag in the browser sends everything it can pick up: URLs, referrers, sometimes even form fields in a query string. In a server container you see every request come in and decide per platform which fields get through. Truncating an IP address, stripping an email address from a URL or sending a field only to Google Ads and not to Meta: you manage all of that in one place.

More durable first-party cookies

If your tagging server runs on a subdomain of your own site (for example metrics.yourdomain.com), that server sets cookies in a first-party context. In its guide to a custom domain, Google calls this a best practice that gives you “the security and durability benefits of server-set cookies”. On your cloud provider’s default domain, the server runs in a third-party context and can only set JavaScript cookies. Read more about why this matters in our piece on first-party data.

Fewer scripts in the browser

Every extra pixel costs load time. By serving tools such as Meta and LinkedIn via the server instead of through their own script, part of that JavaScript disappears from the browser. Don’t expect miracles, though: the Google tag or web container is still needed to collect the data.

A place to enrich data

A server container can add data to events that the browser does not know, such as a margin per product or a lead status. That way you send Google Ads a conversion value that is closer to revenue.

Server-side tagging and consent (GDPR)

The Belgian Data Protection Authority (GBA/APD) is clear: a cookie for analytics purposes is not strictly necessary and therefore requires consent, and withdrawing that consent must be as easy as giving it. In the Netherlands, the Autoriteit Persoonsgegevens takes the same line. That does not change because the data runs through your server.

What does change: you can pass the consent status to the server container and respect it there per tag. Google works with four consent types: ad_storage, analytics_storage, ad_user_data and ad_personalization. In the basic variant, Google tags only load after a choice in the banner; in the advanced variant they load immediately with a default status of “denied” and send cookieless pings. How to set that up for Google Ads is explained in consent mode v2 for Google Ads.

Setting up server-side tagging in 7 steps

1. Take an inventory of your tags and consent

List which tags run today, which events they measure and which consent category they fall under. This is also the moment to clean up: duplicate GA4 tags and forgotten pixels do not move with you. Without this step, you copy existing errors into a more expensive environment.

2. Create a server container in Google Tag Manager

In Google Tag Manager, choose a new container of the “Server” type. The container comes with a GA4 client and GA4 tags by default, so you can receive GA4 traffic straight away.

3. Choose your hosting

You can have the tagging server created automatically in Google Cloud (Cloud Run) or provision it yourself. Google recommends running at least two instances in production, so you don’t lose data during an outage, and mentions an indicative price per server per month there, billed by Google itself. You also need a separate preview server to be able to test. If you don’t want to manage your own cloud, choose a managed host such as Stape: less maintenance, but one more supplier in your record of processing activities.

4. Connect your own subdomain

Set up a subdomain such as metrics.yourdomain.com and point it to your tagging server, or serve the container via a path on your own domain. Only then do you benefit from server-set cookies in a first-party context. If you skip this step, everything runs in a third-party context and you miss a large part of the benefit.

5. Point your web container to the server

In your web container (or the Google tag), set the server URL so that GA4 hits go to your tagging server instead of directly to Google. If you work with a data layer, it remains the source of your events and parameters: the server receives what the web container passes on.

6. Set up clients and tags in the server container

Add the right tag per platform: GA4, Google Ads conversions, the Meta Conversions API, possibly LinkedIn. If you send the same event to Meta via both the browser and the server, include a shared event ID so Meta can deduplicate. Let each tag fire only when the consent status allows it.

7. Test, go live and monitor

Test every change in preview, in both the web container and the server container. In Google Tag Assistant you see which tags fire and with which data; in the server container preview you see, per incoming request, which client picked it up and which tags forwarded it. Then check in GA4, Google Ads and Meta Events Manager whether the events arrive with the right values. After going live, monitor whether the servers stay reachable and whether your event counts remain stable.

Common mistakes with server-side tagging

• No custom subdomain. The server runs on the cloud provider’s default domain, so the cookies remain third-party.
• Double counting. The old browser tags stay switched on alongside the new server-side tags, or Meta receives browser and server events without a shared event ID.
• Forgetting consent on the server side. The banner works in the browser, but the server forwards everything regardless of the choice.
• One instance in production. During an outage, your measurement data is lost until someone notices.
• Moving a messy foundation along. Server-side tagging does not fix bad events or a missing data layer. Also read the classics in common mistakes in Google Analytics tracking.

How do you check whether your server-side setup works?

1. Open your web container preview and check in Tag Assistant whether the GA4 hits leave for your own subdomain.
2. Open your server container preview and look, per request, at which client picked it up and which tags fired, with which status code.
3. Check in GA4 DebugView whether the events arrive with the right parameters.
4. Use the test events in Meta Events Manager and the conversion diagnostics in Google Ads.
5. After a week, compare the event counts with your old setup and with your CRM.

Not sure whether your current setup is right before you start? A tracking audit first maps your existing tags, consent and data discrepancies.

When does server-side tagging pay off, and when not?

It pays off mainly if you put serious budget into Google Ads or Meta and those platforms need better signals, if you serve several platforms from the same events, or if you want strict control over which data you share. For a small B2B site with a handful of enquiries per month and one GA4 property, a clean client-side setup with correct conversion tracking is often enough. Start there.

In our setups we rarely start with the server. At Suivo the gain came from one robust form listener and a clean data layer; at Kaizo it came from one clear conversion, the booked demo, which GA4, Google Ads and Meta see in the same way. Server-side tagging builds on such a foundation; it does not replace it.

Frequently asked questions

Is server-side tagging GDPR compliant?

Not automatically. It does give you better means to work in a GDPR-compliant way: you see all outgoing data, can filter fields and can respect the consent status per tag. The obligation to ask for consent for analytics and advertising cookies still applies.

Do I still need a regular Google Tag Manager container?

Yes, in virtually every setup. The web container or the Google tag collects the events in the browser and sends them to your server. The server container processes and distributes them. Read more about the basics in our article on Google Tag Manager.

Does server-side tagging bypass ad blockers?

Partly, and that is not the goal. Via your own subdomain, requests are blocked less often than well-known third-party domains, but visitors who do not give consent may not be measured with cookies on the server side either.

What does server-side tagging cost?

The costs consist of hosting (Google Cloud or a managed host) and the time for setup, testing and maintenance. How much work that is depends on the number of platforms, your consent setup and the state of your current tracking. That is why we work on request, after a short analysis.

What is the difference with server-side tracking for Google Ads?

Server-side tagging is the broad infrastructure for all your platforms. For Google Ads, specific techniques come on top, such as enhanced conversions and offline conversions from your CRM. You can read about those in server-side tracking for Google Ads and setting up enhanced conversions.

Want server-side tagging set up for you?

We set up server-side tagging as part of a complete measurement setup: inventory, server container, custom subdomain, consent and a test round per platform. See how our tracking specialist works, or start with a tracking audit if you first want to know where your measurement leaks today. Rather discuss it straight away? Get in touch.