Le retour de la vengeance des statistiques

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".

À vous les studios !

\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.

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.

Anto59290 tu peux me faire un MP pour qu’on en parle et s’organise ?

(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. 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.

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

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

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

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, …).

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 ).

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à ?

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…

En voyant toutes les informations accessibles, je ne risque pas de couper uBlock Origin. Ça ne me dérange pas que ZdS ait accès à ça, mais Google…

En fait c’est pas trop grave que des personnes coupent les infos envoyées à google analytics tu sais.

Tout dépend de combien de personnes on parle. Et ils peuvent très bien représenter une population qui lit beaucoup plus que la moyenne, qui sait.

Je ne trouve pas que ça soit bloquant.

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 (mais c’est pas le plus important, je le conçois)

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