Reference
What is server-side tracking?
On this page
The short answer
With ordinary tagging, your visitor’s browser sends the measurements straight to Google and Meta.
With server-side tagging it sends them first to an address on your own domain, and they travel on from there.
That address is a server you control. What goes on to a third party from that point is your decision.
How client-side tracking works today
In the classic setup your site loads a piece of code for every service that sends straight from the browser to Google, Meta or TikTok. That works, but it happens in the place where you have the least control: a blocker stops the request, the browser’s tracking prevention throws away cookies or requests, and sometimes the visitor is gone before the request has left. What falls away, you do not see — it simply never arrives.
What changes with server-side tracking?
Server-side tagging puts a stop in between the browser and the services: your own subdomain, for example t.yoursite.com. The browser sends its data there — to an address that belongs to your own site — and that server decides what goes on to Google, Meta or TikTok. The traffic moves from a place you do not control to a place you do. The shape of the picture barely changes; who makes the requests, and where they pass through, does.
Server-side tracking or server-side tagging?
You will meet both terms, often interchangeably and usually for the same thing. There is a real difference, and it is worth knowing because it decides what you should be searching for.
Server-side tracking is the broader term: the measuring happens on a server instead of in the browser. That can be done with a tag manager, but equally with your own integration talking straight to Google’s or Meta’s API.
Server-side tagging is the narrower case: server-side tracking where a tag manager runs on that server — in practice almost always Google Tag Manager’s server container. The tags that used to sit in the browser now sit there.
Tagyard runs the second one. If you came here looking for server-side tracking you are in the right place: this is one form of it, and it is the form you can put to work without writing the integration yourself.
If you want the shorter comparison with the classic setup, it has its own page: client-side vs server-side tracking.
The benefits of server-side tracking
Less is stopped along the way
The request goes to an address on your own domain, so blocklists that work on known tracker domains do not catch it. What a blocker can still see is the shape of the request: the path, the form of the data, how often it happens.
You decide what leaves
The data arrives at your server first. There you can see and limit what goes on to a third party — drop fields, round them off, or switch a destination off entirely. This is the most underrated of the three, and the only one that sits entirely within your own control.
Cookies are set by your own server
Not by javascript in the browser, but by your server in the response. That helps — within the limit described in the next section, and that limit matters more than it is usually made out to.
What does it not solve?
This is where most expectations go wrong. Server-side tagging moves where your measurements travel; it changes nothing about the rules, about the quality of your source, or about what a browser decides. Four things to be level-headed about.
Safari still caps your cookies
This is the most important nuance and the most ignored one, and it applies to every hosted setup — ours just as much.
WebKit treats a first-party subresource that resolves elsewhere through a CNAME as third-party CNAME cloaking, and caps every cookie in that response at seven days. An A record has not escaped that automatically since Safari 16.4: WebKit compares the measurement server’s IP address with the website’s and applies the same limit when they share fewer than half of the address bits — sixteen for IPv4. Self-hosting on a separate VPS almost never meets that bar.
What you do get: on Chrome and Firefox that limit does not apply, and a cookie set by your server does not fall over the moment a blocker stops the javascript. What you do not get is a long-lived cookie on Safari.
Sources: WebKit, “CNAME Cloaking and Bounce Tracking Defense” (2020), and WebKit pull request 5347 (2022).
You know no more about your visitor than the browser passed on
Server-side moves where the data travels; it does not invent any. What the browser did not send — because the visitor gave no consent, or because your site does not measure it — does not appear on the server side after the fact.
A wrong measurement plan does not get better
Measure the wrong event and you will measure it wrong more accurately from now on. Quality starts with what your site sends, not with where it passes through.
Consent still applies
Server-side tagging is not a way around the cookie banner. It makes it easier to pass a consent choice along properly, and that is something other than not needing one. Anyone selling it as a way around is selling you a problem.
What you need to set it up
A server container in Tag Manager
In Google Tag Manager you create a server container alongside your web container. It holds what happens to your measurements once they arrive.
A subdomain of your own domain
An address under your own domain, for example t.yoursite.com, where the measurement traffic goes.
A DNS record
Usually a CNAME pointing that subdomain at your measurement server. That address needs a valid certificate, or the browser refuses the connection.
Somewhere for it to run
The server container has to live somewhere. This is the only one of the four that costs money, and the next section is about it.
Where can you run it?
Roughly three ways, and every one of them has a drawback — ours included. If you want the providers side by side: server-side tracking tools compared.
With Google, on Cloud Run
You run the server container in your own Google Cloud project. Close to the source and entirely in your own hands.
Drawback: Fiddly to get right, and you pay per use — which makes it hard to know in advance what it will cost.
Yourself, on your own server
Google’s standard image on a VPS or a machine of your own, with your own certificate in front of it.
Drawback: Cheap in money, expensive in attention: certificates, updates, and nobody noticing when it stops.
With a party that runs it
A hosted service sets the server up for you and keeps it running. Stape, TAGGRS and Tagyard all do this.
Drawback: A fixed amount per month, and you depend on that party.
What does it cost?
Running it yourself costs mainly time, plus the bill for your server or your cloud usage. A hosted setup starts at around ten euros a month for a small site and rises with the number of requests. Concrete amounts and volumes are on the pricing page.
Where does Tagyard fit in?
To be clear: this piece was written by a party that sells server-side tagging. Read it with that in mind.
Tagyard is the third way from the previous section — a hosted service. The difference comes down to two things: the traffic log is included as standard, and a screen tells you in plain language whether your tracking works, instead of leaving you to work it out from log lines.
Whether that is the difference you are looking for is yours to judge. What Tagyard does, and who for, is on the homepage.