Google Analytics in 30 secondi

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…

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”.