Server-side tagging

In the browser model, a page loads a vendor’s script and that script sends the event directly to the vendor. In the server-side model, the event goes to a server you control, and that server forwards it on.

The difference is where the request originates. A browser request can be blocked by an ad blocker, stripped by tracking prevention, or lost when a script fails to load. A server-to-server request is not subject to any of that, because the visitor’s browser is no longer the one making it.

The genuine benefits. Fewer lost events, so reporting is more complete. Control over what leaves your infrastructure, since the payload is assembled by you rather than by a vendor’s script. Less client-side JavaScript, which usually means a faster page.

The two misconceptions worth killing.

It is not a consent workaround. Moving the request to your server changes who sends the data, not whether you were allowed to. If a visitor did not consent to marketing tracking, sending their event server-side is the same violation with an extra hop. Anyone selling it as a way around consent is describing a compliance problem, not a feature.

It is not free accuracy. Server-side events are only as good as what reached the server. If the click ID never made it into your order record, forwarding that order from your server does not attribute it — it just sends an unattributed conversion more reliably.

The naming is genuinely inconsistent across vendors. Some call the outbound direction “tagging” and the inbound direction “tracking”; others use them interchangeably. Establish which one is meant before agreeing to anything.