Server-side tracking gets sold as a privacy improvement often enough that it is worth being precise about what it does and does not do under the GDPR. The short version: it changes the route your data takes, which is genuinely useful, and it changes none of the obligations attached to collecting it.
What server-side tracking does change
The data reaches you first. In a client-side setup the browser sends straight to Google or Meta, and whatever the script decided to include is what they get. In a server-side setup it arrives at a server you control first. You can see what is in it, drop fields, round values, or stop sending to a destination entirely.
That is a real capability, and it is the one that matters for data minimisation. It is the difference between hoping a vendor’s script behaves and deciding what leaves.
You can put the server in the EU. If the container runs in the EU, the leg from the visitor to your server does not raise an international transfer question. The leg from your server onwards still can, and honestly usually does — most advertising platforms are not in the EU. Server-side does not remove that; it makes it one clearly identified transfer instead of a diffuse set of them.
What server-side tracking does not change
You still need a lawful basis, and usually consent. What you are allowed to store on and read from someone’s device is governed by the ePrivacy rules, and they are about the device, not about which machine sends the request afterwards. Moving the send server-side does not turn a cookie that needed consent into one that does not.
You still have to honour the choice. A server-side setup makes it easier to pass a consent signal through properly, because you control the middle step. That is an argument for doing it well, not an argument for skipping it.
You are still the controller. It is your site, your purposes, your measurement plan. A provider hosting the container for you is a processor and needs a processing agreement with you. That obligation does not move because the infrastructure did.
The four documents
When a client’s lawyer reviews your setup, this is usually the list. It is worth being able to produce all four without a phone call.
A processing agreement under article 28, with the mandatory content actually in it rather than promised on request. A sub-processor list naming every party involved and where they sit. A privacy statement that describes what is processed and for how long. And terms that say what happens to the data when you stop.
Ours are all four on the site rather than behind a form: the processing agreement, the sub-processor list, the privacy statement and the terms. They were written against the real product, which also means they are worth reading rather than skimming.
The honest summary
Server-side tracking is a better place to make privacy decisions from, and a worse excuse for not making them. If you are choosing a provider partly on this basis, the questions to ask are where the servers are, who the sub-processors are, and whether the processing agreement exists today.
Server-side tracking tools compared goes through the other criteria. If you are earlier than that, client-side vs server-side tracking explains the mechanism, and the Meta Conversions API post covers the platform most people are here for.
This is a description of how the technology relates to the rules, not legal advice. For your own setup, ask someone qualified.