Google Analytics in 30 secondi

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.

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…

Mi sono accorto che pur avendone parlato più volte non ho mai scritto il post di riferimento della funzione _setVar(stringa). Questa funzione serve a scrivere un valore all’interno del cookie __utmv, e il valore è a discrezione del webmaster del sito; una volta che il contenuto del cookie è impostato, esso verrà trasmesso in tutti i successivi invii di codice a Google Analytics (ovvero ogni volta che verrà richiamata la gif trasparente), permettendo così di “taggare” il visitatore (attenzione: il visitatore e non le visite).
Un esempio tipico è quello di assegnare tramite _setVar il valore “loggato” a chi effettua il login sul sito, in modo da poter discernere la sua attività da quella di chi non l’ha fatto.

L’uso è molto semplice, si tratta di impostare la riga

trackPageview._setVar('miovalore');

in un punto qualsiasi della pagina, sull’onclick di un elemento, sull’onload del body. Ovunque insomma ci sia bisogno di impostare il cookie che da lì in poi – e per i successivi due anni – manterrà il valore, a meno che esso non sia sostituito da un’altra funzione _setVar impostata dal medesimo codice di GA (quindi le _setVar di due siti diversi non interferiscono, come è ovvio che sia). Su un blog Wordpress, ad esempio, sarebbe possibile assegnare un valore corrispondente al livello dell’utente che si collega (Administrator, Editor, Contributor, ecc.).
Il famoso sistema supercookie per tracciare tutte le fonti di una conversione separa diversi valori di setvar con un segno | (pipe), e lo fa per ovviare all’unico vero grande limite di questa gestione da parte di GA: esiste un solo cookie __utmv, quindi si può attribuire un solo valore ad ogni utente; oppure si possono assegnare più valori come nel supercookie, ma essi verranno sempre riportati come aggregati (per intenderci, ogni valore è una riga del report).
La speranza di tutti noi è che un giorno Google decida di aumentare i possibili valori di questo cookie mantenendoli però separati, perché la gestione della funzione _setVar() è molto comoda.

A livello di report il valore impostato da _setVar() viene scritto nel campo “Definito dall’utente” (User Defined se usi l’interfaccia inglese) e lo si può trovare nel report omonimo all’interno del gruppo “visitatori” oppure come valore utilizzabile nel menu a tendina delle segmentazioni. Una lettura esaustiva, in inglese, sui report relativi alla segmentazione viene da morevisibility.com, da cui si evincono due informazioni interessanti:

• nel caso in cui un utente cambi il valore di _setVar() durante una sessione di visita, GA attribuirà l’eventuale conversione al primo valore letto per quella sessione.
• le pagine viste, al contrario, vengono tutte attribuite all’ultimo valore

Un’altra cosa su cui vale la pena di ragionare è che _setVar() rappresenta l’unico punto di ingresso in GA in cui è possibile inserire un valore arbitrario. Tutti gli altri valori infatti dipendono dall’attività di navigazione e sono dati puri o derivati da calcoli. Questo cosa significa? significa che, fatte salve le limitazioni sulla privacy imposte dai termini del servizio, dentro al cookie __utmv possiamo infilare qualsiasi cosa ci sia utile avere direttamente dentro all’interfaccia di Google Analytics affinché possa essere incrociata con gli altri dati, ad esempio i dati demografici dei visitatori da utilizzare successivamente per il bidding demografico di AdWords.

[edit: è uscito giusto in questi giorni un post sul blog ufficiale che parla dei segmenti definiti dall'utente e di _setVar()]

Come detto nel post precedente, la funzione che si usa in Google analytics per controllare la durata di una sessione di visita, ovvero il tempo massimo che può intercorrere tra la vista di due pagine prima che la visita venga considerata (forzatamente) conclusa, è _setSessionTimeout(stringa).

La funzione accetta come parametro una stringa – sebbene in realtà si tratti di numeri – e precisamente vuole il numero di secondi trascorsi i quali la sessione verrà considerata conclusa. Ad esempio aggiungendo prima della chiamata a trackpageview() la riga

pageTracker._setSessionTimeout(“900″);

si imposteranno sessioni di 15 minuti (60*15 = 900).
Questa funzione va maneggiata con cura, non tanto perché distruttiva nei confronti dei dati inviati, ma poiché è in grado di variare pesantemente i risultati delle analisi. Impostare sessioni molto brevi porta fisiologicamente ad aumentare il numero di visite (e di visitatori di ritorno), mentre allungarle sortisce l’effetto inverso. Usatela se ne avete realmente bisogno perché conoscete bene il tipo di utenza del vostro sito e perché avete esigenze particolari.

Google Analytics è un sistema di tracciamento delle visite tramite javascript, come abbiamo visto più volte; significa che ogni volta che un browser con javascript abilitato visita una pagina contenente il GATC, esso invia immediatamente una serie di informazioni ai server di Google. Siti con traffico molto alto, nell’ordine delle milioni di pagine viste al mese, generano una mole di richieste molto alta, ma naturalmente il problema non è certo la banda che l’infrastruttura di Google può dedicare ad Analytics, bensì il problema potrebbero essere i report.

I dati accumulati dai server vengono processati e messi “ordinati” nel database di GA, ma non viene fatto quasi nessun precalcolo. I dati sono sostanzialmente grezzi, altrimenti non si potrebbero creare i nuovi rapporti personalizzati. Questo però comporta lo svantaggio di dover effettuare i calcoli “al volo” ogni volta che apriamo un report, infatti più dati ci sono più il sistema può risultare lento (e con i segmenti avanzati la cosa è accentuata parecchio). Per questo motivo i profili con molte pageviews potrebbero presentare la dicitura “questo rapporto si basa su dati di esempio. Ulteriori informazioni” e i dati avere una percentuale di scostamento a fianco: significa che il numero visualizzato non è preciso ma è appunto in un intorno percentuale di quanto indicato.

La funzione _setSampleRate(stringa) serve a dire a Google Analytics di non conteggiare tutti i visitatori, ma solo la percentuale passata come parametro alla funzione. Ad esempio impostando la funzione così:
pageTracker._setSampleRate("70");
verranno tracciati solo sette visitatori ogni 10. Su siti di grandi dimensioni è un’operazione statisticamente possibile, e non inficia i rapporti generati anche perché Google Analytics si comporta in maniera coerente rispetto ai visitatori che ritornano. Ogni visitatore viene “marchiato” dalla funzione: se GA decide di tracciarlo, lo traccia sempre. Se decide di non tracciarlo, non lo traccia mai. In questo modo il suo comportamento è sempre registrato e l’esperienza utente sul sito non viene stravolta nei report.

Se il dubbio che vi ha assalito durante la lettura di questo articolo è “non sono sicuro di voler tralasciare parte delle visite”, la creazione di due oggetti di tracciamento distinti che puntano a due profili differenti è la soluzione che fa per voi: un profilo conterrà tutti i dati, un altro solo un sample. Potrete fare le analisi sul profilo agile e approfondire le questioni dubbie su quello completo, diminuendo il tempo di attesa del caricamento dei dati. Ecco un esempio di codice

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write("\<script src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'>\<\/script>" );
</script>

<script type="text/javascript">
var firstTracker = _gat._getTracker("UA-12345-1");
firstTracker._setSampleRate("70"); // traccia il 70% delle visite
firstTracker._trackPageview();

var secondTracker = _gat.getTracker("UA-67890-1");
secondTracker._trackPageview(); //traccia tutte le visite
</script>

Esiste un modo alternativo di gestire le campagne in Google Analytics rispetto a quanto è stato illustrato nel post “la gestione delle campagne“: la gestione illustrata (e quella maggiormente utilizzata) inizia e finisce con la composizione e la diffusione di un link opportunamente taggato. Non è necessario fare altro, poiché il codice di tracciamento di Analytics sa già cosa deve fare, cosa deve raccogliere e cosa deve inviare ai server di Google senza bisogno di modificare nulla.

Il modo alternativo consiste nel tracciare come campagne anche URL che non sono stati pensati e progettati per GA; indirizzi magari precedenti all’installazione dello script, o indirizzi inviati per email per errore senza i parametri necessari, o altre cause. La condizione necessaria è che questi url presentino dei parametri riconoscibili, e la gestione si realizza tramite cinque funzioni (una per parametro possibile) in grado di convertire parametri che per Analytics non avrebbero senso in parametri di una campagna.

La prima funzione che affrontiamo è _setCampContentKey(stringa), e permette di convertire un parametro dell’url della landing page nel parametro utm_content inviato ai server. Supponendo che l’url inviato per email a migliaia di persone sia
http://www.miosito.it/xr100.php?fonte=newsletter&da=email&offerta=lancio-xr100&contenuto=sconto&chiave=casco

si può tramutare il parametro “contenuto” in “utm_content” aggiungendo la funzione
pageTracker._setCampContentKey("contenuto");
prima della chiamata a _trackPageview(); del GATC.

La funzione analoga _setCampMediumKey(stringa) effettua la medesima operazione ma consente di decidere da dove prendere il contenuto del parametro utm_medium. Nel caso succitato il parametro “da” viene catturato e trasformato aggiungendo la riga
pageTracker._setCampMediumKey("da");
prima della chiamata a _trackPageview();

Le altre tre funzioni da utilizzare in casi del genere, con le medesime modalità, sono:

• _setCampNameKey(stringa), cattura l’equivalente del parametro utm_campaign (“offerta” nell’esempio)
• _setCampSourceKey(stringa), cattura l’equivalente del parametro utm_source (“fonte” nell’esempio)
• _setCampTermKey(stringa), cattura l’equivalente del parametri utm_term (“chiave” nell’esempio)

Ovviamente le aggiunte di queste funzioni prima di trackPageview vanno fatte solo ed esclusivamente nella landing page che è oggetto della campagna “sbagliata”.

La gestione delle campagne è uno strumento molto potente in Google Analytics e alcuni si spingono addirittura a dire che sia la cosa meglio riuscita del prodotto. Quale che sia la vostra opinione, è indubbia una cosa: la gestione è talmente semplice che basta visitare un link con i parametri di una campagna per iniziare a vedere i relativi dati nei report. Non ho volutamente scritto “iniziare a diffondere link con i parametri” perché intendo proprio quel che ho detto: basta che qualcuno visiti un vostro indirizzo con i parametri di una campagna, una qualsiasi.
Per chiarire ancora meglio, se io visito il vostro sito tramite questo indirizzo
http://www.tuosito.it/index.php?utm_source=ilmiobrowser&utm_medium=miainiziativa&utm_campaign=melasonoinventata

voi inizierete a vedere le mie visite sotto la campagna “melasonoinventata”. C’è da dire che nei grossi numeri è improbabile che qualcuno riesca a far emergere una campagna inventata, e se ci riesce significa che porta abbastanza traffico da meritare una campagna vera, ma in siti con traffico relativamente basso è una possibilità che esiste. Se vogliamo è lo stesso discorso fatto a riguardo della copia dello script su domini diversi: la scelta progettuale è una, ed è degli ingegneri di Google, ma il sistema mette a tua disposizione gli strumenti per proteggerti. Nel caso in cui non si vogliano tracciare le campagne (nessuna campagna!) si può usare la funzione _setCampaignTrack(booleano), che disattiva il relativo tracciamento. E’ sufficiente aggiungere la riga
pageTracker._setCampaignTrack(false);
prima di trackPageView().

Essendo una funzione booleana, il tracciamento è spento o acceso; o escludete tutti i tracciamenti – e quindi non userete le campagne nemmeno volendolo – o li accettate tutti, compresi quelli “fasulli”. Alternativamente si può pensare a un filtro di inclusione solo per le proprie campagne, ma sarebbe un filtro da aggiornare molto spesso e comporterebbe qualche restrizione alla gestione stessa delle campagne.

La seconda funzione di cui parliamo oggi è _setAllowAnchor(booleano) e serve ad abilitare la gestione degli url delle campagne anche tramite il separatore # (cancelletto), oltre ai classici ? (punto di domanda) e & (e commerciale). Se devo essere sincero non ho mai visto utilizzare questa funzione da quando mi occupo di GA (anzi, ho visto URL taggati col cancelletto ma nelle pagine di destinazione non c’era la funzione _setAllowAnchor), ma poiché espande le possibilità di utilizzo è bene conoscerla. L’utilizzo è semplice, basta aggiungere la riga
pageTracker._setAllowAnchor(true);

prima della chiamata a trackPageView()

La funzione che va maggiormente tenuta da conto quando si instaurano delle campagne è _setCookietimeout(stringa); il motivo risiede nella gestione del cookie __utmz da parte dello script di Analytics: il cookie contiene le informazioni relative alla provenienza, ad esempio:
205114892.1220963346.1.1.utmccn=(organic)|utmcsr=google|utmctr=world+browser+stats |utmcmd=organic
(si viene da una ricerca su google con chiave “world browser stat”)

oppure:
219072577.1223545748.1.1.utmgclid=CITpr_XumZYCFQVOtAodAmkD7g|utmccn=(not%20set)|utmcmd=(not%20set)|utmctr=hotel%20roma
(provenienza campagna AdWords con chiave “hotel roma”)

Questo cookie ha una vita predefinita di sei mesi, o meglio 15.552.000 secondi, e le informazioni contenute sono sovrascritte secondo le famose regole:
- Le visite provenienti da una campagna, un referral, una visita organica o un adword aggiornano sempre il cookie.
- Il traffico diretto viene sempre sovrascritto da referrer, organico e campagne taggate o adword.

Questo significa che se un visitatore arriva sul vostro sito tramite una ricerca da Google per “hotel roma” e poi se ne va, per i successivi sei mesi una sua eventuale visita diretta con conversione verrà attribuita a Google organico. Allo stesso modo, se proviene da una campagna fatta su una mailing list, si salva l’indirizzo nei preferiti e poi torna dopo cinque mesi e converte, la conversione è assegnata alla campagna della mailing list.

Per vari motivi questo tempo può essere ritenuto inaccettabile: Google Analytics mette a disposizione la funzione setCookieTimeout per prendere il controllo della data di scadenza del cookie __utmz. La funzione prende in ingresso come parametro il numero di secondi trascorsi i quali il cookie scadrà e il visitatore smetterà di essere marchiato con la campagna. Si usa così:
pageTracker._setCookieTimeout("5184000");

Vi lascio anche un breve elenco di date convenzionali trasformate in secondi:
1 giorno = 86400 secondi
7 giorni = 604800 secondi
14 giorni = 1209600 secondi
15 giorni = 1296000 secondi
30 giorni = 2592000 secondi
60 giorni = 5184000 secondi
90 giorni = 7776000 secondi
120 giorni = 10368000 secondi
180 giorni = 15552000 secondi