Le tracking côté serveur, sans pistage

Le tracking côté serveur, c'est une mesure qui part de votre serveur et non du navigateur du visiteur. Rien n'est chargé côté client, donc il n'y a rien à bloquer, rien qui puisse échouer, et rien à refuser.

Cette page explique ce que c'est, ce que cela change, et les deux choses qu'on lui prête souvent et qu'il ne fait pas tout seul.

Comment cela fonctionne

Avec une mesure dans le navigateur, la page charge un script, le script fabrique un hit, et le hit part vers le fournisseur. Trois choses doivent réussir : le script doit se charger, s'exécuter, et atteindre le réseau.

Avec une mesure côté serveur, votre application sait déjà qu'une page a été servie. Elle envoie le hit elle-même, depuis votre code, avant même que la réponse ne parte.

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

C'est toute l'intégration en Laravel. Pour couvrir l'ensemble du trafic web d'un coup :

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

Les requêtes non-GET, les réponses d'erreur, l'AJAX et les requêtes qui attendent du JSON sont ignorés automatiquement : vos API et vos formulaires ne polluent pas vos statistiques.

Navigateur ou serveur

La quatrième ligne est la limite honnête, et elle joue dans l'autre sens. Un serveur ne voit jamais un défilement, un clic de dépit ou un formulaire abandonné en cours de route. Si c'est ce que vous mesurez, le navigateur n'est pas un compromis, c'est l'exigence.

Ce que cela change

La part de trafic que vous voyez réellement. C'est tout l'intérêt. Une mesure qui ne dépend pas du navigateur ne perd pas les visiteurs dont le navigateur la refuse.

Le poids de la page. Rien à télécharger, rien à exécuter, rien dans le chemin critique du rendu.

Où la donnée passe d'abord. Le hit va de votre infrastructure à votre fournisseur, plutôt que de l'appareil de votre visiteur vers un tiers. Pour certaines analyses, cela seul change le raisonnement.

Ce que cela ne change pas

Deux croyances reviennent assez souvent pour qu'il faille les nommer, parce que les deux sont fausses.

Le tracking côté serveur n'est pas automatiquement plus respectueux de la vie privée. Il peut l'être moins. Votre serveur voit l'adresse IP complète, l'agent utilisateur entier, la session, parfois l'utilisateur connecté. Un script de navigateur en voit moins que votre propre back-end. Ce qui protège un visiteur, ce n'est pas l'endroit d'où part le hit, c'est ce que le destinataire en conserve et pendant combien de temps. Posez cette question-là à un fournisseur avant celle de l'architecture.

De notre côté, le mécanisme est publié en entier sur la page Comment nous comptons : un sel quotidien, détruit chaque nuit, qui rend l'empreinte de la veille impossible à recalculer, et une adresse IP jamais enregistrée, ni même retenue en entier dans le calcul.

Le tracking côté serveur ne supprime pas la question du consentement. Ce n'est pas un contournement de bandeau. Le consentement dépend de vos finalités et de votre configuration, pas du transport. Déplacer le hit du navigateur vers le serveur change qui l'envoie, pas ce que vous en faites. Qui vous vend le côté serveur comme une dispense vous vend un avis juridique qu'il n'a pas qualité pour donner, et c'est vous qui le porterez.

Le tracking côté serveur et le RGPD

L'éditeur d'un site est responsable du traitement de la mesure de son audience ; le fournisseur n'est que sous-traitant. Cela ne change pas côté serveur, et aucun outil ne vous en décharge.

Ce qu'un fournisseur peut faire, c'est raccourcir votre analyse. La nôtre est hébergée en France par un seul sous-traitant, OVH SAS, nommé dans notre politique de confidentialité, sans transfert hors de l'Union européenne, avec un DPA signé et une rétention qui s'applique toute seule. Cela fait quatre questions que vous n'avez pas à instruire.

Ce qu'aucun fournisseur ne peut faire, c'est décider à votre place si un consentement est requis. Nous vous donnons la documentation technique pour cette analyse, pas la conclusion.

Est-ce que cela utilise des cookies ?

Aucun cookie d'identification ni de traçabilité, et par construction : Quiet Metrics n'écrit chez le visiteur rien qui permette de le reconnaître d'une visite à l'autre. Distinguer les visiteurs sans les identifier se fait par une empreinte calculée depuis un sel secret régénéré chaque nuit puis détruit, ce qui rend impossible de suivre la même personne d'un jour à l'autre.

Deux choses seulement peuvent être écrites chez le visiteur, et aucune ne l'identifie. La première sert à arrêter la mesure : le marqueur d'exclusion qm_ignore, que la personne pose elle-même en ajoutant ?qm_ignore=1 à l'adresse d'une page, et retire avec ?qm_ignore=0. Il ne contient aucun identifiant, ne nous est jamais transmis, et vaut aussi bien pour la mesure côté serveur que pour le script. La seconde est le cookie de continuité de visite qm_visit, posé par la mesure pour dix minutes glissantes : il vaut 1 chez tout le monde et évite qu'un changement de réseau en cours de visite ne fasse compter deux fois la même personne. Il n'est jamais posé chez quelqu'un qui s'est exclu. Le détail est sur la page Comment nous comptons.

Le côté serveur n'impose pourtant pas ce choix. Un outil côté serveur peut parfaitement déposer un cookie depuis votre propre domaine, et plusieurs le font. Les deux questions sont distinctes : posez les deux.

Pour commencer

Trois paquets Composer, pour PHP simple, Laravel et Symfony, plus un script navigateur si vous voulez mesurer quelque chose que le serveur ne peut pas voir. La documentation couvre chacun, et la page du SDK PHP donne la version sans framework.

Si vous comparez avec d'autres outils, le comparatif des alternatives à Google Analytics présente les familles côte à côte, y compris les cas où nous ne sommes pas la bonne réponse.