Le retour de la vengeance des statistiques

Because killer-feature

a marqué ce sujet comme résolu.
Auteur du sujet

Coucou les devs,

En janvier je vais sûrement avoir du temps. Je m’avance peut-être un peu mais on va partir du principe que c’est bon. Bref. J’aimerais bien (re)venir jouer avec vous en (re)venant coder sur la plateforme. Et comme je suis aussi auteur, j’aimerais prendre en main un sujet qui m’intéresse vivement : Les statistiques sur les contenus pour les auteurs.

Alors oui, je sais, firm1 s’y était déjà frotté à grand coup de parsing de logs nginx. Perso cette approche ne me convient pas. Je trouve que ca fait un peu "hack" et je sais pas, ca me titille un peu. Bref, ce qui me plairait se serait de jouer avec l’API Google Analytics puisque l’outil est déjà en marche sur le site (même si je sais que c’est pas totalement fiable étant donnée que certains bloquent les trackers).

Je me propose donc d’essayer de jouer avec ça et remet donc le sujet sur la table. Mon plan d’attaque :

  1. Avoir l’API qui fonctionne dans notre architecture
  2. Qu’un auteur puisse avoir des données basiques sous forme tabulaire…
  3. … puis sous forme graphique…
  4. … puis pouvoir changer l’intervalle de temps d’étude.
  5. Et ce serait bien aussi de fournir des données de références (comparer les stats du contenu par rapport à la moyenne des contenus du site ? etc)
  6. Puis ensuite on discutera de si on veut exposer ça publiquement aux lecteurs ou pas, ça sera du détail d’implémentation je pense (mais aura des conséquences sur le nombre d’appels à l’API Google).

Bref, il y a de quoi s’occuper et de quoi s’amuser ! Surtout que ca fait fort longtemps que j’ai touché à ZdS. Mais comme cette fonctionnalité me tient à cœur et, je pense, peux motiver beaucoup d’auteurs, j’ai envie de m’y coller !

En terme de "stats à afficher", j’imagine les métriques "Temps moyen par page du contenu, nombre de vues par page, nombre de vues uniques par page, sites référents + termes de recherche".

Je pars sur l’objectif "0 cache", "0 enregistrements dans no bdd", en partant du principe que l’on épuisera pas les 50k requêtes par jour autorisées. D’ici à ce que cela arrive, il sera toujours temps de repenser les choses.

À vous les studios !

Je ne suis pas du tout familier avec Google Analytics, je vais donc découvrir pas mal en avançant, donc faut pas avoir peur de me dire si je me fourvoie dans certaines termes/aspects à l’heure actuelle.

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+20 -0

Cette réponse a aidé l’auteur du sujet

Une super initiative. :)

Afficher des stats, c’est bien. Des stats lisibles et interprétables par n’importe qui, c’est mieux.

Temps moyen par page du contenu

Ça inclut les gens qui passent et partent direct (lecture des commentaires). La médiane ne serait-elle pas plus intéressante, car moins biaisée ? De plus, il faut si possible le rapprocher avec le temps estimé de lecture donné dans les contenus (histoire d’avoir une référence).

nombre de vues par page, nombre de vues uniques par page

Si moi j’ai besoin de détail sur la différence entre les deux (vue unique, c’est la même machine sur plusieurs jours, ou c’est quelque chose de plus complexe ?), ça mérite à minima une explication pour être interprété correctement.

sites référents + termes de recherche

OK.


Sinon, comme je le disais sur l’autre sujet, et même si c’est complètement contradictoire avec l’objectif de simplicité ( :euh: ), donner un estimateur de l’écart (écart-type, intervalle de confiance à 95 %…) permet d’éviter les surinterprétation.

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+0 -0

\o/ Je soutiens l’idée !

Et justement, je commence à étudier les statistiques (je suis en L1 de sociologie), donc si je peux donner un coup de main, ce serait avec plaisir. :)

"Les accidents dans un système doivent se produire, mais il n’est pas obligatoire qu’ils produisent pour vous et moi." Laurence Gonzales - Deep Survival

+0 -0
Auteur du sujet

Alors déjà, merci à tous pour votre enthousiasme, clairement ça encourage. N’espérez pas du nouveau trop vite non plus, je suis en vacances la semaine prochaine (donc pas de dev’ et téléphone uniquement pour poster de court message). J’ai juste voulu amorcer ce thread un peu tôt connaissant la verbosité de notre cher communauté ^^

@firm1 je suis content de voir ton +1, connaissant le travail que tu as déjà fait sur le sujet. Ne m’en veux pas de ne pas le reprendre, c’est juste que je me sens pas en mesure de reprendre ton travail et préfère m’orienter sur cette solution qui me semble plus raisonnable et envisageable techniquement à court/moyen terme.

@gabbro: Merci pour ton retour. Je te propose qu’on rajoute une étape dans mon petit plan d’attaques qui serait la 5b "Améliorer l’affichage pour exposer une vraie valeur statistique, au delà de la donnée brute". Et ca donnerait je pense encore plus de valeur à la feature ! (et faudra m’aider sur les principes statistiques, j’ai pas trop de background pratique à ce niveau).

En tout cas encore une fois ca fait plaisir. Je pense que les plateformes exposant librement et de manière transparente sont rares et que ZdS accompagne ce genre de chose me plait beaucoup.

PS: J’ai volontairement passé sous silence les données démographique. Elles ont à mon avis peu/aucune pertinence dans le contexte de nos consultations de savoir.

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+0 -0

Cette réponse a aidé l’auteur du sujet

Trop fort !

Je colle mon brouillon rédigé la semaine dernière:


Salut à tous,

Je créé ce topic pour vous proposer une idée d’amélioration pour Zeste de Savoir: avoir des statistiques à disposition des auteurs de contenu. Ça rappellera peut être à certains une ZEP. Je pense que l’on peut dire que cette ZEP a été un échec, ce qui avait était tenté semble quelque chose de bien compliqué. Je vous propose ici une idée d’implémentation simple.

L’idée serait de mettre à disposition pour les auteurs deux métriques par contenu: - Le nombre total de visiteurs uniques (depuis toujours) - Le nombre de visiteurs uniques sur les 30 derniers jours.

Je vous propose ces deux métriques très simple pour pas que l’on s’embarque dans un délire impossible à réaliser. Si cela fonctionne avec ces deux mesures il sera toujours possible d’en ajouter dans le futur.

Comment récupérer ces infos

Une tentative avait été faite en parsant les logs de NGinx. Je vous propose aujourd’hui d’utiliser l’API de Google Analytics, voici les inconvénients :

  • Ne prends pas en compte les visiteurs bloquant les trackers type Google Analytics
  • Repose sur un service externe

Et pour moi voici les avantages:

  • Un système sans maintenance et robuste
  • Un client en Python natif et officiel
  • Un solution plus simple ?

Visuellement je pense que l’on a deux options:

  • Ajouter une page regroupant les statistiques des contenus de l’user
  • Ou alors trouver un endroit où afficher ces deux mesures sur des pages existantes ?

Je pense qu’on se retrouve sur plusieurs points, notamment l’API analytics et essayer de faire un truc simple au début et l’améliorer au fut et à mesure. Si tu créé quelque chose je suis chaud pour participer.

À voir quelles métriques on souhaite exposer au final, mais je pense que c’est une idée Qui intéresse du monde ;)

Anto

Édité par Anto59290

+0 -0

(et faudra m’aider sur les principes statistiques, j’ai pas trop de background pratique à ce niveau).

N’hésite pas à me réveiller quand tu arriveras à la partie 5b. :P Un exemple de truc que je trouve plutôt pas mal, c’est le site sentinelles : on a les infos propres (moyenne, intervalle de confiance à 95 %), une description détaillée des variables au survol, et surtout une explication avec des mots qui décrit ce qui se passe à celui qui ne pige rien aux stats. Mais je m’avance, on verra ce genre de choses lorsque ce sera nécessaire.

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+1 -0
Auteur du sujet

Je profite du thread pour brainstormer : Ce serait marrant si à la fin, lorsqu’on a des jolis graphes avec (je suppose) souvent des dates en abscisses, que l’on puisse avoir des marqueurs aux dates où le contenu a subit une mise à jour avec republication, histoire de voir si les gens viennent voir les corrections / nouveaux morceaux

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+3 -0
Auteur du sujet

Et des marqueurs pour les mises en une ? Les anciennes mises en une sont conservés ?

tleb

J’y ai pensé, mais volontairement omis. Bien que l’on peut demander une mise en une, j’ai peur que des gens commencent vraiment à faire du kikimeter et viennent harceler l’équipe com’. Bref, à mon sens la mise en une devrait être un choix éditoriale (du site donc) et non pas de l’auteur, et donc l’auteur ne devrait pas s’en soucier donc pas dans ses stats.

Mais je reste ouvert bien sûr, le choix de la communauté primera :)

Édité par Eskimon

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+3 -0

Bah au-delà de ça on peut tout simplement imaginer des marqueurs temporels (timestamp, label) qui se placent sur le graph. Certains sont automatiques (publication, mise à jour, nouveau commentaire (à voir), …) et en plus, les rédacteurs du contenu peuvent en placer comme ils veulent (Mise en une, présentation de leur contenu à un endroit, …).

Auteur du sujet

J’ai pas résisté à l’envie de faire quelques tests avec l’API de google et mon blog qui est branché avec depuis plusieurs années. Et en fait c’est assez simple et super rapide à mettre en œuvre (sans compter que Anto59290 a lui aussi attaquer de son côté pour préparer les aspects Django :D ).

Typiquement, j’arrive assez simplement à obtenir les infos suivantes :

  • keyword - mots-clés ayant amené vers la page (lorsqu’arrivé via un moteur de recherche)
  • fullReferrer - url complète du lien qui a amené vers cette page
  • avgTimeOnPage - Temps moyen passé sur la page
  • users - Nombre "d’utilisateurs" ayant visualisé la page (utilisateur au sens google, pas au sens ZdS)
  • newUsers - Nombre de nouveau "utilisateurs" ayant visualisé la page (même remarque)
  • sessions - Nombres de sessions (Un "utilisateur" venant plusieurs fois déclenche plusieurs sessions)

Tout cela peut-être vu sur une échelle de temps paramétrable (échelle au mois/semaines/journée, les échelles horaires n’ont pas d’intérêt je pense). Je propose aussi qu’on limite l’affichage au plus récent à "hier" (pour pas que les gens viennent voir 15000 fois par jour si les stats ont pas bougé d’un pouillième et griller du quota de requête pour rien). À terme on pourra aussi voir les statistiques "à la page près" donc comparer les chapitres entres eux (pour voir quelles parties sont plus fréquentées par exemple etc).

Bien que de manière naturelle on aimerait voir des graphes, on peut aussi imaginer un résumé court avec une phrase simple comme par exemple :

"xxxx utilisateurs (dont yyyy nouveaux) ont visité le site entre aa/bb/cc et dd/ee/ff. Ils ont visités un total de — pages en restant en moyenne ---- minutes par page. Le mot-clé favori amenant sur ce contenu est abcd"

les rédacteurs du contenu peuvent en placer comme ils veulent (Mise en une, présentation de leur contenu à un endroit, …).

Ca devient pas un peu overkill déjà ?

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+2 -0

J’ai trouvé un petit module intéressant, au cas où : https://github.com/zhebrak/django-statsy. Il permet de créer facilement des graphiques d’évènements (visite d’une page, clic sur un lien, etc). Si ça peut vous être utile… ;)

"Les accidents dans un système doivent se produire, mais il n’est pas obligatoire qu’ils produisent pour vous et moi." Laurence Gonzales - Deep Survival

+1 -0

Cette réponse a aidé l’auteur du sujet

Salut à tous,

On continue d’avancer sur le sujet ! J’ai pris en charge la partie Django et j’ai commencé par poser les bases avec :

  • Nouvelle route / URL + gestion des droits d’accès
  • Mise en place d’une fausse API pour test, qui sera remplacée avec les données obtenues par Google Analytics
  • Affichage des "données brutes" en tableau
  • Mise en place d’une gestion de base de l’échelle de temps
  • Mise en place d’une gestion très basique des graphiques
  • Début d’une interface pour comparer des URL entre-elles

Bon on est sur de l’ultra travail en cours, mais je vous met quand même un petit screen :

statsWIP

Bon évidemment ça ne veut pas dire que l’on implémentera tout ça dans une première version, mais ça permet de donner une idée de la direction dans laquelle on va. Pour l’avenir on a noté quelques petites idées:

  • Marqueur automatiques (date de publication, date de Maj, etc.). Et pourquoi pas un jour, marqueurs personnalisés
  • Choix plus fin des dates (avec un petit calendrier par exemple pour le choix de la date de début / fin)

Pour le front on demandera probablement un coup de main pour faire mieux en termes de présentation, graphs, etc. (Il me semble que Abdelazer s’est porté volontaire mais je ne suis pas 100% sur).

Tous les retours, commentaires, rêves, propositions, critiques sont bienvenues.

Anto59290

+10 -0

Il faudrait voir si c’est possible, à partir des URLs, de facilement retrouver les noms des parties, chapitres, etc car c’est quand même plus sympa à lire :D (mais c’est pas le plus important, je le conçois)

+2 -0

Il faudrait voir si c’est possible, à partir des URLs, de facilement retrouver les noms des parties, chapitres, etc car c’est quand même plus sympa à lire :D (mais c’est pas le plus important, je le conçois)

Situphen

C’est vrai que ça serait mieux. Je le met sur la liste des trucs a regarder de plus près ;)

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut les citrons,

Dernières avancées de 2017 avec notamment:

  • L’ajout des URLs nommées demandés dans les posts précédent. On voit maintenant le titre du chapitre/partie à la place de son URL (plus sympa quand même ;) ) . Il y a aussi le lien pour amener directement à la version en ligne si jamais vous avez oublié ce que vous aviez écrit (ou pour gonfler vos stats :p )
  • J’ai nettoyé la sidebar pour laisser uniquement ce qui est nécessaire.
  • Le mode de comparaison est maintenant fonctionnel et permet de comparer entre 2 et N1 URLS entres elles. Elles sont alors affichées ensemble sur les graph.
  • Nettoyage de code et refactoring afin d’être plus souple pour la suite. Normalement il sera assez simple de rajouter / supprimer une métrique, etc.

WIP2

WIP3

La liste des idées pour la suite:

  • Avoir une page qui permet de voir les graphes pour une seule partie (ce qui n’est pas possible aujourd’hui)
  • Améliorer la lisibilité des graphs (titres, couleurs)
  • Améliorer l’interface (bouton pour revenir à la home des stats depuis la page de comparaison, etc.)
  • Marqueur automatiques (date de publication, date de Maj, etc.). Et pourquoi pas un jour, marqueurs personnalisés.
  • Choix plus fin des dates (avec un petit calendrier par exemple pour le choix de la date de début / fin)

On commence a avoir une base de travail niveau back-end et interface, il faudra par la suite brancher les bonnes informations au bonne endroits et rendre tout ça plus joli et plus facile à lire.

Bon réveillon :)


  1. N étant un entier naturel supérieur à 2 et inférieur au nombre de parties du contenu :p 

+8 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte