Server-side tagging: what it is, when it is worth it, and how to set it up

Server-side tagging sends your website’s tracking events to a server container you control, usually a Google Tag Manager server container on your own domain, and that server forwards them to GA4, Google Ads, Meta and other platforms. Use it when you send conversions to several ad platforms, need to control what each vendor receives, or want sturdier first-party measurement. Skip it for now if your browser tags are still unreliable, because a server only forwards what the browser sends.

What is server-side tagging?

In a standard client-side setup, the browser loads a separate script for each vendor, and each script sends its own data. GA4, the Google Ads tag and the Meta Pixel each collect what they collect, and you have limited say over it.

In a server-side setup, the browser sends one stream of events to a server container. Google describes the container’s clients as “adapters between the software running on a user’s device and your server container.” A client claims each incoming request and turns it into event data, and server tags forward that data to each destination. Google’s introduction to server-side tagging puts the main benefit plainly: you have “full control over how that data is shaped, and where it is routed from the server.”

You still keep a web container in the browser. It captures pageviews, form submits and purchases, and sends them to the server container instead of straight to every vendor. Our beginner’s guide to server-side tagging with GTM covers that relationship in more detail.

Client-side vs server-side tagging: what changes?

Server-side tagging trades a simpler setup for more control. The table below shows where the two differ in practice.

When is server-side tagging worth it?

It tends to pay off when at least one of these is true:

• You send conversions to two or more ad platforms and want one place to control and check them.
• You need to keep certain fields away from certain vendors, for example in healthcare or finance.
• Meta or Google Ads bidding depends on conversion data, and you want the Conversions API and Google Ads tags running from a first-party endpoint.
• Your site has enough traffic that small losses in browser data change your reporting.

It is usually not the first fix. If events fire twice, forms do not send leads, or UTMs are missing, a server will forward those problems faithfully. Fix the browser layer first; our tracking QA checklist is a good place to start. If you work in a regulated industry, read healthcare marketing tracking without PHI before you route anything.

How do you set up server-side tracking?

The steps below follow Google’s server-side Tag Manager documentation. They assume you already have a working web container.

1. Create a server container

In Google Tag Manager, create a new container and choose Server as the target platform. New server containers include Google Analytics 4 clients and tags, so GA4 requests have something to claim them from the start.

2. Choose hosting: Cloud Run, App Engine or a managed host

Google’s recommended host is Cloud Run. Its Cloud Run setup guide lets you provision the service “either automatically in Google Tag Manager or manually in Google Cloud.” It recommends “a minimum of 2 instances to reduce the risk of data loss in case of a server outage,” and you also provision a separate preview server so GTM Preview works for the container.

App Engine is still documented, but Google’s App Engine guide says “the recommended deployment option is Cloud Run.” It also warns that App Engine’s default request logging can add significant logging charges.

Managed hosts such as Stape run the same server container for you and bill by request volume. They suit teams that do not have, or do not want, a Google Cloud project to look after.

3. Put the server on your own domain

Your server gets a default cloud URL, such as a run.app address, but you should not use it in production. Google’s custom domain guide says a server on the default domain “can only set JavaScript cookies.” It lists two first-party options:

• Same origin, such as www.example.com/metrics, which Google calls best practice. This usually needs a CDN or load balancer to route the path.
• A subdomain, such as metrics.example.com, which is simpler to set up with a DNS record.

Both give the server access to server-set cookies on your domain. Pick the one your hosting and DNS setup can support reliably.

4. Point the web tags at the server

In the web container, set the server container URL on your Google tag so GA4 requests go to your domain instead of Google’s. Google’s send data guide covers the setting for GTM and for gtag.js, and how to serve the Google tag script itself through the server container.

If you only want Google’s scripts to load from your own domain, Google tag gateway for advertisers is a lighter option. It serves scripts such as gtm.js first-party, but it does not give you a server container to shape and route data.

5. Route each destination

Add one server tag per destination, each with a trigger limited to the events it should send.

• GA4: the GA4 client claims requests from your Google tag, and a GA4 server tag forwards them to your property.
• Google Ads: Google’s Ads setup guide needs a Conversion Linker tag and a Google Ads Conversion Tracking tag with your conversion ID and label. Remarketing and Enhanced Conversions are optional extras with their own settings.
• Meta Conversions API: Meta publishes a Conversions API tag for server-side GTM that it writes and maintains. Customer details such as email and phone must be hashed (Meta’s examples use SHA-256), but client_ip_address, client_user_agent, fbc and fbp must not be, per Meta’s customer information parameters.
• Other platforms, such as LinkedIn or TikTok, through their own server tag templates where they exist.

If the Meta Pixel still runs in the browser, deduplicate. Meta’s deduplication guide says the Pixel’s eventID must match the server’s event_id, and the event names must match too. Events are only deduplicated within 48 hours of the first one.

Enhanced Conversions and a full Meta Conversions API rollout each deserve their own plan. For conversions that happen after the website, such as a closed deal in a CRM, see our guides to offline conversions and sending GoHighLevel conversions to Google and Meta.

6. Keep consent in the browser

Google’s server-side consent guide says “you only need to set up consent mode in the web container.” The Google tag adds the visitor’s consent state to each request, and “Google product tags in the server are consent-aware.”

That guide covers Google tags only; it does not say how non-Google server tags handle consent. Our recommendation, not Google’s: do not assume a tag such as the Meta Conversions API tag reads the consent state on its own. Add a consent condition to its trigger and test it with consent declined. Consent mode itself, including the difference between basic and advanced mode, is covered in Google’s consent mode overview.

7. Test both containers together

Run GTM Preview on the web and server containers at the same time. In the server preview, Google’s debug guide shows the client that claimed each request, the outgoing requests to each vendor and their responses, and which tags fired or did not fire. Then check GA4 DebugView, Google Ads conversion status and Meta Events Manager’s Test Events, with consent accepted and with consent declined.

What does server-side tagging cost?

Hosting is a monthly cost that grows with traffic. As of October 2026:

• Cloud Run: Google’s setup guide estimates each server at “approximately $45 /month (USD)” with 1 vCPU and 0.5 GB of memory and CPU always allocated. With the recommended two instances, that is roughly $90 a month before the preview server and any logging. Cloud Run offers request-based and instance-based billing, which changes how idle time is charged.
• App Engine: Google’s guide estimates about $40 a month per server in production, plus possible logging charges.
• Stape: its pricing page lists a free plan for up to 10K requests, and paid plans from $17 a month billed annually for up to 500K requests, $83 a month for 5M and $167 a month for 20M, also billed annually. The page shows $20, $100 and $200 crossed out next to those prices; check it for the current monthly-billing rate.

Hosting is rarely the biggest cost. Setup, routing each platform, consent checks and the monitoring that catches a broken tag are where the time goes. Budget it as infrastructure you maintain, not a one-off project.

What are the common server-side tagging mistakes?

Most broken setups we review have one of these:

• The server runs on the default cloud domain, so it cannot set server cookies on your domain.
• The web tags still send directly to GA4 as well as to the server, so events count twice.
• Meta events go through both the Pixel and the Conversions API without a shared event ID.
• Non-Google server tags fire for visitors who declined consent.
• The server runs a single instance, or nobody watches its errors, so outages lose data quietly.

We cover these in more depth in seven tracking mistakes that wreck server-side GTM setups. For a broader view of how we plan tracking, read our measurement guide.

Server-side tagging checklist

1. 1The server container runs on at least two instances or a managed plan sized for your traffic, with a preview server for testing.
2. 2The server URL is on your own domain, as a same-origin path or a subdomain, on HTTPS.
3. 3Every Google tag in the web container uses the same server container URL, and nothing still sends directly to GA4.
4. 4Each server tag has a trigger, and each destination receives only the fields it needs.
5. 5Google Ads has a Conversion Linker and a Conversion Tracking tag in the server container.
6. 6Meta Pixel and Conversions API send the same event name and event ID, and hashed customer fields exclude IP, user agent, fbc and fbp.
7. 7Declined-consent visits are tested, and non-Google server tags do not send data for them.
8. 8Results are checked in GA4 DebugView, Google Ads and Meta Test Events before anyone reports on them.