ZEP-11 : Interface de statistiques sur les tutoriels

Dites, j'ai une petite question. Cette ZEP a pour titre : « Interface de statistiques sur les tutoriels ». Mais si j'ai bien suivi, la ZEP-12, va considérablement réduire la frontière entre les tutos et les articles. Pourrait-on alors imaginer que cette ZEP s'étend aux articles, soit directement, soit plus tard ?

Sinon, voilà mon tableau en prime :

Oui, les articles l'auront automatiquement une fois la zep-12 en prod. Avant ca dépensera de la motivation du dev qui va la faire.

Toutafé ! C'est juste qu'à l'époque ca n'était pas encore le cas

grillé par le fantome

Je sens que je vais souffir si je dois en plus assurer la compatibilité avec cette ZEP. Faut vraiment qu'on se grouille de terminer la zep 12 histoire que ça soit les autres qui soient compatibles avec nous parce que là ça va causse masse de problème avec les changements d'url.

Artragis soulève un point important: cette ZEP va tomber à plat quand on va changer les URLs, nan ?

Pas forcément. Tout dépend de ce que l'on va décider par la suite comme modèle de stockage, mais à priori, il y a des façons de faire qui n'impactent pas la ZEP-12.

Je comprends pas trop pierre_24, tu peux expliquer "tomber à plat" ?

Eh bien, imaginons que GA stocke ces infos en fonction de l'URL de la page (ça me semblerai logique): dès qu'on va se mettre à changer l'URL, toute les stats vont retomber à zéro pour l'URLs susmentionnée, non ? D'ailleurs, je me permet de poser la question de manière générale: qui d'un tuto qui vois son titre (donc son slug, donc son url) changer en cours de route ?!?

Le cas d'un changement d'URL (qu'il soit lié à un refactoring ou au slug) doit être géré côté serveur en renvoyant une 301 sur l'ancienne URL.

Qu'il s'agisse d'un robot ou non d'ailleurs, le mec qui a bookmarké une URL doit être redirigé proprement.

Ca me semble être un cas ultra classique que de changer l'URL d'une ressource. GA doit savoir gérer les 301 quand même. (en fait j'en suis quasi sûr).

Le cas d'un changement d'URL (qu'il soit lié à un refactoring ou au slug) doit être géré côté serveur en renvoyant une 301 sur l'ancienne URL.

Je précise à toute fin utile que ZEP-12 ou pas, ce n'est actuellement pas le cas. J'écris une issue de ce pas.

EDIT: fait.

Promis, je vais être lourd mais constructif.

Je justifie : [3->10] je fais pas de SEO, savoir la proportion de fille, ou les mot-clé quivontbien ne m’intéresse pas.

Pour la 6, tant que Mathjax sera la solution privilégié, ce critère risque d'être pertinent.

Pour la 2, je me base sur ma pratique. Je peux lire un tuto en 4 fois, ou en une seul. Le survoler puis y revenir,… Bref, avoir un temps moyen apporte peu d'information. Et avoir la courbe complète est contraire avec ce que je disais précédemment, et qui est un peu passé inaperçu :

Exploiter correctement des données, c'est compliqué. En se restreignant a quelques données représentatives, on apporte probablement plus aux auteurs qu'en leur en donnant trop.

Ce qui, au passage, est le contraire de l'avis d'Eskimon, « qui veut le moins devrait s’arrêter là » Si les données en plus sont sur un panneau annexe, je dis rien. Mais je suis contre le fait de surcharger la page principal des stats avec des trucs peu utiles/demandées.)

Le temps passé médian aurait l'avantage de couper les gens qui quittent sans lire du tout, ou ceux qui s'endorment devant leur PC, tout en restant simple. Si c'est médian, on va dire « pourquoi pas ». Après, je ne sais pas de quel donnés vous disposez.

Pour toute les données, je voudrai insister sur un truc : if faut donner des intervalles de confiance ou un truc équivalent (écart-type, variance, fonction de log-vraisemblance¹). Exemple : j'ai 500 visites par jour en moyenne. Je fais de la pub sur les réseaux sociaux, et je passe à 600. Je conclus que c'est trop chouette. Pas de bol, mon intervalle de confiance à 95% était de [300 ; 700], il est possible tout à fait que mon démarchage n'ai eu aucune influence et que la variation soi purement statistique. J'aurai eu un intervalle de [450 ; 550], j'aurai effectivement pu conclure à l'efficacité du démarchage. Problème lié : dans le cas des données journalière, on a une volatilité au sein de la semaine (semaine week-end surtout). Donner une moyenne² glissante sur les 7 derniers jours plutôt que la valeurs d'hier.

En espérant avoir été pas trop lourd et très constructif.

Roh ! cet oiseau attaqueur de vieilles, il vient toujours casser l'ambiance.

Plus sérieusement,

Pour toute les données, je voudrai insister sur un truc : if faut donner des intervalles de confiance ou un truc équivalent (écart-type, variance, fonction de log-vraisemblance1). Exemple : j'ai 500 visites par jour en moyenne. Je fais de la pub sur les réseaux sociaux, et je passe à 600. Je conclus que c'est trop chouette. Pas de bol, mon intervalle de confiance à 95% était de [300 ; 700], il est possible tout à fait que mon démarchage n'ai eu aucune influence et que la variation soi purement statistique. J'aurai eu un intervalle de [450 ; 550], j'aurai effectivement pu conclure à l'efficacité du démarchage. Problème lié : dans le cas des données journalière, on a une volatilité au sein de la semaine (semaine week-end surtout). Donner une moyenne2 glissante sur les 7 derniers jours plutôt que la valeurs d'hier.

Je suis assez d'accord sur ce point.

Gabbro : ton point de vue est intéressant et tu le justifie bien. ça rejoint la question de SpaceFox sur comment on va déterminer les critères de prise ou non d'une statistique ?

Étant donné que les participations au sondage s’essoufflent un peu (mais le sondage suit son cours), je vous propose de m'aider à répondre à cette question.

Mon avis sur la question serait :

• La métrique qui a obtenu plus de 90% au sondage (pourcentage tiré à la louche pour exprimer la notion de majorité) sera disponible pour tout le monde (non connectés, membres, auteurs, validateurs, etc)
• La métrique ayant obtenu entre 10% de 90% au sondage ne sera disponible que pour les auteurs et les validateurs : j'entends pas là que chaque auteur ne pourra voir ces métrique que sur ses tutoriels, et ne connaitra pas celles des autres.
• La métrique ayant obtenu moins de 10% au sondage ne sera pas prise en compte.

La métrique ayant obtenu entre 10% de 90% au sondage ne sera disponible que pour les auteurs et les validateurs : j'entends pas là que chaque auteur ne pourra voir ces métrique que sur ses tutoriels, et ne connaitra pas celles des autres.

Je ne comprends pas la logique de cette règle.

Ces métriques sont-elles utiles à d'autre personne que les auteurs ? Je me demande à quoi cela sert à un utilisateur lambda de connaître la fourchette d'âge du tutoriel, le nombre de vue ou encore les mots clés utilisés pour arriver sur le tutoriel…

idem. Je reste sur mon idée du "panneau supplémentaire pour afficher les métriques moins plébiscitées"

ça veut dire en gros que ces métriques ne sont pas approuvées majoritairement et étant donné qu'il y en a qui sont tout de même pour, on les met a disposition, sans toutefois les rendre publique.

C'est une question à laquelle on a pas encore répondu non plus. J'ai donc fais une proposition, n'hésitez pas à donner vos avis, ou si vous avez de meilleures idées.

Du coup pour toi, toutes les métriques sont publiques ?

Pour moi elles ne sont réservées qu'aux auteurs.

ça veut dire en gros que ces métriques ne sont pas approuvées majoritairement et étant donné qu'il y en a qui sont tout de même pour, on les met a disposition, sans toutefois les rendre publique.

Ma question était en fait : "pourquoi ne pas les rendre publiques" ? Du coup je suis d'accord avec le caribou : toutes les métriques sont publiques, certaines sont juste plus visibles que d'autres.

Y'a une différence entre "quelle donnée est disponible à travers une API" i.e. "quelle donnée est fournie par ZdS" et "quelle donnée est afffichée ou non dans l'UI".

Avant de se poser la question de comment on représente graphiquement en fonction de qui visionne la page, je pense vraiment qu'il faut décider de comment on agrège les données, quelles métriques, sur quelle plage temporelle, etc.

Faut voir ça vraiment comme une expression de besoin (user story dans le jargon agile machin chouette) :

je suis auteur, ce que je veux savoir c'est ci et ça

je suis validateur, ce qui m'intéresse c'est ça, avec telle granularité

Si on commence à réfléchir :

• en termes de métriques GA
• en termes d'UI

C'est mort on va patauger.

Je ne me prononce pas sur le sondage car justement : je ne suis ni potentiel auteur, ni validateur, les stats de consultation d'un tuto ne m'intéressent pas.

Je suis donc à 100% d'accord avec Eskimon, qui peut le plus peut le moins. On s'en fout d'un panneau complémentaire, faudra voir ça avec le designer UX qui s'occupera de l'interfaces de statistiques. Et là ouais la réflexion de Gabbro est complètement valable (à propos de la mise en page hein, le reste c'est son expression de besoin à lui et c'est adapté), faudra pas surcharger, y'a différents niveaux de lecture etc.

Mais faut penser "founisseur de données" pour l'instant. Sinon on va se perdre complètement.

Une donnée fournie par l'API de ZdS devrait être fournie dans une UI (certaines peut être moins visibles que d'autres), pour la simple et bonne raison qu'une fois que c'est disponible dans l'API tu ne peut pas interdire à un client tiers de l'afficher ailleurs. Pour rester cohérent il faudra donc que ce que donne l'API finisse sur le site d'une manière ou d'une autre.

Pour le reste, je laisse les avis s'exprimer sur la visibilité de la métrique.