Platforms

GA4 server-side tracking

GA4 server-side tracking means your site sends its analytics events to a server container on your own subdomain, and that container forwards them to Google Analytics. The events, the parameters and the conversions stay exactly as you built them; only the route changes.

That last point is why this is worth doing on an existing setup. You are not rebuilding your measurement plan, you are changing where it travels.

How GA4 server-side tracking runs

Your web container keeps firing the same GA4 events. Instead of going straight to Google, they arrive at your measurement address — t.yoursite.com — where the GA4 client in your server container receives them and passes them on.

Three things follow from that. Requests go to your own domain, so blocklists built around known tracker hostnames do not match. The event reaches a machine you control before it reaches Google, so you can see and limit what leaves. And cookies are set by the server in its response rather than by a script.

What is server-side tracking has the full mechanism, including where that last one runs into Safari.

Expect a step in your reports

Your numbers will move, usually up, on the day you switch. Events that used to be lost to a blocker or to a visitor leaving before the request completed now arrive.

That is the improvement working, but it does mean any month-over-month comparison spanning the switch compares two collection methods rather than two months. Mark the date in your annotations and be careful with the first comparison you run afterwards.

The Measurement Protocol is a different thing

The Measurement Protocol sends events to GA4 from a server without any browser hit at all. It is the right tool for things that happen off your site — a refund processed in your back office, a lead that converts on the phone.

It sits alongside a server container rather than replacing it. What it cannot do is carry the page context a browser hit brings with it, so it is an addition to your measurement rather than a substitute for it.

What stays your problem

Consent still applies. A GA4 hit from a visitor who refused analytics storage is still cookieless, exactly as consent mode intends — the server does not change what you were allowed to collect.

And a wrong event stays wrong. Server-side improves delivery, not the measurement plan behind it.

Alongside the ads platforms

The same container that feeds GA4 can feed Google Ads, Meta and TikTok from the same event. See Google Ads server-side tracking, the Meta Conversions API and what is the Conversions API for the advertising side, and Getting started for the setup.

Questions people ask

Will my GA4 numbers change after moving server-side?
Yes, and usually upward, because events that a blocker or an early tab close used to lose now arrive. Expect a step in your reports on the day you switch. It is not a data quality problem, but it does mean any comparison spanning the switch is comparing two different collection methods.
Do I need to rebuild my GA4 setup?
No. Your events, parameters and conversions stay as they are. What changes is the route between your site and GA4, not your measurement plan. That is the main reason server-side is worth doing on an existing setup rather than a rebuild.
Does server-side GA4 avoid the cookie banner?
No. Consent applies to what you store on and read from the visitor's device, which is decided in the browser regardless of where the request travels afterwards. Consent mode still works, and a server container makes passing the signal through easier.
What about the Measurement Protocol?
It is a separate route for sending events to GA4 from a server without a browser hit at all, useful for things that happen off the site such as a refund. It sits alongside a server container rather than replacing it, and it does not carry the page context a browser hit does.