Google Analytics in 30 secondi

Qualche giorno fa mi ero messo a scrivere un post in cui sostanzialmente mi chiedevo quanto potesse essere vera l’affermazione che feci qualche tempo fa in occasione della presentazione del tracciamento dei siti mobile tramite script lato server; mi chiedevo se Google Analytics avrebbe abbandonato del tutto l’uso di javascript. Il post non mi soddisfaceva, e l’ho cestinato, ma oggi mentre riordinavo le bozze ho trovato questo articolo di Paul Legutko, datato settembre 2009: Web analytics without javascript? in cui si dice che la previsione secca “javascript sparirà entro cinque anni” è addirittura di Yahoo.

Ad alcune considerazioni ammetto di non aver pensato, sono interessanti. Vediamole:
– mobile. Ho appena detto che la soluzione di Google per il mobile non usa javascript, ma un pezzo di codice lato server (asp, php, eccetera). E’ vero che il supporto a javascript da parte degli smartphone è in costante ascesa, ma perché un colosso come big G – che pure ha fatto del tracking code javascript di Analytics una colonna portante – non crede in questa tecnologia portata sui cellulari?
– integrazione dei dati. Praticamente tutti i sistemi di tagging “sparano” i dati in un datacenter remoto; che sia Google, Webtrends o Omniture importa poco, perché l’esigenza sempre più sentita oggi è quella di integrare i dati della web analytics con tutti gli altri messi a disposizione dalla Business Intelligence. Allora perché inviare i dati per poi cavarli di nuovo fuori? è un processo poco razionale, se ci pensiamo…
– cookie. L’attenzione sempre maggiore verso la privacy e la sicurezza degli utenti online porta quasi sempre a puntare anche il dito contro i cookie. Secondo l’autore dell’articolo la percentuale di rifiuto dei cookie è tra il 3 e il 7%, a seconda della tipologia di sito preso in considerazione. Addirittura, alcuni software antivirus tracciano come “non pericolosi” i cookie traccianti dei sistemi di web analytics, ma ne consigliano comunque la cancellazione.

In passato si è parlato ogni tanto di Flash come sostituto di javascript, poiché Flash è leggero e presente su quasi tutti i computer che navigano in rete, ma è anche vero che ultimamente si sente dire che Flash morirà a causa di HTML5 (ok, in rete si sente dire di tutto, ma stiamo ragionando abbastanza in astratto…). In uno dei commenti al post viene invece suggerito il packet sniffing lato server, ovvero l’apertura di tutti i pacchetti a livello TCP che vengono inviati dal server ai visitatori del sito, in modo da carpire tutte le informazioni che normalmente vengono affidate allo script di tracciamento. Questa però è una soluzione che non è affatto alla portata di tutti, certamente non semplice quanto copiare e incollare un pezzo di codice in tutte le pagine di un sito.
Sia come sia, ritengo difficile pensare di tornare ai file di log, almeno non nella forma in cui li abbiamo conosciuti (e in qualche caso ancora conosciamo). Cinque anni sono un tempo enorme in informatica, e può darsi che la prossima generazione di sistemi di web analytics utilizzerà una tecnologia che non è stata ancora inventata; il dibattito però è affascinante, ed ancora una volta potenzialmente in grado di ribaltare completamente il settore.

[questo post tecnico è stato scritto da Paolo Ciarrocchi; dopo avermi chiesto una mano per risolvere un problema, ha iniziato a voler capire più a fondo il principio di funzionamento di Google Analytics. Ne è scaturito questo post, perché comunque è un argomento che non avevo ancora affrontato 🙂 ]

Installazione del codice di monitoraggio.

Utilizzare Google Analytics per tracciare gli accessi ad un sito e’ molto semplice, e’ sufficiente inserire il codice di monitoraggio in tutte le pagine del sito che vogliamo tracciare.
Esempio di codice di monitoraggio:

<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-y");
pageTracker._trackPageview();
} catch(err) {}</script>

xxxxxxx indica l’account number e y indica il property number. Questa coppia identifica in modo univoco il profilo utilizzato per collezionare e analizzare le statistiche.
E’ consigliabile inserire il codice di monitoraggio appena prima del tag di chiusura del body della pagina:

</body>

Ora che avete inserito il codice non resta che aspettare fino a 24 ore per iniziare a collezionare ed analizzare i primi dati.

Ma come fa Google Analytics a monitorare il vostro sito?

Ogni volta che una pagina monitorata viene caricata il codice javascript che avete inserito effettua una richiesta GET verso la URL http://www.google-analytics.com/__utm.gif inserendo al suo interno una serie di parametri.

Ecco un esempio:

http://www.google-analytics.com/__utm.gif?utmwv=4.3.1&utmn=2028990980&utmhn=xxxxxx&utmcs=UTF-8&utmsr=1280x1024&utmsc=32-bit&utmul=it&utmje=1&utmfl=10.0%20r32&utmdt=xxxxx&utmhid=941747535&utmr=-&utmp=/xxxxx&utmac=xxxxxx&utmcc=__utma%3D1.3953800709497065000.1248852507.1251792483.1251811994.60%3B%2B__utmz%3D1.1248852507.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B

Una chiara spiegazione di tutti i parametri che possono essere inviati verso google-analytics e’ presente al seguente URL:

code.google.com/intl/it-IT/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html

Troubleshooting del codice di monitoraggio.

Avete di dubbi sul corretto funzionamento del vostro codice di monitoraggio?
Volete capire meglio quali informazioni vengono inviate ai server di Google?

Vi consiglio di utilizzare i seguenti plugin per Firefox per tracciare le chiamate verso http://www.google-analytics.com/__utm.gif

• Live HTTP Headers
• Firebug

Live HTTP Headers

Il plug-in e’ disponibile al seguente URL:
https://addons.mozilla.org/en-US/firefox/addon/3829

Questo add-on vi permetterà di visualizzare tutti gli header HTTP inviati e ricevuti durante la navigazione di un sito web.
Terminata l’installazione del plugin andate in strumenti e selezionate Live HTTP Headers, attendete che il plugin si avvii e selezionate il tab Generator. Selezionate quindi le opzioni indicate nel seguente screenshot:

Firebug

Il plug-in e’ disponibile al seguente URL:
http://getfirebug.com/

Questo plugin vi permetterà di fare editing, debugging e monitoring delle componenti HTML, Javascript e CSS delle pagine caricate dal vostro browser.
Per monitorare le interazioni con Google Analytics andremo quindi ad utilizzare un piccolo sottoinsieme delle sue funzionalità.

Terminata l’installazione del plugin dovrete attivarlo premendo l’icona

Attivate ora il pannello Net e selezionate la tipologia Immagini:

Potete ora provare questi due ottimi strumenti per fare troubleshooting del codice di monitoraggio di Google Analytics. Utilizzateli per intercettare tutte le chiamate verso la URL http://www.google-analytics.com/__utm.gif e analizzate, con molta attenzione, i parametri che vengono passati all’interno della GET.

Non vedo GET verso http://www.google-analytics.com/__utm.gif !!

Probabilmente non state utilizzando correttamente gli strumenti, verificate le configurazioni e ricordatevi che:

• Ogni volta che caricate una pagina contenente lo snippet di codice di Google Analytics viene inviata una GET verso __utm.gif. Quando fate troubleshooting potete fare un semplice refresh della pagina per cercare nuovamente di intercettare la GET.
• Ogni volta che cliccate su di un link marcato come “virtual page view” viene inviata una GET verso __utm.gif. Questo scenario e’ particolarmente interessante dal punto di vista del troubleshooting in quanto richiede una conoscenza della configurazione di Google Analytics superiore al semplice “copia e incolla” del suo codice di tracking
• Potreste essere di fronte ad un BUG di Google Analytics (o delle relative API usate da altri prodotti Google), questa possibilita’ e’ indubbiamente remota ma non e’ da escludere a priori (Io stesso ho iniziato a fare troubleshooting del codice di monitoraggio di Google Analytics in quanto mi sono trovato di fronte ad un BUG di un prodotto di Google).

Cosa cercare all’interno della GET?

Ottima domanda!
Ci sono indubbiamente alcune variabile che devono essere sempre analizzate con attenzione:

• utmac – Indica il vostro account di GA. Controllate che sia valorizzato correttamente.
• utmdt – Indica il titolo della pagina che include il tracking code di GA
• utmp – Indica la page request della pagina in questione
• utmr – Indica il referral

Ci sono poi variabili che forniscono informazioni relativamente sia al browser che al “computer” che state utilizzando:

• utmcs – Indica il language encoding del browser
• utmje – Indica se Java e’ abilitato nel browser (in quel caso la variabile e’ valorizzata a 1)
• utmul – Indica la “lingua” del browser
• utmfl – Indica la versione di Flash
• utmhn – Indica il nome dell’host
• utmsc – Indica la profondidita’ di colore del vostro monitor
• utmsr – Indica la risoluzione del vostro monitor

Ci sono poi variabili strettamente legate alle campagne e all’e-commerce, come gia’ indicato in precedenza vi invito a leggere la guida al troubleshooting di Google (in inglese) per maggiori informazioni:

code.google.com/intl/it-IT/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html

[Molti dei problemi che risolvo per me, amici o clienti, li risolvo proprio guardando gli header HTTP verso i server di Google Analytics. In quell’unica stringa di testo ci sono tutte, TUTTE, le informazioni che il vostro browser invia ad Analytics. Se c’è un problema lì non c’è filtro che tenga: GA registrerà un dato erroneo, o peggio non registrerà nulla. Se visitando la pagina non vedete nemmeno partire la richiesta per la gif, siete già a metà dell’opera e potete concentrarvi solo sul vostro codice, lasciando del tutto perdere I pannelli di GA 😀 ]

Tracciare cosa cercano gli utenti tramite il motore interno è molto importante quando si fa web analytics, perché è fonte di informazioni dirette sui contenuti più interessanti che spesso non sono abbastanza valorizzati. I dati che si possono estrarre guardando alla ricerca interna sono però molti di più, e combinarli con il resto delle informazioni che il software di web analytics ci fornisce accresce di molto le nostre possibilità di comprendere meglio cosa accade sui siti.

In effetti la ricerca interna è fonte anche di un’altra importantissima informazione, se riusciamo a catturarla: cosa l’utente cerca ma non trova sul nostro sito, cioè contenuti che ci vengono richiesti ma che non forniamo. Questo è il motivo per cui Justin Cutroni ha scritto un interessante post su come tracciare le ricerche con zero risultati (link non più disponibile). Purtroppo è un post molto tecnico e non credo riuscirei e renderlo meno “spesso” di così traducendolo. Se volete tracciare le ricerche con zero risultati, quella è la via.

C’è però una buona notizia: se usate WordPress, monitorate la ricerca interna e avete il plugin per Google Analytics di Yoast (tra l’altro tre condizioni che avevo già raccomandato in passato 😉 ) vi basta aggiornarlo all’ultima versione – cioè la 3.2.3 – e seguire le semplici istruzioni contenute in questo video:

Configuring Site Search Tracking in Google Analytics from Joost de Valk on Vimeo.

Ovvero andare in modifica del profilo, poi dire “Sì” alla domanda “Utilizzi categorie per la ricerca su sito?”, digitare cat come “Parametro di categoria” e infine dire a GA “Sì, rimuovi i parametri di categoria dall’URL” tramite l’ultima opzione. Facile, no? 🙂

Ulteriore segno del grado di interesse che desta la ricerca interna è questo post di Tom Pitts, che consente di tracciare anche il numero di risultati per ogni ricerca. Per utilizzare questo metodo è necessario modificare l’header globale del template, la pagina che mostra i risultati delle ricerche e il codice di monitoraggio di GA.

Giovanni mi segnala per email un articolo molto molto interessante per chi ha il cruccio del last cookie win / first cookie win. Ricordo infatti a tutti che Google Analytics è un sistema “last cookie win”, in cui la conversione viene attribuita all’ultima sorgente che ha portato la visita, con alcune regole specifiche per il traffico diretto. Altri sistemi invece preferiscono la logica del “first cookie win” (e su GA possiamo impostarla sulle campagne taggate tramite il parametro no_override), ma quale che sia la logica applicata il difetto che tutti riconoscono è quello di non consentire di tenere traccia di tutte le diverse sorgenti che hanno contribuito a formare nel cliente la decisione di convertire.

So che alcuni sistemi stanno provando (non l’ho mai provato, e correggetemi se sbaglio, ma mi pare che sitovivo abbia una soluzione di questo tipo) a sviluppare logiche miste di attribuzione di una conversione a più sorgenti, ma da oggi grazie al lavoro di un Google Analytics Authorized Consultant possiamo avere qualcosa di similare – ancorché abbastanza di base – per tracciare tutte le sorgenti che hanno concorso ad una conversione: loro lo chiamano “super cookie“.

Questo super cookie si occupa di raccogliere il referrer di ogni visita, di salvarlo in un nuovo cookie chiamato _utmcw e di chiamare la funzione _setVar() impostando il valore di questo cookie come parametro della funzione stessa. I vari referrer non vengono sovrascritti ma messi in coda e separati da un carattere |.
Attraverso un rapporto personalizzato, composto almeno dal parametro “totale completamenti all’obiettivo” e della dimensione “valore definito dall’utente”, avremo modo di verificare tutte le sorgenti che hanno generato conversioni, nella forma (e nell’ordine esatto) ad esempio di:

direct|google(organic)(keyword1)|yahoo(organic)(keyword2)|direct|referral(www.sitoesterno.it)

che ad esempio si riferisce ad una conversione avvenuta alla quinta visita, la prima delle quali diretta (digitazione dell’url o bookmark, ad esempio), la seconda da google con ricerca keyword1, la terza da yahoo con ricerca keyword2, la quarta diretta e la quinta tramite un link dal sito sitoesterno.it. Tramite il super cookie si possono ad esempio conoscere esattamente TUTTE le parole chiave e le frasi che sono state cercate dall’utente prima di convertire

Il punto forte di questo script è che ricostruisce da solo la sorgente, evitando il problema della discrepanza di scrittura del cookie quando avvengono due referral nella stessa sessione di cui vi ho già parlato.

Il punto debole, come ho fatto notare nel post degli autori, è che non è previsto (ma non saprei nemmeno come implementare) un meccanismo di pulizia del super cookie, che continua ad essere aggiornato anche dopo la conversione. Per un visitatore regolare che non pulisce mai i cookie c’è il rischio che esso si gonfi senza sosta. Un punto intermedio è che il supercookie traccia e scrive solo visite provenienti dalle sorgenti “standard”, quindi traffico diretto, referral, ricerche organiche e CPC. Per tracciare anche le campagne, ad esempio le campagne email taggate, il sorgente javascript dello script andrebbe modificato, e sono sicuro che essendo GAAC loro possono sicuramente farvi avere un preventivo per questa operazione 🙂

L’utilizzo dello script è abbastanza semplice. si tratta di scaricare il file dal post linkato, aprire il file cw-algorithm.js e modificare la riga 7
var __ignore = "www.ignore.co.uk";
inserendo l’indirizzo del sito che ospita lo script. Dopodiché caricare i due file sul server web e modificare il codice di tracciamento di Analytics come segue:

<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="/cw-setup.js"></script> 
 
<script type="text/javascript"> 
var cookieTracker = _gat._getTracker("UA-XXXXXX-X");
cookieTracker._trackPageview();
</script> 
 
<script type="text/javascript" src="/cw-algorythm.js"></script> 
 
<script type="text/javascript"> 
cookieTracker._setVar(ConversionWorks);
</script> 
 
<script type="text/javascript"> 
var pageTracker = _gat._getTracker('UA-XXXXXX-X');
pageTracker._trackPageview();
</script> 

sostituendo ai vari UA-XXXXXX-X il vostro numero di UA. Notare che la parte di codice riferita a cookieTracker non è un errore, e serve a non sporcare i vostri cookie di default con i valori del super cookie.

In definitiva mi sembra un’aggiunta utile a chi non è soddisfatto del modo in cui vengono attribuite le conversioni alle sorgenti, e una fonte di informazioni utili a prescindere per tutti gli altri. Se il vostro “Valore definito dall’utente” (e/o la vostra funzione _setVar() ) è vuoto, questo può sicuramente essere un sistema valido per usarlo.

Post originale su conversion works e pacchetto da scaricare

image credit: conversionworks.co.uk

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]

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.