Google Analytics in 30 secondi

Uno degli aggiornamenti al changelog di Google Analytics di Agosto riporta questa interessante informazione

The call to _setAllowHash(false) is no longer required when configuring cross-domain tracking. Pages that already include a call to _setAllowHash(false) will continue to work, but it is no longer required when setting up a new site.

il che equivale a dire che la funzione è deprecata (e infatti è segnata deprecata anche nella documentazione).
Non c’è bisogno che vi precipitiate a modificare alcunché: se infatti toglieste il _setAllowHash(false) da un sito in cui è presente, causereste il reset di tutti i cookies dei vostri visitatori: la modifica quindi si intende solo a partire dalle nuove installazione che farete. Inoltre il processo di creazione automatica dello script non è ancora stato aggiornato, e scegliendo l’opzione “più domini di primo livello” propone ancora l’uso di _setAllowHash(false).

Non passa giorno senza novità per Google nell’ultimo periodo. Quella di oggi sarà particolarmente gradita: il blog ufficiale di webmaster tool e quello di Analytics riportano la notizia che i clic sui pulsanti +1 dei nostri siti, purché verificati in GWT, hanno una sezione di report apposita nel pannello dei webmaster. E sappiamo che prima o poi quei report finiranno dentro a Google Analytics (a proposito, mi hanno attivato nel programma pilota, ma c’è poco da segnalare per adesso). La seconda cosa che dicono, molto più interessante, è che dentro a GA c’è una nuova sezione di report, che si chiama proprio sociale e si trova dentro il gruppo VISITATORI.

E’ composto da un primo report COINVOLGIMENTO, che segmenta le visite tra “socially engaged” e “not socially engaged”, cioè tra chi ha o non ha cliccato un bottone sociale. Il secondo report è AZIONE, e al pari del report degli eventi mostra l’azione compiuta dai visitatori. Nei miei report al momento viene tracciato (automaticamente) il pulsante +1 di Google. Ogni azione ha anche una “sorgente sociale”, cioè google è la sorgente sociale, +1 è l’azione, e le due cose combinate sono google +1; in effetti non mi è al momento chiaro il perché di questa scelta (non è che facebook ha il più uno per cui l’azione +1 possa avere due dirfferenti sorgenti sociali…), ma è così.
L’ultimo report è PAGINE, e ci mostra gli URL esatti delle pagine dove sono stati premuti i pulsanti: il report si presenta come tabella pivot con azioni e sorgenti sociali, ma poiché ho ancora pochi dati non sono riuscito a modificarlo a piacere.

Ecco uno screenshot dal blog ufficiale

Come dicevo sopra, al momento l’integrazione tra pulsante e tracciamento è automatica – ovviamente – solo per il +1 di Google. Se volete aggiungere gli altri pulsanti dovrete fare affidamento su una nuova funzione, _trackSocial(), con la seguente sintassi

_gaq.push(['_trackSocial', network, socialAction, opt_target, opt_pagePath]);

• network è obbligatorio, ed è una stringa con il nome del social network cui il bottone si riferisce
• socialAction è obbligatorio, ed è una stringa con l’azione svolta, ad esempio INVIO, LIKE, SHARE, TWIT, ecc…
• opt_target è opzionale, ed è una stringa che rappresenta la pagina (URL o ID o quel che volete) che genera l’azione sociale. Se omesso viene usato l’url della pagina corrente estratto tramite document.location.href
• opt_pagePath è opzionale ed è una stringa che rappresenta l’indirizzo senza dominio dal quale viene generata l’azione sociale. Se omesso viene usato location.pathname+location.search e in genere si può omettere, tranne nel caso in cui la pagina venga registrata du Analytics con una url diversa dalla corrente tramite l’uso di una pagina virtuale e _trackPageview

Ovviamente non dovete inserire queste funzioni nel normale codice di monitoraggio, altrimenti ogni pagina vista corrisponderebbe a una o più azioni sociali, ma dovete fare in modo che esse siano richiamate alla pressione dei pulsanti. La maggior parte di essi ha infatti la possibilità di specificare la chiamata a qualche funzione quando viene premuto. La pagina di documentazione della funzione fornisce alcuni esempi (tracciare i like di facebook, tracciare i tweet) e un esempio di codice per fare il tutto automaticamente, scritto da Nick Mihailovski).

Questa parte di tracciamento comporta del lavoro aggiuntivo, ma ritengo ne valga la pena. Dopo potrete sapere cosa e quanto condividono i vostri utenti, da dove vengono quelli che condividono di più, come i pulsanti interagiscono col vostro ecommerce, se lo fanno, e usando le campagne generare dei circoli viziosi tipo “4 persone provenienti da quel referrer hanno sharato il contenuto su facebook, che era taggato con una campagna che mi ha portato 347 persone e 14 vendite”. E il tutto senza ancora aver visto cosa ci riserva Google da PostRank

Morto un papa se ne fa un altro, recita il detto; ed ecco che tolto il report velocità di connessione, arriva “velocità del sito”, come annunciato dal blog ufficiale.

Il nuovo report è disponibile soltanto nella versione v5, che è accessibile a tutti tramite il link rosso in alto nell’interfaccia, ed è utile per capire quali sono i tempi di caricamento delle nostre pagine. Poiché in Google spingono pesantemente su questo aspetto (il codice di Adsense è passato ad asincrono, quello di GA lo era già, Chrome dispone di uno strumento nativo bellissimo per comprendere i tempi di caricamento, da poco hanno rilasciato Page Speed Online…), molti di voi avevano correttamente pronosticato che il sostituto del vecchio report sulla velocità di connessione sarebbe stato qualcosa di simile.

Tecnicamente si tratta di aggiungere una funzione al codice di tracciamento, la funzione _trackLoadPageTime, chiamandola senza passargli valori dopo aver chiamato _trackPageview, in questo modo:

<script type="text/javascript">
 var _gaq = _gaq || [];
 _gaq.push(['_setAccount', 'UA-XXXXX-X']);
 _gaq.push(['_trackPageview']);
 _gaq.push(['_trackPageLoadTime']);

 (function() {
   var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
   ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
   var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
 })();
</script>

Dopo aver fatto questa modifica il report “velocità del sito”, che si trova sotto il gruppo CONTENUTI, inizierà a popolarsi con i dati, mentre prima mostrerà soltanto dei laconici zeri. Poiché la nuova funzione effettua un’ulteriore chiamata alla gif __utm.gif, anche se essa è presente in tutte le pagine non invierà dati per ogni pagina vista, ma effettuerà un invio a campione (e adesso è anche chiaro a cosa servisse il contatore interno alle chiamate UTMS: non puoi randomizzare le chiamate se non c’è un contatore ), per cui analizzando le richieste che partono dal codice di monitoraggio sarà perfettamente normale non vedere sempre due richieste.

Nel blog ufficiale c’è anche un link ad un custom report già pronto che potrebbe risultare utile: Site Speed Custom Report (il link porta direttamente al custom report pronto da salvare, dovete essere loggati a Google Analytics per vederlo); si tratta di un report che usa come metriche Visite, Rimbalzi, Tempo di caricamento medio e Campione per il caricamento, e come dimensioni Browser e Pagina.

Tempo di caricamento medio è il tempo, espresso in secondi, che una pagina impiega per caricarsi, dalla prima chiamata a quando il browser considera completato il caricamento.
Campione per il caricamento indica il numero di pagine viste utilizzate per calcolare il dato precedente, in modo che sia chiaro l’indice di confidenza espresso.

Poiché ovviamente tutto è segmentabile, le possibilità sono infinite: ad esempio si potrà finalmente capire se l’alto tasso di uscita da una certa pagina è dovuto o no all’alto tempo di caricamento della stessa. O se il tasso di rimbalzo di una certa campagna AdWords è dovuto alla lentezza della relativa landing page.

Una funzione che non ho mai menzionato su questo blog è _setReferrerOverride(url), che serve a sovrascrivere il referrer estratto automaticamente da Google Analytics prima che esso venga passato ai server per l’analisi. Perché si dovrebbe fare una cosa simile? Ad esempio un motivo valido può essere che per qualche problema tecnico che non riuscite a risolvere immediatamente – mentre i dati stanno venendo registrati sbagliati – il referrer non è quello atteso. Questa funzione vi permette di ripristinare quello corretto.

La funzione accetta come parametro una sola stringa, che deve essere l’url del referrer (reale o fittizio) che decidete di impostare per quella pagina, o per quella singola chiamata del codice di tracciamento.

_gaq.push(['_setReferrerOverride', 'http://www.referrerfinto.it/parametro=2]);

Un caso reale e molto pratico in cui si usa questa funzione è ad esempio per tracciare completamente lato codice – quindi senza usare filtri e profili-copia, le ricerche fatte su Google Images. E’ sufficiente usare questo codice

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-xxxxxxxx-x']);
var ref = document.referrer;  //prendo il referrer
if (ref.search(/images.google/) != -1 && ref.search(/prev/) != -1) { //se contiene sia images.google sia /prev/
var regex = new RegExp("images.google.([^\/]+).*&prev=([^&]+)"); //scrivo la regex per estrarre i due valori
var match = regex.exec(ref); // la eseguo
_gaq.push(['_clearOrganic']); //pulisco la lista dei motori di ricerca
_gaq.push(['_addOrganic','images.google.'+match[1],'q']); // aggiungo un unico motore di ricerca (google immagini)
_gaq.push(['_setReferrerOverride', 'http://images.google.'+match[1]+unescape(match[2])]); //sovrascrivo il vecchio referrer con quello apposito
}

_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>

(l’autore originale dello script era Joost De Valk nel forum ufficiale, poi è stato modificato per renderlo asincrono da un altro utente)

Non male, no?

Il vantaggio del codice asincrono è che crea una coda di comandi che viene eseguita in parallelo allo scaricamento di altri javascript, rendendo il caricamento della pagina più veloce. La cosa che spesso trae in inganno – da quel che sento – è che molti pensano che adesso tutto debba essere inserito dentro a questa coda prima che i comandi vengano “sparati” verso i server di Google Analytics. Non è vero.

Un esempio tipico è il monitoraggio degli eventi, che sono associati quasi sempre ad azioni effettuate dall’utente, quindi non è possibile prevedere se esse saranno fatte 10 secondi o 25 minuti dopo che la pagina ha finito di caricarsi. Quale è la sintassi da utilizzare per tracciare un evento (per praticità riprendo lo stesso esempio del post originale sulla funzione trackEvent)con il nuovo codice asincrono? è semplicemente:

<a href="#" onclick="_gaq.push(['_trackEvent', 'categoria', 'azione', 'descrizione', valore]);">Play</a> 

come vedete la funzione è la stessa, così come i parametri (ve lo ricordo: categoria e azione sono obbligatori, gli altri opzionali), cambia solo la sintassi. Sparisce pageTracker e ci sono alcune parentesi in più, ma non è poi molto differente dalla vecchia forma, no?

Se vi ricordate, qualche tempo fa abbiamo parlato della funzione _setCustomVar() e del fatto che essa sostituisce quasi totalmente la vecchia _setVar() perché è più flessibile e può memorizzare più dati, anche contemporaneamente. Uno dei parametri da passare alla funzione è lo “scopo”, un numero intero che rappresenta l’uso che si fa dello slot che decidiamo di usare tra i cinque disponibili.

Ecco, se usiamo la funzione per scrivere un valore riferito al visitatore, ovvero se usiamo uno scope con valore 1, allora abbiamo successivamente la possibilità di richiamare quel valore usando la funzione _getVisitorCustomVar(); l’unico parametro che accetta in ingresso è l’indice dello slot ove risiede la stringa che abbiamo scritto nel cookie del visitatore, per cui ad esempio se durante una precedente sessione di visita il visitatore si è loggato e abbiamo usato la funzione

pageTracker._setCustomVar(1,"condizione","loggato",1);

durante una visita successiva possiamo chiamare

pageTracker._getVisitorCustomVar(1); 

e vederci restituire in risposta la stringa “loggato” da utilizzare come meglio crediamo.

Premesso che non ho ancora usato questa semplice funzione, prevengo già una possibile domanda: non so se funziona anche con gli altri scopi, cioè con porzioni di cookie riferite alla sessione o alla pagina. A giudicare dalla documentazione – e ragionandoci un po’ su – direi di no, ma in questi casi non c’è niente di meglio di un bel test!

Andrea mi pone un quesito, ma in verità ultimamente molti mi fanno domande che sono riconducibili alla stessa soluzione. La domanda di Andrea riguarda il fatto che su un profilo vede il suo stesso sito nei referrer.

Innanzitutto chiariamo una cosa: TUTTE le pagine viste generate da un click hanno un referrer, anche quelle interne (potete verificarlo guardando i cari vecchi logifles generati dal webserver). Se digito una URL e vado sulla home di un sito faccio una visita diretta, se poi clicco la prima voce di menu, la pagina corrispondente avrà come referrer la home page, e così via per le successive. Il fatto che i referrer interni siano esclusi in modo predefinito dai sistemi di web analytics (ma non tutti, infatti nelle definizioni della Web Analytics Association il referrer interno esiste ed è vivo e vegeto – vedi il documento di definizione degli standard, pagina 18) spesso ci porta a dimenticarci di questo fatto.

Detto questo, Andrea si è accorto da solo del possibile problema: su un sottodominio c’è lo stesso codice usato per il dominio di primo livello, e secondo lui questo genera l’errore. Vorrebbe quindi sapere come filtrare le visite che hanno quel referrer, e qui sta il suo sbaglio: la soluzione corretta è quella di usare _setDomainName(“.miosito.it”); che forza la scrittura del cookie di Google Analytics in modo che mio sito.it e sottodominio.miosito.it usino lo stesso cookie. Senza quella funzione infatti GA scrive due cookie differenti per il dominio principale e il sottodominio, e ovviamente interpreta le visite che “travasano” da uno all’altro come appartenenti a due siti differenti, generando quindi un referrer.

Ci sono controindicazioni ad usare _setDomainName? no, nessuna. Per questo motivo secondo me dovrebbe essere inserita di default nei vostri codici di tracciamento, anche se non avete sottodomini. Perché se un domani li avrete non perderete la congruenza dei cookie già creati e rilasciati sui browser dei visitatori passati.

[photo credit: orphanjones' on Flickr]

A partire dal primo dicembre 2009, la funzione _setVar() è deprecata, il che significa che non va più usata nel proprio codice di tracciamento. Nel contempo sotto al report “definito dall’utente” è stato aggiunto “Variabili personalizzate”, che consente di monitorare quel che viene definito con la nuova funzione. Il vecchio report è adesso popolabile soltanto tramite filtro.

_setVar() è stata invece sostituita dalla nuova _setCustomVar(indice, nome, valore, scopo), che ha le stesse possibilità della precedente, ma aggiunge ulteriori livelli di utilizzo e possibilità di tracciamento. Vediamo come:

• indice è un numero intero, da 1 a 5, e rappresenta lo “slot” nel quale il valore viene inserito.
• nome è una stringa, e rappresenta il nome che diamo alla variabile impostato.
• valore è una stringa e rappresenta il contenuto della variabile personalizzata
• scopo è una numero intero – opzionale – che possiamo usare per tenere traccia del perché quella variabile viene impostata. Valori tipici sono 1, 2 e 3 che nell’idea di Google Analytics rappresentano nell’ordine variabili impostate a livello di visitatore, di sessione o di pagina.

Dal punto di vista del programmatore la funzione ritorna un valore booleano: true se la variabile personalizzata è stata impostata correttamente, false se qualcosa è andato storto. Tenete a mente che la somma dei caratteri di nome e valore non può sorpassare i 64 caratteri.

Perché è utile dichiarare uno scopo? perché la nuova funzione _setCustomVar() può essere usata in contesti differenti rispetto alla vecchia _setVar(), ad esempio per raggruppare i contenuti senza trucchi. Il codice necessario per raggruppare le pagine della categoria “sport” potrebbe ad esempio essere:
pageTracker._setCustomVar(1,"sezione","sport",3);

Se per adesso non avete voglia di fare troppe modifiche ma vi interessa solo continuare a far fare ad Analytics quello che facevate con _setVar(), la traduzione della vecchia riga

trackPageview._setVar('miovalore');

si fa – ad esempio – con

trackPageview._setCustomVar(1,'valore_pers','miovalore',1);

Si è inserito il valore di 1 nello scopo perché la vecchia funzione impostava SOLO valori a livello utente, che sono appunto quelli con scopo 1.

Ricordatevi sempre che _setCustomVar() va chiamata PRIMA di un trackPageview() o di un _trackEvent(), poiché la funzione imposta il valore ma non comunica niente ai server, mentre le altre due poi inviano tutte le informazioni, quindi anche il valore appena impostato, a Google Analytics

Nel tentativo di migliorare la coerenza tra i nomi delle funzioni, Google ha cambiato nome a tre funzioni e nel contempo ha reso obbligatorio impostarne i parametri in millisecondi invece che in secondi:

_setVisitorCookieTimeout(millisecondi) prende il posto di _setCookiePersistence().
_setSessionCookieTimeout(millisecondi) prende il posto di _setSessionTimeout().
_setCampaignCookieTimeout(millisecondi) prende il posto di _setCookieTimeout().

_setVistorCookietimeout() imposta il numero di millisecondi trascorsi i quali il cookie che identifica un visitatore scade ed esso si presenta come un nuovo visitatore (posto ovviamente che non abbia fatto visite tra l’ultima impostazione del cookie e il momento in cui scade; ogni nuova visita postpone il momento della scadenza del cookie). Il valore di default è due anni (63072000000 millisecondi).

_setSessionCookieTimeout() imposta il numero di millisecondi che devono trascorrere senza visitare nuove pagine affinché la sessione di visita scada e il visitatore si presenti come un visitatore di ritorno incrementando il contatore delle visite. Il valore di default è trenta minuti (1800000 millisecondi)

_setCampaignCookieTimeout() imposta il numero di millisecondi trascorsi i quali il cookie che contiene le informazioni sulla provenienza del visitatore viene azzerato. Per maggiori informazioni potete rileggere il mio vecchio post. Il valore di default è sei mesi (15768000000 millisecondi; in giorni però sarebbero 182,5).

Già che ci siamo, come feci l’altra volta, vi lascio un elenco di valori convenzionali che potrebbero esservi utili usando queste funzioni:
1 giorno: 86400000 millisecondi
7 giorni: 604800000
14 giorni: 1209600000
15 giorni: 1296000000
30 giorni: 2592000000
60 giorni: 5184000000
90 giorni: 7776000000
120 giorni: 10368000000
180 giorni: 15552000000

Della funzione _addOrganic() abbiamo già parlato in passato: essa serve ad aggiungere un motore di ricerca alla lista predefinita che Google Analytics riconosce autonomamente, lista che viene modificata nel tempo e che rispetto al post di luglio 2008 è diventata:

images.google:q
google:q
yahoo:p
msn:q
bing:q
aol:query
aol:encquery
lycos:query
ask:q
altavista:q
netscape:query
cnn:query
looksmart:qt
about:terms
mamma:query
alltheweb:q
gigablast:q
voila:rdata
virgilio:qs
live:q
baidu:wd
alice:qs
yandex:text
najdi:q
aol:q
club-internet:query
mama:query
seznam:q
search:q
wp:szukaj
onet:qt
netsprint:q
google.interia:q
szukacz:q
yam:k
pchome:q
kvasir:q
sesam:q
ozu:q
terra:query
nostrum:query
mynet:q
ekolay:q
search.ilse:search_for
rambler:words

fino ad oggi i vostri motori di ricerca venivano aggiunti in coda a questa lista, ma poiché il match viene effettuato in ordine e interrotto alla prima occorrenza (perché una visita con keyword non può certo essere attribuita a due motori differenti!) c’era la remota possibilità che un motore predefinito intercettasse la visita e la keyword prima del motore da voi specificato. Per questo motivo a partire dal mese scorso è stato aggiunto un parametro opzionale alla funzione che serve a dire a GA di consultare prima la lista dei motori personalizzata, e dopo quella predefinita.
Il nuovo parametro è opzionale, è un booleano (quindi 1 o 0, vero o falso) e se non specificato è automaticamente impostato su falso, in modo da replicare la situazione già esistente.

Riprendendo l’esempio che feci nel post originale, la nuova sintassi per aggiungere il motore di Libero e metterlo in cima alla lista (quindi prima di images.google) è

pageTracker._addOrganic("libero","query",1);

Sono piccoli miglioramenti che ai più possono risultare inutili, ma che sicuramente risolvono grossi problemi a qualcuno nel mondo…