Google Analytics in 30 secondi

Oggi voglio segnalarvi uno script che alcuni di voi potrebbero trovare utile, e che serve a tracciare i click sui link esterni e sui download tramite gli eventi di Google Analytics, anziché tramite il classico metodo delle “pagine virtuali”. E’ una tecnica descritta da Stephane Hamel sul blog immeria, e ve la posso presentare senza averla provata perché gli autori sono gli stessi dell’estensione WASP, per cui possiamo fidarci!

I click sui link esterni saranno tracciati con un evento di nome “outbound”, una action “click” e una label uguale all’url visitato. I download invece avranno un evento “download”, la stessa action “click” e una label uguale al nome del file scaricato. L’espressione regolare predefinita è questa
/\.(docx*|xlsx*|pptx*|exe|zip|pdf|xpi)$
e cerca sostanzialmente eseguibili, pdf, archivi zip, estensioni di Firefox e documenti Office 2007, ma siete ovviamente liberi di modificarla come più vi pare cercando nel file gaAddons.js la riga
var fileTypes = new RegExp(/\.(docx*|xlsx*|pptx*|exe|zip|pdf|xpi)$/i);
e modificandola in base ai tipi di file che il vostro sito propone agli utenti.

Per abilitare questo tracciamento è sufficiente scaricare il file gaAddons.js dal sito di immeria, caricarlo sul proprio server e aggiungere una riga al codice html delle pagine, prima della chiusura di BODY, non importa se prima o dopo la chiamata al GATC. La riga da aggiungere è
<script src="/js/gaAddons.js" type="text/javascript"></script>

nell’ipotesi in cui il file risieda nella sottocartella /js/, altrimenti dovrete indicare il percorso per trovare il file dello script.

E’ una soluzione che ritengo valida, ma che non implementerò a tappeto sui profili che gestisco, miei o dei clienti. Valuterò caso per caso se il beneficio ottenuto vale lo sforzo (sforzo di installazione, ma anche di manutenzione e di interpretazione dei report). Il criterio sul quale mi baserò è puramente numerico, infatti ritengo che questa implementazione tramite gli eventi porti benefici su siti con grandi numeri, dove il numero di click su link esterni e download è significativo e quindi il numero di pageviews virtuali ha un impatto di un certo tipo sui totali visualizzati da GA. Per siti di piccole dimensioni, al momento, non ritengo necessario l’uso degli eventi per questo tipo di monitoraggio, e resta sempre valido il sistema automatizzato realizzato da me e Francesco Terenzani

WASP è l’acronimo di Web Analytics Solution Profiler, ed è un’estensione per Firefox che permette di conoscere quale strumento di web analytics è in uso nelle pagine che visitiamo.
Nella sua versione base è in grado di fare una scansione di un intero sito e riportare lo stato della presenza dei sistemi di web analytics, e abbiamo ormai imparato quanto sia importante ai fini della qualità dei dati in ingresso che lo script sia presente su tutte le pagine che vogliamo monitorare di un sito. Al momento rileva la presenza di 125 diversi sistemi di web analytics.

La versione a pagamento non ha limitazioni e permette analisi più approfondite. Oggi ho saputo che la prossima versione che sarà rilasciata entro Gennaio introdurrà una sidebar specifica per alcuni sistemi, tra cui naturalmente Google Analytics, che consentirà di conoscere al volo i dettagli dello script. Niente che non si possa già fare con un po’ di buona volontà o tante altre estensioni del browser Mozilla, ma avere tutto a portata di mano tramite un tool sviluppato apposta per chi fa web analytics è tutta un’altra cosa…

Per avere un’idea di quello che sarà possibile fare vi consiglio di dare un’occhiata allo screenshot

Tra le informazioni che la nuova sidebar visualizza troveremo:

• la versione dello script di GA e il numero dell’account cui vengono inviati i dati
• title, referrer rilevato e URL della pagina
• encoding, abilitazione di Java e versione di Flash, risoluzione dello schermo
• contenuto dei cookie scritti da Google Analytics

A mio avviso è un’estensione da avere, e non solo per GA, e quando avrò modo di provare la versione 1.0 valuterò se sia anche il caso di acquistarla.

Nonostante la versione del GATC non sia cambiata, il codice di monitoraggio da inserire nelle pagine web su alcuni profili è leggermente variato. Questo il codice che potreste trovare:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-XXXXXXX-XX");
pageTracker._trackPageview();
} catch(err) {}</script>

Come potete notare l’oggetto pageTracker e la relativa chiamata al metodo _trackPageview si trovano dentro ad un blocco try, in un’istruzione try… catch.

In programmazione il costrutto try… catch permette di gestire le “eccezioni” che più semplicemente potremmo definire “errori”. Per farla breve la variante del codice di Google Analytics sopra riportata cerca di eseguire le sue normali funzioni e in caso di errore… non fa niente, ma evita che appaiano errori nella console Javascript del browser:

Inoltre, un errore Javascript nel codice di Google Analytics, in certe condizioni, potrebbe bloccare l’esecuzione di altri script presenti nella pagina, riducendo le funzionalità di un sito web.

Con questo try… catch si riduce quindi il rischio che il codice di Google Analytics generi un errore, che potrebbe ad esempio essere causato dalla mancata inclusione del file ga.js. A sua volta, la mancata inclusione del file ga.js, potrebbe essere causata da un programma o estensione per bloccare annunci pubblicitari, da impostazioni di rete in server aziendali o da servizi estremi di protezione della privacy, come ad esempio FoolDNS.

Per concludere, se non volete rischiare di avere un sito che “non funziona” per colpa di Google Analytics, potete fare tre cose:

1. Non usate Google Analytics!
2. Lasciate il codice di Google Analytics al suo posto, tra i propri tag SCRIPT e /SCRIPT. Se lo prendete e lo mettete in un file esterno o in mezzo ad altro codice Javascript, rischiate che in caso di errore non funzioni neanche tutto il resto. In alternativa inserite il codice di Google Analytics in un costrutto try… catch, come nella variante proposta da Google.
3. Includete il codice di tracciamento appena prima della chiusura del tag /BODY e non tra i tag HEAD e /HEAD delle pagine HTML. Questo vale per Google Analytics come per tutti i file Javascript che risiedono su server esterni. Infatti i browser leggono i documenti in modo sequenziale, dall’inizio alla fine, e quando trovano l’inclusione di un file Javascript non proseguono fino a che il file non è stato incluso. Se i server di Google Analytics non fossero raggiungibili per qualsiasi motivo, la porzione di pagina non caricata non includerebbe il contenuto principale.

[questo è un guest post di Francesco Terenzani. Francesco è il classico “amico di chat che non si è ancora conosciuto di persona” ma è una persona in gamba ed è molto preparato. Quando ho un dubbio su javascript mi permetto di disturbarlo, e lui trova sempre qualche minuto da dedicarmi. D’altronde senza il suo lavoro non avremmo mai prodotto lo script per auto-tracciare link esterni e download anche in presenza di multipli GATC.]

[to Joe Texeira: yes, I noticed the change in the script on 13th November, but I was waiting for my friend Francesco to confirm me some ideas 🙂 ]

Quando vi proposi la libreria di Brian Clifton per tracciare automaticamente link e download, dissi che soffriva di un problema. A molti sembrerà un problema di poco conto, una cosa che usano in pochissimi, ma ha realmente una sua utilità che vado a spiegarvi: la libreria di Clifton funziona solo con l’oggetto predefinito di GA, pageTracker. Se voi istanziate più oggetti per più profili, non va. Dovete modificare il sorgente e conoscere a priori il nome dell’oggetto di monitoraggio. Insieme a Francesco Terenzani (lui l’autore materiale del codice, io ci ho messo alcune idee e test) ci siamo subito messi a pensare a una soluzione più snella ed efficace per colmare questa lacuna, e l’abbiamo trovata e descritta nel post di Francesco.

Le istruzioni sono molto chiare e non ve le riporto (e tra l’altro non c’è nemmeno bisogno di una chiamata onload), vorrei invece porre l’accento ancora una volta sulla flessibilità della soluzione che abbiamo trovato. Possiamo istanziare due o più oggetti di tracciamento e tracciare gli stessi download su due o più account diversi, oppure possiamo tracciare cose diverse su account diversi come mostrato da Francesco. Invece di fare dei filtri a monte di profili-copia, con una semplice riga nel GATC otteniamo lo stesso risultato.

Guardate questo codice (realmente testato):

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript" src="_ftTrack.js"></script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXX-5");
pageTracker._initData();
pageTracker._trackPageview();
_ftTrack(pageTracker, "link|doc|rtf|pdf|zip");

var miopersonalTracker = _gat._getTracker("UA-XXXXX-12");
miopersonalTracker._initData();
_ftTrack(miopersonalTracker, "doc|rtf");
</script>

se notate, al secondo oggetto di tracciamento manca la chiamata a trackpageview(), che è quella che trasmette i dati ai server di Analytics. Questo perché trackpageview viene richiamata già al momento della creazione delle pagine virtuali, cui viene passato come argomento il percorso delle pagine virtuali stesse. Con il codice che ho scritto sopra avremo due profili, magari copie, il primo dei quali traccia tutto come sempre con in più i link esterni, i documenti doc, rtf e pdf e gli archivi zip, mentre il secondo traccia SOLO i documenti doc e rtf. ma avendo escluso la chiamata ordinaria di trackpageview, questo oggetto non traccia tutte le altre pagine, la home page ad esempio. Traccia SOLO i documenti, così possiamo fare analisi segmentata già dall’origine (ad esempio, gli arrivi da motore di ricerca ci indicheranno quali sono i documenti meglio indicizzati e per quali keyword).
Ecco un esempio di bacheca nel profilo copia di cui ho parlato:

Brian Clifton ha appena pubblicato una versione aggiornata del suo script per taggare automaticamente tutti i link in uscita, i download e i click sui mailto:, indirizzata a chi usa ga.js come codice di monitoraggio.

Il sorgente è abbastanza chiaro, per essere utilizzato dovete salvare quel file e personalizzare la variabile extTrack con il dominio (o i domini) su cui lo script è installato e che quindi saranno considerati “interni” e la variabile extDoc con le estensioni dei file da monitorare. La variabile extTrack è interesante, e ci permette anche di escludere dal tracciamento tutti i link verso un intero dominio esterno.
A quel punto dovrete includere nella sezione HEAD delle vostre pagine una riga come
<script type="text/javascript" src="addLinkerEvents-ga.js" />

Dopo di che la funzione va richiamata sull’onload del BODY, modificandolo come segue
<body onload="addLinkerEvents();">

Nei report i link esterni sono tracciati come pagine virtuali della cartella /ext/, i download come pagine virtuali della cartella /downloads/ e i clic sulle email come pagine virtuali della cartella /mailto/.

E’ una soluzione interessante che ci permette di automatizzare un lavoro fondamentale come il tracciamento dei download e dei click esterni, che incorpora una buona idea ma che ne manca completamente un’altra, anche se minore: nei prossimi giorni conto di segnalarvi una risorsa cui sto lavorando insieme a un amico che dovrebbe includere l’idea che manca allo script di Clifton. (eccola: the italian way)

Processo generale

In genere i dati provenienti da una pagina che contiene il codice di monitoraggio di Analytics (d’ora in poi GATC) vengono processati in questo ordine:

1. Un browser richiede una pagina correttamente configurata con il GATC
2. il GATC crea e inizializza un oggetto di tracciamento associato con il numero di account inserito nel GATC stesso
3. Vengono eseguiti i metodi di tracciatura personalizzati
4. Il codice di monitoraggio viene inizializzato e viene eseguito il metodo principale, _trackPageview()
   – Viene determinato il dominio
   – Vengono scritti o aggiornati i cookie
   – Vengono registrate le caratteristiche del browser, le informazioni sulla pagina e i tracciamenti delle campagne (se ci sono)
5. Il codice richiede una immagine sui server di Google, __utm.gif
   – La gif, composta di un singolo pixel trasparente, viene inviata al browser del visitatore
   – L’URL della gif contiene un insieme di parametri derivati dall’inizializzazione del codice di monitoraggio. Questa URL viene registrata nei logfiles del webserver di Google.
   – Tipicamente la gif risiede sul server di Analytics, ma nel caso di Urchin stand-alone essa risiede su un server locale del cliente
6. Questo insieme di parametri viene estrapolato dai logfiles e viene usato per popolare i database, che poi vengono usati per generare i report nell’interfaccia.

Il riferimento al codice di monitoraggio

Le prime cinque righe del tag script di default che incolliamo nelle pagine servono a determinare dinamicamente il protocollo HTTP usato dalla pagina e a richiamare il javascript appropriato dai server di Google. Tramite queste righe possiamo evitare di preoccuparci di dover cambiare il codice se usiamo un misto di pagine sicure e non sicure (http e https).

L’esecuzione del codice di monitoraggio

Il secondo set di tag javascript include i metodi necessari a eseguire la chiamata per la collezione dei dati. Questa parte del codice deve anche contenere i metodi personalizzati che vogliamo applicare alle pagine del sito. L’ordine di chiamata dei metodi fornito nel codice di default è importante, ed bisognerebbe sempre seguire queste linee guida quando si altera il GATC per le proprie necessità:

• La prima linea dello script di tracking dovrebbe sempre inizializzare l’oggetto di tracking
  var pageTracker = _gat._getTracker("UA-123456-1");
  Questa prima linea inizializza l’oggetto con l’ID del dominio che forniamo come parametro. I metodi che seguono useranno questo oggetto
• Le righe finali del codice dovrebbero chiamare i metodi _initData() e _trackPageview().
  Qualsiasi metodo personalizzato che imposta o inizializza un valore dovrebbe essere inserito prima di _initData().

(traduzione e adattamento di Google Analytics Custom Tracking)