SSD Nodes Learn Hosting plans →
Guides Matt ConnorPar Matt Connor · Mis à jour le 2026-08-28

Analytics web auto-hébergé : quel outil sur un VPS ?

Comparez Plausible, Umami, Matomo, GoatCounter et GoAccess : RAM, base de données, croissance du disque, reverse proxy et visiteurs bloqués par les ad blockers.

Quel outil d’analytics web auto-hébergé devriez-vous exécuter sur un VPS ?

L’analytics web auto-hébergé se divise en deux familles. Choisir la mauvaise famille vous coûte plus cher que choisir le mauvais produit. La première exécute un petit script dans le navigateur du visiteur et stocke les données rapportées par ce script. La seconde lit le journal d’accès que votre serveur web écrit déjà. Tout le reste, notamment la base de données et la mémoire nécessaire, découle de ce choix.

La réponse courte pour un petit serveur. GoatCounter et Medama tiennent sur 1 GB, car chacun se compose d’un seul processus qui utilise un seul fichier. Umami ajoute un conteneur Postgres et fournit un tableau de bord lisible par une personne non technique. Plausible Community Edition et Rybbit utilisent tous deux ClickHouse. Prévoyez donc 2 GB de RAM ou plus. Matomo est le produit complet et nécessite un serveur dimensionné en fonction de votre trafic. GoAccess n’ajoute absolument rien à la page, car il lit un journal qui existe déjà.

Balise script ou journal du serveur : ce que chacun peut voir

Une balise script mesure les navigateurs. La page se charge, le script s’exécute, puis il envoie une requête à votre collecteur. Tout ce qui interrompt cette chaîne vous reste invisible : JavaScript désactivé, liste de filtrage qui bloque la requête, échec de la requête vers le collecteur ou crawler qui n’exécute jamais les scripts.

Un parseur de journaux mesure les requêtes. Votre serveur web écrit une ligne pour chaque requête, que vous installiez quelque chose ou non. Les données sont donc déjà stockées sur disque. Il voit tous les crawlers et tous les accès à un fichier qui ne contient aucune balise script. Il ne peut pas voir ce qui s’est passé dans le navigateur. Il ne peut pas non plus voir une page fournie depuis le cache du navigateur ou depuis un CDN (content delivery network) placé devant votre serveur, car cette requête n’a jamais atteint votre serveur.

Les deux nombres ne correspondront pas. Aucun des deux n’est faux. Matomo peut utiliser les deux méthodes et documente les données perdues par l’importation des journaux par rapport à son JavaScript tracker : résolution d’écran et titres des pages, événements, suivi du contenu, heatmaps, enregistrements de sessions et analytics des formulaires. Cette liste représente le coût du comptage des requêtes au lieu des navigateurs.

Le trafic des bots explique l’autre moitié de l’écart. Les comptages fondés sur les journaux incluent les crawlers, sauf si vous les filtrez. Sur un site courant, leur part est suffisamment importante pour modifier vos conclusions. GoAccess et l’importation des journaux de Matomo filtrent tous deux les bots connus. Aucun des deux ne peut filtrer un crawler qui falsifie son user agent. Il est donc préférable d’associer tout comptage fondé sur les journaux au blocage des crawlers d’IA sur le serveur, puis de lire le journal après le blocage et non avant.

GoAccess : analysez les données des journaux existants

Installez-le depuis le dépôt Debian et Ubuntu officiel du projet, car les paquets des distributions ont souvent du retard sur les releases.

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg arch=$(dpkg --print-architecture)] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Pointez ensuite l’outil vers le journal et générez un rapport statique.

goaccess /var/log/nginx/access.log -o ~/report.html --log-format=COMBINED

Cette commande échoue avec Permission denied pour un utilisateur ordinaire, car sur Ubuntu le journal nginx appartient à root et à un groupe nommé adm. Ajoutez votre compte à ce groupe avec sudo usermod -aG adm $USER, puis déconnectez-vous et reconnectez-vous, car l’appartenance aux groupes est prise en compte lors de la connexion. Exécutez id et vérifiez que adm apparaît dans la liste avant de réessayer.

Un rapport établi à partir du journal actif ne couvre que les entrées que logrotate n’a pas encore déplacées. Les requêtes d’hier se trouvent dans access.log.1 et les plus anciennes sont compressées. Une vue hebdomadaire doit donc également lire les fichiers archivés.

zcat /var/log/nginx/access.log.*.gz | goaccess - --log-format=COMBINED -o ~/last-week.html

Il existe aussi un mode temps réel, --real-time-html, qui met à jour la page via un WebSocket. Il nécessite un second port et sa propre règle de proxy. Pour la plupart des sites, un rapport horaire généré par cron suffit et réduit la surface à sécuriser.

GoatCounter : un binaire Go et un fichier SQLite

GoatCounter est fourni sous la forme d’un binaire compilé statiquement. Aucun runtime n’est donc à installer. Téléchargez une build depuis la page des releases et exécutez-la, ou utilisez l’image.

docker run -p 8080:8080 -v goatcounter-data:/home/goatcounter/goatcounter-data arp242/goatcounter

Lancé comme binaire, goatcounter serve écoute sur le port 8080 et crée la base SQLite à ./goatcounter-data/db.sqlite3. Créez le premier site depuis la ligne de commande plutôt qu’avec l’assistant web lorsque l’instance se trouve déjà derrière un proxy.

goatcounter db create site -vhost=stats.example.com -user.email=me@example.com

Il peut gérer lui-même son certificat avec goatcounter serve -listen=:443 -tls=tls,rdr,acme en utilisant ACME (automatic certificate management environment). Cette approche est utile sur un serveur qui n’exécute aucun autre service. Si nginx ou Caddy utilise déjà le port 443, laissez GoatCounter sur le port 8080 et faites suivre les requêtes vers lui avec un proxy. D’après les chiffres du projet, le script de suivi fait environ 3.5K. Un pixel de suivi est également disponible pour les pages qui n’embarquent pas de JavaScript. Si SQLite devient le facteur limitant sur un site très fréquenté, le même binaire peut utiliser Postgres avec goatcounter serve -db 'postgresql+dbname=goatcounter'. Les sauvegardes consistent à copier un fichier. C’est le principal avantage de cette forme d’outil.

Medama : un conteneur unique qui annonce 256 MB

Medama est ici la plus récente des options sous forme de binaire unique. Il n’utilise volontairement pas de cookies, et le projet annonce un tracker de moins de 1 KB ainsi que des petits sites fonctionnant sur des machines virtuelles avec 256 MB de mémoire. Il s’agit des chiffres publiés par le projet, et non de mesures effectuées pour ce guide.

docker volume create medama-data
docker run -d -p 127.0.0.1:8080:8080 -v medama-data:/app/data ghcr.io/medama-io/medama:latest

La commande officielle publie le port sur 8080:8080. Le préfixe loopback indiqué plus haut est intentionnel ; la section consacrée au reverse proxy explique pourquoi. La première connexion utilise admin avec le mot de passe CHANGE_ME_ON_FIRST_LOGIN, et le nom de ce mot de passe correspond à l’instruction.

Un mode d’échec documenté peut vous induire en erreur. La connexion fonctionne uniquement via HTTPS ou sur localhost. Si vous configurez le proxy avant le certificat, le formulaire rejette un mot de passe correct sans afficher la raison. Terminez d’abord la configuration TLS (transport layer security), puis connectez-vous.

Umami : PostgreSQL et un tableau de bord familier

git clone https://github.com/umami-software/umami.git
cd umami
docker compose up -d

Cette commande démarre l’application sur le port 3000 avec un conteneur PostgreSQL à ses côtés. La documentation indique PostgreSQL v12.14 comme version minimale et Node.js 18.18 ou une version ultérieure si vous compilez l’application depuis les sources. Une image précompilée est disponible : docker.umami.is/umami-software/umami:postgresql-latest. Elle nécessite que DATABASE_URL pointe vers une base de données que vous exécutez déjà.

La première connexion utilise admin avec le mot de passe umami. Modifiez-le avant de faire pointer le DNS vers le serveur, car l’instance devient accessible depuis Internet dès que l’enregistrement est résolu et que le proxy répond. Pour les détails de Compose, les fichiers d’environnement et la policy de redémarrage, consultez une stack Docker Compose sur un VPS au lieu de copier une stack que vous n’avez pas lue.

L’empreinte comprend un processus Node et Postgres. C’est plus lourd qu’un binaire unique, mais beaucoup plus léger que tout ce qui utilise ClickHouse.

Plausible Community Edition : ClickHouse fixe le minimum de RAM

git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce
cd plausible-ce
touch .env
echo "BASE_URL=https://stats.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
docker compose up -d

La version v3.2.1 est actuelle en août 2026, et la commande clone la fixe volontairement. La stack comporte trois éléments : l’application, Postgres pour les comptes et les paramètres, et ClickHouse pour les données d’événements. SECRET_KEY_BASE doit être une chaîne d’au moins 64 octets, ce que produit l’appel openssl.

Les prérequis de Plausible demandent au moins 2 GB de RAM afin que ClickHouse et l’application ne déclenchent pas l’out of memory killer, ainsi qu’un CPU compatible avec SSE 4.2 ou NEON, dont ClickHouse a besoin. Il est préférable de vérifier ce second point avant l’achat. C’est l’une des différences pratiques à prendre en compte pour choisir entre un VPS ARM et un VPS x86. ClickHouse utilise également autant de mémoire qu’il estime disponible. Sur un serveur partagé, définissez donc une limite comme indiqué dans la limitation de la mémoire des conteneurs dans Compose.

BASE_URL doit être exactement égal à l’URL publique. Si ce n’est pas le cas, vous vous connectez, l’application vous redirige vers le mauvais hôte et le cookie de session est enregistré pour un domaine qui ne correspond pas à celui utilisé par votre navigateur. Vous revenez alors au formulaire de connexion sans message d’erreur.

Le fichier Compose fourni ne publie aucun port, car il est prévu qu’un proxy soit placé devant l’application. Ajoutez un fichier override qui publie le port par défaut de l’application sur loopback uniquement.

cat > compose.override.yml << EOF
services:
    plausible:
        ports:
            - 127.0.0.1:8000:8000
EOF

Matomo : le produit complet et le serveur dont il a besoin

Matomo fonctionne avec PHP et MySQL ou MariaDB. Il s’intègre donc à la stack web classique plutôt qu’à une stack de conteneurs. C’est aussi le seul outil de cette sélection qui publie des recommandations matérielles selon le volume de trafic.

ChartMatomo sizing guidance by monthly pageviews
The data behind this chart
[
  {
    "label": "100K/month",
    "cpu_cores": 2,
    "ram_gb": 2,
    "disk_gb": 50
  },
  {
    "label": "1M/month",
    "cpu_cores": 4,
    "ram_gb": 8,
    "disk_gb": 250
  },
  {
    "label": "10M/month",
    "cpu_cores": 8,
    "ram_gb": 16,
    "disk_gb": 400
  }
]

Il s’agit des minimums publiés par Matomo en août 2026, et non de mesures effectuées pour ce guide. Jusqu’à 100,000 pages vues par mois, Matomo demande 2 cœurs CPU, 2 Go de RAM et 50 Go de SSD. Un seul serveur héberge alors l’application et la base de données. À 1M/month, il faut 8 Go de RAM et 250 Go de disque. À 10M/month, Matomo recommande deux serveurs. La dernière ligne concerne le serveur de base de données : 16 Go de RAM et 400 Go de disque. Comparez ces valeurs de stockage aux options autonomes, où l’ensemble des données tient dans un seul fichier SQLite.

L’archivage est souvent le point qui surprend. Par défaut, Matomo génère les rapports lorsqu’un utilisateur ouvre le dashboard. À mesure que les données augmentent, le dashboard ralentit et finit par expirer. La correction documentée consiste à désactiver l’archivage déclenché par le navigateur dans les paramètres généraux, puis à exécuter l’archiver depuis cron, avec l’utilisateur propriétaire des fichiers Matomo, dans le répertoire Matomo.

php console core:archive --url=https://analytics.example.com

Matomo conserve également les tables de logs bruts à côté des tables de rapports traités. Il peut supprimer périodiquement les anciennes données brutes et les anciens rapports. Activez cette fonction lors de l’installation, et non lorsque le disque est plein. Matomo peut aussi importer les logs d’accès du serveur. C’est donc le seul produit de cette sélection qui couvre les deux familles à la fois.

Rybbit et les stacks plus récents

git clone https://github.com/rybbit-io/rybbit.git
cd rybbit
chmod +x *.sh
./setup.sh your.domain.name

Rybbit est un projet récent doté d’un tableau de bord moderne. Le script d’installation écrit le fichier d’environnement et démarre la stack avec Docker Compose. Il exécute ClickHouse et fournit Caddy comme serveur web. Caddy utilise le port 443 et demande un certificat pour le domaine que vous avez indiqué. Sur un serveur où nginx utilise déjà le port 443, le script ne pourra pas s’y attacher. Utilisez donc la procédure Compose manuelle du projet et placez-le derrière votre proxy existant. La documentation indique au moins 2 GB de RAM. Elle mentionne aussi des tests sur Ubuntu 24 LTS et exige ARMv8.2-A ou une version ultérieure sur ARM en raison de ClickHouse.

Pour tout projet récent, la réserve est simple : les fonctionnalités arrivent rapidement, tout comme les changements incompatibles. Épinglez un tag, lisez les notes de version avant de faire un pull et effectuez d’abord une sauvegarde de la base de données.

Mesurez la rétention et la croissance du stockage sur votre propre serveur

La croissance du stockage dépend de ce que l’outil enregistre pour chaque événement. GoatCounter agrège les visites dans des compteurs : sa base augmente donc davantage avec le nombre de pages distinctes et de jours qu’avec le volume brut. Umami et Matomo enregistrent une ligne par événement. Matomo stocke en plus des tables de rapports traitées. ClickHouse stocke les événements en colonnes et les compresse fortement. C’est pourquoi Plausible supporte un volume qui mettrait à rude épreuve une base de données orientée lignes.

Ce guide ne donne pas de valeur en mégaoctets par million de pages vues, car aucune mesure n’a été effectuée sur votre trafic. Faites la mesure vous-même. Adaptez les noms du service et de l’utilisateur à votre propre fichier Compose.

du -h goatcounter-data/db.sqlite3
docker compose exec db psql -U umami -d umami -c "SELECT pg_size_pretty(pg_database_size('umami'));"
docker compose exec plausible_events_db clickhouse-client -q "SELECT formatReadableSize(sum(bytes_on_disk)) FROM system.parts WHERE active"

Notez la valeur, attendez une semaine, puis relevez-la de nouveau. Divisez la différence par le nombre de pages vues indiqué par le dashboard pour cette semaine. Cette valeur correspond à votre site et à votre filtrage des bots. Elle est donc plus utile que toute moyenne publiée. Définissez ensuite une limite de rétention tant que la valeur reste faible. Un disque plein arrête tous les services du VPS, pas seulement l’outil d’analytics. C’est la meilleure raison de conserver le volume de la base de données à un emplacement dont df -h vous avertira. Ce risque mérite une attention particulière sur un serveur qui héberge déjà des données volumineuses, car un serveur photo auto-hébergé remplira le disque bien avant qu’une base de données d’analytics ne s’en approche.

Fonctionnement derrière un reverse proxy sur un sous-domaine

Placez le collector sur un sous-domaine du site qu’il mesure, par exemple stats.example.com. Le collector devient ainsi une requête first-party. Les règles du navigateur qui bloquent les requêtes third-party ne s’appliquent donc pas.

Liez l’application à loopback lorsque vous publiez le port du conteneur. Docker ajoute ses propres règles de pare-feu avant celles d’ufw. Un conteneur publié sur -p 3000:3000 reste donc accessible depuis Internet, même si ufw status indique que le port est refusé. Testez-le depuis une autre machine avec curl http://SERVER_IP:3000 : vous obtiendrez le tableau de bord. Avec une publication sur -p 127.0.0.1:3000:3000, le même test renvoie Connection refused et seul le proxy peut y accéder. Cette précaution ne sert pas uniquement à masquer un tableau de bord. Elle est essentielle pour exécuter un service onion sur le même serveur, car tout service qui répond encore sur l’interface publique peut relier l’adresse cachée à votre IP. Le endpoint du collecteur doit rester accessible depuis Internet, mais pas le tableau de bord. Si vous préférez le consulter via un réseau privé plutôt que de publier un second sous-domaine, annoncer le réseau du VPS à votre tailnet avec un subnet router permet d’y accéder sans ouvrir de port.

server {
    listen 443 ssl;
    server_name stats.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Les en-têtes de forwarding sont indispensables ici. Sans X-Forwarded-For, chaque visite arrive depuis 127.0.0.1. Le rapport par pays reste alors vide et le nombre de visiteurs uniques tend vers 1. Chaque projet détermine quel en-tête il approuve et avec quel paramètre. Consultez donc une fois sa documentation consacrée au proxy au lieu de supposer le comportement. Caddy définit lui-même ces en-têtes. Avec Caddy, un Caddyfile pour cette même configuration tient en deux lignes.

stats.example.com {
    reverse_proxy 127.0.0.1:3000
}

Si vous n’avez pas encore choisi de proxy, la comparaison de nginx, Caddy et Traefik indique lequel convient à un serveur unique hébergeant quelques sous-domaines.

Avez-vous encore besoin d’une bannière de cookies si vous auto-hébergez vos services ?

L’auto-hébergement change qui détient les données. Il ne change pas ce que la loi prévoit pour ces données. Distinguez bien deux règles. La règle du consentement prévue par l’ePrivacy concerne le stockage ou la lecture de toute donnée sur l’appareil du visiteur. Un outil qui ne définit aucun cookie et n’écrit rien dans le stockage local n’est donc pas soumis à cette exigence précise. Le RGPD concerne le traitement des données personnelles. Une adresse IP est une donnée personnelle. Vous avez donc toujours besoin d’une base légale, d’une durée de conservation et d’une réponse lorsqu’une personne demande quelles données vous détenez à son sujet.

Plausible, Umami, GoatCounter et Medama ne définissent aucun cookie par défaut. Les données que chacun déduit à la place varient selon le projet et peuvent changer d’une version à l’autre. Consultez donc la documentation de confidentialité du projet, plutôt qu’un résumé. Matomo fournit l’anonymisation des adresses IP et un endpoint d’opt-out que vous activez dans l’interface d’administration.

Les autorités de régulation arrivent à des conclusions différentes selon les pays. La CNIL française publie, par exemple, les conditions dans lesquelles la mesure d’audience peut être exemptée de consentement. Cette section présente un résumé factuel et ne constitue pas un avis juridique. Pour un site réel avec de vrais utilisateurs, demandez conseil à un avocat dans votre juridiction.

Un point est souvent oublié : un access log constitue lui aussi une donnée personnelle. GoAccess n’ajoute aucun script à la page, mais traite tout de même les adresses IP. Les analytics fondées sur les logs ne sont donc pas automatiquement exclues de ces règles. Déplacer un service sur votre propre serveur déplace l’exposition au lieu de la supprimer. C’est aussi pourquoi ce que masque réellement une instance SearXNG auto-hébergée s’arrête aux moteurs de recherche, alors que les requêtes elles-mêmes arrivent toujours dans vos propres logs.

Bloqueurs de publicité : pourquoi vos chiffres vont baisser

Les listes de filtrage font des correspondances sur le hostname et sur des motifs d’URL. Un produit d’analytics hébergé est facile à identifier, car tout le monde le charge depuis le même hostname bien connu. Déplacer le collector vers votre propre sous-domaine retire ce hostname de la requête. Servir le script depuis un chemin de votre choix retire aussi le nom de fichier bien connu. Ces deux changements modifient les éléments sur lesquels une liste doit faire une correspondance.

Cet article n’avance aucun taux de détection, car il n’en a pas mesuré. La proportion de visiteurs qui bloquent une configuration donnée dépend de votre audience. Une audience de développeurs bloque beaucoup plus qu’une audience générale. Mesurez plutôt votre propre écart. Pendant la même semaine, comptez avec GoAccess les requêtes correspondant aux pages HTML dans l’access log, puis comparez ce nombre aux pages vues indiquées par votre outil basé sur un script. Sur votre site, la différence correspond aux visites bloquées et aux pages servies depuis le cache.

Attendez-vous à ce que les totaux changent le jour où vous abandonnez un produit hébergé. Une partie de cette variation n’aura toutefois rien à voir avec le blocage. Les produits ne définissent pas tous une page vue de la même manière. Ils ne comptent pas nécessairement de la même façon un changement de route dans une single-page application. Ils ne considèrent pas non plus qu’une session se termine au même moment. Comparez les tendances sur plusieurs semaines avant de conclure que le trafic a baissé.

Lequel pour quel site

  • Un site personnel ou un blog qui reçoit environ 50,000 pages vues par mois au maximum : GoatCounter ou Medama, sur un VPS de 1 GB, avec des sauvegardes sous forme de copie de fichiers.
  • Un site sur lequel vous ne pouvez pas ajouter de script, ou destiné à un public qui bloque fortement les scripts : GoAccess sur le journal existant, à intervalles réguliers.
  • Un site de petite entreprise dont le tableau de bord est consulté par une autre personne : Umami, avec son conteneur Postgres.
  • Un site pour lequel vous voulez suivre des objectifs et des funnels, sur une machine dotée d’au moins 2 GB de RAM : Plausible Community Edition, ou Rybbit si vous voulez le nouveau tableau de bord et acceptez un projet plus récent.
  • Plusieurs sites, de nombreux comptes utilisateur ou l’obligation de conserver les données brutes selon votre propre politique de rétention : Matomo, dimensionné selon les recommandations publiées plus haut.

Commencez par l’outil le plus simple qui répond à votre question réelle. Passer de GoatCounter à Plausible plus tard vous coûtera un sous-domaine et une partie de l’historique. Passer de Matomo à un autre outil vous imposera une migration que vous n’apprécierez pas. Si vous cherchez encore quels autres services installer sur la même machine, le comparatif plus large de l’auto-hébergement indique ceux qui peuvent y cohabiter. Si vous voulez en réalité tracer les requêtes d’une application plutôt que compter les visiteurs, un service d’observabilité auto-hébergé est l’outil adapté.

FAQ

L’auto-hébergement d’un outil d’analyse dispense-t-il d’une bannière de cookies ?

Non, et ces deux questions sont distinctes. La règle du consentement prévue par ePrivacy concerne le stockage ou la lecture d’informations sur l’appareil du visiteur. Un outil qui ne définit aucun cookie et n’écrit rien dans le stockage local n’est donc pas soumis à cette exigence particulière. Le RGPD relève d’une autre règle et encadre le traitement des données à caractère personnel. Une adresse IP est une donnée à caractère personnel : vous devez donc toujours disposer d’une base légale et définir une durée de conservation, même sans cookie. L’auto-hébergement transfère les données sur votre serveur et fait de vous la partie responsable de leur traitement. Consultez les recommandations de votre autorité de contrôle et demandez conseil à un avocat pour votre situation.

De combien de RAM l’analyse auto-hébergée a-t-elle besoin sur un VPS ?

C’est le datastore qui détermine les besoins, pas le dashboard. GoatCounter et Medama s’exécutent comme un seul processus et utilisent un seul fichier. La documentation de Medama indique que les petits sites fonctionnent sur des machines disposant de 256 MB. Umami ajoute un conteneur Postgres à côté d’une application Node. Plausible Community Edition et Rybbit utilisent tous deux ClickHouse, et les deux projets indiquent un minimum de 2 GB. Les recommandations de Matomo commencent à 2 cœurs CPU et 2 GB de RAM pour un maximum de 100,000 pages vues par mois.

Pourquoi mes chiffres auto-hébergés sont-ils inférieurs à ceux de l’outil d’analyse que j’ai remplacé ?

Deux causes expliquent ce résultat, et elles sont toutes les deux réelles. Les filter lists bloquent certaines requêtes du collector. Tous les outils fondés sur un script perdent donc ces visites. Les produits comptent également les visites différemment : la définition d’une page vue et le moment où une session se termine varient selon l’outil. Comparez les requêtes HTML correspondant aux pages de votre access log sur une semaine avec les pages vues mesurées par script pendant la même semaine. L’écart correspond aux visites bloquées et aux pages servies depuis le cache, mesurées sur votre propre site plutôt qu’à partir d’un taux publié par un tiers.

Puis-je exécuter Plausible ou Rybbit sur un VPS ARM ?

Les deux utilisent ClickHouse, qui nécessite SSE 4.2 sur x86 ou NEON sur ARM. Les exigences de Plausible le précisent exactement, et la documentation de Rybbit indique que les systèmes ARM doivent utiliser ARMv8.2-A ou une version ultérieure. Les cœurs ARM actuels des serveurs satisfont cette exigence, contrairement aux anciens. L’échec se manifeste par le refus de démarrer de ClickHouse avec une erreur de jeu d’instructions, et non par un message dans le log de l’application. Sur une petite machine ARM, les outils utilisant un seul fichier évitent cette contrainte, car aucun d’eux n’exécute ClickHouse.

Dois-je analyser les logs du serveur au lieu d’utiliser un script de tracking ?

Utilisez l’analyse des logs lorsque vous ne pouvez pas ajouter de script, lorsque votre audience bloque fortement les outils de tracking ou lorsque vous voulez inclure les crawlers dans le décompte. GoAccess lit un log que votre serveur écrit déjà. Il n’ajoute donc ni poids aux pages ni base de données. En contrepartie, vous ne voyez rien de ce qui se passe dans le navigateur. Vous manquez également les pages servies depuis un CDN ou le cache du navigateur, car la requête n’atteint jamais votre serveur. De nombreux sites utilisent les deux méthodes et les considèrent comme deux mesures différentes.