Server-side tracking
Server-side tracking sends conversion and analytics events from a server you control instead of the visitor's browser: a more durable route for the same events.

The event doesn't change (a purchase is still a purchase), but the transport does: server-to-server requests survive ad blockers, Safari's cookie caps, and the script failures that silently eat browser-sent events. Meta's Conversions API and Google's server-side endpoints exist so the same conversion can take this route.
#More durable, not invisible
Server-side changes how events travel, not what you're allowed to collect: consent applies identically on every transport, and a denied user is denied everywhere. What it buys is durability. The browser is a hostile delivery environment; your server isn't. It also carries real costs, infrastructure to run and plumbing to maintain, so smaller stacks often don't need it yet.
In practice: Buron ships a first-party pixel backed by a production server-side pipeline, so the events feeding its warehouse don't depend on what a browser felt like delivering.
What it fixes, what it costs, and whether it belongs in your stack is covered in Server-side tracking: what it fixes, what it costs, and whether you need it. The Google-infrastructure route is Server-side tagging with sGTM.
Related terms
Conversions API (CAPI)
The Conversions API is Meta's server-to-server channel for conversion events: a second delivery route for the same events the pixel sends from the browser.
Server-side tagging (sGTM)
Server-side tagging runs your tag manager on a server you control, so events reach ad and analytics platforms from your infrastructure instead of the visitor's browser.
Tracking pixel
A tracking pixel is a tiny image or script that fires an HTTP request on a pageview or event, carrying the URL, referrer, timestamp, and identifiers to a collection server.