Full Answer

The mechanism is straightforward. Every inbound HTTP request carries the full URL, including any query parameters, as part of the request headers. A server-side tracking implementation reads those headers at the application layer — in PHP, Node.js, or whichever framework powers the site — before the browser has rendered a single pixel. At that moment, utm_source, utm_medium, utm_campaign, and any click identifiers are available as raw variables.

The server stores these values in a first-party context: a session record, a database row, or a direct pipeline to BigQuery. This storage is entirely outside the browser's jurisdiction. Safari ITP, which aggressively caps cookie lifetimes and strips query decorations, cannot retroactively delete what a server has already written to its own database. Ad blockers, which prevent JavaScript tags from loading, have no effect on server-side code that never runs in the browser.

Redirect chains present a related but distinct risk. When a URL passes through multiple hops — HTTP to HTTPS, a marketing platform redirect, a URL shortener — each hop can silently drop query parameters if the redirect configuration omits the QSA flag or equivalent. Server-side capture eliminates this risk by recording parameters on the very first request, before any redirect fires. For stores running campaigns on Facebook, Google, or TikTok, this means the critical connection between the ad click and the eventual purchase is preserved from the first millisecond the request touches your infrastructure.