Matomo/Réflexions version2
= Introduction =
Histoire.
phpMyVisites est depuis 1 an et demi en version 1.x. La structure actuelle n'est pas adaptée pour répondre aux exigences toujours plus importantes des utilisateurs, amateurs, confirmés ou entreprises. La structure de la base n'est pas assez souple, évolutive. La structure du code n'est pas modulaire. Il n'est pas facile de faire des modifications sur le code source, de développer des skins.
Nous souhaitons développer une version 2 de phpmyvisites, qui aura des fonctionnalités importantes en terme d'évolutivité et de souplesse. Bien sûr nous réutiliserons des parties importantes de l'actuel phpMyVisites qui fonctionnent bien (traductions, design de l'interface, présentation générale, bases de données des moteurs, etc.). Mais il est obligatoire de faire un travail de fond sur la base de données, les fichiers, la gestion des données, l'architecture générale.
Cette version 2 représente un travail très conséquent, et nous avons besoin de l'aide de spécialistes pour nous aider dans nos choix techniques, nos réflexions, pour donner des bonnes idées ou nous conseiller sur ce qu'il faut faire et ne pas faire.
Ce wiki est l'endroit idéal pour que chacun puisse s'exprimer. Vous pouvez le compléter librement, après vous être enregistré. Bonne lecture !!
Objectifs.
PhpMyVisites a pour objectif de devenir l'outil de statistiques nouvelle génération le plus complet, rapide, puissant et évolutif. Pour cela l'équipe de développement s'engage à suivre les 10 commandements suivants :
Release Early, release Often.
Suivons les grandes idées du développement du logiciel libre. On publiera des versions bêta le plus régulièrement possible cet été pour que les testeurs ne s'ennuient pas. Également :
 18. To solve an interesting problem, start by finding a problem that is interesting to you.
 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
 7. Release early. Release often. And listen to your customers.
 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
 9. Smart data structures and dumb code works a lot better than the other way around.
 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
 12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
 13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
 15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
 17. A security system is only as secure as its secret. Beware of pseudo-secrets.
 19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
= DeadLine prévue =
Beta 1, Codename "Ouf" (10 octobre).
Première release publique
Plus tard.
= Documentation de phpMyVisites v2 =
Une documentation qui soit modulaire, réutilisable !
Dans ce domaine tout reste à faire. L'idée est de faire une documentation utilisateur très complète, facile à comprendre, et surtout réutilisable. En effet à long terme nous aimerions que les éléments de l'interface de phpmv soient cliquables, et le clic ouvre la partie de la doc concernée.
Par exemple un clic sur [?] au dessus d'un graphe ouvre une pop up ou charge dans la page l'explication de ce graphe, en 2 parties : 
Documentation technique.
= Général =
Documentation du code.
= Questions / réponses =
Abstraction BDD par Adodb (choix final).
Nous allons certainement utiliser Adodb pour l'abstraction BDD.
Le principe sera :
- rester au plus près des appels natifs pour l'enregistrement des logs, on devra donc écrire les requêtes utilisées pour les logs pour chaque serveur de base de données séparément dans des fichiers séparés, sachant que les requêtes sont normalement standards.
- pour tout le reste de l'appli, on utilise Adodb
Ce choix fait suite à des benchmarks et rapports de fonctionnalités que je publierai peut être au propre un jour.
Nous mettions en comparaison pear:db, adodb, adodblite, et mysql natif.
Comptabilisation des moteurs de recherches via un système de log parallèle.
Voir discussion sur
http://fr.wikibooks.org/wiki/Documentation_phpMyVisites/R%C3%A9flexions_version2/SearchEnginesDetection
Sauvegarde et restauration des données par un système simple.
Dans l'administration, un lien « Sauvegarder la base de données » entraîne la création d'un fichier .gz sur le serveur, librement téléchargeable par l'utilisateur. Cette archive contient un DUMP de la base.
Dans l’administration, un lien « Restaurer la base de données » permet la lecture de ce GZ et la restauration des données du DUMP.
À réfléchir pour une compatibilité avec toutes les bases de données (ça ne doit pas être évident ?). Le générateur de DUMP doit à mon avis ne pas dépendre de la structure de la bdd et doit être générique (il lit tout seuls les tables avec un préfixe xxx_ et les champs et crée le fichier).
Export OOo.
Utiliser du format open document pour l'export des données (compatible koffice, OO 2, etc.)
Voir les classes à utiliser pour faire ça
Autres Q/A.
= Architecture =
Base de données.
= Coding Standard =
= Nouvelles fonctionnalités (liste non définitive) =
"Des fonctionnalités (parmi les moins importantes) ne seront peut être pas développées s'il manque du temps."
Fonctionnalités globales.
Intérêts de visites.
On peut analyser les intérêts des visiteurs (indicateurs définis) selon divers critères caractérisant ce visiteur.
Critères :
Indicateurs (informations) disponibles :
Ex : combien de pages en moyenne ou de temps en moyenne restent les gens
Nommer les pages.
Possibilité de nommer les pages, via une variable dans le code javascript, de la forme par exemple :
var pagename = "Mon_titre";
var pagename = "groupe1&gt;groupe2&gt;mon_titre";
var pagename = "groupe1&gt;mon_titre";
Cette convention de nommage demande un temps d'adaptation au site sur lequel phpmyvisites est installé mais propose une très grande facilité de maintenance (voire aucune maintenance, normalement), et une évolution (si le site évolue largement) très aisée.
À noter que l'on peut récupérer le contenu de la balise <title>[..]</title> pour l'assigner automatiquement à cette variable, pour encore plus de facilité de mise en place.
Si la variable pagename n'est pas renseignée, l'URL est enregistrée (avec possibilité d'exclure certains paramètres de cette URL).
Le nommage de pages est très important.
Il peut par exemple permettre de savoir quelles actions précises sont effectués sur un module donné.
Il peut permettre de connaître l'état d'avancement de l'acte d'achat sur un site de commerce (mise dans le panier, validation commandes, saisies coordonnées, paiement). On peut alors facilement visionner le taux d'abandon à chaque étape.
Groupes de pages.
Possibilité de classer dynamiquement les pages dans des groupes de pages. N niveaux de groupes sont disponibles.
var pagename = "groupe1&gt;groupe2&gt;mon_titre";
Possibilité d'avoir les stats par groupe de pages (nombre de consultation du groupe).
Nombre de consultation par groupe d'entrée, par groupe de sortie (statistiques déjà présentes pour les pages).
IHM : Elle doit être simple, clair, accessible. On doit pouvoir voir tous les groupes, éventuellement
avec AJAX pour un chargement rapide et efficace (et joli).à définir... 
Définition de variables modulaires par page.
Nouveauté qui permet à phpMyVisites "de répondre a priori à tout problème, même très spécifique".
Le principe est simple : des variables (4 pour l'instant) sont dites « libres » et sont donc définissables par le webmaster.
Elles peuvent désigner des nombres (chiffres, prix, id), des chaînes (PrénomNom de la personne logguée pour un intranet, nom d'un sous état d'une page...), des états (connecté à la section membre), etc.
Il est ensuite possible d'isoler les visites en fonctions de ces variables et de leur valeur.
Exemple : 
on peut faire des études en fonction de la valeur du paramètre
désignant le PrénomNom des membres
on peut étudier les différences de comportement en
fonction des visiteurs connectés (abonnés) ou anonymes
Ces variables sont propres à chaque site et sont renommables par site, pour améliorer l'affichage dans l'interface.
Pour la consultation des données, le principe suivant peut être utilisé : lors du clic sur une page (ou « action ») donnée, une pop up se lance, et pour chacune des 4 variables (si elles ont été assignées), on affiche :
Ex : 
Le lien consultation par exemple déplie un tableau avec le
contenu suivant :
On visionne pour une page donné des sous états, de manière simple et pratique.
On peut imaginer sur un "intranet" une variable PrenomNom :
On visionne rapidement qui s'est connecté à chaque
page, combien de fois.
Ces statistiques sont aussi disponibles pour les groupes.
Dans ce cas on fait la somme pour chaque page du groupe.
Pour le groupe « plomberie » on somme le nombre de pages vues avec un état « connecté » ou « anonyme ».
Avec cette technique de variables libres et renommables, on peut envisager répondre à tout problème spécifique.
Statistiques à l'année.
Pour l'instant seules sont dispos les stats au jour, semaines, mois.
Pour les stats à l'année, les stats sur les mois sont utilisées.
Bilan multi-sites (facultatif).
Dans le sélecteur de sites est disponible un « Bilan global », où sont sommées et moyennées les valeurs essentielles de chaque site.
Cela implique que les données de tous les sites soient archivées, cela lance donc éventuellement l'archivage de chaque site.
Les données intégrées seront (à compléter) : 
Mesure des téléchargements.
Les téléchargements sont simples à mettre en place : pour comptabiliser dans phpmyvisites une page de type "fichier", et donc pouvoir comptabiliser des fichiers .zip .exe ou autres, il suffit de mettre un lien pour le téléchargement de ce fichier de la forme
 http://adresse phpmyvisites/phpmyvisites.php?go=URL OU ON REDIRIGE&pagename=FILE:NOM DU FICHIER LISIBLE AVEC ÉVENTUELLEMENT LES GROUPES&id=ID DU SITE DANS PHPMYVISITES
Le script redirige automatiquement vers l'url _GET['go'] 
La variable pagename dans le cas d'un fichier est de la forme
 var pagename = "FILE:fichier_a_telecharger.zip";
Ou avec un nom « parlant »
 var pagename = "FILE:Plan_accès_entreprise";
Gestion des referers « partenaires ».
Il serait intéressant que certaines URLS connues soient classées dans une section partenaires dans affluents. De même quand il y a un paramètre idsite_partner=xx dans l'url du site analysé pouvoir considérer cet id comme provenant d'un site partenaire.
Cette fonctionnalité entraîne la gestion des sites partenaires dans l'administration :
Gestion des referers « newsletters ».
Idem que pour les sites partenaires, gérer les visites venant d'une newsletter via la détection d'une variable idnewsletter.
Cette fonctionnalité entraîne la gestion des newsletters dans l'administration :
L'id valeur de la variable idnewsletter est alors donné par phpmyvisites, et c'est cet id qui doit être placé dans les liens de la newsletter.
Chemins, suivi, tracking... (facultatif).
On définit des chemins à étudier. Un chemin est un ensemble de pages, de 2 à 6 par exemple.
 Exemple :
 accueil > consultation produit > avis clients > consultations produit > achat 
Informations à donner pour chaque chemin prédéfini de ce type. Attention, la notion de prédéfini est importante, car seules les stats sur des chemins pré-demandés par l'utilisateur seront accessibles (impossible de calculer les données pour tous les chemins différents, milliers de possibilités)
avez vous des idées de nouvelles fonctionnalités ou IHM ?
Fonctionnalités administration.
Exclusion d'IP et de plages d'IP.
Pour un site donné, on peut exclure une ou plusieurs plages d'IP.
De la forme A.B.C.D ou A.B.C.x ou A.B.x ou A.x
x pouvant prendre n'importe quelle valeur
Intérêt : dans les réseaux de grandes entreprises, il est impossible d'installer un cookie sur chaque poste (technique disponible actuellement dans phpmyvisites) cette exclusion par plage d'IPs est pratique et fiable.
Gestion avancée des utilisateurs et des droits.
Importante nouveauté. Il sera possible de créer des utilisateurs avec différents droits sur chaque site.
Fonctionnalités : 
Niveaux de droits prédéfinis (d'autres sont ajoutables mais ça ne semble pas naturel)
Chaque utilisateur est caractérisé par un alias, un login, un password
Sont affichés les dates de dernière connexion, les ips et hostnames des dernières connexions.<BR><BR>A
noter l'arrivée par défaut en mode « anonymous » qui concerne tous les visiteurs non logguées. On gère les droits de ce anonymous comme on gère les droits d'un user enregistré. Bien sûr il ne faut pas lui donner plus que le droit de visiteur.
Un site peut avoir plusieurs URLs différentes.
Ces URLs sont enregistrées dans l'admin pour le site considérée et les provenances à partir de ces urls ne sont pas considérées dans les «
sites affluents » mais dans les « accès directs »
Système simple et pratique de sauvegarde restauration de toutes les données (facultatif).
En un clic, une archive est créée sur le serveur dans un répertoire /backup/ en gzippé
Possibilité de restaurer les stats facilement (lecture du gzip et écriture données base)
Fonctionnalités visites.
Fréquences des visites.
Question : comment gérer les visiteurs uniques proprement ? <BR>Réponse : gestion plus fine des visiteurs et de leur visites. Gestion via des cookies et une autre méthode qui consiste à considérer que la parfaite concordances d'éléments techniques que sont l'OS, la résolution, le navigateur, la profondeur de couleur et l'IP implique qu'une personne est unique (elle a donc une IP fixe et une configuration fixe, souvent le cas, et de plus en plus pour les Ips fixes). On ne peut plus se baser sur la différence heure locale/heure serveur car les XP SP2 sont mis à l'heure de MS automatiquement. Cette information n'est plus pertinente. À noter que si une personne change de navigateur il n'y aura aucun
moyen de la détecter comme un visiteur unique (son cookie change ET son navigateur change). Ce cas reste très rare.
Information disponibles :
Pages vues par visites significatives.
Nombre de pages vues pour les visites de plus d'une page. Plus intéressant que la donnée « pages vues par visite » qui prend en compte les visites à une page vue.
Durée de visite par page.
Par page être capable de donner le temps de
visite moyen
Top des meilleurs configurations.
Top des meilleurs trio OS/navigateur/résolution
pour montrer les tendances du marché
Pages des visites à une page vue (facultatif).
Liste des pages qui ont entraînées
une visite à une page vue (single access pages) : classées
par nombre de visites. Cela peut mettre en avant des pages sans
contenu ou liens vers d'autres contenus. Des pages à
retravailler (le taux de visites à une page vue doit être
le plus faible possible).
Divers (à préciser...).
Export des données dans différents formats (facultatif).
Il serait intéressant de pouvoir exporter
toutes les données fournies dans l'interface de phpmyvisites
dans différents formats :
Cette fonctionnalité implique un important
travail de structuration des donnéees, le must étant
certainement de passer par le XML pour ces exportations. Voir la
compatibilité de la classe PEAR XML_Serializer avec les
hébergeurs, car elle serait très pratique.
Vision plus globale de l'évolution à long terme de l'audience (facultatif).
Il serait intéressant de voir plus
facilement l'évolution de l'audience sur des longues périodes.
Solutions ? Graphiques plus étalés dans le temps,
tableaux récapitulatifs remontant plus que
7jours/7semaines/7mois.
À réfléchir...
Conservation urls précises des moteurs de recherche (facultatif).
Demande fréquente des utilisateurs mais
lourdes contraintes techniques : il serait intéressant pour
eux de conserver les urls précises des moteurs de recherche qui
ont permis d'accéder au site. Cela permet de voir directement
le classement dans le moteur de recherche en un clic.<BR>Problèmes
différents, il y a énormément d'adresses à
conserver pour un volume de données très important. 
Le must serait de
proposer cette fonctionnalité en option activable ou pas.<BR>A
voir si du temps disponible...
Ne logguer que les requetes sur le site audité (facultatif).
SI un concurrent met le même marqueur sur les pages de SON site, alors on enregistre ses stats dans notre phpmyvisites.
Aucun intérêt pour qq1 de faire si ce n'est de polluer les stats.
Il suffirait de tester que l'url est bien une des urls du site enregistré dans site_urls
= Divers =