Server-side and client-side tracking

How the two methods collect

Client-side tracking runs code in the visitor’s browser, which sends a record to the analytics service as the page loads and each time you record an event. Server-side tracking sends that record from a machine you control: your own backend, or a tagging server your pages post to first. Both reach the tool as an HTTP request. What differs is where the request starts, what the sender can know, and who is responsible for it getting there. The collection methods in general, log files included, are set out in what web analytics is.

Three arrangements sit behind those two words.

The first is a script in the page that talks to the vendor directly. The second is server-side tagging, where the page sends its data to a tagging server you run and that server forwards it: Google recommends the Google Analytics tag on the page as the sender and lists the transport methods it can use, among them an image pixel, the Fetch API, XHR and a service worker. Collection still begins in the browser there. The third is server-to-server collection, where your backend calls the vendor’s intake endpoint with no browser involved, through the Measurement Protocol for Google Analytics 4, the Events API for Plausible or the HTTP tracking API for Matomo. Server-side analytics, as a phrase, usually means the second or the third.

What the browser knows and the server does not

The browser holds the context a page load creates: the referrer, the language, the screen size, route changes inside an application that load no new page, and the fact that the page rendered at all. A server knows none of it unless you send it.

The parameter lists say it plainly. Matomo’s tracking API accepts ua as an override for the User-Agent header, used to detect the operating system and browser, lang as an override for Accept-Language, used to detect the country where geolocation is off, urlref for the referrer and res for the screen resolution. Plausible’s Events API requires the User-Agent header, uses its raw value to calculate the identifier behind unique visitor counting, and fills its browser, operating system and device reports. Google Analytics 4 takes the other approach and joins the most recent geographic and device information from tagging to Measurement Protocol events by client_id, stating that where your tag did not collect device information it defaults to desktop for web streams.

The server knows what the browser never learns: a payment that cleared after the tab was closed, a refund, an order taken over the phone, a subscription that renewed. It also knows figures the browser cannot be trusted with, such as the confirmed value of an order.

What the server route costs to run

The cost is not the code that sends one event. It is everything the browser used to do for you.

You supply the identity. Plausible documents X-Forwarded-For as the way to pass the visitor’s address when the event comes from a backend, and warns that forwarding a server, hosting or delivery network address instead makes its bot filtering drop the event: the API still answers 202 with no obvious error, and the only sign is an x-plausible-dropped header. Matomo’s cip parameter, which overrides the visitor IP, requires a token_auth from a user with write permission, and backdating with cdt beyond 24 hours needs that token too, so your backend now holds a key that can write into your analytics.

You work inside an envelope. A Measurement Protocol request carries at most 25 events and a post body under 130 kB. Events backdate up to 72 hours: with the default validation behaviour an older timestamp is accepted but rewritten to 72 hours ago, and with ENFORCE_RECOMMENDATIONS it is rejected. Events meant to join browser-collected ones should reach Google within 48 hours of the original client-side timestamp. Some event and parameter names are reserved for automatic collection, and rules that generate or rename events in the interface do not run on Measurement Protocol events, so that logic is written again in your code.

You run a server if you take the container route. Google’s Cloud Run setup guide asks for a Google Cloud billing account, recommends a minimum of two instances against the risk of data loss, and expects two to ten servers to handle 35 to 350 requests per second. A tagging server on the default provider domain can set only JavaScript cookies, so first-party serving means a subdomain with a DNS change or same-origin serving through a load balancer, plus entries for that address in your content security policy.

And you own delivery: queues, retries and monitoring become your code. A missing client script shows in the page source, while a backend that stopped sending looks like a quiet month.

Blockers, consent and where the request starts

Blocking acts on requests the browser makes: an extension or a filter that stops one leaves no record of the visit.

A tagging server does not change that by itself, because the browser still makes the first hop. What changes it is the address: a request to your own domain does not match a filter list entry for a vendor domain. Plausible states that its proxy serves the script as a first-party request from your own domain so you keep complete data, which is the vendor’s position rather than a verdict.

Events your backend sends never pass a blocker, which is also the uncomfortable part: they are recorded whether or not the visitor would have agreed. Consent rules do not follow the origin of the request. The European Data Protection Board’s guidelines on the technical scope of Article 5(3) of the ePrivacy Directive state that the article is not limited to cookies but covers similar technologies, and an identifier your server writes into a first-party cookie is still information stored on the device. Data protection law applies separately to personal data, and an IP address can be personal data. Whether your site needs a banner depends on the rules where you and your visitors are, on the configuration and on everything else your pages load. This page is not legal advice; the list of tools that store data in the EU covers storage location, and what cookieless means here covers browser storage.

Why the two sets of numbers never match

Put both on one site and the totals will differ for built-in reasons.

They collect from different populations. The page script misses visits that were blocked or declined; the backend misses everything that never reached it and records things no browser session produced.

Identity is a second reason. A server event joins a browser session only if you pass the identifier that ties them, and Google’s join works through client_id. Without it, one person becomes two records.

Filtering is a third. Bot lists work from the user agent and the address in the request, so an event carrying your server’s user agent and your data centre’s address looks like automated traffic, which is what Plausible documents dropping.

Delivery is a fourth. The tool records what it receives, so a retry in your queue that succeeds twice counts twice, and a job that failed silently counts nothing.

Timing is a fifth. Backdating limits push late records to a boundary rather than to their real moment, so a purchase reported three days later can land on the wrong day. Google states that sending events solely with the Measurement Protocol may leave only partial reporting, and that the protocol supplements automatic collection rather than replacing it.

Which route fits which job

The page script stays the default, since it collects the dimensions reports are built from and costs one line of HTML. Server events earn their keep for money and for anything that happens after the browser has gone: a payment confirmed by a provider, a refund, a cancellation. Server-only collection suits places with no browser, such as a kiosk or a scheduled job, and carries the reporting gaps vendors describe.

The directory records this as a column: 26 of the 44 tools document an intake route of their own, meaning an ingest endpoint or an official server library, and 6 more go part of the way: a proxy on your own domain, a connector that carries one kind of data, or a claim with no endpoint behind it. The table of tools shows it with the date each value was checked, and the methodology explains how it is filled.

Questions and answers

Is server-side tracking more accurate?

Not in general. It removes losses to blockers and consent gates for the events your backend sends, and adds losses of its own: whatever you forget to pass is gone, a wrong address in the forwarding header gets events dropped silently, and a failed job leaves no trace. It is better at recording facts your backend already owns, such as a payment that cleared, while the browser stays the better witness for people reading pages.

Does server-side tracking remove the need for a consent banner?

No. The obligation attaches to what you do with a visitor’s device and personal data rather than to which machine sent the request, and the European Data Protection Board’s guidelines on Article 5(3) state that the rule is not limited to cookies. An identifier written into a first-party cookie by your server is still stored on the device. The answer for one site depends on its jurisdiction, configuration and everything else its pages load.

Does server-side tagging defeat ad blockers?

Only the part that changes the address. A tagging server still receives its first request from the browser, through an image pixel, Fetch, XHR or a service worker, so a filter list can match it like any other. Serving from your own domain is what makes that request harder to match, and events sent from your backend never meet a blocker at all.

Can I run analytics entirely from my own server?

For some tools, yes. Plausible’s Events API, Matomo’s tracking API and other intake endpoints accept pageviews and events with no browser involved, provided you pass the user agent, the address and the referrer yourself. Google is explicit that a Measurement Protocol-only setup may give partial reporting, since tagging supplies geographic and device data.

Which tools accept events sent from a server?

26 of the 44 tools in the table document one, and 6 more offer a partial route, such as a proxy on your own domain. The shape differs: an HTTP endpoint you call directly, a library for your language, or a tagging server that forwards to the vendor. Check what identity data the endpoint expects, whether backdating is allowed and for how long, and what happens to events the vendor drops.