Server-side tracking, no tracking cookies

Server-side tracking means the measurement leaves your server, not the visitor's browser. Nothing is loaded on the client, so there is nothing on the client to block, to fail, or to be refused.

This page explains what it is, what it changes, and the two things it is often credited with that it does not do on its own.

How it works

With browser-side measurement, the page loads a script, the script builds a hit, and the hit goes to the analytics provider. Three things have to succeed: the script must load, run, and reach the network.

With server-side measurement, your application already knows that a page was served. It sends the hit itself, from your own code, before the response even leaves the building.

Route::middleware('quiet-metrics')->group(function () {
    Route::get('/', HomeController::class);
});

That is the whole integration in Laravel. To cover all your web traffic at once:

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->appendToGroup('web', \QuietMetrics\Laravel\Middleware\TrackPageview::class);
})

Non-GET requests, error responses, AJAX and requests expecting JSON are ignored automatically, so your APIs and your forms do not pollute your statistics.

Client-side versus server-side

The fourth row is the honest limit, and it cuts the other way. A server never sees a scroll, a rage click or a form abandoned halfway. If those are what you measure, browser-side is not a compromise, it is the requirement.

What it changes

The share of traffic you actually see. This is the whole point. A measurement that does not depend on the browser does not lose the visitors whose browser refuses it.

The page weight. Nothing to download, nothing to execute, nothing in the critical rendering path.

Where the data goes first. The hit goes from your infrastructure to your provider, rather than from your visitor's device to a third party. For some assessments that alone changes the analysis.

What it does not change

Two beliefs come up often enough to be worth naming, because both are wrong.

Server-side tracking is not automatically more private. It can be less. Your server sees the full IP address, the complete user agent, the session, sometimes the logged-in user. A browser script sees less than your own backend does. What protects a visitor is not where the hit starts, it is what the receiver keeps and for how long. Ask any provider that question before the architecture one.

For our part, the mechanism is published in full on the page How we count: a daily salt, destroyed every night, that makes yesterday's fingerprint impossible to recompute, and an IP address that is never stored, nor even used in full in the computation.

Server-side tracking does not remove the consent question. It is not a way around a banner. Whether consent is required depends on your purposes and your configuration, not on the transport. Moving the hit from the browser to the server changes who sends it, not what you do with it. Anyone selling you server-side as a consent exemption is selling you a legal opinion they are not qualified to give, and you are the one who carries it.

Server-side tracking and the GDPR

The publisher of a site is the controller for measuring its own audience; the analytics provider is a processor. That does not change with server-side, and no tool relieves you of it.

What a provider can do is make your assessment shorter. Ours is hosted in France by a single processor, OVH SAS, named in our privacy policy, with no transfer outside the European Union, a signed DPA and retention that applies automatically. That is four questions you do not have to research.

What no provider can do is decide for you whether you need consent. We give you the technical documentation for that analysis, not the conclusion.

Does it use cookies?

No identifying or tracking cookies, and not by design: Quiet Metrics writes nothing on a visitor's device that would make them recognisable from one visit to the next. Distinguishing visitors without identifying them is done with a fingerprint computed from a secret salt that is regenerated every night and then destroyed, which is why the same person cannot be followed from one day to the next.

Two things only can be written on a visitor's device, and neither identifies them. The first exists to stop measurement: the exclusion marker qm_ignore, which the person sets themselves by adding ?qm_ignore=1 to a page address, and removes with ?qm_ignore=0. It holds no identifier, is never sent to us, and covers server-side measurement just as much as the script. The second is the visit continuity cookie qm_visit, set by the measurement for ten sliding minutes: its value is 1 for everyone and it prevents a network change during a visit from counting the same person twice. It is never set on the device of someone who has opted out. The details are on the page How we count.

Server-side does not force this choice, though. A server-side tool can perfectly well set a cookie from your own domain, and several do. The two questions are separate: ask both.

Getting started

Three Composer packages, for plain PHP, Laravel and Symfony, plus a browser script if you want to measure something the server cannot see. The documentation covers each one, and the PHP SDK page has the framework-free version.

If you are weighing this against other tools, the comparison of Google Analytics alternatives lays out the families side by side, including the cases where we are not the right answer.