Matomo/Réflexions version2

Matomo

1. Présentation
2. Installation
3. Configuration
4. Fonctionnalités
5. Fonctionnement
6. Traductions
7. Soutien
8. À propos
9. CodingStandard

---

1. Réflexion Version 2
2. SearchEnginesDetection
3. Réflexions version2 test
4. interfaces club

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 :

• Reliable (fiable)

phpMyVisites sera fiable, ne provoquera aucune perte de données. Un outil de sauvegarde/restauration sera disponible par la suite pour prévenir tout problème.

• Scalable (évolutif)

phpMyVisites saura s'adapter à des audiences de toutes tailles. phpMyVisites saura tenir la charge et assurera une rapidité maximale, via un système d'archivage complexe et une optimisation des traitements et calculs sur les données.

• Secure (sécurisé)

phpMyVisites sera protégé de toute forme de hacking, que ce soit par des visiteurs anonymes ou des membres enregistrés avec des privilèges. La sécurité est une priorité majeure de l'équipe de développement.

• Flexible (flexible)

phpMyVisites proposera un système de thèmes, qui permettra de fournir des rapports avec des apparences différentes pour répondre aux besoins de chaque type d'utilisateurs. Le contenu des rapports pourra également être facilement modifié.

• Modular (Modulaire)

phpMyVisites sera découpé en parties fonctionnelles, chacune étant le plus indépendante possible du reste de l'application. L'ajout de nouvelles fonctionnalités sera facilitée, que ce soit au niveau de l'intégration code ou base de données, et de l'affichage.

• Localizable (traduisible)

phpMyVisites sera entièrement traduisible et gérera les spécificités de chaque langue. Le système de traduction sera simple et il sera très rapide d'ajouter une nouvelle langue.

• Intuitive (intuitif)

phpMyVisites sera facile à installer, facile à utiliser. Les utilisateurs pourront facilement tirer d'importantes conclusions sur l'activité de leur site Internet et sur l'intérêt de leurs visiteurs. Les utilisateurs avancés pourront exploiter les fonctionnalités complexes de phpMyVisites pour des analyses encore plus fines.

• Portable (portable)

phpMyVisites fonctionnera avec des exigences techniques de compatibilité importantes : register_globals Off, error_reporting E_ALL, ne dépendra pas du serveur utilisé, ne dépendra pas du système d'exploitation utilisé, sera compatible avec des versions anciennes de php.

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

Beta 2, Codename "buggyTrip" (date prévue : 29 Octobre)

• correction bug beta1
• gestion multi users / groups puissante
• première implémentation des graphiques

Beta 3 (date prévue : 6 Novembre)

• correction bugs beta 2
• graphiques des statistiques via artichow (tous implémentées, 6 types de graphe)

Beta 4 (date prévue : 13 Novembre)

• gérer les fichiers ds le tableau des pages ou séparément
• correction bugs beta 3
• cookie d'exclusion du webmaster
• gérer les variables par page

Beta 5 (date prévue : 20 Novembre)

• correction bug beta 4
• Module assurant le lancement des calculs des données automatiquement, lancés par les visiteurs lors de leur visite sur phpmyvisites.php (archive ts les sites, tts les périodes, calcule et envoie les mails)
• ajouter choix logo par site
• cleaner présentation module admin
• version anglaise parfaite
• pouvoir choisir de sender le résumé des sites pour l'envoi (seulement sites autorisés !)
• gestion fine des e-mails d'envoi (par utilisateur, fréquence d'envoi, etc.)

Plus tard

• module de conversion des stats de phpmv 1.x vers 2.x
• pouvoir choisir le site sur lequel on arrive par défaut OU sur le résumé

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 :

• "Résumé" qui explique en une phrase ce que donne cet élément comme information
• "Analyse" qui explique comment analyser correctement les données de cet élément

Documentation générale

• Présentation succincte
• Installation et Mise à jour

• Configuration requise
• Étapes de l'installation

• Téléchargement et upload de phpMyVisites
• Phase d'installation web guidée
• Insertion du code Javascript sur les pages du site à auditer

• Mettre à jour depuis une ancienne version

• Fonctionnalités générales

• Nommer les pages
• Classer les pages par groupes
• Intérêts de visites par critères
• Exclusion des faibles populations
• Variables modulaire par page
• Affluent de type newsletter
• Affluent Site partenaire
• Archivage
• Statistiques par mail
• Statistiques par fil RSS
• Multi-Sites
• etc.

• Fonctionnalités des rapports de mesure d'audience

• Visites
• Pages vues
• Fréquence de visites
• Provenance
• Configuration
• Affluents
• Résumé multi-sites

• Administration

• Sécurité

• PHP
• MySQL

• Traductions

• Traductions disponibles (avec traducteurs)
• Ajouter une nouvelle traduction
• Corriger et compléter une traduction existante

• Support

• Documentation
• FAQ
• Forums
• BugTracker

• À propos

• Licence du logiciel
• Licence de la documentation
• Historique
• Équipe de développement

Documentation technique

• s'occuper de générer la doc du code via phpdoc (il faut un responsable pour ça)
• générer un schéma à jour du MCD
• décrire l'arborescence fichiers
• donner les standards respectés

• faire un appel générale à la communauté pour wikifier, pour corriger/ajouter des bouts de docs

Général

Fonctionnalités

• fort respect des standards (XHTML strict, CSS2)
• Garder la compatibilité avec le maximum de navigateurs en respectant les normes
• compatible php > 4.3 et compatible php 5 (je ne peux pas faire les tests personnellement qq1 devra s'en charger !)
• compatibilité avec la majorité des hébergeurs disponibles
• maintenir la forte internationalisation i18n
• respecter la séparation CONTENU / AFFICHAGE (Smarty & CSS)
• compatible 'register_globals' sur 'OFF' évidemment
• aucune erreur en mode 'error_reporting(E_ALL);'
• OS indépendant (unix, windows, mac) et Serveur indépendant (apache, IIS, etc.)
• il doit être possible d'inclure phpmyvisites dans une interface tierce, via un système simple et non contraignant.

Documentation du code

• PhpDocumentor : http://www.phpdoc.org/
• Liste des éléments reconnus par phpDocumentor http://manual.phpdoc.org/HTMLSmartyConverter/default/phpDocumentor/tutorial_elements.pkg.html
• Exemple dans PEAR http://pear.php.net/manual/en/standards.sample.php

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

La classe tbsOOo est une extension du moteur de template TinyButStrong.

Elle permet de générer dynamiquement des documents OpenOffice en séparant présentation et données.

En pratique, il suffit de concevoir un document avec OpenOffice qui servira de modèle (template). :Ensuite à partir du script PHP, il reste à fusionner ce modèle avec une source de données pour obtenir un nouveau document OpenOffice.

http://www.tinybutstrong.com/apps/tbsooo/doc_fr.html

Autres Q/A

• Comment sont gérées les préférences des utilisateurs en matière de templates ?

>> le choix du template peux être garder en session ou dans un cookie.

Après plus de réflexion, je pense que le template par défaut doit être dans le fichier de conf de phpMyVisites. Ensuite si on veut laisser le choix à l'utilisateur de changer de template, je préconise les cookies, les sessions sont gourmandes en ressource et les cookies permettent de garder le choix d'une session à l'autre. Marco

• Comment gérer proprement les erreurs génériques dans toute l'application ?

>> Une fonction que l'on accroche via set_error_handler() et qui crée une file de message d'erreur affichables dans les templates.

bonne idée ta fonction. Il faudra la développer. Comment vois tu la chose ? Matthieu Aubry 21 jul 2005 à 00:24 (UTC)

Architecture

Général

Base de données

Schéma de l'architecture de la base de données

Coding Standard

• Documentation phpMyVisites/CodingStandard

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 :

• par type d'accès (moteur, site, partenaire, newsletter, direct)
• par mot clé
• par moteur
• par site affluent
• par partenaire
• par newsletter
• par pays
• par continent
• par OS
• par navigateur
• par résolution
• par heure locale
• (par page d'entrée)

Indicateurs (informations) disponibles :

• pages vues par visite
• pages vues par visite significatives
• taux de visites à une page
• durée de visites
• fréquence de visites

Ex : combien de pages en moyenne ou de temps en moyenne restent les gens

• français
• américains

• qui viennent de Google
• de Yahoo

• ou qui ont tapé comme mot "toto"
• ou 'titi'

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>groupe2>mon_titre";
var pagename = "groupe1>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>groupe2>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...

possibilité que le > délimiteur soit un / facilement. On peut alors séparer les grands thèmes du site si le site est organisé par répertoire. POwerFULL !!

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 :

intranet

on peut faire des études en fonction de la valeur du paramètre

désignant le PrénomNom des membres

media

on peut étudier les différences de comportement en

fonction des visiteurs connectés (abonnés) ou anonymes

ATTENTION

ce qui suit sont des pures spéculations, les réflexions sur la faisabilité, le temps de développement et l'intégration n'ont pas été faites !

ecommerce on peut imaginer pouvoir faire des stats sur les ventes, CA

• nb de commandes
• panier moyen
• nb d'objets moyen par achat
• fréquence de commandes par visite
• délai (en temps et pages vues) avant la commande

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 :

• nom variable et valeur,
• nombre de visites sur cette page (« action ») avec cette valeur de variable

Ex :

• Magasin

• informatique

• plomberie

• consultation
• achat
• envoie à un ami

• charcuterie

• Contacts

Le lien consultation par exemple déplie un tableau avec le contenu suivant :

Etat visiteur	Visites
connecté	400 (40%)
anonyme	600 (60%)

On visionne pour une page donné des sous états, de manière simple et pratique.

On peut imaginer sur un intranet une variable PrenomNom :

Nom	Visites
Dupond_Jean-Marie	3 (n%)
Ernesto_Philippe	2 (n%)

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) :

• toutes les informations relatives aux visites et nombre de pages vues,
• les pays, continents,
• les configurations matérielles,
• les affluents (moyenne des types d'affluents et meilleurs moteurs).

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 :

• nom du site partenaire,
• URL du site partenaire,
• id valeur de la variable idsite_partner.

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 :

• nom newsletter.

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)

• à chaque étape

• nombre de hits
• arrivés (de quelles parties/pages/referers ?)
• sorties (vers quelles parties/pages/referers ?)

• sur la globalité

• personne qui ont fait le chemin en ENTIER du début à la fin

et oui attention, car même si à la dernière étape on a 500 personnes, ce n'est pas pour ça que les 500 personnes viennent de la première étape et ont suivi toutes les étapes dans l'ordre. Il est important d'avoir une vision globales des hits de chaque étape mais également des hits sur le chemin en entier.

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 :

• ajout nouvel utilisateur
• modification caractéristiques utilisateur
• (futur : suppression utilisateur)

Niveaux de droits prédéfinis (d'autres sont ajoutables mais ça ne semble pas naturel)

• Super admin : tous les droits sur tous les sites sans exception et sans modification possible ;
• Admin site N : droits de modification, de purge des données, etc.
• Consultant site N : droit de voir les stats, d'ajouter un cookie pour ne pas être pris en compte ;
• Visiteur : droit (ou pas) de consulter les stats.

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.

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 ?
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 :

• fréquence de visites sur la période,
• nombre de visiteurs uniques (chiffre exact... contrairement à actuellement),
• taux de retour des visiteurs sur la période (assiduité)
• % de nouveaux visiteurs / % visiteurs connus (graph : soit 2 barres verticales, soit une à 2 couleurs),
• pages vues par visite du visiteur fidèle,
• moyenne des pages vues du visiteur fidèle,
• nombre de visiteurs par nombre de visites sur la période.

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 :

• CSV

• XML

• XHTML Imprimable

• PDF

• OpenOffice

• Envoi de mail automatique (problème de l'archivage qui est nécessaire...)

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.
Problèmes

quand beaucoup de mots clés différents, de moteurs

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.
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

Syntaxe MediaWiki

• Syntaxe Wikipédia

Divers liens

• Optimiser php : http://developpeur.journaldunet.com/tutoriel/php/040330-php-nexen-optimiser1.shtml
• Bonnes pratiques pour la qualité des services en ligne http://opquast.com/ Il pourrait être très intéressant de respecter le plus de points possibles de ces listes complètes de « bonnes pratiques » : http://opquast.com/bonnes-pratiques/?niveau=3