Client-Side vs Server-Side Tracking
Date: 2026-08-16
Where the event is generated. Client-side sees what the user did and loses a growing share of it; server-side records what actually happened and can’t see the browser at all. The answer is both, split by which property matters.
What it is
Client-side tracking generates events in the browser and sends them directly to each vendor.
Server-side tracking generates them on your backend — from a request handler, a webhook, or a database change — and sends them from there.
CLIENT-SIDE SERVER-SIDE
browser ──▶ vendor A browser ──▶ your server
──▶ vendor B │
──▶ vendor C ├──▶ vendor A
├──▶ vendor B
blockable, lossy, └──▶ vendor C
rich in context
reliable, authoritative,
blind to the browser
The trade
| Client-side | Server-side | |
|---|---|---|
| Sees clicks, scroll, UI state | Yes | No |
| Sees device, viewport, referrer | Yes | Only if passed |
| Blocked by ad blockers | Frequently | No |
| Affected by consent | Yes, must be gated | Yes, and still must be — see below |
| Survives page unload | Unreliably | N/A |
| Authoritative for orders | No | Yes |
| Cost to run | Vendor SDK only | Infrastructure |
| Time to add a vendor | Minutes | A deploy |
In plain terms: the browser knows what the user experienced but is an unreliable narrator. The server knows what really happened but has no idea what the page looked like.
The split that works
Decide per event, on one question: is this a fact about the interface, or a fact about the business?
INTERFACE — client-side BUSINESS — server-side
page_view purchase
product_viewed refund
filter_applied subscription_renewed
scroll_depth payment_failed
cta_clicked order_shipped
form_field_error stock_updated
purchase is the one that matters most. Fired client-side it’s lost to blockers, lost on unload, and duplicated on refresh. Fired from the order webhook it’s exactly as accurate as your order table — which is the standard you’ll be reconciled against — Tool Discrepancies.
Consent applies to both
The common misconception. Moving collection server-side does not remove the legal requirement — consent attaches to the processing and to storing or reading information on the user’s device, not to which machine sends the HTTP request.
If a server-side event carries an identifier that originated from a cookie, you’re still relying on that cookie. See Consent Management and UK GDPR and PECR for Analytics.
What server-side genuinely changes is reliability and control, not lawfulness.
What server-side buys beyond reliability
- Fewer third-party scripts in the browser, which is main-thread time and a security surface — Third-Party Scripts
- First-party cookies set by the server, which aren’t subject to the browser caps on script-set cookies — Browser Privacy Restrictions
- Data control. You decide what each vendor receives, rather than the vendor’s SDK deciding
- One collection point to enrich, filter and route — Server-Side Tag Management
What it costs
- Infrastructure. A container to run, scale, monitor and pay for
- Engineering for every change. The thing tag managers exist to avoid
- Lost context. Device, viewport, referrer and consent state must be explicitly forwarded or they’re gone
- Identity work. Joining a server event to the browsing session that preceded it needs an identifier passed through deliberately — this is where most implementations quietly fail, and it presents as unattributable conversions — Identity Stitching
The realistic architecture
Not a choice, a division:
- Client-side for interface events, sent to one first-party endpoint rather than to each vendor
- Server-side for transactions, from the system of record
- A shared identifier passed both ways, so the two streams join
- Reconciliation against the order system as a standing check — Guide - Auditing a Tracking Plan
Point 3 is the one that makes or breaks it. Without it you have two datasets that agree on nothing.