firm1
commented
3 years ago On en a déjà discuté sur discord, mais j'avoue que je préfère déléguer ce type de taches aux outils qui savent le faire (probablement mieux que nous) quand il en existe.
Pourquoi ?
Les solution 1 et 2 me plaisent moyennement pour trois raisons :
- Étant donné qu'on parle de données statistiques, il suffit que l'on se trompe une fois dans les règles de gestion (comment on filtre un robot d'un vrai utilisateur, oublie d'augmenter le compteur sur une page), ou que celles-ci évoluent, pour rendre caduque une partie de nos informations. La solution 2 est déjà moins problématique car on peut recalculer les anciennes valeurs (en supposant qu'on ait une bonne durée de rétention des logs)
- On va globalement augmenter notre codebase et probablement maintenir ce code sur le terme
- Difficile de faire la séparation entre "pages vues" et "vues uniques" sur un contenu
Je suis plutôt favorable à l'une des options 3 ou 4. Ma préférée étant la 4, parce qu'une fois installé, on peut enlever le bandeau de consentement du site, avoir des stats plutot complètes, et ça me rassure sur les règles de gestions implémentées, puisque matomo est un produit aujourd'hui très mature.
SpaceFox
AmauryCarrade
artragis
Situphen
philippemilink
Bonjour,
Les statistiques des contenus ont été implémentées il y a quelques temps dans #4942 en utilisant l'API de Google Analytics. C'était effectivement une bonne idée afin de se simplifier la vie (après tout, on a déjà des statistiques, autant s'en servir), mais l'on est forcés de constater que concrètement, cette solution ne tient pas la route.
En effet, Google Analytics est massivement bloqué, et l'on constate un énorme gap entre des données statistiques externes et celles reportés dans un contenu. Par exemple, ce billet indique 25 vues le 18 février, quand le tweet de ZdS qui l'a principalement diffusé nous dit que le lien a été cliqué plus d'une centaines de fois (et les statistiques de Twitter sont, elles, fiables).
On ne parle pas d'une petite différence, mais d'un facteur 4, et j'ai déjà constaté un facteur 10.
Je propose donc dans ce ticket plusieurs solutions alternatives pour collecter des statistiques des contenus (et uniquement des contenus).
Méthode 1 — In situ, tout à la main
La première méthode consiste à tout faire nous même. Le concept est simple : pour chaque requête, on collecte les données en temps réel, et on les assemble la nuit.
Concrètement, on aurait deux modèles. Un modèle
tutorialv2.LiveStatistics(ouLiveHits) contiendrait :Dés lors que quelqu'un charge une page d'un contenu, on ajoute un enregistrement horodaté à cette table. Il faudrait exclure les bots, mais la dépendance
user-agentsintroduite par #6021 permet de le faire très simplement (parse(ua_string).is_bot, en gros).Pour éviter d'accumuler une énorme quantité de données et simplifier l'affichage des statistiques, un cron passerait tous les jours à minuit pour assembler toutes les visites d'une journée dans une autre table, disons
tutorialv2.Statistics. Cette table ne contiendrait que quatre champs :Une commande Django ferait l'assemblage et supprimerait les données de la table contenant les données en temps réel.
Pour afficher les statistiques, il suffirait alors de lire cette table, qui contient directement toutes les données. Pour avoir aussi des données en temps réel, on pourrait agréger les données du jour de la table
LiveStatistics(il y en aura beaucoup moins que si on devait le faire avec l'intégralité des vues). Connaître les statistiques en temps réel reste utile, en particulier pour les articles ou billets événementiels.Avantages — Aucune dépendance, fonctionne dans tous les cas, impossible à bloquer, respectueux (on ne stocke aucune donnée personnelle). Inconvénients — On doit tout gérer nous-même.
Méthode 2 — In situ, mais données des différentes journées depuis les logs nginx
C'est le même principe que la première méthode, mais au lieu de collecter les statistiques en temps réel nous-même dans une table
LiveStatistics, on utilise un programme commegoaccesspour lire les logs nginx. Le reste est identique.À noter que ça avait été tenté mais sans succès sur #3785. Cela dit, les outils ont pu évoluer depuis.
Avantages — On utilise des logs déjà existants. Inconvénients — On dépend fortement de l'infrastructure du projet. Ce n'est pas testable sans nginx, et si l'architecture change d'une telle façon qu'on a pas accès aux logs, ça ne fonctionnera plus. Si
logrotatefait tourner les logs durant la journée, les statistiques seront incomplètes (sauf erreur ?).Méthode 3 — Avec Matomo, installé classiquement dans les règles du RGPD
Matomo est un logiciel libre permettant de collecter des statistiques, concurrent direct de Google Analytics. Il est possible de le configurer d'une telle façon qu'il ne soit pas nécessaire de demander leur accord aux visiteurs pour collecter des statistiques, essentiellement car on ne collecte plus de données personnelles (les adresses IP sont tronquées, notamment).
On utiliserait alors les API de Matomo (installé chez nous, a priori ?) pour faire exactement comme aujourd'hui (où l'on utilise les API de Google Analytics).
Avantages — Rien à gérer : Matomo se débrouille pour collecter, filtrer, dé-dupliquer, les statistiques. Inconvénient — Pas mal de gens bloquent Matomo à vue, même s'il est configuré pour être respectueux (car ils ne peuvent pas le savoir). Il me semble que c'est même le cas de Firefox lui-même, par défaut, quand la protection contre le pistage est activée (mais à vérifier) ; il y a donc un risque de retrouver le même genre de problèmes qu'avec Google Analytics.
Méthode 4 — Avec Matomo, mais collecte côté serveur
Matomo permet également de collecter des statistiques côté serveur. On ferait ça (pour toutes les pages du site, du coup ?), et on afficherait les stats comme actuellement, avec les API de Matomo au lieu de Google Analytics.
Avantages — Rien à gérer : Matomo se débrouille pour collecter, filtrer, dé-dupliquer, les statistiques. Impossible à bloquer. Inconvénient — Ça ajoute une requête vers un service externe côté serveur, ce qui peut créer un goulot de performances si Matomo a un souci ou est juste lent. Il n'y a pas de SDK officiel de Matomo pour Python, seulement un SDK non-officiel maintenu par une personne et mis à jour sporadiquement.
Voilà donc ce qu'il en est.
À noter également que ces solutions ne permettent que de suivre le nombre de pages vues uniques, quand actuellement sont disponibles en plus :
Le nombre de session n'est pas particulièrement utile à mon sens. Le nombre de nouveaux visiteurs, ça se discute, et on pourrait réfléchir comment le stocker si on le juge pertinent — en réalité, il y a moyen que ce ne soit pas si complexe en stockant une liste de hash représentant des visiteurs, mais ça commence furieusement à ressembler à des données personnelles et à une ré-implémentation d'un Matomo.
Concernant le temps de lecture et les mots-clefs et liens entrants, on pourrait fonctionner en mode hybride, surtout que ces choses là dépendent moins du nombre de personnes collectées (statistiquement, ça doit se valoir même si on collecte une sous-partie), en récupérant ces données depuis Matomo/Google Analytics, et les vues depuis un système plus efficace.
De manière générale, je trouve qu'il n'est pas embêtant de perdre des données car ça permet de simplifier les statistiques. L'idée est de savoir à quel point on est lu, pas de faire des campagnes marketing avec ces données ^^ .
my two cents
L'objectif de ce ticket est de récolter des avis sur ces différentes méthodes, sur leur pertinence, et sur ce qu'il serait préférable de faire (“rien” étant également une option, mais je trouve que l'état actuel des choses n'est pas idéal). J'attends donc vos retours avec intérêt.
Bonne journée !