Piwik : une alternative open source à Google Analytics

Posté par . Modéré par j.
1
17
avr.
2008
PHP
Piwik est une application libre de statistiques et de mesure d'audience de sites Internet développée en PHP/MySQL. Il s'agit en fait de la nouvelle version de phpMyVisites. Piwik se veut être une alternative solide Open source à Google Analytics et présente d'ores et déjà une bonne communauté de développeurs.

La démonstration présente sur le site web est très prometteuse. Même si ce n'est actuellement qu'une version beta, elle est tout à fait utilisable. Un des atouts de Piwik est une API très riche et facilement utilisable (possibilité d'exporter les données dans des formats divers, d'exporter des graphes etc.)
  • # Piwik semble prometteur

    Posté par . Évalué à 5.

    J'utilise phpMyVisites depuis longtemps, il est très bien et Piwik semble prometteur au niveau des nouveautés. Avoir une alternative à Google Analytics me semble d'autant plus important qu'il y a un petit coté "big brother" à cet outil (cf http://artisan.karma-lab.net/node/1202), même si l'on ignore ce que Google fait réellement des données collectées.

    Par contre, le site n'a pas l'air accessible en ce moment.
    • [^] # Re: Piwik semble prometteur

      Posté par (page perso) . Évalué à 4.

      le site est linuxfrisé ?
    • [^] # Re: Piwik semble prometteur

      Posté par . Évalué à 2.

      Oulà ça fait longtemps que je n'ai plus posté ici :)
      C'est joli Piwik.
      Un des gros problèmes de PhpMyVisites était le gonflement de la base de données avec le temps, est-ce que c'est résolu sous Piwik ?
      • [^] # Re: Piwik semble prometteur

        Posté par . Évalué à 1.

        Question pertinente, j'ai vu plusieurs fois PhpMyVisites faire s'écrouler des serveurs MySQL (pourtant pas avec un gros trafic), et depuis j'ai tendance à l'éviter.

        Si il y a eu quelques modifications à ce sujet en plus de la (superbe) nouvelle interface, je ne les trouve pas sur le site, et je suis preneur de l'information.
        • [^] # Re: Piwik semble prometteur

          Posté par . Évalué à 4.

          Piwik n'a pas encore ete soumis a des tests de charge pour des sites a moyen/fort traffic. Le logiciel fonctionne tres bien sur des sites a traffic modere (<2000 visites jour).

          Concernant la taille de la DB, l'architecture rend possible le developpement d'un plugin pour supprimer des anciens enregistrements afin de purger les donnees non utilisees. Il reste a implementer :)
  • # Piwik

    Posté par (page perso) . Évalué à 3.

    Il existe un module Drupal pour bien intégrer piwik ?
    • [^] # Re: Piwik

      Posté par (page perso) . Évalué à 1.

      A mon avis en se basant sur le module de google analytics, tu dois pouvoir en faire un avec peu de travail :)
      • [^] # Re: Piwik

        Posté par (page perso) . Évalué à 2.

        Ca tombe bien c'est mon boulot :)
        • [^] # Re: Piwik

          Posté par (page perso) . Évalué à 0.

          Par contre n'oublie pas de respecter la licence :)
          • [^] # Re: Piwik

            Posté par (page perso) . Évalué à 1.

            C'est le plus dur, coder avec Drupal c'est un bonheur, mais avoir du feedback c'est la mort...

            Et pourtant c'est pas faute de leur poster des patchs

            (rien à voir avec la licence en fait)
          • [^] # Re: Piwik

            Posté par . Évalué à 1.

            «Par contre n'oublie pas de respecter la licence»

            ?? bah elle a quoi leur licence ? C'est du GPL tout à fait classique, non ?
  • # Plastistik

    Posté par (page perso) . Évalué à 6.

    J'ai commencé à bosser sur une alternative à BBCode/PhpMyVisites (que j'aime bien mais bon en production requêter du mySQL en live à chaque hit c'est suicidaire, mais cool le nouveau nom :) ), qui s'appelle Plastistik.

    Le but est d'avoir un système qui permette de très nombreuses requêtes simultanées, mais en gardant un set de données exhaustif et complet. Pour ça le principe est simple : le compteur requête un script très léger qui va stocker les données brutes du visiteur dans un fichier texte (c'est très rapide donc même avec beaucoup de requêtes concurrentes on perds peu de données, mais on en perds un peu à cause des écritures concurrentes sur un même fichier, mais ça pourrait être amélioré en utilisant plusieurs fichiers différents), et un daemon ou un cron (selon le volume de stats que vous engrangez ou vous préférences) parse le fichier texte, interprète les données, et les insère correctement dans la base mySQL.

    L'idée de base c'est que je voulais avoir des stats pour mes sites mais :
    * webalyzer/awstats ça pue c'est moche c'est lent
    * google machin/estat truc je veux pas qu'ils sachent des infos sur mes visiteurs, sans compter qu'ils pourraient foutre de la pub dans leurs marqueurs
    * Phpmyvisites est pas adapté aux sites en production et mettra rapidement un serveur à genoux

    Il me fallait donc un truc simple, léger, et qui sois puissant au niveau des possibilités de rapports perso. Pour la légèreté j'ai aussi pris en compte le temps de chargement du script et il est donc possible de recopier sans aucun problème le javascript du marqueur dans votre propre site voir au milieu du code html pour éviter de charger un élément externe.

    Le code est ici :
    http://svn.kd2.org/svn/misc/apps/plastistik/

    Pour le moment seul le stockage des stats est fonctionnel, l'affichage je réfléchis encore à un système simple de créer des rapports personnalisé (plugins ? requêtes sql ?[1]). On stocke les données suivantes pour le moment :

    Pour chaque visiteur :
    * ip/hostname (ipv6 ready)
    * pays
    * navigateur, version, moteur de rendu (webkit/gecko/opera/trident/etc.)
    * OS
    * résolution écran
    * heure de début de la visite
    * heure de fin de la visite
    * Langues acceptées par le navigateur
    * Plugins acceptés par navigateur

    Pour chaque hit :
    * page visitée
    * referrer
    * temps de chargement de la page (facultatif)
    * heure du hit

    Voilà je pense c'est déjà bien comme données ça doit permettre pas mal de rapports sympas. On peux gérer plusieurs sites en mm temps et créer des marqueurs (tags) si on veux.

    Si ça intéresse des gens, pour participer, critiquer, ou repiquer des idées, hésitez pas !

    [1] l'idée c'est que les gens puissent créer leurs propres rapports comme ils le sentent et moi comme ça j'ai juste à en faire 2-3 bateaux et les autres les gens intéressés les feront :)

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Plastistik

      Posté par . Évalué à 1.

      Je dis peut-être une ânerie, mais stocker les données selon le schéma de phpMyVisites permettrait de réutiliser leur interface, non?
      • [^] # Re: Plastistik

        Posté par (page perso) . Évalué à 1.

        C'est pas une ânerie :) J'y avais pas pensé mais je viens de regarder leur structure de table et je pense que leur schéma doit occasionner plus d'espace occupé que celui que j'ai choisi (le mien est sûrement encore améliorable mais il doit déjà limiter le stockage pas mal), mais ça aurait été une bonne idée si leur schéma était un peu mieux foutu.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Plastistik

          Posté par (page perso) . Évalué à 4.

          et les logs apache ?
          - ça éviterait du doublon de stockage ?
          - ça a un format standard et utilisable ?

          cela permet tout de même de découpler correctement la génération de données (efficacement en plus) / exploitation de ces données, non ?
          • [^] # Re: Plastistik

            Posté par (page perso) . Évalué à -1.

            Alors alors les logs apache c'est cool mais t'y a pas accès en mutualisé, et c'est pas du tout un format standard ou utilisable, en fonction des versions d'apache le format est différent et chaque personne peut changer le format à sa guise... Sans compter le petit problème qui est que les logs c'est MAL en production, ça tue tes serveurs. De plus ça stocke pas des informations très utiles pour certains comme : temps de chargement d'une page par le navigateur, résolution de l'écran, plugins installés, etc..

            Sinon si tu veux juste utiliser les logs apache le petit soft qui s'appelle Visitors fait ça très bien. Mais là le but c'est pas ça, avoir un outil de stats indépendant permet des trucs bien plus intéressants (rien que par exemple avoir une archi distribuée sur plusieurs serveurs à la conf hétérogène) et apporte moins de contraintes.

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: Plastistik

              Posté par (page perso) . Évalué à 3.

              Sans compter le petit problème qui est que les logs c'est MAL en production, ça tue tes serveurs.
              bin Piwik remplace l'activation des logs par des insertions en base MySQL, le même principe s'applique pour tuer un serveur non ? (en plus efficace)

              avoir un outil de stats indépendant
              Je ne vois pas ce qui empêche, d'avoir les logs apache au bon format et de demander aux gentils admins d'y pourvoir lorsque c'est possible.
              En revanche, je vois très bien la charge ajoutée si,à chaque requête, des traitements applicatifs sont effectués. Comme contrainte sur le serveur, c'est un peu se tirer une balle dans le pied quand le site se fait /.er ou linuxfriser.
              • [^] # Re: Plastistik

                Posté par (page perso) . Évalué à 2.

                Mettre le service de stats sur la même machine que le site web c'est un peu une mauvaise idée :) Ca revient effectivement au même qu'activer les logs apache, et c'est pas une bonne idée. Les stats si ça marche pas c'est pas super grave, ça doit pas tuer ton service web pour autant, pour ça il faut séparer. Enfin ça part de la base que ton service web ne saturera pas avant le service de stats, ce qui n'est pas sûr du tout dans beaucoup de cas :)

                « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: Plastistik

              Posté par (page perso) . Évalué à 6.

              Sans compter le petit problème qui est que les logs c'est MAL en production, ça tue tes serveurs.
              Et si ton serveur se fait tuer, sans les logs, tu fais comment pour connaitre le coupable ?
              • [^] # Re: Plastistik

                Posté par . Évalué à 1.

                Normalement, tu peux demander à syslog de transférer les logs à un autre serveur, non? Et tu dois pouvoir demander à Apache de logguer dans syslog. Et la boucle est bouclée. 'fin je crois.
                • [^] # Re: Plastistik

                  Posté par (page perso) . Évalué à 2.

                  Apache ne peut pas utiliser syslog pour les acces. Seulement pour les erreurs.

                  L'autre jour j'ai utilisé un wrapper perl pour faire ça et j'ai bien vautré tout un cluster :)
                  http://www.oreillynet.com/pub/a/sysadmin/2006/10/12/httpd-sy(...)

                  Avoir des access log est une obligation. Donc autant les utiliser pour faire des stats.

                  Mes deux cents.
                  • [^] # Re: Plastistik

                    Posté par (page perso) . Évalué à 2.

                    Obligation ? Tu peux très bien les désactiver ça ne pose aucun problème, je comprends pas ce que tu veux dire là...

                    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                    • [^] # Re: Plastistik

                      Posté par (page perso) . Évalué à 3.

                      Il veut dire que lorsque au bout de 2 ans de services rendus, un serveur commence à déconner. Lorsque ton patron te demandera d'ou vient le problème tu lui répondra quoi ?
                      - Oh bah je sais pas.

                      Avoir des logs du serveur et les logs des acces est utile dans la mesure ou ça te permet d'identifier d'éventuels problèmes, au niveau du serveur, au niveau des accès de voir s'il y a des gens qui essayent de faire des DoS, tentent d'accèder à des endroits sur ton serveurs, font du crawling pour trouver des répertoires cachés (non indexés), requêtes mal forgées, que sais-je encore.
                      • [^] # Re: Plastistik

                        Posté par (page perso) . Évalué à 3.

                        La loi t'oblige à conserver les logs d'acces un certain temps (1 ans) lorsque tu héberges des sites web en France.

                        http://www.ahinc.eu/files/CNIL_-_R_tention_des_donn_es_de_co(...)

                        Ensuite ne pas avoir de logs d'acces, c'est un peu comme ne pas traiter le cas d'une division par zéro. On peut toujours se dire que ça n'arrivera jamais.
                        • [^] # Re: Plastistik

                          Posté par (page perso) . Évalué à 1.

                          Si tu te dis que conserver les access log d'apache suffit pour obéir à cette loi (dont je me fout totalement puisque j'habite pas en france) je te souhaite bon courage pour répondre à la requête "on voudrais l'ip et les infos du mec qui posté le billet machin disponible sur le blog http..." sur une plateforme ou tu gère des centaines (ou plus) de blogs... Ces infos doivent être stockées par l'application web elle-même, les requêtes judiciaires concernent les auteurs d'éléments publiés, pas les visiteurs (ou alors j'ai jamais vu le cas et je vois pas en quoi ça serait justifié). Si tu regarde du côté de la plupart des plateformes de publication qui ont une taille relativement importante, aucune ne stocke ni ne conserve les access logs (et pour cause, ça coûterait très cher).

                          Les logs d'accès ça peut se révéler utile sur une petite plateforme, des petits trucs, mais sinon y'a plein de raisons pour ne pas en avoir (surcharge machine, coûts de stockage, vie privée de tes visiteurs, utilité toute relative, etc.).

                          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                          • [^] # Re: Plastistik

                            Posté par (page perso) . Évalué à 2.

                            Je travaille sur des des machines à plusieurs millions de requêtes par jours qui font des access log.

                            On s'en sert pour débusquer les scripts plantés et toute sorte d'attaques (upload de script malicieux, utilisation de formulaires pour spammer) ...

                            Quand tu ne maîtrise pas le code des sites que tu héberge, il n'y a guère d'autres solutions qu'une analyse rigoureuse des access_log, maillog et ton ami netstat.

                            Par ailleurs, j'ai déjà eu a répondre a des requêtes judiciaires. Un gros grep leur suffit. Ils ont des gens capables d'analyser ça.

                            >> bzgrep -i viagra access_server.Tuesday.bz2 | wc -l
                            31
                  • [^] # Re: Plastistik

                    Posté par . Évalué à 1.

                    Voila la config que j'ai dans httpd.conf:

                    CustomLog "|/usr/bin/logger -p local1.info" debug

                    debug étant un format particulier de log. Et syslog redirige vers une autre machine.

                    Et aucun souci pour logger plus que quelques millions de hits par jour.
                    • [^] # Re: Plastistik

                      Posté par (page perso) . Évalué à 2.

                      J'avais franchement été refroidis par le wrapper en perl que je cite plus haut.

                      Je vais essayer ça.
    • [^] # Re: Plastistik

      Posté par . Évalué à 3.

      Question peut-être stupide (je ne connais pas la politique de développement du projet), mais pourquoi tu n'as pas fait tout ça dans le cadre du projet phpMyVisites au lieu de créer un nouveau projet?

      Parce que maintenant on a 2 projets: Piwik et Plastistik, et quelque chose me dit que les 2 ont plutôt vu des évolutions complémentaires qu'incompatibles, non?

      Un rapprochement des deux te paraît-il plausible?
      (ça éviterait de choisir entre "bien" et "bien aussi"...)
      • [^] # Re: Plastistik

        Posté par (page perso) . Évalué à 2.

        Oh c'est juste que j'avais besoin d'un truc efficace dispo rapidement, et surtout fallait tester en vrai l'idée du fichier "tampon" pour voir si c'était réaliste (pas trop de perte de données, rapidité, efficacité).

        C'est pas un vrai projet suivi comme peut l'être phpMyVisites, juste un petit truc comme ça, plus utile pour ses idées et concepts que son implémentation.

        Mais effectivement ça serait bien que ça puisse servir à Piwik/phpMV si ça les intéresse tout du moins :)

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Ça c'est cool

    Posté par (page perso) . Évalué à 10.

    Des graphiques en Flash !! Trop bien ! Ça m'évite de l'essayer...
    • [^] # Re: Ça c'est cool

      Posté par . Évalué à 1.

      C'est vrai qu'il y en a un peu trop... et toutes ces animations de camembert ou diagramme qui scintillent, ca fait un peu trop playskool.
      • [^] # Re: Ça c'est cool

        Posté par (page perso) . Évalué à 3.

        En fait il faut saluer l'énorme effort fait par l'équipe de piwik pour rendre leur logiciel "Manager Compatibeul" :)
    • [^] # Re: Ça c'est cool

      Posté par (page perso) . Évalué à 5.

      Ca reste du flash entièrement généré avec des outils open source et utilisant les spécifications qui ont été pondues par adobe. Donc tout à fait lisible par gnash...
  • # Quid de piwik jobs

    Posté par (page perso) . Évalué à 1.

    Piwik propose des jobs ? (http://piwik.org/blog/2008/04/piwik-jobs/)

    Quelqu'un a des infos ? Combien de places ? Combien de temps ? Combien d'argent ? Etc ?
  • # Statistiques sur de longues durées

    Posté par (page perso) . Évalué à 1.

    Un des trucs que je reproche à phpmyvisites, c'est que sur mon hébergement mutualisé, impossible d'obtenir des stats sur une durée supérieure à une journée

    Sur une journée, ça passe, sur une semaine, memory ou time limit. Et je vous dis pas pour une durée d'un mois.

    (Pour les sceptiques, je vous met le lien vers les stats de mon site qui sont en accès public : http://visites.palsambleu.fr/)

    Pour piwik, le problème semble persister, puisque tout déraille quand je sélectionne une période d'une semaine sur le site de démo :

    http://piwik.org/demo/index.php?module=Home&action=index(...)

    Suis-je le seul à avoir ce problème ?

    (Sinon, c'est le seul truc que je reproche à phpmv. J'adore ce programme)
  • # Comparaison Google Analytics

    Posté par . Évalué à 2.

    Oui alors google c'est le mal je sais ...
    Mais comparer ton scipt php tueur de serveur ;) a google analytics c'est pas connaitre google analytics. A moins qu'il y est des plugins mais la demo est vraiment pauvre niveau fonctionnalités ...

    Et mis à part le flash kicool lol je vois pas qu'elle est la valeur ajouté face à Awstats qui utilise les log d'apache.

    Enfin bon je dis ça je dis rien hein ... :oD
    • [^] # Re: Comparaison Google Analytics

      Posté par (page perso) . Évalué à 6.

      Bien d'accord.
      Entre faire des requetes SQL qui défoncent les perfs à chaque hit et réutiliser les capacités de logs d'une architecture multithreadé dont la puissance a fait ses preuves, ya pas photos....

      Après, rien n'empeche celui qui veut s'amuser d'enrichir les logs, de les insérer dans une base de données et de faire ses corrélations la dessus, mais pas sur un serveur de prod qui se prend 40mbps de traffic dans la tronche.
    • [^] # Re: Comparaison Google Analytics

      Posté par (page perso) . Évalué à 2.

      Une des valeur ajoutée concerne les données générées par piwik/phpmyvisites qui sont plus complètes que les logs Apache.
      Ceci vient du faite que piwik utilise la méthode du tracker javascript (comme GA), ceci permet entre autre d'enregistrer des données comme la résolution des écrans (ou toute autre données décrivant le client que l'on peut récupérer en JS) qu'il est impossible de faire figurer dans les logs Apache.

      Par ailleurs, tout comme google analytics le fait, rien ne vous empêche de dédier un serveur pour la gestion des stats. Votre serveur de prod est alors libéré, et votre porte monnaie plus léger ;-)
      • [^] # Re: Comparaison Google Analytics

        Posté par . Évalué à 2.

        Une des valeur ajoutée concerne les données générées par piwik/phpmyvisites qui sont plus complètes que les logs Apache.
        Ceci vient du faite que piwik utilise la méthode du tracker javascript (comme GA), ceci permet entre autre d'enregistrer des données comme la résolution des écrans (ou toute autre données décrivant le client que l'on peut récupérer en JS) qu'il est impossible de faire figurer dans les logs Apache.


        awstats permet :
        - de faire figurer ces informations dans les logs Apache
        - d'effectuer des statistiques sur celles-ci

        Voir : http://awstats.sourceforge.net/docs/awstats_faq.html#SCREENS(...)
    • [^] # Re: Comparaison Google Analytics

      Posté par . Évalué à 2.

      Les interets sont - entre autres -:
      - vous controlez vos donnees et ne les cedez pas a google ou microsoft ou yahoo ou autre
      - l'architecture a plugins permet d'ajouter les fonctionnalites souhaitees
      - la presence d'apis completes et simple d'utilisation est unique et permet de reutiliser tres facilement les donnees calculees par piwik
      - interface customizable, possibilite d'exporter les graphiques flash dans votre site/blog, etc..

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.