Google Analytics in 30 secondi

La domanda che mi fa Francesca in un commento è semplice:

Ciao!
La mia è più che altro una curiosità:
ma se inserisco due volte lo stesso identico codice in una pagina cosa succede? Raddoppiano tutti i dati??

La risposta avrebbe dovuto essere abbastanza semplice, ma siccome avevo tempo ho messo su un piccolo esperimento per avere più dati. All’inizio, lo ammetto, ero sconcertato; poi mi sono accorto di un mio errore e la cosa è tornata ad avere un senso.
La situazione, piuttosto atipica invero, è quella in cui lo stesso identico codice di monitoraggio è presente due o più volte sulla stessa pagina. Potrebbe essere perché due persone differenti lo hanno inserito – magari uno in header e uno prima di /body – o perché si sta usando un plugin automatico ma il codice era già stato messo a mano nel template. Quali che siano le ragioni, Google Analytics non effettua nessun tipo di controllo su questa casistica, quindi i javascript vengono eseguiti entrambi e i dati vengono inviati due volte.

Questo però non si traduce in un raddoppio totale di tutti i dati. O meglio, raddoppiano solo i dati che ha senso siano doppi, quelli che tecnicamente potrebbero effettivamente derivare da una situazione di quel tipo. Ad esempio le visite non raddoppiano, perché una visita ha una durata predefinita di trenta minuti. Il fatto che in in una frazione di secondo vengano viste due pagine non intacca il concetto di sessione, per cui le due esecuzioni del GATC sono attribuite correttamente alla visita giusta. Raddoppiano invece le pagine viste, poiché vi sono due chiamate alla funzione trackpageview(). Queste chiamate, tra l’altro, avvengono a una frazione di secondo di distanza l’una dall’altra, per cui non falsano il tempo medio trascorso sulla pagina. Falsano invece, e di molto, il bounce rate. Poiché un bounce è una visita di una sola pagina vista, se sono presenti due codici di monitoraggio sulla pagina, ogni visita sarà composta sempre di almeno due pagine viste, per cui il vostro sito avrà un bounce rate dello 0%.

Il modo più semplice per accorgervi di un errore simile è appunto quello di guardare il bounce rate. se è zero o siete bravissimi o potete avere un errore di questo tipo. Un altro modo, meno immediato, è quello di guardare la pagine viste: con un doppio codice esse non possono mai essere in numero dispari

Royal Pingdom, il blog ufficiale del servizio di monitoraggio dell’uptime dei siti pingdom, ha pubblicato un interessante post dopo aver condotto un test sui diecimila siti più popolari secondo la classifica di Alexa, trovando che almeno la metà di essi usa Google Analytics, e che il 40% di questi usa ancora il vecchio codice.

Si parla di grossi nomi come foxnews.com, wired.com, istockphoto.com, e ironicamente anche di blogger.com e doubleclick.com, che sono di proprietà di Google stessa. Dei 9758 siti che sono stati in grado di rispondere alle chiamate automatiche di pingdom.com, 4872 hanno lo script di GA sulla home page, e di questi 1992 ancora chiamano urchin.js, che è la vecchia versione dello script.

Questi siti, tra le altre cose, non possono avvantaggiarsi di una serie di funzionalità che sono specifiche di ga.js, la nuova incarnazione del javascript introdotta nel dicembre del 2007:

• logica ad oggetti
• interazioni più facili con elementi AJAX nelle pagine
• monitoraggio degli eventi
• un codice più leggero e veloce da eseguire
• auto riconoscimento del protocollo usato dalle pagine, se http o https

Stando alle informazioni disponibili, e a una frase di un Google Analytics Authorized Consultant nel post citato, il supporto al vecchio urchin.js cesserà in qualche momento durante l’estate, intorno ai famosi diciotto mesi proclamati quando venne introdotta la nuova versione.

Se nel vostro sito state ancora usando urchin.js, è bene sapere che probabilmente avete ancora solo tre o quattro mesi di tempo per migrare. Se fatta con le dovute cautele la migrazione è indolore, e vi permetterà di dimenticarvi della “dead line” di Google; inoltre avrete accesso alle nuove funzionalità. Anzi, la transizione potrebbe essere un buon momento per applicare tutte quelle piccole migliorie che avete letto in questo blog e che avete sempre rimandato per mancanza di tempo. Se il sito è generato dinamicamente da un sistema di gestione dei contenuti, ci sono buone probabilità che il vostro programmatore di fiducia sia in grado di effettuare la transizione in poco tempo, e spesso modificando un solo file. Se avete centinaia di pagine statiche in HTML, è adesso il momento buono per iniziare, giacché è possibile far convivere urchin.js e ga.js sullo stesso sito MA NON sulla stessa pagina.

In ogni caso avrete a che fare con la pagina ufficiale della migrazione, che vi linko per comodità

[edit 11 aprile: In questo post sul blog ufficiale Brett Crosby smentisce che urchin.js sarà dismesso durante l'estate, contraddicendo sia quanto venne detto all'introduzione del codice a oggetti sia quanto detto dal Google Analytics Authorized Consultant. Io continuo a rimanere dell'idea che compatibilmente con tempi e costi di ognuno sia bene migrare tutto a ga.js, e mi comporto di conseguenza con i clienti]

Durante i giorni scorsi, poco prima del Festival di Sanremo, all’indirizzo www.rai.it è andato online il nuovo portale internet della televisione pubblica italiana, che fa uso della tecnologia Microsoft Silverlight per lo streaming dei contenuti. Per chi non lo sapesse, Silverlight è il “concorrente” di Adobe Flash per quel che concerne le cosiddette “Rich Internet Application”, ovvero quelle applicazioni – soprattutto web – sofisticate che difficilmente riescono ad essere realizzate con i canonici HTML, CSS e Javascript.

Nei sistemi Windows, se non erro, Silverlight dovrebbe essere installato insieme agli aggiornamenti di Miscrosoft Update, ma è sempre comunque possibile installarlo a mano la prima volta che si tenta di accedere ad un contenuto realizzato con quella tecnologia. Google Analytics contiene un intero report dedicato a Flash player che riepiloga quali versioni di Flash sono installate nei browser dei visitatori e in che percentuale essi hanno visitato il sito, ma non ha nessun tipo di report per Silverlight. Se avete la necessità di conoscere anche le percentuali delle due versioni esistenti di Silverlight, Hello Szabi! ha migliorato un precedente script di Mark Monster per farlo.

Dopo aver scaricato e uploadato sul sito lo script ufficiale per il test della versione Silverlight (fornito da Miscrosoft stessa) sarà sufficiente aggiungere queste righe di codice

<script type="text/javascript" src="silverlight.js"></script>
<script type="text/javascript">
  var hasSilverlight = Boolean(window.Silverlight); 
  var hasSilverlight1 = hasSilverlight && Silverlight.isInstalled('1.0'); 
  var hasSilverlight2 = hasSilverlight && Silverlight.isInstalled('2.0'); 
  if (hasSilverlight1) { pageTracker._trackEvent("silverlight", "v1"); }
  if (hasSilverlight2) { pageTracker._trackEvent("silverlight", "v2"); }
  if (!hasSilverlight1 && !hasSilverlight2) { pageTracker._trackEvent("silverlight", "none"); }
</script>

subito DOPO la chiusura del tag SCRIPT di Google Analytics. Nella sezione eventi del vostro profilo troverete un evento di nome “silverlight” con tre azioni: none, v1 e v2. “none” è naturalmente il numero di visitatori che non hanno il plugin installato, mentre v1 e v2 sono rispettivamente il numero di coloro che hanno la prima e la seconda (l’ultima disponibile al momento in cui scrivo) versione

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)