Suivre des clics à l’aide de Google Analytics

Standard

Google Analytics
Google Analytics est un puissant outil d’analyse des visites sur un site web. Si vous ne l’utilisez pas encore, je vous le recommande vivement : les données fournies par Google Analytics vous seront extrêmement utiles.

Dans quel cas utiliser des événements ?

Une fonctionnalité avancée de Google Analytics qui est très intéressante à utiliser est celle de la gestion des événements. Je ne suis néanmoins pas encore un expert avec cette fonctionnalité, c’est pourquoi je vous présenterai seulement la gestion des événements provenant d’un clic d’un utilisateur. Imaginons : vous avez un site avec une page d’inscription. Vous avez un lien vers cette page dans votre menu, un autre dans un article de votre blog et un dernier dans votre footer. Quel lien est le plus cliqué ? Si vous faites un changement de design dans votre footer, le lien dans le footer sera-t-il cliqué plus souvent ?

La gestion des événements proposé par Google Analytics va vous permettre d’avoir des réponses à ces questions.

La fonction _trackEvent()

Pour la suite, vous devez utiliser Google Analytics et avoir le code de Google Analytics présent sur toutes les pages de votre site. Nous allons utiliser la fonctionnalité _trackEvent pour pouvoir suivre les événements (ici les clics) sur votre site.
La fonctionnalité _trackEvent prend les arguments suivants :

Voici une description de chacun des paramètres :

  • category : string. La catégorie générale de votre événement (par exemple “Page d’inscription”).
  • action : string. L’action pour cet événement (par exemple “Clic”).
  • opt_label : string. La description de cet événement (par exemple “Lien footer”).
  • opt_value : int. Dans notre cas, on n’utilisera pas ce paramètre. On l’utilise dans des cas bien précis, quand on a besoin d’une valeur numérique associée à un événement. Par exemple, dans le cas d’une vidéo, la durée de la lecture jusqu’à ce que l’utilisateur clique sur “Pause” par exemple.
  • opt_noninteraction : boolean. La valeur par défaut est false. Si la valeur est à true, le fait de déclencher cet événement ne sera pas compté comme une interaction. Si vous laissez à false, le déclenchement de cet événement sera bien compté comme une action, et votre utilisateur ne sera donc pas compté dans le taux de rebond (bounce rate).

Mise en place

Maintenant que vous savez comment utiliser la fonction _trackEvent, il faut l’implémenter dans votre code. Voici par exemple ce qu’il faudra écrire dans votre code si je reprends l’exemple initial avec des liens vers une page d’inscription placés à différents endroits.

Vous voyez que peu de choses varient. En effet, la catégorie doit rester la même pour comprendre de quel événement je peux parler, l’action est la même (toujours un clic), seul le label varie selon la localisation du lien. Dans cet exemple, pas besoin d’opt_value et je ne me suis pas soucié de mon taux de rebond sur ces pages.

Où retrouver ces statistiques ?

Une fois votre code mis à jour, vous pouvez retrouver les statistiques de vos événements dans l’onglet “Contenu” puis dans “Événements”. Cliquez ensuite sur le nom de la catégorie de votre événement, puis sur “Libellé d’événement” pour voir la répartition des événements au sein de votre catégorie.

Voici un exemple de résultat qui provient de Teen Quotes :
Google Analytics

Vous voilà en possession de statistiques intéressantes. À vous maintenant de les exploiter au mieux !

Pour aller plus loin, l’aide Google à propos de l’event tracking (en anglais) : dev.google.com/analytics/devguides/collection/gajs/methods/gaJSApiEventTracking.

Conserver les sessions dans les sous-domaines en PHP

Standard

Par défaut, PHP utilise le cookie PHPSESSID pour propager les sessions à travers les différentes pages d’un site. Par défaut, PHP utilise le domaine et le sous-domaine courant pour déclarer ce cookie.

Par exemple, si je me connecte sur www.monsupersite.com, mon cookie PHPSESSID sera déclaré pour la localisation www.monsupersite.com. Les données contenues dans la session ne pourront pas voyager avec le visiteur pour un autre domaine ou sous-domaine. Ceci veut dire que mes données $_SESSION ne seront malheureusement pas accessibles sur forum.monsupersite.com par exemple !

Pour rendre les données de la session accessibles sur tous les sous-domaines de votre domaine principal, il va falloir rajouter une ligne au tout début de tous vos fichiers où une session est susceptible d’être créée. Le plus sage étant encore de l’inclure sur toutes vos pages, immédiatement après l’ouverture de la balise PHP. Il suffit de rajouter ceci :

Ceci aura pour effet de supprimer le sous-domaine. Par exemple forum.monsupersite.com devient .monsupersite.com. Ainsi, toutes les données de la session seront accessibles sur tous les sous-domaines de monsupersite.com !

Les problèmes rencontrés avec Amavis

Standard

Au cours des derniers mois, j’ai rencontré plusieurs problèmes sur mes différentes machines qui ont été causés par Amavis et qui ont été difficile à réparer pour. Dans cet article, je vais vous détailler les problèmes que j’ai rencontré et les solutions que j’ai trouvé pour y venir à bout, en espérant que ceci vous soit utile !

Amavis, c’est quoi ?

Amavis est un filtre pour les emails. Il est open source et est écrit en Perl. Il est souvent associé à Postfix pour l’envoi d’emails qui est très utilisé dans les systèmes UNIX. Amavis peut être utilisé pour :

  • détecter les virus, spam et les erreurs de syntaxe ;
  • bloquer, rediriger ou transférer des emails ;
  • mettre en quarantaine ou archiver des emails ;
  • bien d’autres choses que je ne connais pas…

Amavis et les inodes

Par défaut, Amavis stocke les emails qu’il a détecté comme virus ou spams dans un dossier spécifique. Sous Debian, celui-ci se trouve à /var/lib/amavis/virusmails. Le problème est qu’Amavis ne vide jamais ce répertoire… Ceci peut être très problématique car au fil du temps le dossier se remplit encore et encore et il peut parfois saturer votre quota d’inodes sur votre serveur. En effet, si vous envoyez quelques milliers d’emails par jour depuis votre serveur, il est probable que vous ailliez ce problème un jour ou l’autre. Dans mon cas, le dossier utilisé par Amavis /var/lib/amavis/virusmails comptait plus de 50 000 inodes ! Un problème qui peut complètement saturer votre /var sans que vous compreniez d’où vient le soucis.

Le problème avait été reporté, et malheureusement l’équipe d’Amavis ne veut pas mettre en place une suppression automatique tous les 15 / 30 jours de ce dossier. Personnellement, je ne comprends pas cette logique. Connaissez-vous un administrateur système qui souhaite garder une trace de tout ce qui a été considéré comme “spam” pendant plusieurs années ? Vous pouvez trouver cette discussion à l’adresse suivante : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569150.

Quoi qu’il en soit, si vous voulez éviter d’avoir ce problème, il va falloir agir. La solution proposée par Thomas Goirand sur Debian me parait être une excellente solution. Il suffit de mettre en place une tâche cron tous les X jours exécutant la commande suivante :
L’autre solution, moins classe, consiste à supprimer le répertoire /var/lib/amavis/virusmailsquand votre nombre d’inodes commence à vraiment augmenter. Vous devrez ensuite exécuter les commandes suivantes :

Bonus, si vous voulez savoir combien d’inodes vous avez dans des sous-répertoires, il vous faut taper la commande suivante :
Ceci risque de prendre un certain temps si vous faites ceci dans un répertoire comptant une longue arborescence !

Quels symptômes pour un problème avec Amavis ?

Les problèmes que vous pouvez rencontrer à cause d’Amavis peuvent avoir des conséquences importantes mais sont parfois difficiles à identifier. Si vous rencontrez les problèmes suivants, il faudra regarder du côté d’Amavis :

  • Aucun email n’est envoyé depuis votre serveur. Les emails s’entassent dans la mail queue.
  • Votre nombre d’inodes est très important alors que votre disque comporte encore beaucoup d’espace.

Dans le premier cas, regardez d’abord au niveau de vos logs de mail si vous pouvez obtenir des informations complémentaires. Si le problème vient d’Amavis, pensez à le désactiver (voir étape suivante). Avant de prendre des décisions radicales, vous pouvez rajouter les emails en attente dans la mail queue et demander à Postfix de les envoyer en tapant les commandes suivantes :

Pour le second soucis, vous pouvez déterminer immédiatement si Amavis est responsable de cette augmentation du nombre de vos inodes. Rendez-vous dans le dossier /var/lib/amavis/ et exécutez la commande indiquée précédemment permettant de voir combien d’inodes comptent vos sous-répertoires.

Désactiver Amavis

Vous aurez beau vous acharnez, parfois il faut mieux désactiver Amavis pour être tranquille. Si vous voulez faire ceci, voici les étapes qu’il vous faudra suivre.

Tout d’abord, il va falloir vous rendre dans le fichier de configuration de Postfix se trouvant dans /etc/postfix/ et se nommant main.cf en commentant une ligne ressemblant à la suivante. Pour ma part, elle indique à Postfix d’envoyer les emails sur localhost en utilisant le port 10024.

Vous pouvez également faire référence à Amavis dans le même dossier, mais dans le fichier master.cf. Il faudra commenter les lignes suivantes :

Parfait ! Il ne reste maintenant plus qu’à recharger les fichiers de configuration de Postfix, rajouter les emails dans la mail queue et tenter de les envoyer à nouveau. Ceci se fait avec les commandes suivantes :

Dernière étape, ne plus démarrer Amavis automatiquement au démarrage. Ceci se fait avec la commande :

Vous voilà débarrassé d’Amavis !

Mon tout premier Hackathon

Standard

Hackhours
Le week-end dernier, j’ai participé à la première version du Hack Hours, un Hackathon organisé par l’Exia.CESI avec mes collègues et amis de Quantic Télécom (Thibaud Dauce, Josselin Lecocq et Merlin Nimier-David). Pour ceux qui ne connaissent pas, le but d’un Hackathon est de produire en un court laps de temps un projet informatique avec une petite équipe. Le week-end dernier, nous avions donc 28 heures pour monter un projet autour du mobile (application web ou native).

Un Hackathon, c’est bien.

Si vous n’avez pas encore participé à un Hackathon, je vous y invite vraiment ! Voici quelques raisons qui pourraient vous inciter à franchir le pas :

  • C’est fou. Coder pendant une longue période, avec très peu de pauses avec des amis, c’est vraiment marrant.
  • Vous passerez un bon moment. Généralement, l’ambiance dans ces événements est excellente. À noter que le plus souvent ces événements sont gratuits et que les organisateurs font tout pour vous faciliter la vie : boissons, repas, connexion Internet et parfois matériels sont fourni aux participants !
  • Vous apprendrez énormément. Il est très probable que vous allez avoir à réaliser des choses que vous n’avez jamais faites auparavant, que vos collègues connaissent ou que vous allez découvrir pour les besoins de votre projet.
  • Vous aurez de nouvelles idées. Grâce aux autres groupes, vous découvrirez de nouvelles tendances, de nouvelles façons d’aborder des problèmes. En clair, que du bonus pour votre créativité !
  • Vous rencontrerez des gens. Des développeurs, des designers, des businessmen, des chefs d’entreprise, des étudiants… Chacun vous apportera quelque chose. Une occasion en or pour échanger et faire de nouvelles rencontres !

Comment réussir un Hackathon

Je vais développer dans cette partie les méthodes que nous avons appliqué et qui nous ont semblé être efficaces. Bien évidemment, ceci n’est absolument pas complet et n’est en rien une vérité générale. Toutefois, j’espère que ceci vous sera utile si vous participez à un Hackathon.

  • Restez simple. Lors de la recherche de votre projet, gardez toujours en tête que vous devez trouver une idée simple. Vous n’allez pas pouvoir développer en quelques heures un géant de demain. Demandez-vous ce qui vous manque au quotidien, ce dont vous avez besoin, ce qui est dans les tendances actuelles. Votre projet ne doit pouvoir faire que quelques tâches, mais il doit les faire bien. Et surtout, il doit les faire avant la fin du Hackathon !
  • La conception fait tout. Vous ne devez pas négliger la conception de votre projet. Inutile de foncer tête baissée sur votre ordinateur, à taper frénétiquement les premières lignes de code. Réunissez-vous. Réfléchissez. Écrivez sur un tableau ou sur des feuilles de papier vos idées, la structure de votre code, vos fonctions, décrivez votre interface. Ceci sera votre document de référence, votre objectif sera de coder les fonctionnalités que vous avez identifiées comme importantes pour votre projet. Une fois ceci fait, répartissez-vous les tâches en fonction des compétences au sein de votre équipe.
  • Ne négligez pas la présentation de votre projet. Il est fort probable qu’au terme du temps imparti pour le développement vous devrez présenter votre projet. Ne négligez surtout pas cet aspect ! Vous devez mettre en valeur votre projet, montrer qu’il fonctionne. Ne vous attardez pas sur les détails techniques, parlez plutôt de votre concept, pourquoi ce projet est utile et pourquoi il va plaire. Entraînez-vous avec le reste de votre équipe à cette présentation : définissez ce que vous allez dire, prévoyez une démonstration de votre projet. Priez pour que votre projet ne plante pas pendant la présentation !

Conclusion

Quoi qu’il arrive, si vous avez bien travaillé avec votre équipe, vous vous serez amusé, vous aurez appris, vous serez fiers de votre projet. Ceci aura été bénéfique pour vous ! Vous avez donc tout gagné !

P.S. : nous avons gagné ce Hackathon 😀