[plugin] plnStatistiques - les statistiques de visites de votre site
Bonjour à tous,
Suite à la discussion qui a débuté là, voici mon plugin de statistiques :
plnStatistiques v0.5 béta
Ses grandes fonctionnalités :
- 100% esprit "pluXml", c'est à dire léger et pas de bases de données.
- 100% "interne", c'est à dire sans appel externe (à la différence de google analytics par exemple)
- Suivi des visites (côté "site"), du nombre de visiteurs uniques (1 visiteur unique = 1 ip), du nombre de pages demandées
- Affichage des statistiques côté administration (avec des jolis graphiques basés sur Chart.js, que j'ai choisi du fait de sa licence MIT)
- Possibilité de choisir le nombre de jours conservés dans l'écran de configuration du plugin (après 2 jours de stockage, le plugin offre même des informations de suivi du poids du fichier de stockage dans cet écran)
- Aucun affichage côté site
Le plugin est encore en version Béta, même s'il est pleinement fonctionnel en l'état. Je n'ai aucune idée de son comportement à long terme (aucun test de charge effectué).
Ma grande problématique à ce stade du développement est de réussir à séparer les robots des visiteurs humains. J'ai installé le plugin sur un de mes sites et les visites que j'ai sont, à mon avis, à 90% des robots. Cela casse complètement l'intérêt du suivi des statistiques... Si vous avez des idées, je suis preneur
Si vous souhaitez utiliser le plugin, je serais ravi d'avoir des retours sur son fonctionnement (notamment taille de plxStatistiques_before.xml, nombre de visiteurs unique à la journée, et vos impressions sur le nombre de robots/visiteurs sur le total). Tout autre remarque sera la bienvenue, que ce soit par exemple sur l'affichage, sur les indicateurs enregistrés ou sur d'autres fonctionnalités que vous aimeriez bien voir apparaître.
Suite à la discussion qui a débuté là, voici mon plugin de statistiques :
plnStatistiques v0.5 béta
Ses grandes fonctionnalités :
- 100% esprit "pluXml", c'est à dire léger et pas de bases de données.
- 100% "interne", c'est à dire sans appel externe (à la différence de google analytics par exemple)
- Suivi des visites (côté "site"), du nombre de visiteurs uniques (1 visiteur unique = 1 ip), du nombre de pages demandées
- Affichage des statistiques côté administration (avec des jolis graphiques basés sur Chart.js, que j'ai choisi du fait de sa licence MIT)
- Possibilité de choisir le nombre de jours conservés dans l'écran de configuration du plugin (après 2 jours de stockage, le plugin offre même des informations de suivi du poids du fichier de stockage dans cet écran)
- Aucun affichage côté site
Le plugin est encore en version Béta, même s'il est pleinement fonctionnel en l'état. Je n'ai aucune idée de son comportement à long terme (aucun test de charge effectué).
Ma grande problématique à ce stade du développement est de réussir à séparer les robots des visiteurs humains. J'ai installé le plugin sur un de mes sites et les visites que j'ai sont, à mon avis, à 90% des robots. Cela casse complètement l'intérêt du suivi des statistiques... Si vous avez des idées, je suis preneur
Si vous souhaitez utiliser le plugin, je serais ravi d'avoir des retours sur son fonctionnement (notamment taille de plxStatistiques_before.xml, nombre de visiteurs unique à la journée, et vos impressions sur le nombre de robots/visiteurs sur le total). Tout autre remarque sera la bienvenue, que ce soit par exemple sur l'affichage, sur les indicateurs enregistrés ou sur d'autres fonctionnalités que vous aimeriez bien voir apparaître.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Une alternative simple et ergonomique, pour connaître seulement le nombre de visites, en restant dans l'interface de PluXml
Je n'ai pas encore testé, mais je l'ai téléchargé.
Merci Gari !
Quelques petites modifications, exclusivement tournées vers la distinction "humain" vs "robot".
J'ai rajouté la possibilité de modifier un regex de sélection de robot dans la partie config. Cela permet, en testant HTTP_USER_AGENT, de déterminer si le visiteur est humain ou non. Bien entendu, ce n'est pas fiable à 100%, mais ça donne déjà une bonne idée. Je vous laisse tester
=> Les statistiques de la journée sont à présent découpées en "robots" et "humains". Les statistiques passées affichent toujours tout, mais je compte ne leur faire afficher que les statistiques des humains : après tout, c'est ce qui nous intéresse au premier chef.
Je rappelle que c'est toujours une version béta.
++
Quand aux stats par article, je vais y réfléchir. Le principal problème est le poids du fichier de stockage des données, à mon avis.
-> Ce serait bien de pouvoir gérer les droits en fonction des types de comptes (administrateur, Gestionnaire...) histoire qu'un éditeur ou autres puissent accéder aux stats
@Jormun : Nous sommes sur la même longueur d'onde. En l'occurrence, lors d'une visite le plugin ne fait déjà que de l'écriture, aucun travail de statistiques. J'ai un fichier "quotidien" dont le contenu, une fois par jour jour, se déverse dans un fichier "passé", ainsi le fichier de travail quotidien n'est jamais gros : quelle que soit la taille des archives des statistiques, le temps de traitement d'une visite est le même.
J'ai pensé à faire de l'agrégation, pour l'instant je repousse cette tâche, je la mettrai en place lorsque j'aurai un peu plus de visibilité sur la façon dont tout ça se comporte et sur ce que je veux garder comme info exactement. On peut même imaginer des options d'agrégation plus ou moins poussées à choisir dans l'interface de configuration...
De la même manière, j'envisage de stocker carrément les pages html de résultat des statistiques pour les rappeler sans avoir besoin de faire le moindre nouveau calcul (après tout, les statistiques de novembre 2014 ne vont pas évoluer...). A moduler avec la regex de sélection robot/humain...
Je préfère éviter le cron, même si ça me démange, tout simplement parce que les gens n'y ont pas forcément accès. Bon ça ne m'empêche pas de le faire, quitte à ce que ce ne soit pas utilisé... A voir, ce n'est pas dans ma liste prioritaire disons.
Petite question en passant : pensez-vous que la notion de "visteur", c'est à dire "tranches de 15 minutes d'un visiteur unique", soit utile et/ou pertinente ? De mon côté, je ne regarde que le nombre de visiteurs uniques et le nombre de pages vues. Savoir qu'un visiteur particulier est resté 5 minutes ou 2h m'importe assez peu en fait... Et vous ?
Pour répondre aux quelques remarques de Jormun rapidement :
- sur le cron et le script php, c'est effectivement ce que je comptais faire. Je n'avais cependant pas pensé à proposer un bouton de lancement côté admin.
- je ne connais pas le json. Après recherche sur Internet, je comprends que c'est une méthode de stockage de donnée "proche" de javascript. Pour l'instant, je n'ai pas l'intention d'utiliser ça, sauf si quelqu'un me convainc que c'est la bonne méthode
- merci pour la regex augmentée
Pour le visiteur à 15 minutes, cela vient de plxStats de Stéphane, où l'objectif est d'afficher les statistiques côté site. On pouvait ainsi dire "il y a X utilisateurs actuellement connectés", en considérant qu'un visiteur connecté était une IP vue dans les 15 dernières minutes. Idem pour le XML déjà à moitié calculé : comme l'affichage se fait côté site, il faut faire les calculs à chaque nouvelle visite...
Les besoins ne sont pas du tout les mêmes, ce qui explique qu'il faille tout revoir. Ce que je fais
Le fichier utilisé est un csv de "log" pur et dur. Très gourmand en mémoire, il a cependant beaucoup d'infos.
L'idée est, pour les versions suivantes, de construire au moins un autre type de fichier d'agrégat pour alléger le poids et améliorer les performances.
plxStatistisques v0.4 béta
Je rappelle une fois encore qu'il s'agit une version béta.
Si vous faites une migration, je vous invite à désactiver l'ancien plugin, à installer le nouveau et à le réactiver (plusieurs actions importantes se passent à la réactivation).
Vous pourrez également supprimer les à présent obsolètes fichiers plxStatistiques_today.xml et plxStatistiques_before.xml se trouvant dans data/configuration/plugins. Ils contiennent l'ensemble des statistiques déjà enregistrées, mais je n'ai pas prévu de migration vers le nouveau format (hé, c'est juste une béta version pour l'instant
Le changelog :
v0.4
- refonte complète du système de sauvegarde (csv au lieu de xml)
- retrait du concept de "visiteur" lié à un temps de connexion
- Très forte modularité du code, qui permet aisément d'ajouter des indicateurs et des types de fichiers.
- Ajout du trafic horaire
- Ajout de la possibilité de gérer le niveau de profil pouvant accéder aux statistiques
- Les mots clé provenant des robots?
- Le titre des pages vues ?
merci
Les mots clés provenant des robots : je ne vois pas du tout à quoi ça fait référence.
Oui c'est géré, et il y a même la possibilité de rajouter ses propres mots clés.
En voici un petit extrait :
2015-02-14;11:48:52;82.80.249.167;plxCalendrier-1891-07;"Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0";
2015-02-14;11:48:52;82.80.249.167;plxCalendrier-2145-07;"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:26.0) Gecko/20100101 Firefox/26.0";
2015-02-14;11:48:57;82.80.249.167;plxCalendrier-1891-01;"Mozilla/5.0 (Windows NT 6.0; rv:26.0) Gecko/20100101 Firefox/26.0";
2015-02-14;11:48:57;82.80.249.167;plxCalendrier-2146-01;"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36";
2015-02-14;11:49:02;82.80.249.167;plxCalendrier-1890-07;"Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36";
2015-02-14;11:49:02;82.80.249.167;plxCalendrier-2146-07;"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36";
2015-02-14;11:49:06;82.80.249.167;plxCalendrier-1890-01;"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.71 (KHTML, like Gecko) Version/6.1 Safari/537.71";
Date et heure, on voit qu'ils viennent en même temps. Le query_string est hallucinant : c'est un accès à mon calendrier, mais en demandant des dates débiles comme juillet 2146 ou juillet 1890... Les USER_AGENT semblent être ceux d'un navigateur normal.
Vous avez des propositions pour que je puisse virer ces visites des statistiques ?
En l'occurrence, une version 0.5 beta devrait arriver rapidement, qui permet de choisir si on veut afficher les robots dans les statistiques (je me suis rendu compte que pour mes sites, ça me tue complètement la visibilité sur les visiteurs humains, étant donné que ceux-ci ne sont pas très nombreux) et qui permet également de corriger une sorte de bug qui voyait "disparaitre" des statistiques une date pour laquelle rien ne s'était passé (autrement dit, si un fichier journalier n'est pas créé pour une journée en particulier, ce qui peut arriver si y'a vraiment personne qui vient ou en cas d'indisponibilité du site, cette date n'est pas du tout prise en compte dans les statistiques).
Elle corrige le bug d'affichage dont je parlais dans mon post précédent et permet de retirer les robots de l'affichage des graphiques. Elle offre également une meilleure souplesse d'affichage des graphiques, en permettant à l'utilisateur de choisir quel graphique il veut voir. En l'occurrence, 4 "places" sont offertes, il suffit de choisir.
Chaque choix d'affichage est enregistré, permettant de le retrouver au coup suivant.
A noter que ce choix d'affichage est "unique", c'est à dire que si plusieurs administrateurs interviennent en même temps et qu'ils ne veulent pas voir les mêmes graphiques, ca risque d'être le bordel...
Ah oui, suite à une remarque de Jerry, le plugin s'appelle à présent plnStatistiques
Ce qui serait bien, c'est que la regex pour les robots soit préremplie dans le panneau de configuration et que l'on ait la possibilité d'enregistrer des adresses IP que l'on ne souhaite pas prendre en compte, afin que la visite de l'administrateur et des autres membres éventuels ne soit pas comptabilisée dans les stats.
Pour les adresses IP, c'est jouable, je vais voir comment faire.
Si on le configure après l'activation, la regex est bien pré-remplie.
En fait, à l'activation il construit la configuration "de base" (si elle n'existe pas). Donc effectivement il faut bien activer avant de configurer.
pour l'instant je suis sur un autre projet de plugin, je laisse un peu plnStatistiques en dormance pour une raison simple : je le laisse tourner sur mon site à moi et j'attends que sa base de données (en fichiers textes
Après, si tu as des demandes particulières, n'hésite pas à les faire
Gari.
merci pour ce plugin ! J'ai relevé un petit souci :
quand le fichier langue n'est pas présent, le français n'est pas chargé par défaut et on a droit au nom des variables comme "L_ADMIN_NB_UNIQUE_VISITS".
Je vais faire la traduction occitane quand j'aurai deux minutes
Le fichier de langue est fourni avec le plugin. Il ne peut donc, sauf manipulation indue, ne pas être présent. Cependant, comme je ne suis pas un expert du fonctionnement des langues dans pluXml, je laisse éventuellement quelqu'un d'autre apporter ses lumières... Stéphane, si tu passes dans le coin...
Etant donné que fr.php est le seul fichier de langue, il devrait être considéré comme celui par défaut.
En gros, quand il cherche oc.php, s'il ne le trouve pas il devrait se rabattre sur fr.php.
Je ne crois pas qu'il existe une telle dynamique de fonctionnement dans pluXml.
Question aux experts : est-il possible d'indiquer à un plugin qu'un fichier de langue doit être considéré comme le fichier par défaut ? Par exemple un truc du genre $plxPlugin->setDefaultLangage("fr") ?