Server-side tracking
What it is
Conversion events sent to the ad platforms and to analytics from a server you control, either beside the browser tracking or as its replacement.
What it’s good at
Recovering signal lost to blockers and to browsers that restrict cookies; the platforms bid on conversion data, and a fuller count is the commercial point. And collection moves under your control: you decide what is sent and with which fields.
What it costs to own
The build is engineering: a developer standing up an endpoint or a hosted container, then mapping events from the shop with a shared event ID so browser and server report the same sale once. Maintenance is the larger half; interfaces change, and the builder moves on. Two limits survive every build. Consent is checked in your own code or nowhere. And when the shared event ID slips, the same sale counts twice; the pixel’s failures read as zeros, while this one’s read as growth.
When it’s a poor fit
It fits poorly when no developer hours are committed past go-live; the build without the keeping produces the inflation above. It fits poorly when most visitors decline consent: the events you may lawfully send are the consenting share, so the size of that share decides how much signal there is to recover. And when nobody reconciles platform counts against the shop today, it re-plumbs a number no one checks.
What it sits beside
It runs beside the pixel, deduplicated, and behind the consent platform; Google Tag Manager’s server container is the usual vehicle. The go-live date becomes a break in the numbers: every comparison across it compares counting methods.
My experience
The setups I have seen hold up over time had a developer who kept looking after them past go-live.