Server-side tracking

Updated 2026-11-02

Definition

Server-side tracking records events from your server instead of from a script in the visitor's browser. Your backend sees a signup or payment, then sends that event to your analytics tool directly.

Client-side tracking runs in the browser. It sees what the visitor sees, including the URL, referrer and clicks, but ad blockers and browser limits can stop it. Server-side tracking avoids those problems, but it can't see the browsing behavior unless you pass it along.

Example

This example uses made-up numbers. Your checkout records 100 sales in a month. A browser conversion tag on your thank-you page counts only 88, because of ad blockers and people closing the tab. A record from your server, or from your payment provider, counts all 100.

Those 12 missing sales at $150 each are $1,800 your browser-only reports would never see. But the server record alone won't tell you which campaign brought those buyers. You still need the browser visit to connect the two.

The usual approach

Most teams combine the two. The browser captures where people came from. The server captures what they did, especially anything involving money. An ID links the two. The term "server-side tagging" can also mean sending browser events through your own server before they reach vendors, which is a related but separate idea.

How Headstream measures it

Headstream uses both, split by what each does best. Visits and events come from a browser script. Payments come from Stripe through webhooks and a history import, so a closed tab or ad blocker can't lose a sale. Connecting Stripe is in beta.

The two sides are linked by email, Stripe customer ID or a visitor ID you add to a charge. Answers to "how did you hear about us?" can also be sent from your server through the API. Headstream has no public API for sending pageviews or custom events from a server, so those come from the browser script.