[plugin] plnStatistiques - les statistiques de visites de votre site

GariGari Member
février 2015 modifié dans Plugins
Bonjour à tous,

Suite à la discussion qui a débuté , 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

plxStatistiques.png

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.
«1

Réponses

  • Super intéressant, ce plugin !

    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 ! :)
  • Génial, très bonne idée, j'ai pas la possibilité de le tester aujourd'hui mais ça m'a l'air prometteur :)
  • La version 0.3 est sortie : plxStatistiques v0.3
    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.
  • CKDevelopCKDevelop Member
    février 2015 modifié
    ça me plait beaucoup, simple et efficace, merci

    ++
  • Détection d'une visite : facile, dès lors que mon plugin est appelé, c'est qu'il y a une visite. Je ne suis pas certain de comprendre ce que tu entends par "code du wiki".
    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.
  • cfdevcfdev Member
    février 2015 modifié
    Cool en test chez moi, je te ferai quelques retours des que possible (demain ;))

    -> 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
  • @cfdev : bonne idée.

    @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.
  • GariGari Member
    février 2015 modifié
    Que de bonnes remarques... Je suis en cours de refonte du plugin, histoire d'utiliser la méthode proposée par Jormun.

    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 ;)
  • GariGari Member
    février 2015 modifié
    Ok je pige mieux. Je connais très mal javascript, j'imagine que ça s'est vu :)

    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 ;)
  • GariGari Member
    février 2015 modifié
    Nouvelle version. Refonte complète de la structure du fichier de sauvegarde et de la façon de l'appeler. On peut dire que le fonctionnement du plugin a complètement changé. Il me sera beaucoup plus facile d'ajouter des indicateurs, des types de fichiers, un système de cache avec cette nouvelle mouture.
    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 :p).

    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
  • Avec cette nouvelle gestion des stats, est-il possible d'avoir:
    - Les mots clé provenant des robots?
    - Le titre des pages vues ?

    merci ;)
  • Les pages vues : les pages vues (query_string) sont actuellement enregistrés mais cette version du plugin ne permet pas de les traiter. Ca viendra dans une prochaine version. Mon vrai problème est de savoir comment fournir l'information : lorsqu'il y a beaucoup d'article, ça devient difficile de tout gérer en affichage. Ou alors j'affiche les 10 pages les plus vues ?

    Les mots clés provenant des robots : je ne vois pas du tout à quoi ça fait référence.
  • Ahh les mots clés pour déterminer si on est face à un robot ou un humain ?
    Oui c'est géré, et il y a même la possibilité de rajouter ses propres mots clés.
  • en parlant de robot, sur mon site je me suis pris environ 1100 pages vues en l'espace de quelques minutes par une même IP qui a utilisé de nombreux USER_AGENT différents.
    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 ?
  • Utilise honeypot pour voir...
  • Chapeau au codeur de se plugin, et bonne continuation pour les mises à jour futures... :)
  • Merci :)
    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).
  • Hé ben elle est arrivée : plnStatistiques v0.5 béta
    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 ;)
  • Hé ben, je viens de la télécharger :D

    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.
  • La regex pour les robots est pré-remplie, normalement. J'ai fait un test d'installation sur une pre-prod, tout a bien marché de ce côté là. Je vois pas bien le problème...
    Pour les adresses IP, c'est jouable, je vais voir comment faire.
  • Mea culpa : pour la regex, en effet, ça fonctionne. C'est juste que j'ai configuré le plugin avant de l'activer.
    Si on le configure après l'activation, la regex est bien pré-remplie.
  • Ah tiens j'avais jamais fait gaffe qu'on pouvait configurer un plugin avant activation.
    En fait, à l'activation il construit la configuration "de base" (si elle n'existe pas). Donc effectivement il faut bien activer avant de configurer.
  • C'est ce que j'ai vu en mettant le nez dans le code.
  • appollo20appollo20 Member
    février 2015 modifié
    Salut Gari à tu des infos sur les futurs Mises à jour... Je les attente avec impatience a++++ :D
  • Salut Appollo,
    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 :p) se remplisse, histoire de voir comment gérer au mieux la charge dans les prochaines versions. Actuellement, la gestion des fichiers de log commence déjà à alourdir le plugin après deux semaines environ (5 secondes pour charger les statistiques côté admin, par contre bien entendu cela ne ralentit en rien les autres parties du site, côté admin ou côté site).
    Après, si tu as des demandes particulières, n'hésite pas à les faire :)
    Gari.
  • Merci beaucoup pour les infos Gari... bonne continuation!!! pour les plugin
  • RubénRubén Member
    Coucou,
    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 :)
  • GariGari Member
    Salut,
    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...
  • RubénRubén Member
    Oui oui le fichier langue est présent, mais j'ai l'interface de pluxml en occitan et dans un tel quand le plugin doit, je suppose, chercher un fichier oc.php et non fr.php du coup je vois des noms de variables. Il faudrait faire une vérif, si langue-défaut existe, on l'emploie sinon fr.php.
  • GariGari Member
    Je comprends mieux.
    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") ?
Connectez-vous ou Inscrivez-vous pour répondre.