Google Analytics in 30 secondi

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]

Una delle domande che mi viene rivolta più spesso – e che noto essere un evergreen tra le frasi di ricerca dei visitatori in arrivo – riguarda la presenza di due o più codici di monitoraggio di Google Analytics sulla stessa pagina/sito. Con la vecchia versione dello script, quella che fa riferimento a urchin.js, le cose erano leggermente più complicate di adesso, ma non ne parleremo. Cosa aspettate ad aggiornare il GATC a ga.js?

Poiché il nuovo codice di monitoraggio è scritto seguendo la logica della programmazione a oggetti, per inviare i dati a due profili differenti è sufficiente creare due distinti oggetti di tracciamento. In GA gli oggetti di tracciamento sono quelli identificati dalla riga di codice
var pageTracker = ...

In effetti quando nei post ci si riferisce a pageTracker si commette una imprecisione: quello è il nome dell’unico oggetto creato per definizione dal codice che Google ci mette a disposizione, ma nulla vieta di cambiargli nome o, appunto, crearne più d’uno. Ecco allora che un codice fatto così:

<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">
var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-99999-3");
MarcoTracker._trackPageview();
</script>

è perfettamente legale e funzionante, ed invierà i dati all’account 12345 profilo 1 e 99999 profilo 3. Se la necessità è quella di inviare dati a più di due account si procederà di conseguenza creando ulteriori oggetti di tracciamento con nomi differenti. Questi oggetti sono (o meglio, dovrebbero essere, ma lo vediamo più tardi) completamente indipendenti l’uno dall’altro, per cui è possibile aggiungere funzioni al primo piuttosto che al secondo.

Nella realtà le cose sono leggermente differenti, e Lunametrics ci spiega perché: nonostante i codici di tracciamento facciano riferimento ad account differenti, i cookie – che ricordo sono scritti in base al dominio e non all’account Analytics – sono gli stessi per tutti e due (o più) oggetti di tracciamento.
Tra i casi di “sicuro insuccesso” relativi alla presenza di più codici di monitoraggio in una stessa pagina, Lunametrics ne cita tre che vale la pena di riportare:

1 – Codici differenti

var pageTracker = _gat._getTracker("UA-11111-1");
pageTracker._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-22222-1");
MarcoTracker._trackPageview();

Nell’esempio di Lunametrics il primo oggetto di tracciamento include le funzioni _setAllowHash e _setAllowLinker e il secondo no. In questo caso i due oggetti tentano di scrivere lo stesso cookie con intenzioni e formati diversi.

2 – Pagine differenti

Nel caso in cui uno dei due codici non sia inserito in tutte le pagine, magari in seguito a una condizione if impostata male o non realizzata, alcune pagine vengono tracciate in un account e in un altro no. Il codice di tracciamento “in difetto” vedrà i cookie che erano originariamente stati creati da una pagina che non ha quel codice. La prima pageview registrata dal secondo codice avrà informazioni di referrer diverse, poiché penserà di essere la prima pagina della visita mentre in realtà è la seconda, e così via…

3 – Segmenti personalizzati in base a _setvar()

Il segmento personalizzato “Valore definito dall’utente” viene impostato tramite la funzione _setVar() e immagazzinato nel cookie __utmv. Siccome i due codici usano gli stessi cookie, un segmento personalizzato creato dal primo codice è automaticamente creato e disponibile anche per il secondo. Questo comporta l’impossibilità di avere, ad esempio, un valore impostato su “loggato/non loggato” per il primo oggetto e “maschio/femmina” per il secondo. Poiché l’esecuzione di javascript è sequenziale nella pagina, il secondo codice sovrascriverà sempre il cookie e l’unica informazione disponibile per il segmento, alla visita/pagina successiva, sarà quella impostata dal quell’oggetto di tracciamento.

Se decidete di implementare più codici di monitoraggio di Google Analytics su uno stesso sito, o una stessa pagina, dovete prestare attenzione alle possibili conseguenze.
[photo credit: oskay su flickr]

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 ]

Come segnalato dal puntuale e sempre attento Morevisibility, Google ha silenziosamente aggiornato il codice di tracciamento richiamato dal javascript di GA. Ve ne potete accorgere usando al volo la funzione getVersion() come descritto in questo post: al momento la versione è passata a 4.3, e la modifica più evidente è già visibile nella finestra di selezione del codice da incollare nei profili, come riportato in figura:

(clicca per ingrandire l'immagine)

Il nuovo GATC non prevede più la chiamata a initData(), una funzione indispensabile al corretto funzionamento del sistema che è stata quindi – giustamente – resa invisibile all’utente e richiamata sempre e comunque un modo implicito. Google non ha ancora annunciato ufficialmente la modifica, ma sono abbastanza convinto che la cosa non comporterà la necessità di aggiornare di colpo i nostri script.