ZEP-11 : Interface de statistiques sur les tutoriels

Des chiffres, des graphes, du kikimeter !

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet
Cartouche
ZEP 11
Titre Interface de statistiques sur les tutoriels
Révision 2
Date de création 25 juillet 2014
Dernière révision 06 mai 2015
Type Feature
Statut Validation

Contexte de la proposition

Cette proposition vise a fournir aux membres, un outil de suivi statistique de la consultation du contenu publié. L'auteur pourra ainsi savoir simplement différentes choses afin de déterminer les points d’amélioration ou de modification nécessaire. Par exemple, si les lecteurs restent significativement plus longtemps sur un chapitre il serait peut-être bon de découper ce dernier. Ou encore si l'auteur propose des ressources (liens, documents/sources a télécharger etc), il aimerait probablement savoir si ces dernières sont consultées ou non pour déterminer si ce travail de documentation est nécessaire ou non.

Objet de la proposition

Cette ZEP vise donc l’implémentation et la mise en forme d'une interface de consultation de données statistiques sur le contenu du site. Cette interface sera accessible via le menu de gauche du tutoriel.
Cette page devra être le plus clair possible pour qu'un utilisateur non technicien puisse aussi recueillir des informations (donc il faut éviter l'utilisation de jargon par exemple).

Moyens mis en œuvre

Nous avions envisagés au départ de recueillir les données venant de l'API Google, mais force est de constater, après réflexion et estimation de volumétrie, que ZdS n'a pas les moyens de les exploiter.

Les moyens utilisés sont les suivants (dans l'ordre chronologique) :

  1. Lire une fois par jour les logs de notre serveur Web (nginx), les parser, filtrer le contenu qui nous intéresse et stocker le resultat dans une base de donnée;
  2. Exposer les données de la base ZdS via une API;
  3. Présenter les résultats dans une interface de statistique.

Voici un schéma un peu technique qui illustre l'architecture globale du système.

Architecture finale du module de statistique

Les informations à récupérer

Après, un sondage, la communauté s'est exprimée sur les informations qui l’intéressent plus ou moins. Parmi ces informations, celles que l'on peut obtenir grace aux logs sont les suivantes :

Proposition Description Total "Oui" Total "Non" Total "Pourquoi pas"
1 Le nombre total de visites. 17 0 0
2 Les URLs sources qui ont permis d'accéder au tuto avec le nombre de visites depuis ces sources. 15 2 0
3 Le nombre de clics sur les différents liens du tuto. 5 9 3
4 Connaitre depuis quelle plateforme (navigateur, système d'exploitation, taille d'écran, etc.) les gens consulte mon tutoriel. 5 10 2
5 Connaitre le temps moyen que met mon tutoriel pour se charger sur un navigateur 7 9 1
6 Savoir depuis quelle zone (ville, pays, continent) les gens consultent mon tutoriel 7 7 3
7 Connaitre le pourcentage de nouveaux utilisateurs qu'apporte mon tutoriel au site 8 7 2

Ces informations seront donc stockées dans la base de donnée de ZdS.

Le modèle de stockage des informations ?

Les informations seront stockées dans une base de données SQL (ici MySQL) car le modèle des données s'y prête bien. La mise en place d'index permettra d'améliorer les performances de lecture sur la base étant donné que la nature du besoin demande de pouvoir lire efficacement les données.

La capacité de stockage de la base est largement estimée à 10 Go/an. Ce qui représente tout de même un cout de stockage.

L'API

Afin que tout le monde puisse jouer avec les statistiques, les données seront rendues d'abord par une API. Le site lui même utilisera l'API pour afficher les données.

Par souci d’homogénéité avec les autres API du site, les paramètres de restrictions (throttling) seront les mêmes que sur les autres modules. C'est à dire qu'un client disposant d'une clé pour l'API aura un nombre de requêtes autorisés largement supérieur à un client sans clé. Il sera donc possible d’accéder à l'API sans avoir de clé.

La différence sera au niveau de la durée du cache sur les requêtes. Étant donné que le traitement d'analyse/parsing/stockage de logs sera fait une fois par jour, nous devons avoir une taille de cache de 24h, invalidé à chaque lancement de la procédure d'analyse.

Les verbes de l'API

Tout client de l'API (y compris le site) ne doit accéder à l'API uniquement qu'au travers de la méthode GET, il s'agit donc d'une API en lecture seule.

Les paramètres des requêtes

Les paramètres des requêtes sont les variables que l'on passent à une url de l'API sous la forme http://api_url/?v1=x&v2=yv3=z. Dans cet exemple, v1, v2, v3 sont les paramètres de la requête.

Les paramètres sont tous facultatifs, et en cas de non renseignement d'un paramètre, la valeur par défaut sera celle spécifiée dans le fichier de paramètre (le settings.py) de zds.

Le module des statistique devra donc autoriser les paramètres suivants :

  • date_debut : AAAAMMJJ.
  • date_fin : AAAAMMJJ.
  • heure_debut : HHMMSS.
  • heure_fin : HHMMSS.
  • profondeur: Int. il s'agit de la profondeur du json rendu (voir l'exemple)
  • page: Int

Les URLs de l'API

L'API devra mettre à disposition des clients les URLs suivantes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
/api/contenus/stats/visites/
/api/contenus/:content_type/stats/visites/
/api/contenus/:content_type/:content_id/stats/visites/
/api/contenus/:content_type/:content_id/stats/visites/
/api/contenus/:content_type/:content_id/stats/visites/sources/
/api/contenus/:content_type/:content_id/stats/visites/plateformes/
/api/contenus/:content_type/:content_id/stats/visites/plateformes/os
/api/contenus/:content_type/:content_id/stats/visites/plateformes/navigateur
/api/contenus/:content_type/:content_id/stats/visites/geo/
/api/contenus/:content_type/:content_id/stats/visites/geo/continents/
/api/contenus/:content_type/:content_id/stats/visites/geo/continents/pays/
/api/contenus/:content_type/:content_id/stats/visites/geo/continents/pays/villes
/api/contenus/:content_type/:content_id/stats/visites/geo/pays/
/api/contenus/:content_type/:content_id/stats/visites/geo/pays/villes
/api/contenus/:content_type/:content_id/stats/visites/geo/villes
/api/contenus/:content_type/:content_id/stats/visites/geo/continents/
/api/contenus/:content_type/:content_id/stats/clics-internes/
  • :content_type : représente le type de conteneur (article, tutoriel, chapitre, partie)
  • :content_id : représente l'identifiant du conteneur sur zds

Un json d'exemple

Pour donnée une idée de ce vers quoi on va, voici la structure du json visée pour l'url /api/contenus/:content_type/:content_id/stats/visites/. On voit que là on a toutes les informations demandées.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
{
  "id" : "",
  "type": "",
  "total_visits" : 189,
  "uniques_visits": 86,
  "new_visits": 8,
  "avg_load_speed": 457,
  "sources" :[
      {
          "dns": "google.fr",
          "total_visits" : 189,
          "uniques_visits": 86,
          "new_visits": 8,
          "avg_load_speed": 157
      },
      {
          "dns": "twitter.com",
          "total_visits" : 14,
          "uniques_visits": 5,
          "new_visits": 0,
          "avg_load_speed": 447
      },
      {
          "dns": "yahoo.fr",
          "total_visits" : 189,
          "uniques_visits": 86,
          "new_visits": 8,
          "avg_load_speed": 401
      }
  ],
  "plateformes" : {
      "os": [
          {
              "name": "Windows",
              "version": "7",
              "total_visits" : 189,
              "uniques_visits": 86,
              "new_visits": 8,
              "avg_load_speed": 401
          },
          {
              "name": "Unknow",
              "version": "Unknow",
              "total_visits" : 189,
              "uniques_visits": 86,
              "new_visits": 8,
              "avg_load_speed": 401
          }
      ],
      "navigateur": [
          {
              "name": "Firefox",
              "version": "7",
              "total_visits" : 189,
              "uniques_visits": 86,
              "new_visits": 8,
              "avg_load_speed": 401
          },
          {
              "name": "Google Chrome",
              "version": "32",
              "total_visits" : 189,
              "uniques_visits": 86,
              "new_visits": 8,
              "avg_load_speed": 401
          }
      ]
  }
  "geo" : {
      "continents": {
          "pays": {
              "villes" : [
                  
              ]
          }
      },
      "pays": {
          "villes" : [
              
          ]
      },
      "villes" : [
          
      ]
  }
}

Évolutions de la ZEP ?

L'idée est dans une première version d'utiliser les logs du site comme provider des données. Une seconde itération (et si le besoin s'en ait sentir) consistera à prendre en compte les données de Google Analytics pour mettre à disposition 3 métriques demandées.

  • Le temps moyen passé sur le tuto.
  • Le type d'audience (fourchette d'age, sexe) que mon tutoriel attire
  • Les mots clés qui permettent d'arriver sur mon tutoriel depuis un moteur de recherche

Annexes

Édité par firm1

Je vais peut-être poser une question folle, mais c'est quoi GA ?

Non mais je connais la réponse, c'est juste que je n'aime pas voir les sigle incompréhensible. Tout le monde ne sait pas ce qu'est GA, GH, QA, MMH, OCP, PKI, etc.

firm1

C'est un peu HS, mais bon.

Peut-être serait-il bien, si quelqu'un en a le courage, de mettre par écrit ici, tout les abréviations que pourrait rencontré un utilisateur lors du développement ou plus généralement sur le site.

Staff
Auteur du sujet

Ou on pourrait tout simplement parler en Français sans abréviation, ni autre langage SMS. Déjà qu'on a du mal a de comprendre des fois en Français, s'il faut rajouter des abréviations, on ne s'en sort plus. Et je ne parle même pas des mots en anglais sortis du chapeau … ;)

Bonne idée cette ZEP, actuellement on manque de retour après la rédaction à part les commentaires. Moi je verrais bien un bouton "Statistiques" dans la barre d'outil d'édition d'un tuto/article, et on pourrait y intégrer l'idée des "mercis" (voir le topic des propositions de rétribution aux contributeurs).

En gros, une ZEP pour des stats GA/etc. sur ZDS, moi j'dis OK. :D

ZdS : un palimpzeste pour le savoir. | Les codes correcteurs, c'est bien.

+1 -0

Ou on pourrait tout simplement parler en Français sans abréviation, ni autre langage SMS. Déjà qu'on a du mal a de comprendre des fois en Français, s'il faut rajouter des abréviations, on ne s'en sort plus. Et je ne parle même pas des mots en anglais sortis du chapeau … ;)

firm1

En meme temps j'ai fait expres d'ecrire en toute lettres avant d'introduire l'abbréviation "Google Analytics (GA)/Google Tag Manager (GTM)" :-°

(OK chui un boulet j'ai écris GTA au lieu de GTM (sale geek tiens) mais l'idée était la !)

Je vais rajouter une belle balise acronyme du coup pour etre sur que personne passe a coté…

et on pourrait y intégrer l'idée des "mercis" (voir le topic des propositions de rétribution aux contributeurs).

Ca me semble un peu "hors scope" entre un outil "statistiques" et un outil "remerciements". Le but n'est pas le même.

Édité par Eskimon

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

+0 -0

Sinon, il serait bien de définir exactement ce que l'on veut remonter aux auteurs (sans forcément tout implémenter tout de suite), car il faut vérifier si Google Analytics récupère bien tout, sinon il faudra même en place la remontée voulu dans Google Tag Manager.

+1 -0
Staff

Sinon, il serait bien de définir exactement ce que l'on veut remonter aux auteurs (sans forcément tout implémenter tout de suite), car il faut vérifier si Google Analytics récupère bien tout, sinon il faudra même en place la remontée voulu dans Google Tag Manager.

devock

Les indicateurs intéressants seraient à mon avis les visiteurs (uniques), le nombre de pages vues, le temps moyen passé sur le tuto, le nombre de sorties (le visiteur quitte le tuto, mais je ne sais pas si c'est simple à détecter s'il ne quitte pas le site complètement). Tout cela pourrait être croisé avec les dimensions temps (à la journée, faut pas déconner), parties et chapitres.

Après, il faudra voir comment on met le tout en forme.

Mais à mon avis, tout cela doit entrer dans un cadre un peu plus vaste d'analyse des données de ZdS. L'idée serait de monter un petit "data warehouse" croisant au moins deux sources de données : celles de Google Analytics et celles de la base opérationnelle de ZdS. Et c'est en se basant sur ce data warehouse qu'on pourrait extraire des stats intéressantes sur les tutos, mais aussi sur tout le site : quels sont les sujets les plus visités, les forums les plus fréquentés sont-ils ceux dont les sujets sont couverts par des tutos du site, etc. Il serait alors assez simple d'extraire des données pour les auteurs tutos ou encore pour faire des articles sur les stats du site. Bref, plein d'utilisations possibles. Le sujet me botte bien en tout cas. :)

Édité par ShigeruM

Suivez ZdS sur Twitter ! Et venez aux JZDS Lille !

+5 -0

Gros déterrage, mais comme la ZEP-3 est bientôt fini et que je suis pas forcement utile sur les autres et que je suis auteur donc intéressé par ce sujet, je reviens a la charge ici…

Pour moi cette ZEP doit rester sur le périmètre "Donnees statistiques des tutoriels pour l'auteur". Deja si on a ca se sera bien et une joli mise en oeuvre de l'API de Google Analytics (car pour l'instant on a rien.

Maintenant comme le dit très justement ShigeruM, il va falloir faire un inventaire des données possibles a obtenir via GA et celle pertinentes pour l'auteur.

Donc s'il y a des auteurs dans la salle, n’hésitez pas a donner votre avis sur le sujet !

A l'heure actuelle je vois bien les choses dans l'ordre suivant :

  • Listage de tout ce qu'on peut obtenir
  • Listage de ce que l'on veut
  • Passage en validation
  • Puis dev.
    • Mise en oeuvre de la connexion vers l'API depuis ZdS
    • Extraction des données depuis google vers chez nous
    • Mise en beauté de ces informations
    • [Bonus] Rédaction d'un guide pour les auteurs pour apprendre a lire ces données et les exploiter

Je suis novice en analyse GA, toute aide est bien sur la bienvenue !

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

+0 -0
Staff

Ce qui m'intéresserait en tant qu'auteur, sans supposer de ce qui est faisable avec GA ou autre d'ailleurs, ce serait cette liste au Père Noël ci :

  • Le nombre total de visites (total depuis la 1ère publication, depuis la dernière MAJ majeure, historique). Permet d'avoir une idée de si le tuto plaît ou non.
  • Le nombre de visiteurs uniques (total depuis la 1ère publication, depuis la dernière MAJ majeure, historique). Permet d'avoir une idée de si le tuto plaît ou non ; en conjonction avec le précédent, permet de savoir si les lecteurs reviennent souvent lire le tuto ou non.
  • Le temps moyen passé sur le tuto (global, pourquoi pas un graphe de répartition, ou proportion de personnes qui partent avant 1 minute). Permet de savoir combien de temps le lecteur consacre au tuto et combien abandonnent dès l'intro.
  • Si le tuto a plusieurs parties, les stats précédentes pour chaque page (en plus des stats globales), avec les pages de sorties si possible. Permet de voir ce qui plaît et où les gens décrochent.
  • Les URLs sources qui ont permis d'accéder au tuto (avec la page pointée si le tuto a plusieurs sous-parties) avec le nombre de visites depuis ces sources. Permet de savoir d'où viennent les lecteurs et qui ça intéresse.
  • Le nombre de clics sur les différents liens du tuto. Ceci pour savoir si les liens ont semblé utiles ou non (exemple pragmatique : le lien vers la news de sortie de la v1.1 avec les stats dans la dépêche sur Linuxfr.org n'a intéressé personne) ; permet de dégager les liens inutiles ou de mieux présenter les liens utiles ignorés.

Il me semble que toutes les données sont disponibles dans Google Analytics, avec un doute pour le dernier point.

Je me demande à quel point ces données statistiques devraient être publiques. Personnellement je n'ai aucun inconvénient à ce que tout ça soit public : ce sont des données souvent privées parce qu'elles servent à monnayer les espaces publicitaires ; mais nous n'avons pas ce problème.

On pourrait aussi imaginer envoyer des rapports (hebdomadaires ? mensuels ?) aux auteurs.

PS : il faut en plus (en particulier si les données sont publiques) une explication sur comment interpréter les résultats, et un avertissement sur le fait que ce sont des données partielles puisque l'utilisateur peut refuser d'être tracé par l'outil d'analyse.

Édité par SpaceFox

+1 pour le cote publique de la chose en fait. Dans une politique de transparence ca permet notamment de montrer a l'utilisateur a quoi sert google analytics sur ZdS et donc peut-être même que certains pourraient le rajouter en liste blanche :)

Et il me semble aussi que toutes les données que tu aimerais sont dispos dans GA.

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

+0 -0

@SpaceFox : Ta dernière donnée est partiellement disponible, mais Google a mis en place les événements et on peut avoir ce genre d'information (et sans presque intervenir sur le site, vu que tout est faisable depuis Google Tag Manager).

Pour ce qui est des données publiques, ça ne me dérange pas non plus (bon après, faut faire le tri, je ne pense pas que tout va intéresser les lecteurs).

Édité par devock

+0 -0
Staff

Pour ce qui est des données publiques, ça ne me dérange pas non plus (bon après, faut faire le tri, je ne pense pas que tout va intéresser les lecteurs).

Bah pour moi c'est dans une page à part. Donc si l'utilisateur va voir ces stats, il voit toutes les stats. Si y'a des bouts qui ne l'intéressent pas, c'est à lui de gérer.

Staff
Auteur du sujet

En attendant que la spec soit carrée par ici et étant donné que le dev va demander à rajouter un concept technique qui n'existe pas encore dans le code (connexion à l'API de google analytics), ça dérange quelqu'un si je travaille sur un POC dont le but est de poser ces bases techniques ?

Pour delà, je partirai sur quelque chose de simple mais efficace dont tout le monde semble à peu prêt d'accord.

Le nombre total de visites (total depuis la 1ère publication, depuis la dernière MAJ majeure, historique). Permet d'avoir une idée de si le tuto plaît ou non.

SpaceFox

Une fois ceci fait, le reste ne sera (au niveau technique) que des itérations pour rajouter tel ou tel donnée de GA.

Est-ce que ça aurait du sens, ou vous préferez vraiment attendre de specifier tout pour commencer le developpement ?

En attendant que la spec soit carrée par ici et étant donné que le dev va demander à rajouter un concept technique qui n'existe pas encore dans le code (connexion à l'API de google analytics), ça dérange quelqu'un si je travaille sur un POC dont le but est de poser ces bases techniques ?

Rien ne t'empêche de faire un POC, non ? ^^ (rien n'oblige non plus à l'intégrer a upstream le cas échéant, si ça plait pas)

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0
Staff
Auteur du sujet

Je ne suis pas sûr d'avoir bien compris la citation modifiée de mon post. Tu indiques par là que tu veux implémenter les bases techniques + le nombre total de visites d'un tuto depuis la 1ère publication, c'est bien ça ?

SpaceFox

En gros, si je réduis la spec en "Afficher pour chaque tutoriel le nombre total de visites depuis la 1ère publication visible par tout le monde", ça me permettra de poser les bases techniques.

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