> For the complete documentation index, see [llms.txt](https://docs.quanti.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.quanti.io/server-side-tagging/server-side-tagging.md).

# Server-side tagging

A tagging server of your own, on your own domain.

Your site sends its measurement hits to `tag.yoursite.com` instead of Google's domains. That server runs the official Google Tag Manager **server** container and forwards the data to GA4 and to your other destinations.

**Your container stays yours.** We host and operate the server; the Tag Manager account, the tags and the decisions remain in your hands. Delete the server and your container is untouched.

## What it changes

**Measurement travels first-party.** Requests go to a subdomain of your own domain, through DNS records you control.

**Fewer requests are dropped.** The paths and the container identifier are specific to your server, so the published filter lists do not recognise them.

**Cookies can be written by the server.** A cookie set by the server in a `Set-Cookie` header is not subject to the cap Safari applies to storage written in JavaScript — which clears it after seven days of browsing without a visit to your site. Set your GA4 tag's cookie management to *server-managed* to benefit from it.

**Your pages get lighter.** Vendor scripts you route through the server are served from your domain, and you can proxy several of them.

**You see what leaves.** Everything passes through your container, so you decide what each destination actually receives.

## What we promise, and what we do not

✅ Paths and a container identifier **specific to your server**, that the public filter lists do not recognise.

❌ **Not immunity to blockers.** A share of requests remains blockable on their parameters alone, which we deliberately do not alter — changing them would break the requests your tags send to Google. Anyone promising immunity is setting you up for a bad surprise the first time you compare figures.

This is measured, not assumed: we check our paths against the real filter lists — EasyPrivacy, EasyList and uBlock's privacy filters, together more than a hundred thousand rules.

One consequence worth knowing: a provider that gives all its customers the *same* pattern sees that pattern end up in the lists, and it then fails for their whole fleet on the same day. Yours are derived for your server alone.

## Setting one up

Four steps, in this order. The [setup guide](/server-side-tagging/server-side-tagging/setup-guide.md) walks through each of them in detail, including the Tag Manager configuration.

1. **Your container configuration.** Copy it from your Tag Manager *server* container — not the container identifier, which is a different value.
2. **Your collection domain.** Pick the subdomain your site will call, for example `tag.yoursite.com`. Choose carefully: changing it later means editing the snippet on every page.
3. **Two DNS records.** Add them at your registrar. We check them automatically and the server goes live once they have propagated — usually minutes.
4. **The snippet.** Replace the Google Tag Manager snippet on your pages with the one we generate.

You can migrate one site at a time. The standard paths keep being served, so a site still running the old snippet keeps collecting normally, and you can roll back at any point.

## Preview and debugging

The *Preview* button in Tag Manager works as usual, on the server as on the web container.

Always open it **from Tag Manager**. A preview link carries a debug session identifier that is regenerated every time you open the preview; replaying an old link sends your hits to a session nobody is watching, which looks exactly like a server that is not answering.

## One server, several sites

A single server can serve several web containers. Declare each one, and each gets its own snippet — the container identifier is scrambled differently for each, so a snippet cannot be reused from one site to the next.

## What is measured

Two different figures, and they do not mean the same thing.

**Billable hits** — the requests your tags actually claimed: a `GET` or `POST` answered successfully by your container. The loader script, the proxied libraries and everything the server answers on its own are never counted.

**Traffic** — every request that reached the server, health checks included. Use it to watch trends and spot an outage, never to check an invoice.

Availability is measured with a real request to the container, not a simple port test: a server that is up but broken counts as down. We keep a full year of daily history, so the figure survives the server itself.

## Field by field

Every field of the setup screens — the container configuration, the subdomain, the DNS records, the snippet, the proxied libraries, and what exactly counts as a billable hit — is described one by one in the [field reference](/server-side-tagging/server-side-tagging/field-reference.md).

That page is also what the **?** buttons open inside the product: the explanation you read next to a field and the one published here are the same text, so they can never drift apart.