Quel outil d’analytics auto-hébergé sur un VPS ?

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

Les outils d’analyse web auto-hébergés se répartissent en deux familles. Choisir la mauvaise famille vous coûtera 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 access log 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 utilisant un seul fichier. Umami ajoute un conteneur Postgres et fournit un dashboard lisible par une personne non technique. Plausible Community Edition et Rybbit utilisent tous deux ClickHouse : prévoyez donc 2 GB de RAM ou davantage. Matomo est le produit complet et nécessite un serveur dimensionné en fonction de votre trafic. GoAccess n’ajoute rien à la page, car il lit un log qui existe déjà.

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

Une balise de 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 est 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 analyseur 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 le disque. L’analyseur voit tous les crawlers et tous les accès à un fichier qui ne contient aucune balise de script. Il ne peut pas voir ce qui s’est passé dans le navigateur. Il ne peut pas non plus voir une page servie depuis le cache du navigateur ou depuis un CDN (content delivery network) placé devant votre serveur, car cette requête n’a jamais atteint celui-ci.

Les deux nombres ne correspondront pas, et aucun des deux n’est faux. Matomo peut faire les deux. Sa documentation indique ce que l’importation des journaux ne fournit pas par rapport à son tracker JavaScript : résolution d’écran et titres des pages, événements, suivi du contenu, heatmaps, enregistrements de sessions et analyse des formulaires. Cette liste correspond au coût du comptage des requêtes plutôt que des navigateurs.

Le trafic des bots constitue l’autre moitié de l’écart. Les décomptes 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 recommandé d’associer tout comptage fondé sur les journaux au blocage des crawlers IA au niveau du serveur et de consulter le journal après le blocage, et non avant.

GoAccess : analyse à partir des journaux existants

Installez-le depuis le dépôt Debian et Ubuntu du projet, car les paquets des distributions sont en 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-le ensuite 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 standard, car sur Ubuntu, le journal nginx appartient à root et au groupe 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 lue à la connexion. Exécutez id et vérifiez que adm apparaît dans la liste avant de réessayer.

Un rapport généré à 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 ayant subi une rotation.

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

Il existe également un mode live, --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 présente moins de risques à 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 nécessaire. Téléchargez un build depuis la page des releases et exécutez-le, ou utilisez l’image.

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

Exécuté comme binaire, goatcounter serve écoute sur le port 8080 et crée la base SQLite à l’emplacement ./goatcounter-data/db.sqlite3. Créez le premier site depuis la ligne de commande plutôt qu’avec l’assistant web lorsque l’instance est 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 option est utile sur une machine qui n’exécute aucun autre service. Si nginx ou Caddy utilise déjà le port 443, laissez GoatCounter sur le port 8080 et utilisez un proxy vers celui-ci. 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’utilisent pas JavaScript. Si SQLite devient une limite sur un site très fréquenté, le même binaire accepte Postgres avec goatcounter serve -db 'postgresql+dbname=goatcounter'. Les sauvegardes consistent à copier un fichier. C’est le principal avantage de cette architecture.

Medama : un conteneur unique qui annonce 256 MB

Medama est ici la nouvelle option constituée d’un binaire unique. Il n’utilise volontairement aucun cookie et le projet indique un tracker de moins de 1 KB, ainsi que des petits sites exécutés 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 sous 8080:8080. Le préfixe loopback indiqué plus haut est volontaire : la section consacrée au reverse proxy explique pourquoi. La première connexion s’effectue avec admin et le mot de passe CHANGE_ME_ON_FIRST_LOGIN ; le nom de ce mot de passe constitue l’instruction.

Un mode de panne documenté peut vous induire en erreur. La connexion ne fonctionne qu’en HTTPS ou sur localhost. Ainsi, si vous configurez le proxy avant le certificat, le formulaire refuse 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 dashboard que les utilisateurs reconnaissent

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 à côté. La documentation indique PostgreSQL v12.14 comme version minimale, ainsi que 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 se limite à un processus Node et à Postgres. C’est plus lourd qu’un binaire unique, mais beaucoup plus léger que toute solution qui utilise ClickHouse.

Plausible Community Edition : ClickHouse impose un 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 la version actuelle en août 2026, et la commande de clonage 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 officiels de Plausible demandent au moins 2 GB de RAM pour éviter que ClickHouse et l’application ne soient arrêtés par l’out of memory killer, ainsi qu’un CPU prenant en charge SSE 4.2 ou NEON, dont ClickHouse a besoin. Il est utile de vérifier ce second prérequis 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 pense être 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 correspondre exactement à 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 écrit pour un domaine différent de 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 d’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’inscrit donc dans la pile web classique, et non dans une pile de conteneurs. C’est aussi le seul outil présenté ici qui publie des recommandations matérielles selon le volume de trafic.

[
  {
    "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 réalisées pour ce guide. Jusqu’à 100,000 pages vues par mois, Matomo demande 2 cœurs CPU, 2 GB de RAM et 50 GB de SSD. Un seul serveur héberge alors l’application et la base de données. À 1M/month, il faut 8 GB de RAM et 250 GB de disque. À 10M/month, Matomo recommande deux serveurs. La dernière ligne concerne le serveur de base de données : 16 GB de RAM et 400 GB de disque. Comparez ces capacités de stockage aux options mono-binaire, où l’ensemble des données tient dans un seul fichier SQLite.

L’archivage est souvent la principale surprise. Par défaut, Matomo construit ses rapports lorsqu’un utilisateur ouvre le dashboard. À mesure que les données augmentent, le dashboard devient donc plus lent 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 et depuis le répertoire Matomo.

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

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

Rybbit et les stacks plus récentes

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 dashboard moderne. Le script d’installation écrit le fichier d’environnement, puis démarre la stack avec Docker Compose. La stack 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 l’écouter. Utilisez alors la procédure Compose manuelle du projet et placez Rybbit derrière votre proxy existant. La documentation indique au moins 2 GB de RAM, des tests sur Ubuntu 24 LTS et, sur ARM, ARMv8.2-A ou une version ultérieure à cause de ClickHouse.

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

Rétention et croissance du disque : mesurez-la sur votre propre serveur

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

Ce guide ne fournit pas de chiffre en mégaoctets par million de pages vues, car aucune mesure n’a été effectuée sur votre trafic. Faites vous-même la mesure. Adaptez les noms du service et de l’utilisateur à ceux de votre 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 n’importe quelle 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 principale raison de conserver le volume de la base de données à un emplacement où df -h vous avertira. Ce risque mérite encore plus d’attention sur un serveur qui contient déjà quelque chose de volumineux, car un serveur photo auto-hébergé saturera 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 est ainsi considéré comme une requête first party. Il n’est donc pas concerné par les règles du navigateur qui bloquent les requêtes tierces.

Liez l’application à loopback lorsque vous publiez le port du conteneur. Docker écrit ses propres règles de pare-feu avant celles d’ufw. Un conteneur publié avec -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 dashboard. Avec -p 127.0.0.1:3000:3000, le même test renvoie Connection refused, et seul le proxy peut y accéder.

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 semble provenir de 127.0.0.1. Le rapport par pays reste donc vide et le nombre de visiteurs uniques tend vers un. Chaque projet détermine quel en-tête il accepte et avec quel paramètre. Consultez donc sa documentation sur le proxy au lieu de le supposer. Caddy définit lui-même ces en-têtes. Un Caddyfile pour le même usage 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 explique lequel convient à un serveur unique avec quelques sous-domaines.

Faut-il encore afficher une bannière de cookies si vous auto-hébergez votre service ?

L’auto-hébergement change l’entité qui détient les données. Il ne change pas les obligations légales applicables à ces données. Distinguez deux règles. L’obligation de consentement prévue par la directive 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 précise. Le RGPD concerne 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, définir une durée de conservation et répondre aux demandes concernant les données que vous détenez sur une personne.

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

Les autorités de contrôle aboutissent à des conclusions différentes selon les pays. En France, la CNIL publie par exemple les conditions dans lesquelles la mesure d’audience peut être exemptée de consentement. Cette section est un résumé factuel et ne constitue pas un avis juridique. Pour un site réel utilisé par de vrais utilisateurs, consultez un avocat dans votre juridiction.

Un point est souvent oublié : un access log contient lui aussi des données à caractère personnel. GoAccess n’ajoute aucun script à la page et traite malgré tout des adresses IP. Les analytics fondées sur les logs ne sont donc pas automatiquement exclues du champ de ces règles.

Bloqueurs de publicité : pourquoi vos chiffres vont baisser

Les listes de filtrage font correspondre les noms d’hôte et les motifs d’URL. Un produit d’analytics hébergé est facile à détecter, car tout le monde le charge depuis le même nom d’hôte bien connu. En déplaçant le collecteur vers votre propre sous-domaine, vous retirez ce nom d’hôte de la requête. En servant le script depuis le chemin de votre choix, vous retirez également le nom de fichier bien connu. Ces deux changements modifient les éléments sur lesquels une liste doit effectuer la correspondance.

Cet article n’avance aucun taux de détection, car il n’en a pas mesuré. La part des 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 rapportées par votre outil basé sur un script. La différence correspond aux visites bloquées et aux pages servies depuis le cache sur votre site.

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

Quel outil pour quel site

• Un site personnel ou un blog avec 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 dont l’audience bloque fortement les scripts : GoAccess à partir du journal existant, exécuté selon une planification.
• 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 tunnels de conversion, sur une machine disposant d’au moins 2 GB de RAM : Plausible Community Edition, ou Rybbit si vous voulez le nouveau tableau de bord et acceptez un projet moins mature.
• De nombreux 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 besoin réel. Passer de GoatCounter à Plausible vous coûtera plus tard un sous-domaine et une partie de l’historique. Passer de Matomo à un autre outil vous imposera une migration que vous préférerez éviter. Si vous cherchez encore ce qui peut être installé sur la même machine, le comparatif plus large de l’auto-hébergement présente les services qui peuvent y trouver leur place. Si votre véritable besoin est le traçage des requêtes d’une application plutôt que le comptage des visiteurs, un service d’observabilité auto-hébergé est l’outil adapté.

FAQ

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

Non, et ces deux questions sont distinctes. La règle du paquet ePrivacy couvre 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 couvre le traitement des données personnelles. Une adresse IP est une donnée personnelle : 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 selon votre situation.

De combien de RAM un outil d’analytics auto-hébergé a-t-il 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 les chiffres de mon outil auto-hébergé sont-ils inférieurs à ceux de l’outil d’analytics que j’ai remplacé ?

Deux causes expliquent ce résultat, et elles sont toutes les deux réelles. Les listes de filtrage bloquent certaines requêtes vers le collector. Tous les outils basés sur un script perdent donc ces visites. Les produits comptent également les visites différemment, car la définition d’une page vue et le moment où une session se termine varient selon l’outil. Comparez les requêtes de pages HTML enregistrées dans votre access log pendant une semaine avec les pages vues basées sur un script pour la même semaine. L’écart correspond aux visites bloquées et aux pages mises en cache, mesurées sur votre propre site plutôt que déduites d’un taux publié par un tiers.

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

Les deux utilisent ClickHouse. ClickHouse nécessite SSE 4.2 sur x86 ou NEON sur ARM. Les prérequis de Plausible l’indiquent précisément, et la documentation de Rybbit précise que les systèmes ARM doivent utiliser ARMv8.2-A ou une version ultérieure. Les cœurs ARM actuels pour serveurs respectent ce prérequis, contrairement aux anciens. L’échec se manifeste lorsque ClickHouse refuse de démarrer avec une erreur liée au jeu d’instructions, et non dans les journaux 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 journaux du serveur au lieu d’utiliser un script de tracking ?

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