Client-side tracking is the collection of analytics data through a script — typically JavaScript — that executes in a visitor's browser, capturing events like pageviews and clicks and sending them to an analytics server.
Its main advantage is simplicity: a single script tag can be added without backend changes, and it has direct access to browser-level details like screen size and page load timing. Its main weakness is that it depends entirely on the browser cooperating — ad blockers and built-in anti-tracking features can prevent the script from loading or sending data at all, which is why client-side-only setups tend to undercount traffic somewhat.
A tracking script loaded on every page listens for the page finishing load and sends a pageview event to the analytics server — but if a visitor's ad blocker prevents that script from loading, no event is ever recorded for that visit.
Many ad blockers maintain lists of known tracking script domains and block requests to them outright, and because client-side scripts commonly load from third-party analytics domains, they're an easy target for those blocklists.
Yes — it remains the default approach for most analytics tools because of how easy it is to deploy, even as more accuracy-focused setups add server-side tracking alongside it.
Yes — cookieless analytics tools still run client-side scripts to capture events, they simply avoid storing a persistent identifier in the browser to distinguish sessions.