Jouons avec l'API des membres

Les deux. Celle de Spacefox parce qu'il y a une grosse variance et que les derniers points sont piles poil au milieu de l'intervalle min-max observé dépuis novembre-dévembre. Les moyennes mobiles car l'intervale de temps utilisé (ou le taux d'apprentissage si tu la fait en mode "en ligne") va beaucoup influencer ton interprétation : fait là sur deux-semaines et tu verra que ça monte, fait là sur un ou deux mois et elle sera parfaitement droite.

Il y'a quand même un point qui fait que je ne sais pas dans quel sens on peut lire le dernier graphe posté. La courbe annonce qu'a l'ouverture du site le 21 juillet on était a (1800 - 800¹ ) = 1000 sessions, alors qu'on a atteint les milles membres seulement à la mi-septembre. Du coup, la métrique me parait un peu floue pour être exploitée convenablement.

Est ce que les sessions ne sont pas comptés plusieurs fois ? Genre une fois par process gunicorn ? Dans un tel cas, ce serait juste un facteur d'échelle et les tendances pourraient être utilisé.

Mais bon pour l'instant, manifestement, on a aucune métrique correcte.

@firm1 :

La courbe n'a d'intérêt que dans son évolution/tendance. C'est toujours pareil avec ce genre de métriques (sessions créées, nombre de requêtes API, …) : il est extrêmement difficile de faire le lien quantitativement avec le nombre d'utilisateurs. Mais la tendance est généralement intéressante à exploiter.

Une fois par process Gunicorn, je ne pense pas (quoique, ce serait à creuser). Par contre, une fois par point d'utilisation, oui. Typiquement, j'ai 4 sessions : mon fixe, mon portable, mon téléphone, le boulot.

Pour moi on ne peut rien en déduire sur le nombre d'utilisateurs actifs, mais c'est OK pour la tendance.

Si quelqu'un a une idée de métrique correcte, on peut même l'intégrer à Munin.

NB : (addition à mon message et celui de SpaceFox) : c'est valable pour en dégager une tendance tant qu'on ne change rien côté serveur, évidemment… C'est du vécu hein, c'est le genre de graphes à ne pas mettre entre toutes les mains : le nombre de requêtes qui chute du jour au lendemain, appel de la comm' "omfg c'est la catastrophe !" non, c'est juste le serveur/agrégateur en front qui fait très bien son boulot…

Pareil avec le jour où on a mis en place un CDN pour un client…

Ce truc, ça me donne presque envie d'écrire un article : "La difficulté de connaître le nombre d'utilisateurs actifs de son site".

Comme j'aime bien faire des graph, je propose du grain à moudre. Je me suis demandé si on observai des corrélations entre date d'inscription et date de dernière visite. Voici ça ci-dessous.

Que peut on remarquer ?

• On voit bien la ligne diagonale qui représente date d'inscription = date de dernière visite. Donc des membres qui se sont inscrits et ne sont jamais revenus.
• On voit bien la ligne vertical du début du site publique (je rappel que la majorité des comptes avaient été supprimés.
• L’histogramme du haut montre l'évolution des inscriptions : sans surprise un pic à l'ouverture.
• L'histogramme de droite montre que les dernières visites sont relativement constante, sauf sur les créneaux récents : Une grosse proportion des membres s'est connecté dans les dernières semaines.
• le graph du milieu montre une concentration à l'intersection de ces deux zones : on a probablement un gros noyau dur d'utilisateur inscrit à l'ouverture du site qui se connectent encore régulièrement.
• Le droite de régression est, au vu des données, difficile à interpréter.
• Il semble y avoir deux gros groupes d'utilisateurs : ceux qui se sont inscrits sans jamais revenir et ceux qui reviennent régulièrement. En effet les points au centre du triangle sont relativement faibles.

Bon c'est bien gentil les points, mais c'est pas pratique pour voir les concentrations. Voici donc une estimation continue de cette distribution :

On voit tres bien trois groupes d'utilisateurs. On a un gros noyau dur, ici depuis l'ouverture du site et qui se reconnectent régulièrement. On voit un deuxième groupe, en dessous, qu'on a perdu à l'ouverture. Rien de bien anormal. Le reste des membres est en fait dans la zone difficile à évaluer : des membres inscrits depuis peu qui se sont connectés plus ou moins récemment.

Au vus de ça, pour moi, il est très difficile de conclure qu'on perd des membres ou non. Le gros des nouveaux membres ont pour le moment une tendance assez disparate.

Edit:

Si on enlève la période de lancement et les derniers jours on obtient ça :

C'est à dire une majorité d'utilisateurs qui s'inscrivent sans revenir mais une tendance récente plus marqué qu'ailleurs qui semblerait montrer qu'on arrive mieux à conserver les derniers inscrits que. Mais c'est tellement léger que ce n'est probablement pas significatif.

Ce topic devrait être renommé « Analyse statistique du nombre de membres ». Je trouve ça super intéressant mais on a complètement détourné le sujet de base.

@Kje : je suis absolument fan de tes graphs, tu fais ça avec Panda ? T’as un lien vers les sources ?

J'utilise seaborn, c'est une surcouche a matplotlib qui utilise un style plus moderne, des jeux de couleurs issus de l'étude faite par xkcd et qui rajoute quelques fonctions d'analyse automatisé comme celles de mon dernier message.

Je fais un petit up pour savoir si :

• Avez-vous développé de nouvelles bêtises (ou avancé dans vos lib' respectives ?) ;
• Les statisticiens, avez-vous vu du nouveau en cette période de CdS ?

Moi qui voudrait faire une classe client pour l'API (en PHP), je me demandais si il ne faudrait pas faire une liste "officielle" des méthodes qu'une classe devrait comporter, une sorte d'interface ?

Je ne sais pas. En gros faut que ta lib mette a disposition l'API. Mais difficile de faire mieux. Typiquement en python j'ai implémenté un iterateur sur les membres qui va tout évaluer a la demande mais on pourrait pas faire ça facilement dans un langage comme le C. Autant laisser chaque lib adapter l'interface aux possibilité du langage. Dans le doute tu n'a qu'a reproduire les méthodes proposé par l'API.

A mon avis, l'interface c'est tout simplement la façade de l'API (createMember, updateMember, getMember).

Le truc le plus important pour un client API c'est qu'il te permette de te logger très facilement, qu'il conserve en mémoire ton jeton d'authentification et qu'il sache se relogger tout seul quand ton token a expiré. Et qu'il sache gérer les erreurs (arrêt si throttled, relogin sur 401, retry sur 503, …) et qu'il sache naviguer dans la pagination.

C'est vraiment ça qui est le plus casse les pieds à (ré)implémenter (la palme d'or revenant à la pagination…).

J'ai une question concernant cette API, respecte-t-elle les paramètres de confidentialité du compte utilisateur (par ex la case à cocher "Afficher mon adresse courriel publiquement").

Personnellement, je trouve cela assez grave que l'e-mail des utilisateurs puissent être partagés à leur insu (je ne pense pas que ce soit le cas, à mon avis vous avez réutilisé le paramètre de confidentialité existant). Les adresses email sont des données personnelles (la mienne contient par ex nom/prénom) et vous avez en tant qu'hébergeur des obligations en terme de sécurité et de confidentialité : http://vosdroits.service-public.fr/professionnels-entreprises/F24270.xhtml.

Personnellement, je trouve cela assez grave que l'e-mail des utilisateurs puissent être partagés à leur insu (je ne pense pas que ce soit le cas, à mon avis vous avez réutilisé le paramètre de confidentialité existant). Les adresses email sont des données personnelles (la mienne contient par ex nom/prénom) et vous avez en tant qu'hébergeur des obligations en terme de sécurité et de confidentialité : http://vosdroits.service-public.fr/professionnels-entreprises/F24270.xhtml.

oui, l'API respecte la confidentialité. Si la personne refuse de partager son mail l'API le dit et n'envoie pas le mail.

Venant d'un utilisateur qui avait comme pseudo son adresse e-mail, je trouve ça marrant.

Cela dit, oui. L'e-mail n'est pas renvoyé si l'utilisateur ne le désire pas (conformément à ses paramètres).

Edit : Grilled.

Venant d'un utilisateur qui avait comme pseudo son adresse e-mail, je trouve ça marrant.

Il s'agissait d'un compte de test (que j'avais oublié de supprimer) je n'étais pas sur mon navigateur standard et grillé par l'auto-connexion

Enfin bref, évidement que c'est respecté, je pense que beaucoup d'entre nous auraient râlé sinon. On pourrait imaginer un autre paramètre spécifique à l'API mais je pense que celui actuel est suffisant.

En testant un peu l'API pour avoir une idée de ce que l'on peut faire, j'ai été très surpris.

Clem a disparue!!!

Elle ne s'est pas présentée sur le site depuis le 12 aout, soit 25 jours. Est-ce en lien avec l'histoire d'un zeste sans fin? Cette histoire deviendrait-elle vraie sur du court terme?

Suite à cette malheureuse analyse, nous devons nous demander que faire! devons nous lancer un avis de recherche? Avons nous des informations nous permettant de la retrouver, où est-ce bien Saucisson qui projette de la manger (ou de l'assassiner)?

L'API

En attendant de nouvelles informations, cette API est géniale, et on devrait pouvoir en faire pleins de trucs sympas!

D'autres fonctionnalités seraient-elles en développement? (modification de ses tutoriels à distance, …) pour pouvoir faire (par exemple) une appli zeste de savoir, …

D'autres fonctionnalités seraient-elles en développement? (modification de ses tutoriels à distance, …) pour pouvoir faire (par exemple) une appli zeste de savoir, …

techniquement parlant, il sera possible d'importer un tutoriel dans les semaines à venir. Que signifie "importer un tutoriel"? envoyer deux .zip : un avec le texte et le manifeste, un avec les images.

Pour l'instant l'API des tuto n'est pas créée, donc techniquement parlant, on ne peut qu'importer sous forme d'un .zip. Peut être que plus tard ça changera, mais aps tout de suite.