@firm1, tu voulais faire un POC, tu as quelque chose ou pas ?
Désolé je n'ai pas écrit grand chose. J'attendais probablement une sorte de Go que je n'ai pas eu. Mais là je ne peux plus coder grand chose en ce moment.
Ok, pas de souci c'etait surtout pour clarifier et éventuellement gagner du temps 
Shig a aussi bricolé un truc, il m'envoie ses sources bientôt
Dites j'ai découvert ça hier : https://developers.google.com/analytics/devguides/reporting/embed/v1/
Avantages :
Inconvénients :
Qu'en pensez-vous ?
Je pense qu'on peut mettre en place ce service pour avoir des retours sur l'utilisation réelle des stats et ce qui intéresse les auteurs (permettant de mieux cibler le dev d'un outil maison), à condition de prendre l'engagement de développer un outil maison pour éliminer la dépendance dans un délai raisonnable (genre 6 mois).
Pour tester (nécessite un compte Google Analytics) : https://ga-dev-tools.appspot.com/embed-api/
à condition de prendre l'engagement de développer un outil maison pour éliminer la dépendance dans un délai raisonnable (genre 6 mois).
Éliminer la dépendance de Google Analytics en général ou de l'outil en particulier ?
En tout cas se donner des ultimatums ca me semble illusoire. Les devs sont benevoles, on est bien incapable de faire de quelconque planning sur ce qui sera dev ou pas (car les devs n'ont pas toujours le temps ou simplement l'envie de faire telle ou telle feature)
PS : Par rapport a GA, SpaceFox avait redonne un lien plus tot sur pourquoi GA et pas un autre.
Je parle bien d'éliminer l'outil en particulier : éliminer GA paraît illusoire à court ou moyen terme.
Ensuite, je sais bien ce que tu dis sur les devs bénévoles, ce serait juste un moyen d'éviter que la situation s'enkyste parce qu'il y a plus intéressant à faire et qu'on se crée une dépendance non nécessaire juste "pour aller plus vite". La sortie de v1.5 nous a montré qu'il peut y avoir des ultimatums de temps en temps, du moment que cela ne devient pas une habitude.
Testons ça et on verra bien. L'usage nous dira l'utilité ou le besoin de changer ça.
J'ai parlée avec Shig hier en MP, et il avait bricole un peu et m'a aussi fait des remarques tres intéressantes que je me permet de vous recoller ici avec son autorisation :
Comme promis, voici mes sources. Le principe était de fonctionner en deux temps :
Pourquoi fonctionner ainsi ? Pour plusieurs raison en fait… D'une part, il y a une limitation dans le nombre d'enregistrement récupérable par requête avec la version gratuite de l'API. Il est donc impossible de récupérer tout l'historique d'un coup par exemple. J'avais alors pris le parti de récupérer les données quotidiennement et de stocker l'historique en base.
Autre gros intérêt de procéder ainsi : rester indépendant de la source de données. Si un jour on veut changer de "prestataire" pour les stats (on parle ici ou là de ne plus utiliser Google…), alors il suffira de changer l'alim de la base de données. Cela permet de ne rien modifier aux requêtes de génération de rapport et de conserver l'historique. Bref, on sépare l'alim de la restitution. Pour bien faire, il faudrait même utiliser un "sas" de données, etc. En fait la base de l'informatique Décisionnelle (mon taf)…
Autre truc : tu verras que dans le ga_settings.py, j'ai regroupé les mots de passes, etc. mais aussi la définition des "rapports" (exemple : dailyzds), constitués d'"éléments de rapport". L'idée était de n'avoir qu'à paramétrer ces rapports sans changer le code ailleurs. Là encore, ce n'est sûrement pas fait dans les règles de l'art mais ça marchait plutôt pas mal.
Bon, je suis assez bref et sûrement confus, mais je n'ai pas trop le temps là tout de suite. N'hésite pas si tu as des questions particulières.
Enfin concernant l'API des graphes, ça a l'air top en effet ! A court terme ça peut être même carrément génial. Par contre ça nous enferme un peu plus dans l'Univers Google Analytics, ce qui n'est pas top si on pense effectivement passer à autre chose à moyen terme. M'enfin, on n'y est pas. Si on arrive à sortir quelque chose de classe pour les auteurs, ce serait un gros plus pour ZdS. Une sorte de killer feature !
En tout cas le sujet m'intéresse beaucoup. Si j'arrive à dégager un peu de temps, je participerai avec plaisir !
Pour les graphes proprement dits, c'est la mode en ce moment de sortir des libs de graphe en JS, via Canevas, etc… donc ne ne me fais pas de souci là-dessus.
Quant à la notion d'ultimatum, elle ne marche que sur quelques corrections de bugs assez simples. Et encore, lors de la v1.5 c'était aussi pour respecter un planning défini et connu longtemps ) l'avance (le processus de release). Redévelopper ce genre d'outil, c'est beaucoup trop de boulot pour que ça puisse marcher.
Moi je propose qu'a court terme on laisse le choix entre "utiliser embed-api" ou "faire un module perso de rapport" au libre choix du dev qui va prendre ça en charge.
Donc est-ce que ca irait au plus grand nombre de partir sur cette outil "embedded" (embarqué) fourni par google dans un premier temps ou laisser le dev' qui prendra ca en charge decider pour faire "au mieux au plus tôt" et voir plus tard si c'est nécessaire d'ajuster le tir sur :
? Si oui on pourrait ptet passer la ZEP en validation pour commencer a doucement dev ?
Petit point philosophie : Google Analytics (GA) est un choix fait pour plusieurs motifs. L'utilisateur du site n'est lui pas contraint a être pisté et l'auteur d'un contenu n'est pas non plus sujet a l'acceptation de GA puisque cette interface est proposée via l'association et non pas le compte de l'auteur (je sais pas si je suis clair, mais le fond de mon propos est "Personne n'est contraint a rien")
OK pour moi.
Pareil.
Finalement on valide pas, on a un peu discuté avec ShigeruM et on a encore besoin de votre avis . Il va venir vous expliquer pourquoi très bientôt
ShigeruM n'a pas le temps de s'en occuper, donc pour limiter le suspens, voici des citations de notre échange pour vous aider a comprendre notre débat : "Doit-on découpler (datawarehouser) les statistiques ?"
C'est un peu long a lire, mais en sort un débat (très) intéressant entre pragmatisme et jeu avec les données…
1- ShigeruM :
Le principe est de fonctionner en deux temps :
Pourquoi fonctionner ainsi ? Pour plusieurs raison en fait… D'une part, il y a une limitation dans le nombre d'enregistrement récupérable par requête avec la version gratuite de l'API. Il est donc impossible de récupérer tout l'historique d'un coup par exemple. J'avais alors pris le parti de récupérer les données quotidiennement et de stocker l'historique en base.
Autre gros intérêt de procéder ainsi : rester indépendant de la source de données. Si un jour on veut changer de "prestataire" pour les stats (on parle ici ou là de ne plus utiliser Google…), alors il suffira de changer l'alim de la base de données. Cela permet de ne rien modifier aux requêtes de génération de rapport et de conserver l'historique. Bref, on sépare l'alim de la restitution. Pour bien faire, il faudrait même utiliser un "sas" de données, etc. En fait la base de l'informatique Décisionnelle (mon taf)…
2- Réponse Eskimon
Je me pose une question sur l’intérêt de sauver les trucs en base plutôt que d'afficher directement ce que donne google… voici mes arguments :
Bref, je reconnais un peu de mauvaise foi, mais je dois dire que ce dev supplémentaire d'adaptation de données me fait un peu peur pour au final une utilité toute relative…
3- ShigeruM
Ça se tient. Perso je préfère ramener les données et en être vraiment "maître", dans le sens où je peux les requêter comme je veux, avec les outils que je veux, etc. On dissocie la récupération des données de leur exploitation, ce qui me semble plus propre. Et puis rien ne dit que Google fournisse l'historique gratuitement ad vitam… Mais là, tout comme notre changement de fournisseur de stats, c'est ultra-hypothétique. 
L’autre grand intérêt est de pouvoir croiser les données de GA avec nos propres données. Par exemple, comment faire, avec GA, pour répondre à des questions telles que "Quel est la catégorie de tutos la plus visitées ?" ? Ou encore "Les gros posteurs sur les forums sont-ils aussi des auteurs prolifiques ?" ? Avec GA en direct, on a les stats de visites sur les pages, ok. Mais en croisant avec la base opérationnel de ZdS, on pourrait aller beaucoup plus loin.
Au final, même si je pense que "datawarehouser" nos données est la meilleurs solution sur bien des aspects, peut-être que le pragmatisme doit l'emporter en effet, et donc afficher directement depuis GA dans un premier temps…
4- Eskimon
Ouai effectivement je comprend encore mieux la logique de la manœuvre et elle se tient bien.
Du coup on a vraiment deux approches :
5- ShigeruM
Ce type de croisement de données permet de faire bien plus que de simples stats rigolotes, je pense. Ça peut permettre de concentrer nos efforts sur telle ou telle partie du site qu'on constate délaissée, ou bien d'inciter davantage les gros posteurs à écrire des tutos, etc. En fait ça permettrait d'en savoir beaucoup plus sur la communauté et sur l'utilisation qu'elle fait du site et donc de prendre des décisions sur bien des sujets en connaissance de cause.
Mais je suis comme toi, je ne sais pas quelle est la meilleure approche entre ça et le pragmatisme. La première approche étant beaucoup plus gourmande en dev et en ressource BDD (quoi que les temps de traitements en base et le stockage ne sont pas un soucis à mon avis), son regard global serait utile.
Félicitation d'avoir tout lu, maintenant a vous de venir vous greffer au débat ma foi très intéressant !
Est-ce qu'on a une idée :
J'ai une remarque/argument supplémentaire pour la solution consistant à stocker nous-même les données.
Je parlais plus tôt d'une API pour servir les données. Ça a été un peu passé sous silence mais ça me paraît extrêmement important.
Les reports c'est beau, ça permet de faire de beaux exports, y'a de très bonnes solutions pro (ou pas) qui permettent de créer des critères d'agrégation, de générer des graphes, des cubes etc. Sur d'énormes volumes de données c'est très intéressant.
Mais il ne me semble pas qu'il faille voir les choses sous cet angle, si je relis la première ligne de la ZEP, on est en train de parler des auteurs. Donc un contexte assez limité. Et franchement, ce qui, à mon avis, va les intéresser c'est d'abord de disposer des données, après, qu'ils se partagent une feuille Excel ou que quelqu'un fasse une app node-webkit ultra sex ou t'as juste à saisir le nom de ton tuto pour avoir des graphes temps-réel, j'aurais tendance à dire peu importe.
L'accent est beaucoup mis sur la représentation des données, ouais OK c'est clair que y'a moyen de faire des trucs super sympas et c'est plus facile d'avancer en imaginant un graphe plutôt qu'un bout de JSON, je le conçois, mais à mon avis c'est pas la bonne façon de voir le truc.
Bref, ça c'était pour enfoncer le clou de "on sert les données par API, basta, si un joli projet voit le jour (ptetre même en "interne") on l'intégrera dans une page.
Du coup, en partant de ce principe là, ça va directement dans le sens de servir ses propres données, pas celles de Google, sinon en effet, on va attaquer la rate limit de l'API Google d'une part, et il va falloir de toute façon faire un pont entre l'API GA et celle de ZdS.
Si on construit notre propre modèle de données, avec l'énorme boulot qui a été fourni par les devs de l'API existante et les briques en place, ça me paraît pas insensé de penser que ça pourrait aller vachement vite. Après tu donnes ça à manger à n'importe quel dev qui connaît une lib de graphes / reports et le problème est réglé.
Et si l'API n'est pas la bonne approche, alors le travail n'est pas perdu, on pourrait générer des reports "à l'ancienne" (si je puis me permettre) à grands coups de reports/requêtes paramétrés qui sortiront soit des images, soit de l'HTML soit du PDF soit tout ça à la fois.
Mais dans les deux cas, je pense qu'il est essentiel d'organiser les données proprement dans un stockage qui nous est propre et qu'on maîtrise, sans a priori sur la techno d'ailleurs, ça peut-être "not-only"(j'insite)SQL (la majeure partie en SQL, le détail des visites dans Redis ou autre, par exemple), ça peut permettre de requêter de façon très fine les données (paramètres de requête API includeDetails ? par ex.).
Voilà excusez-moi de revenir là-dessus mais je pense vraiment que ZdS devrait se contenter de servir les données et effectivement se concentrer sur le format de celles-ci, plutôt que de se dire "le format c'est le même que GA, on fait juste du "cut-through", ça me paraît vraiment être une fausse bonne idée : oui ça ira plus vite mais ça me semble pas pérenne pour deux sous et typiquement le cas où 6 mois plus tard on se dit "ah merde on est bloqué on peut pas corréler c'est con : soit on fait un pont un peu crado, soit on stocke chez nous" et rebelote pour cette discussion.
Voilà, c'est vraiment que mon avis, et ça peut complètement être à côté de la plaque.
PS (SpaceFox ayant posté entre temps) : oui ce sont des métriques intéressantes à prendre en compte aussi.
Au final, même si je pense que "datawarehouser" nos données est la meilleurs solution sur bien des aspects, peut-être que le pragmatisme doit l'emporter en effet, et donc afficher directement depuis GA dans un premier temps…
Pourquoi partir dans ce cas sur l'affichage direct depuis GA, si l'on sait qu'on va vouloir tendre vers un DWH dans le futur ? A mon sens, si cette option apporte les avantages/puissance rapportés dans le mail, autant partir sur ça directement.
Niveau volume de données, déporter ça sur un nouveau serveur de BDD, c'est envisageable ?
Le principe est de fonctionner en deux temps :
- récupérer les infos depuis GA et les stocker en base ;
- utiliser cette base pour générer des rapports.
Vu la masse des données (historique), leur forme (multidimensionnelle), et l'utilisation qu'on souhaite en faire (décisionnel), si jamais on veut stocker toutes les données GA dans une base, la solution la plus judicieuse serait de stocker ça dans une base NoSQL (Mongodb, Elasticsearch, etc.).
EDIT : pour Javier, une base telle que Elasticsearch propose déjà une API de requetage des données. Donc on ferait d'une pierre deux coup.
Est-ce qu'on a une idée :
- du temps de dev que ça nécessite de récupérer les données ?
- du volume de données à récupérer ?
Il faut aussi je pense compter le temps de dev de l'interface. Car GA peut nous fournir directement les graph. En plus du temps de dev pour récupérer les données, il faut compter celui de l'exploitation.
Pour autant moi j'en revient toujours a la même chose. On est de toute façon tous d'accord que l'idéal serait de stocker chez nous. Je pense que ça ce discute même pas, c'est le coté parfait. Mais si cette solution implique trop de travail ou personne de motivé pour le faire, on aura tout perdu. Je pense encore une fois que ça va dépendre de nos ressources de dev. Si on a uniquement un dev pour intégrer ce truc tout pret de GA, autant au moins avoir ça, en laissant cette zep ouverte pour le jour où quelqu'un pourra faire la solution propre. Si par contre on a des devs motivés pour faire directement la solution propre, parfait.
En soit je ne voit pas de problème à mettre en place la solution GA toute prete puisqu'elle sera toujours plus limité que la notre. La solution toute prete ne fera que présenter les chiffres. Ce n'est pas comme si elle venait avec une dépendance forte, quand on aura la meilleur solution de développé, on pourra remplacer ça sans impacter personne.
Bref pour moi il vaut mieux laisser ça au choix du dev.
pour Javier, une base telle que Elasticsearch propose déjà une API de requetage des données. Donc on ferait d'une pierre deux coup.
Je sais, je l'utilise quotidiennement. Mais elle n'est pas au "format" ZdS c'était mon propos.
Pour parler uniquement du "dans un premier temps", on peut peut-être faire un mix des deux :
Comme ça, le jour où on a des devs libres pour implémenter une interface sexy et/ou un système de requêtage qui vont bien, on aura déjà les données brutes en stock, et la migration sera beaucoup plus simple.
Alors certes, ça nécessite tout de même du dev pour réaliser le système d'import…
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
