Server-side tracking

What moves, and what you trade for it

In browser-side tracking, the visitor's browser sends the event straight to the vendor. In server-side tracking, the browser tells your backend — or tells it nothing, because your backend already knows the thing happened — and your backend sends the event onward. Same event, different sender, and the sender is the whole difference.

• What you gain: an extension cannot drop a request that never leaves the visitor's machine, a failed send can be retried, the payload can be validated before it goes, and API keys stay on your side of the wire.
• What you lose: everything the browser knew and your database does not — the referrer, the viewport, which element was clicked, how far the page was scrolled, and the anonymous visitor id that used to stitch a session together.
• What gets harder: timing and identity. The browser knew the event happened *to a specific visitor, on a specific page, at that moment*; your backend knows a row changed. Reconstructing the rest is the actual work.

The identity problem nobody warns you about

A browser event arrives already carrying context: which page, which referrer, which anonymous id, which campaign labels were sitting on the URL. A server event carries whatever you remembered to store. That is the real work of moving server-side, and it is not the sending — it is deciding, at the moment somebody lands, what has to be copied into your own database because it will not exist five minutes later.

UTM parameters and ad click ids are the sharp case, because they exist on exactly one URL, at the very start. If the click id was never persisted against the account at signup, a conversion you upload three weeks later has nothing to attach itself to — you will have carefully protected a number that can no longer answer the question you built it for. Marketing attribution is that question, and it is decided at landing, not at conversion.

What we learned sending our own conversions server-side

AgentCeres — the AI Growth Officer at agentceres.com — uploads qualified-lead conversions to an ad platform from its own database rather than from anybody's browser, keyed on the click id captured when the person first landed. The surprise was not the sending. It was that a successful HTTP response is not a receipt: our uploads came back 200 while the rows inside them were being rejected, and the real outcome was only visible in a separate status lookup made afterwards. The endpoint we first reached for also turned out to be closed to new integrations, which the 200 did not mention either.

The shape generalises. Browser-side, a lost event is loud in one specific way — the number is simply missing, and a hole is visible. Server-side, the failure is a request your own logs record as a success, so the hole looks like a fact. Anything you move server-side needs a verification step that asks the vendor what it actually stored, rather than trusting what it answered at the time. The receive-side half of this story — how much browser data goes missing in the first place, and why the shortfall was worst in the cohort we were paying to acquire — is on our PostHog page.

It is not a way around consent

Server-side tracking is often sold on defeating ad blockers, which mechanically it does. It is worth being straight about what that means: the blocker was installed by a person expressing a preference, and moving the write to your own server does not create a legal basis you did not have, nor make a first-party claim true because data passed through your domain on its way somewhere else.

• Consent governs the purpose, not the transport. If an event needs consent when a browser sends it, it needs consent when your server sends it.
• A proxy on your own domain is still a transfer when the destination is a third party — describe it as one in your privacy notice rather than reclassifying it.
• The honest version is usually enough. Most of what a small startup actually needs server-side is its own product data — signups, plans, payments — which was never the browser's to send in the first place.