Google Analytics in 30 secondi

Justin Cutroni, che ormai è una fonte ufficiale Google, ha annunciato su Google+ che da qualche giorno sono disponibili dei nuovi campi filtro, che potrete utilizzare per filtrare i dati nei vostri profili. Più precisamente si tratta di:

• Cellulare del visitatore? (orrenda traduzione di “visitor Mobile?”) che identifica se l’utente naviga da mobile o no
• Categoria Evento
• Azione Evento
• Etichetta Evento
• Continente del visitatore

I campi filtro sono inoltre stati riorganizzati e raggruppati logicamente, così da poter essere trovati più facilmente. Con mio sommo disappunto non è stato implementato il filtro sulle variabili personalizzate (quantomeno su quelle impostate con scope=1, cioè permanenti nei browser degli utenti). Questo, ad esempio, ci costringe a usare soluzioni “con la toppa” quando si tratta ad esempio di escludere le proprie visite con un IP dinamico: si veda in proposito questo articolo di Enrico Pavan, in cui si è costretti ad usare ancora la deprecata funzione _setVar (e la sintassi sincrona, anche se io ed Enrico dobbiamo ancora fare due test congiunti per verificare la sua ipotesi illustrata nei commenti).

Altra bella segnalazione, sempre di Justin e sempre su G+, è questa relativa allo script per GreaseMonkey AnnotationManager, che vi consente di copiare annotazioni tra profili/account, rimuoverne molte con un solo clic o anche esportarle. Mi è di recente capitato di dover inserire una annotazione su un profilo: l’ho dovuta ripetere nel profilo di quel sito, nel profilo master senza filtri e in un altro profilo in cui quel sito era combinato con due sottomini. Con AnnotationManager probabilmente avrei risolto con 3 click. Essendo uno script per GreaseMonkey però, è disponibile solo per Firefox/Chrome.

Ultima segnalazione è questo post di Brian Clifton (tra l’altro, come ho detto in questo commento, sta per uscire la versione 3.0 del suo ottimo libro) che riassume gli ultimi studi usciti sulla diffusione di Google Analytics nel web: vari post che più o meno vi avevo segnalato a tempo debito, ma che riassunti così fanno comunque una certa impressione: il 50% del web usa GA, il 45% delle top500 Fortune companies, l’86% di un campione di 800 imprenditori… più esplicativo di così…

Leggendo una presentazione di Leonardo Bellini m’è caduto l’occhio sulla spiegazione dell’algoritmo che determina cosa debba o non debba comparire quando guardate la sezione “avvisi automatici” del report Intelligence; in pratica come Google Analytics sceglie cosa mostrarvi in quegli avvisi.
La spiegazione la dà Brian Clifton nella seconda edizione del suo “Advanced Web Metrics with Google Analytics“, che è in coda per la lettura nella mia pila, ma per l’occasione l’ho aperto alla pagina giusta e cerco di spiegarlo a voi con parole semplici.

Tutto inizia con una curva che molti di voi avranno già visto, cioè la cosiddetta curva gaussiana:

[photo credit: wikipedia]

Il valore centrale (μ – mu) rappresenta il valore mediano della distribuzione, e il valore sigma ( σ ) indica invece la deviazione standard, cioè la distanza di un valore rispetto alla mediana della distribuzione. In una distribuzione normale come quella in figura il 68% circa dei valori è compreso nell’intervallo tra -1 e +1 sigma (valore blu scuro), mentre il 95% dei valori si trova entro + o – 2 sigma.

La barra “Livello di gravità per l’attivazione degli avvisi:” che regola la sensibilità ha dieci possibili valori, ma Brian ci dice che le regolazioni possono variare da 7-sigma (meno sensibile) a 1-sigma (più sensibile), probabilmente in modo proporzionale. Al valore massimo basta che un dato devii di un sigma dal valore mediano atteso per attivare un allarme, alla sensibilità minima deve invece esser fuori dai 7-sigma.

Tenendo presente che con 3-sigma si copre il 99% dei valori, posizionare lo slider come dice Brian, cioè poco più a sinistra di metà (appunto, circa 3-sigma), dovrebbe attivare solo alert per valori che almeno si raddoppiano o si dimezzano.

Quelli tra di voi che mi leggono da più tempo forse si ricorderanno del post “comprendere appieno il tempo sul sito“. Oggi ci ritorniamo per via di un post di metà ottobre di Brian Clifton, che ho avuto modo di leggere solo nel weekend: Brian prende di mira un post del blog ufficiale di Clicktale, che racconta come Clicktale sia più accurato di Google Analytics nel conteggio del tempo sul sito e sulla pagina.

Come ho esplicitato nel mio post passato, il modo per calcolare il tempo sulla pagina è quello di sottrarre il timestamp della pagina successiva da quello della pagina precedente (nel caso del tempo sul sito ovviamente la sottrazione avverrà tra il timestamp dell’ultima pagina della sessione e quello della prima).
Questo porta a tre “problemi”: il primo è che non si può conoscere il tempo sull’ultima pagina, il secondo è che il tempo totale sul sito manca del tempo trascorso sull’ultima pagina, il terzo è che le visite di una sola pagina (i bounce) hanno tempo zero. Cose che ormai conosciamo, ma non solo: questo è esattamente il comportamento tipico dei sistemi di Web Analytics, ed è lo stesso che possiamo trovare nell’ultima versione del documento degli standard della Web Analytics Association (pagina 17).

Come faccia Clicktale a calcolare il tempo sull’ultima pagina non lo so, posso solo azzardarlo da un punto di vista tecnico: deve essere presente un javascript che invia un segnale “hey, sono ancora qui” al server di Clicktale, ogni secondo, per tutte le pagine viste che contengono il suo script. Non può trattarsi di un evento javascript scatenato perché l’uscita dal sito può avvenire in più modi: cambio di URL, tramite digitazione o bookmark, chiusura della scheda, chiusura del browser, spegnimento del PC, e non tutti questi possono generare una chiamata javascript.
E’ conveniente dal punto di vista tecnico? forse se non hai un grosso volume di traffico si, ma se tutte le pagine che contengono il codice di GA facessero una chiamata al secondo come “ping” il sistema collasserebbe all’istante. Ma questo sarebbe eventualmente un problema che dovrebbe risolvere Google; il vero problema è che includere il tempo trascorso sull’ultima pagina porterebbe forse più danni che benefici.

Se guardo tre pagine e sto su ognuna 50 secondi, avere un tempo sul sito di 150 secondi è sicuramente più corretto che averne uno di 100, come invece ci direbbe GA. Ma questo vale solo nel caso in cui i tempi siano all’incirca tutti uguali. Se sto 50 secondi sulle prime due e poi 2000 secondi sulla tre, perché magari mi sono sono andato a bere un caffè e ho chiuso il browser solo al mio ritorno, porta ad avere un tempo totale di 2100 secondi e un tempo medio per pagina di 700 secondi. E vi garantisco che navigare con molte schede aperte (e molte dimenticate aperte) è ormai la norma, specie in ambito lavorativo.
Il sistema che usa Google Analytics e molti altri rinomati sistemi di WA non è il più accurato possibile, ma è il più vicino possibile a quello reale tenuto conto dei vincoli tecnologici odierni.

Come corollario al suo post, Brian dice che il blog di Clicktale usa per monitorare gli accessi anche Google Analytics (il che non è un problema, il detto dice “conosci il tuo nemico” 😉 ), ma che violano i termini del servizio perché includono informazioni personali (nome, cognome ed email) nei loro tracciamenti, informazioni che sono in grado di far risalire puntualmente a chi ha visto cosa e quando. Operazione che è espressamente vietata dalla TOS di Google Analytics.