Server-side tracking has been presented for several years as the response to browser restrictions and signal loss. We implemented it, and the results were mixed in ways worth describing.
What it actually is
In the conventional setup, a browser loads tags that send data directly to third parties. The browser is the intermediary and the browser can block it.
In a server-side setup, the browser sends data to a server you control, and that server forwards it onward.
The difference is where the data is collected and who controls the collection point.
What it genuinely improves
Page performance, measurably. Removing a dozen third-party scripts from the browser improves load times, and load times affect conversion.
Data quality. Ad blockers and network-level blocking prevent a portion of client-side tags from firing. Server-side collection is affected less, so the recorded data is more complete.
Control. You decide what is forwarded to each destination, which means a vendor receives only the fields it needs rather than everything the tag would have collected. That is a genuine privacy improvement rather than a rhetorical one.
And resilience against browser changes, since the collection point is not subject to browser policy in the same way.
What it does not solve
The part that gets oversold.
It does not restore cross-site tracking. A user who cannot be identified across sites cannot be identified across sites regardless of where the data is collected. Server-side collection improves observation of what happens on your own property, not what happens elsewhere.
It does not bypass consent requirements. If a user has not consented to tracking, collecting the same data server-side is the same processing under most privacy regimes, and regulators have said so.
It does not eliminate the need for an identifier. Linking events to a user still requires something to link them with, and the constraints on that are unchanged.
And it does not improve attribution across platforms, which is what most people hoping for a fix actually want.
The obligations it creates
The part that is least discussed by vendors.
You are now the data controller at the point of collection, in a more direct sense than before. Data flows through infrastructure you operate, which means you are responsible for its security, retention and lawful processing.
Configuration is now your responsibility. A mistake that sends personal data to a destination that should not receive it is your mistake, and it is easy to make because the forwarding rules are yours to write.
There is a real cost. Server infrastructure, or a managed service, plus the engineering time to build and maintain it. For a small operation this is not trivial.
And it becomes a dependency. If it breaks, all measurement stops rather than one tag failing.
The consent point deserves emphasis
Because this is where I have seen the worst reasoning.
Some implementations have been sold, explicitly or by implication, as a way of continuing to collect data from users who declined consent, on the basis that the collection happens on your own infrastructure.
That reasoning does not survive contact with the applicable regulations in the stricter jurisdictions, and enforcement action has followed in some cases.
Consent applies to the processing and the purpose, not to the technical route. Anybody proposing this as a consent workaround should be treated with considerable caution, and the question should go to a lawyer rather than to a vendor.
Whether it was worth it for us
On balance yes, for reasons that were not the ones we implemented it for.
The page performance improvement was larger than expected and had a measurable conversion effect on its own.
The data governance improvement — knowing and controlling exactly what each vendor receives — turned out to be the most valuable outcome, and it came up in a compliance review a year later where it saved considerable work.
The measurement improvement was real and modest, in the range of a low double-digit percentage more events recorded, which is useful and not transformative.
What we did not get was any restoration of cross-site visibility, which was the implicit promise in a lot of what we had read, and which was never going to be delivered by moving where a script runs.
What we would do differently
Two things, having implemented it.
Involve whoever handles data protection at the design stage rather than at review, because the configuration decisions are the compliance decisions and they are made by engineers.
And document the forwarding rules properly, in a form a non-engineer can read, because a year later nobody remembers which fields go where and the answer matters the moment anybody asks a question about it.
Both are unglamorous and both would have saved us more time than any technical choice we made.
Who should not bother
A fair conclusion, since the cost is real.
An organisation with modest traffic, a simple site, one or two measurement destinations and no dedicated engineering capacity will spend more on building and maintaining this than the improved data is worth.
The break-even is somewhere around the point where measurement genuinely drives spending decisions of a size that a ten percent data improvement changes the answer.
Below that, improving consent rates and fixing the existing client-side setup properly delivers more for less.