Server-side tagging and first-party cookies, explained

Server-side tagging moves part of your tracking out of the visitor's browser and onto a server you control, reached through a subdomain of your own website. Set up well, it keeps ad click IDs and campaign details long enough to connect a lead to the ad that started it, even on iPhones, and it lets you decide what data each platform receives. This page explains how it works, what it fixes, what it does not, and when a small business should bother.

Two containers instead of one

A standard Tag Manager install is a web container. It runs in the visitor's browser, and each tag in it sends data straight to its vendor: GA4, Google Ads, Meta. Every one of those requests leaves the visitor's device for a well-known tracking domain.

Server-side tagging adds a second container that runs on a server. The web container still runs in the browser, but the Google tag sends its data to your tagging server instead of directly to Google. The server container receives each request, turns it into an event, and its own tags forward that event wherever it needs to go.

Why it lives on your own subdomain

A browser decides whether a cookie is first party by comparing it with the site the visitor is on. A tagging server at s.example.com, serving a website at example.com, shares the site's root domain, so the cookies it writes are first-party cookies. Point the same site at a tagging server on an agency's domain and those cookies become third party, and the main benefit disappears. Each business gets its own tagging subdomain, created with a DNS record on its own domain.

Google also documents a same-origin option, where a path on the main site, such as example.com/metrics, is routed to the tagging server through the site's own web server, load balancer, or CDN. It takes more configuration, and it has one advantage that matters for the caution in the next section: the responses come from the same address as the website itself.

Cookies from a server versus cookies from JavaScript

Attribution depends on remembering where a visitor came from. The gclid and UTM tags are only in the address on the first page view, so something has to save them. There are two ways to write that cookie, and Safari treats them very differently.

HTTP/1.1 200 OK
Set-Cookie: saved_gclid=EXAMPLE123; Domain=example.com; Path=/; Max-Age=7776000; Secure; SameSite=Lax

Max-Age=7776000 is 90 days in seconds. The tagging server writes cookies like this for the click ID, each UTM value, the landing page, and the referrer, and refreshes them when a newer ad click arrives.

A cookie is still a copy on one browser on one device. People clear cookies, switch from a phone to a laptop, or come back a year later. The durable record of a lead's source belongs in the CRM or a database the business owns, saved through hidden form fields when the lead is created. The cookies are the bridge to that record, not the record itself.

What it does about ad blockers, and what it does not

Most blockers work from lists of known tracking domains and scripts. Requests to a subdomain of the business's own site are blocked far less often than requests to well-known analytics and advertising domains, so a server-side setup stops losing honest data to generic block lists.

Two limits are worth knowing. First, the Tag Manager script itself loads from Google's domain by default, and a blocker that stops it stops everything after it. The server container can serve Google's scripts from your own domain as well, which closes that gap for blockers that work from domain lists. Second, first party does not mean invisible. Some privacy tools inspect first-party requests too, and none of this changes what a visitor has or has not agreed to.

What data goes where

1. ArriveA visitor lands on example.com with a gclid and UTM tags in the address.
2. SendThe Google tag sends the page view to s.example.com instead of straight to Google.
3. ClaimThe GA4 client in the server container claims the request and turns it into event data.
4. ForwardServer tags send the event to GA4, and conversions to Google Ads or Meta's Conversions API.
5. RememberThe response writes first-party cookies holding the click ID and campaign values.
6. StoreOptionally, a server tag also sends the event to a database the business owns.

Because the data reaches your server before it reaches any vendor, you choose what each one receives. A server tag can drop fields, remove query parameters that should never have been collected, or send one platform less than another. That control is a privacy benefit as much as a measurement one.

Consent still applies

Moving collection to a server does not change what the visitor agreed to. The Google tag passes the visitor's consent choices along with each request, and Google's own tags in the server container adjust to them. A custom server tag you add, such as one that writes click ID cookies or copies events into a database, does not respect consent on its own. Build the check into it: skip the click ID cookies when advertising storage is denied, and handle the analytics identifier according to the analytics choice. The full setup is in Consent Mode and deletion requests.

What the setup involves

This is the outline rather than a click-by-click build, because the hosting choice changes the details.

1. Create a server container

   Create it in the business's own Tag Manager account, next to the web container. Tag Manager provides a container configuration string that the tagging server needs when it starts.

2. Host the tagging server and a preview server

   Google documents hosting on Google Cloud, and the same container image runs with other providers or on a server you operate. Managed tagging hosts exist too. Whichever you choose, the container itself stays in the business's account.

3. Add the DNS record and a certificate

   Create a DNS record that points the tagging subdomain at the tagging server, and install an HTTPS certificate for it. DNS access is often the step that waits on the owner or the domain registrar, so ask for it early.

4. Point the web container at it

   In the Google tag's configuration settings, set server_container_url to https://s.example.com. This one setting is what routes GA4 data through the server.

5. Configure the clients and tags

   Confirm the GA4 client claims the incoming requests, then add the server tags you need: GA4 forwarding, Google Ads conversion tags, a Meta Conversions API tag from the community template gallery, a cookie writer for click IDs and UTM values, and a tag that sends events to the business's database if it has one.

6. Publish both containers and test in Safari

   Load the site with a test value such as ?gclid=test123, confirm the response from the tagging subdomain sets the cookie, and check its expiry in Safari. Then confirm the hit shows in GA4 Realtime.

Running it: containers fail quietly

A tagging server is infrastructure, and it fails like infrastructure. The dangerous failure is not a crash. It is a container that keeps running, looks normal in its logs, and stops doing its job. On a self-hosted setup, a restart policy brings back a container that crashes, but plain Docker leaves a running container alone even when its health check is failing. Nothing restarts it, and nothing tells you.

• Put an uptime monitor on the tagging server's health endpoint (/healthz) and on the preview server's, with an alert for sustained failure.
• Watch the HTTPS certificate on the tagging subdomain. When it expires, every request to the server fails.
• Check real traffic, not only the health check. A passing health check proves the server is alive, not that events are flowing. Open the site with the browser's developer tools, confirm requests to the tagging subdomain return 200, and confirm the events land in GA4.

When a small business needs it, and when it does not

Google also offers Google tag gateway for advertisers, which loads Google's own tags through your domain using a CDN or load balancer. It is lighter to run, but it covers Google's tags only, so it is not a substitute when you need to send data to other platforms or to your own database. A server container adds a hosting bill and an ongoing maintenance job, which is one more reason to finish the basics first. For how all the levels fit together, see how attribution works.