Server-side vs client-side analytics collection
Analytics can be collected client-side (a browser script fires events) or server-side (the server or a server endpoint records them). The two see different things: client-side captures rich browser context but misses no-JavaScript clients and is affected by blockers, while server-side sees every request but lacks some browser-only signals. Many setups combine them.
What this means
Client-side collection runs a script in the browser, capturing details like viewport, screen, and JavaScript-driven interactions — but it misses clients that do not run the script (some bots, no-JS users) and can be blocked. Server-side collection records requests as the server sees them, capturing every hit including non-JS clients, but without browser-only signals unless they are passed along.
Neither sees the full picture alone, which is why their numbers differ.
How to choose
Use client-side when you need rich in-browser interaction detail; use server-side when you need completeness, resilience to blockers, or central control over what is collected. Hybrid setups send some events server-side for reliability and others client-side for context.
- Client-side: rich browser context, blocker-affected
- Server-side: complete request view, fewer browser signals
- Hybrid setups combine both
Why numbers diverge
Because the two methods observe different populations, expect different counts — that is structural, not a bug. Bot traffic in particular shows up differently: server-side sees non-JS bots that a browser script never fires for.
How it appears in analytics and logs
Client-side and server-side counts differ because they observe different populations — script-executing browsers versus all requests — so reconcile by knowing what each sees.
Diagnostic use case
Use this to understand why two collection methods disagree, and to choose where collection should happen for reliability and privacy.
What WebmasterID can help detect
WebmasterID classifies traffic with server-side context, so human and bot activity can be separated; this page explains the collection trade-off even-handedly.
Common mistakes
- Expecting client-side and server-side counts to match exactly.
- Assuming server-side collection alone reduces obligations.
- Ignoring that blockers and no-JS clients skew client-side data.
Privacy and accuracy notes
Where collection happens affects what data is exposed to which parties; server-side can centralize control but does not by itself reduce obligations. This is educational, not legal advice.
Related pages
- Analytics migration checklist
Migrating analytics tools is more than swapping a script. Because metric definitions rarely match, headline numbers will shift, so the real work is mapping definitions, re-creating goals and events, running old and new tools in parallel to reconcile, and deciding what happens to historical data. This checklist lays out the steps in a tool-neutral way.
- Bot traffic in analytics: filtering it out
Bots — crawlers, scrapers, monitors, scanners — generate requests that, unfiltered, inflate pageviews and distort every metric. Client-side analytics often misses bots (many do not run JavaScript) or miscounts the ones that do. Server-side classification at ingest is the reliable way to keep bot traffic out of human reports.
- Pageviews: what the metric counts
A pageview is recorded when a page is loaded (or a virtual page is rendered in a single-page app). It is the oldest web-analytics metric and the easiest to misread: pageviews count loads, not people, and modern apps and prefetching can inflate or hide them. This page defines the metric and its caveats.
- Website observability
Server-side-classified traffic on one fabric.
Sources and verification notes
- MDN — Navigation and page lifecycle (what a script observes)Background on browser-side measurement limits.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.