on vous a tous ou presque parlé de l’arrivée de Google Universal Analytics.
C’est parti pour:
- révolutionner la mesure avec un protocole unifié,
- vous donner une meilleure vue du parcours client via des plateformes multiples,
- vous permettre d’utiliser des variables et des compteurs personnalisés,
- traquer le offline (ce qui n’est pas exactement vrai mais c’est un sujet pour une autre fois)
Je vous livre ici une technique / preuve de concept qui vous permettra de mesurer à la volée comment vos fichiers PDF sont téléchargés avec Universal Analytics. Sans Javacript.
Attention, non-techniciens et autres Kevins qui lisez la suite, faites le à vos risques et périls 🙂
Universal Analytics, c’est bon – mangez-en!
Tout d’abord, si vous vous êtes penché(e) sur la question, vous aurez remarqué que le nouveau système de mesure de Universal Analytics ne fait plus appel directement au fameux pixel _utm.gif.
Le nouveau « pixel » de Universal Analytics est maintenant ce qu’il convient d’appeler un « endpoint » dans le monde des APIs et autres passerelles logicielles.
Dans le cas de Universal Analytics, notre endpoint est désormais:
http://www.google-analytics.com/collect
Existe également en https évidemment 🙂
On va y accoller différents paramètres qui contiendront entre autres:
- un type d’appel GA: page vue, event, transaction, item, social, timing – pour commencer
- votre numéro de profil GA
- un identifiant anonyme de visiteur unique
- d’autres paramètres venant qualifier le type d’appel
- des dimensions et des métriques personnalisées.
Pas d’informations de cookie et d’horodatage? C’est normal, ce genre de chose est désormais géré côté serveur par Universal Analytics!
Le problème
Mais revenons à notre exemple. Le problème inhérent au tracking de téléchargement de fichiers sur le Web c’est qu’on a aucun moyen de savoir si le téléchargement a abouti ou pas.
J’ai eu dans le temps assisté un éditeur de distribution Linux maintenant défunte. Cette distribution Linux, comme toute bonne distrib’, était téléchargeable au format ISO DVD, soit un bon petit 4,7 Go de téléchargement. De quoi à l’époque télécharger toute la nuit!
Le problème c’est que nous n’avions aucune visibilité sur le taux réel de téléchargement. En effet, même en taggant les liens avec Google Analytics ou autres et en mesurant une page vue virtuelle ou un événement, on arrivait péniblement à un taux de clic qu’on a fini par baptiser indicateur d’intention de téléchargement.
Pourquoi? Parce qu’à moins de regarder les logs serveurs, on n’avait aucun moyen de savoir si un téléchargement avait été accompli à 100% ou si l’internaute avait laché l’affaire en cours de téléchargement ou subi une coupure réseau, etc.
Aujourd’hui la taille des tuyaux de l’Interweb a augmenté donc on se pose moins la question, surtout pour des fichiers de tailles petite et moyenne. Pour les gros fichiers comme l’image ISO de mon exemple, il faut maintenant en moyenne 2 heures pour la télécharger au lieu de 12 😉
Mais le problème n’est pas réglé pour autant: on reste bloqué au niveau de l’intention de clic.
Une solution
Ce que je vous propose c’est de remplacer votre marquage de vos liens PDF par un tracking Universal qui alimentera votre compte Google Analytics sans Javascript.
Commençons par le début: localisons notre log de serveur Web
Dans tout bon serveur Web qui se respecte, votre log Apache se trouve probablement dans /var/log/apache2
Si vous utilisez la rotation quotidienne ou hebdo de logs, tant mieux mais nous allons nous concentrer sur le log en cours, qui s’appelle généralement access_log.
Dans ce log, vos appels aux fichiers PDF prendront très vraisemblablement la forme suivante:
127.0.0.1 – – [04/Apr/2013:21:05:24 +0200] « GET /test.pdf HTTP/1.1 » 200 72839
Concentrons-nous sur la queue (la traîne?) de cette ligne. Elle contient mon fichier ‘test.pdf’, qui a été servi sans erreur (code HTTP 200) et 72Ko de fichier ont été servis.
Avec un peu d’injection de log ou de configuration Apache, vous pouvez aussi insérer la taille réelle du fichier.
Exemple:
127.0.0.1 – – [04/Apr/2013:21:05:24 +0200] « GET /test.pdf HTTP/1.1 » 200 72839
deviendrait
127.0.0.1 – – [04/Apr/2013:21:05:24 +0200] « GET /test.pdf HTTP/1.1 » 200 47816 72839
où 47816 est la taille de fichier servie (que l’internaute a reçu) et 72839 est la taille de référence (celle que l’internaute aurait du recevoir)
Dans ce dernier cas de figure, on fait face à un téléchargement incomplet.
Créons maintenant un petit script shell qui va parcourir votre fichier log à la recherche des dernières mentions de mes fichier PDF.
Pour cet exemple, je définis une expression régulière relativement simple:
[code]GET /(.*\.pdf)[/code]
L’expression entre parenthèses indique que je vais récupérer cette valeur et m’en servir par la suite, notamment pour construire l’URL de mon endpoint.
L’URL finie ressemble à çà:
[code]http://www.google-analytics.com/collect
?v=1 // version de mon site/appli
&t=event // type d’appel GA
&tid=UA-7634164-5 // mon ID de profil GA
&cid=555 // mon numéro anonyme de visiteur
&dh=juliencoquet.com // mon nom d’hôte
&ec=Downloads // Evenement – Catégorie
&ea=PDF // Evenement – Action
&el=$monfichier // Evenement – Libellé
&ev=1 // Evenement – Valeur
&dm1=1 // Métrique personnalisée #1 (Téléchargements) incrémentée de 1
[/code]
Dès que mon appel à Universal Analytics se déclenche, je recois naturellement des données dans mes rapports!
Cliquez pour télécharger le script complet de tracking des PDF dans Universal Analytics
(et oui je mesure aussi ce téléchargement)
[code lang= »shell »]#!/bin/bash
#on définit l’expression régulière servant à détecter le fichier PDF dans chaque ligne de code
pattern=’GET /(.*\.pdf)’
# On récupère chaque nouvelle ligne de mon log Apache contenant un fichier .pdf
tail -f access_log | grep –line-buffered .pdf | while read line; do
echo $line
if [[ $line =~ $pattern ]]; then
#on récupère la valeur entre parenthèses dans la regex
monfichier=${BASH_REMATCH[1]}
fi
#on appelle le pixel Universal Analytics, avec les paramètres qui vont bien
wget -q -O /tmp/pixel.gif "http://www.google-analytics.com/collect?v=1&t=event&tid=UA-7634164-5&cid=555&dh=juliencoquet.com&ec=Downloads&ea=PDF&el=$monfichier&ev=1&dm1=1"
done
[/code]
Voilà, avec ce code là que vous lancez sur votre serveur Web (avec un démarrage serveur tant qu’on y est), vous enverrez un événement à Google Universal Analytics dès qu’une nouvelle ligne de log comportera un fichier PDF.
Pas mal, hein?
Comme vous vous en doutez, ce code est facilement adaptable suivant le format de votre log pour traquer le delta entre la taille réelle du fichier et la taille servie! Vous pouvez aussi créer un type d’événement différent suivant l’extension du fichier (.doc, .xls, etc.)
Evidemment, il s’agit davantage d’une preuve de concept que d’un mécanisme utilisable à grande échelle, surtout si vous avez une grosse consommation de fichiers PDF et que le nombre de nouvelles lignes devient trop lourd à gérer.
Comme d’habitude, vos commentaires constructifs sont les bienvenus!
Il me semble (à confirmer, hein !) que dans Chrome, quand un utilisateur clique sur un fichier à télécharger et que s’ouvre la boite de dialogue système pour choisir où l’enregistrer, le navigateur commence déjà le téléchargement afin de « gagner du temps ».
Imaginons un PDF de 2Mo :
– l’utilisateur clic sur le lien (intention de téléchargement)
– la boite de dialogue s’ouvre pour lui demander où le télécharger
– dans le même temps, le téléchargement commence en arrière plan, vers un dossier temporaire
– l’utilisateur ne fait rien pendant 2 minutes (sa maman l’a appelé, il est allé manger un cookie…)
– le téléchargement se termine en arrière plan, sans que le fichier ne soit déplacé car l’utilisateur n’a toujours pas choisi de destination
– l’utilisateur revient et voit la boite de dialogue « Quoi ? Ah mais je ne voulais pas le télécharger j’annule »
– dans les rapports, on voit qu’on a délivré entièrement le PDF alors qu’en fait l’utilisateur à l’impression de ne jamais l’avoir téléchargé
Bon c’est un cas extrême, bien sûr. Et il faudra bien vérifier que cela se passe ainsi.
Mais c’était histoire de faire la remarque 🙂
C’est très intéressant, surtout que personnellement je propose un PDF en téléchargement pour mes coloriages. Par contre, j’aimerais savoir si on peut avoir la même chose pour suivre les visiteurs sur des images ? C’est à dire qu’ils ne passent pas sur des pages HTML mais directement sur le JPG.
Oui tout à fait, la méthode est un peu la même. On peut en plus dans le log détecter si l’acès à l’image est direct (sans charger la page) avec le champ referer
Merci, par contre je comprend à peine le code pour PDF alors je vais devoir me pencher quelques temps dessus avant d’y parvenir. Si on change dans le script Bash PDF par JPG, cela suffit-il. Je peux aussi rajouter que j’ai Nginx et non Apache. Cela change quelque chose ?
changer PDF en JPG suffit en effet, mais je suis moins habitué à Nginx donc l’emplacement des logs changera sans doute
J’aime beaucoup la démarche, qui nous fait enfin sortir du front dév pur et dur 🙂
Par contre, le CID n’étant pas dans les fichiers logs, il est ici une constant. Ainsi, si on voit effectivement les téléchargements réels, ils ne sont pas rattachés au visiteur.
Du coup je suppose que t’analyses les données ad/site via l’intention de téléchargement, et le « taux de dl total » via ce script?
Thomas
Exactement 🙂
Techniquement, je n’ai même pas besoin du CID mais bon…
Il me semble qu’il est obligatoire pour n’importe quel hit
au temps pour moi, je pensais à autre chose 🙂