Google Analytics in 30 secondi

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.

Vorrei ora sapere come interpretare il tempo medio espresso con numeri del tipo 14799878978102900… Cosa significa? E come convertirlo in un formato familiare?

Elisabetta sta usando gli export in CSV e TSV per riproporre su Excel i dati di Google Analytics, ma il formato non è molto malleabile. Mentre cercavo una soluzione per un attimo ho creduto di aver fatto una scoperta, ma era tardi e oggi tutto si è ridimensionato, ma affrontiamo un problema alla volta.

Importare correttamente CSV e TSV in Excel

Google Analytics esporta sempre i file dei report in formato inglese (anche se usate l’interfaccia in italiano), quindi usa i punti per separare i decimali, ma fortunatamente non le virgole per le migliaia. Importare direttamente tutto in un Excel “europeo” fa risultare il tempo medio (e in generale le cifre relative al tempo) in un numero come quello indicato da Elisabetta.

Una possibile soluzione è quella di impostare Excel nel formato inglese prima di importare i dati. Su Excel 2003: strumenti -> opzioni -> internazionale -> togliere la spunta da “utilizza separatori di sistema” e impostare il separatore decimale sul punto e quello delle migliaia sulla virgola. Bisognerà poi ricordarsi di rimettere tutto a posto prima di uscire, e comunque la modifica viene applicata a tutti i fogli Excel aperti e che si apriranno, per cui potrebbe non essere la soluzione ottimale.

L’altro metodo consiste nello scaricare il CSV o il TSV, aprirlo con un editor di testo e sostituire tutti i punti con delle virgole, poi salvare e importarlo in Excel. E’ un pochino laborioso, lo so, ma questo consente di non toccare le impostazioni e poter aprire e lavorare su altri file.
Usando questo metodo bisogna poi importare correttamente i dati: da Excel si seleziona il menu File -> Apri -> si seleziona il CSV o il TSV salvato precedentemente e si avvia la procedura. selezionare su un foglio vuoto di Excel, cliccare Dati -> importa dati esterni -> importa dati… e selezionare il file scaricato in precedenza. Nella finestra di dialogo che si apre la prima scelta da fare è dire che i campi sono delimitati, poi è necessario selezionare 65001: Unicode (UTF-8) nell’origine file, per evitare problemi con le lettere accentate. Nella schermata successiva il delimitatore va impostato su Tabulazione se avete per le mani un TSV, su Virgola se avete un CSV. L’anteprima dati vi aiuterà a capire se state facendo la scelta giusta. Nella terza schermata potete lasciare il formato dei numeri su generale e cliccare su Avanzate… per impostare il separatore decimale corretto, il punto e quello delle migliaia, la virgola. (grazie a Stefano per il suggerimento nei commenti )
(edit: esiste una terza via: scegliere “CSV per Excel. In questo caso non dovete specificare UTF-8 come codifica, e dovete lasciare la tabulazione come separatore, quindi l’unica cosa da impostare sono i separatori nella terza schermata. grazie Eloisa!)

A questo punto avrete il tempo medio espresso in secondi, con un numero tipo 47,0701754385964. Per riportarlo ad una forma più familiare è necessario dividere quel numero per 60 * 60 * 24 (cioé 86400) – magari copiandolo su un’altra colonna – e poi applicare il formato di cella personalizzato ore minuti secondi hh:mm:ss (che trasforma il numero di prima in 00:00:48)

La precisione dei dati in Google Analytics

Appena ho iniziato a fare prove per rispondere a Elisabetta ho preso un grosso abbaglio. Mi sono detto “come è possibile che Google Analytics conosca il tempo medio sulla pagina preciso fino al microsecondo?” (tra l’altro sbagliando, perché guardando il valore esatto nella barra della formula, non troncato dalla visualizzazione, sarebbe preciso oltre il picosecondo, 10^-12). Ovviamente la risposta è “non la conosce, ma essendo il tempo medio un valore calcolato con una frazione, possono esserci più decimali di quanti ce ne siano nei dati di partenza.

Voglio però farvi notare due cose: la prima è che nel database di Google Analytics – in questo caso, ma non vedo perché dovrebbe essere diverso su altri campi – le cifre non vengono troncate secondo quel che è necessario a Google per la visualizzazione dei report; potrebbe fare il calcolo e tenere il numero intero di secondi, o al massimo un paio di decimali, invece conserva decimali fino al tredicesimo e li converte al volo nel momento in cui l’interfaccia li mostra.
La seconda è che questo aspetto ci torna utile in altri campi: abbiamo detto che le percentuali che vediamo nell’interfaccia di GA sono arrotondate a due decimali, mentre nell’export di decimali ne abbiamo 15. Su grandi numeri il 65,711878 o il 65,7149999 potrebbero avere un significato diverso, anche se poi vengono entrambi arrotondati a 65,71%. Stesso discorso ad esempio guardando l’indice$ delle pagine: molte potrebbero avere 0,01 e sembrarci tutte uguali, ma avendo molti più decimali a disposizione su Excel siamo in grado di effettuare analisi più dettagliate.

Oltre al commento di Antonio, è un periodo che mi capita di leggere in giro domande sul tempo sul sito. Penso sia necessario ritornarci ancora una volta, perché è un concetto mai abbastanza ribadito, ed è importante comprenderlo fino in fondo:

Nel nostro mondo il tempo è un concetto lineare, lo impariamo sin da piccoli. Non è invertibile, scorre in un solo senso, ed ha intervalli di durata nota: un secondo, un minuto, tre ore, cinque giorni… Possiamo quasi sempre sapere quanto tempo occorra affinché una cosa accada, sia che debba ancora accadere sia che stia accadendo. Ad esempio quando rispondiamo alla domanda “tra quanto tempo tramonterà il Sole?” facciamo la differenza tra l’ora del tramonto e l’ora corrente. Quando invece proviamo a capire se nostro figlio sarà un campione di apnea iniziamo a contare quando immerge la testa sott’acqua e smettiamo quando risale paonazzo
Questi due esempi hanno qualcosa in comune: si basano sulla differenza tra due momenti distinti.

Nel mondo dei bit, e di internet in particolare, le cose sono leggermente più complicate: l’HTTP, cioè il protocollo attraverso il quale viaggiano le informazioni sul web, è un protocollo senza comunicazione di stato (stateless), e questo comporta il fatto che ogni richiesta che viene fatta “riparte da capo”, non ha memoria di ciò che è successo prima. Inoltre le richieste vengono in genere fatte dal browser e le risposte vengono date dal server, che chiude la comunicazione appena ha terminato il compito e aspetta la prossima richiesta, dello stesso o di un altro browser. In una ipotetica conversazione umana, le cose andrebbero all’incirca così:

browser1: “ciao server, sono Firefox dall’ip 1.2.3.4 e mi serve la pagina index.html”
server: “eccoti la pagina index.html”
browser2: “ciao server, sono Internet Explorer dall’ip 6.72.33.124 e mi serve la pagina index.html”
server: “eccoti la pagina index.html”
browser1: “ciao server, sono Firefox dall’ip 1.2.3.4 e mi serve la pagina contatti.html”
server: “eccoti la pagina contatti.html”

e così via. Nessuna frase inizia con “ti ricordi di me? ora mi servirebbe…”

Questo preambolo serve ad introdurre la frase centrale di questo post: che si usi un sistema basato su logfiles o su tag javascript, di ogni comunicazione viene registrata SOLO E SOLTANTO la data e l’ora di richiesta.

Da qui l’assunto numero due: per calcolare il tempo di stazionamento di un utente su una pagina, servono gli stessi dati che usiamo noi per calcolare la dimensione di un lasso temporale: servono almeno due orari. D’altronde i computer sono costruiti dagli uomini, e sanno solo fare meglio i calcoli

Se una persona non guarda due pagine, non sarà possibile sapere per quanto tempo è stata sull’unica che ha visto (ed ecco perché i bounce contano zero).
Se una persona guarda 6000 pagine, il calcolo sarà fatto su 5999, perché non è nota l’ora in cui è stata vista la pagina 6001, che non esiste.
Sarebbe come se – ipoteticamente – nel mondo reale un osservatore dovesse calcolare quanto tempo un uomo rimane dentro una stanza: ci rimane il tempo che intercorre tra l’ora in cui esce e l’ora in cui entra. Ma se questo uomo fosse in grado di teletrasportarsi altrove dopo essere entrato?
Analogamente al famoso gatto di Schrödinger un utente su una pagina può essere considerato sia come “visita ancora attiva” sia come “visita terminata”. L’equivalente dell’aprire la scatola per noi è la visita della pagina successiva.

Questo problema viene risolto dalla web analytics introducendo il concetto di “tempo della sessione”, ovvero un tempo solitamente configurabile – e per convenzione impostato a trenta minuti – entro il quale se non viene registrato un’altra data/pagina vista la visita viene considerata conclusa (in Google Analytics si usa la funzione _setSessionTimeout). Per continuare con l’analogia della stanza, è come se l’osservatore esterno di cui sopra avesse istruzioni di andarsene e non registrare nulla se la persona non esce dalla stanza dopo mezz’ora.

In conclusione ricordatevi una cosa: di ogni pagina si conosce esclusivamente il momento in cui l’utente inizia a guardarla… almeno fino a quando non ne guarda un’altra

image credits: Fabiola Medeiros su Flickr

Non conosco Brandt Dainow e non leggo il suo blog, però trovo parecchio interessante e condivisibile il post di “risposta” di Ian Thomas su “Lies, damned lies…”. Brandt asserisce che Google Analytics sbaglia le misurazioni (anzi, lo farebbe apposta) al punto che molte persone percepirebbero una situazione fortemente distorta rispetto alla realtà. Si concentra in particolar modo sul fatto che GA considera le visite di una sola pagina (i bounce, tanto per chiarire) come visite valide e le usa anche per calcolare la durata media delle visite.

Mi permetto di riportare i tre punti che Ian usa per smontare questa tesi:

• Esistono innumerevoli situazioni in cui è perfettamente legittimo che i visitatori guardino una sola pagina: il lettore tipico di blog, che consulta la homepage e va via se non ci sono aggiornamenti, o chi clicca su un articolo da un feed rss e lo legge. Tagliare via tutte queste visite sarebbe da pazzi
• Sebbene l’inclusione di queste visite nel calcolo del tempo medio sia un problema conosciuto, escluderle non lo risolverebbe ma semplicemente lo sposterebbe altrove: non si avrebbe un numero “più accurato” ma un numero “inaccurato in altra maniera”. Non si avrebbe comunque modo di conoscere il tempo di permanenza sull’ultima pagina, e questo si rifletterebbe in una scarsa accuratezza del dato in presenza di una visita di due pagine
• Il tipo di metrica che produce GA è il risultato di lunghi studi e discussioni (e peraltro è aderente agli standard della Web Analytics Association); c’è bisogno di una forte motivazione per cambiare una metrica semplice e facile da capire con una più complicata che non apporta sostanziali miglioramenti

Sono personalmente d’accordo al cento per cento con Ian, e non solo perché questo blog tratta di Google Analytics. Non difendo nessuno a priori e quando ne ho occasione mostro anche i limiti di GA, ma non mi sembra questo il caso: particolarmente significativa la frase “Quando, come industria, non siamo d’accordo su cosa costituisca esattamente una visita, è facile accusare questo o quel sistema di non essere accurati semplicemente perché non si ha fiducia nell’approccio che essi hanno nei confronti dei dati“. Che non esista un tool perfetto e universale lo sappiamo tutti (e se non lo sapete lo ripeterò ancora una volta), il problema è che bisogna trovare un tool di cui fidarsi. Bisogna studiare, conoscere, chiedere e provare, e poi scegliere di conseguenza. Possibilmente verificando l’aderenza del prodotto con i famosi standard della WAA.

Volevo approfittare di questo post per fare un’altra considerazione: Ian Thomas lavora in Microsoft, e faceva parte del team di adCenter Analytics (il sistema di analisi che prima si chiamava Gatineau), ma nonostante questo difende GA, che è comunque un suo competitor. E’ un comportamento molto onesto che ritrovo spesso nel web, in maggior parte negli Stati Uniti dove c’è una cultura migliore del mercato e della concorrenza, ma che mi sembra ancora più accentuato quando si guarda al settore della Web Analytics. Io penso che la ragione sia da ricercare nel grande fermento che lo sta attraversando e dal relativo nuovo interesse che vedo nascere intorno alla web analisi (di pochi giorni fa la discussione “la web analytics è a prova di crisi?” di Eric Peterson su Web Analytics Demystified). Non sono abbastanza dentro al settore per definirla una “seconda giovinezza”, ma credo che le aziende si stiano rendendo conto che c’è bisogno di analisi, e che le analisi sono un investimento e non un costo, spesso un investimento che permette di tagliare con senso altri costi. Voi cosa ne pensate?

[image credit Morning Glory on Flickr]

Uno dei possibili parametri per definire delle KPI (Key Performance Indicator) su un sito è il tempo trascorso dai visitatori sulle nostre pagine. Questo dato è presente in Google Analytics, ed è conforme agli standard della Web Analytics Association, ma spesso noto molta confusione nell’interpretazione dei report relativi. Cercherò di farvi capire come funziona con esempi pratici:

La domanda tipica che mi sento rivolgere è all’incirca questa: “perché nella bacheca GA mi segna un certo tempo medio sul sito e nel dettaglio contenuti un altro?” (vedi la figura sotto)

La risposta secca è: perché il primo valore è la media del tempo sul sito, il secondo è la media delle medie del tempo su ogni singola pagina.
Google Analytics calcola il tempo su ogni pagina tramite la differenza tra il timestamp (preciso al secondo, calcolato in UNIX time) di ogni pagina meno il timestamp della pagina precedente. E di conseguenza il tempo sul sito è il timestamp dell’ultima pagina visitata meno il timestamp della prima.
Chiariamo con una schema: Continua a leggere “Comprendere appieno il tempo sul sito”