Google Analytics in 30 secondi

M’è passato sotto agli occhi questo post di edynamic: The Four Most Confusing Metrics in Google Analytics e ho pensato che valesse la pena di riprenderlo, anche se parla di cose che negli anni ho già affrontato su questo blog.

Le prime due metriche interessate sono il bounce rate e l’exit rate (tasso di rimbalzo e tasso di uscita, in italiano): le definizioni per queste due metriche sono:

• Bounce rate: una visita che non fa registrare una seconda pagina, o un evento (che non sia classificato come “non interattivo” tramite apposito settaggio).
• Exit rate: l’ultima pagina vista di ogni sessione.

Le differenze principali sono che per esserci un bounce la visita deve iniziare e concludersi nella stessa pagina, quindi è una condizione che può verificarsi oppure no, mentre una sessione deve necessariamente terminare da qualche parte, quindi una exit page c’è sempre.

Vi pregherei di non considerare i calcoli successivi nel post originale, perché sono effettuati su un assunto sbagliato 🙂
Nel caso descritto nel loro esempio, che riporto qui

Session 1: Page A > Page B > Page C > Exit

Session 2: Page B > Page C > Page A > Exit

Session 3: Page C > Page B> Page A > Exit

Session 4: Page A > Exit

i calcoli corretti sono:
– Il bounce rate della pagina A è 50% (1 bounce – la quarta sessione – su 2 sessioni in cui era landing page)
– Il bounce rate della pagina B è 0% (0 bounce su 1 sessione in cui era landing page)
– Il bounce rate della pagina C è 0% (0 bounce su 1 sessione in cui era landing page)

– L’exit rate della pagina A è 75% (è stata l’ultima pagina in 3 sessioni su 4)
– L’exit rate della pagina B è 0% (non è mai stata l’ultima)
– L’exit rate della pagina C è 33% (è stata l’ultima in una sessione su 3 in cui è stata vista)

In ogni caso ne avevo parlato circa cinque anni fa

Le altre due metriche che generano confusione sono il tempo sulla pagina e il tempo sul sito: il tempo sulla pagina è il tempo trascorso su ogni pagina, calcolato come la differenza tra il momento in cui il sistema sa che stiamo facendo “cose” su una pagina (apertura di pagina, eventi sulla pagina) e il momento in cui è stata aperta la pagina precedente. Inoltre, quando si calcola il tempo sulla pagina, Google Analytics non include le visite che hanno fatto dei rimbalzi, che abbasserebbero drasticamente la media.

Con esempi pratici, sempre presi dal post e corretti per non generare confusione (ipotizziamo non ci siano eventi in questo tracciamento):

Session 1: Page A (30 seconds) > Page B (60 seconds) > Page C > Exit

Session 2: Page A > Exit

Session 3: Page A (20 seconds) > Page B > Exit

– Il tempo medio sulla pagina A è 25 secondi (30+20 diviso 2, perché i bounce non contano).
– Il tempo medio sulla pagina B è 60 secondi (60 diviso 1, perché quando una pagina è l’ultima non si può calcolare il tempo sulla pagina. Diverso sarebbe se ci fossero eventi sulla pagina)
– Il tempo medio sulla pagina C è di 0 secondi.

Il tempo medio sul sito usa lo stesso principio, ma sottrae il momento dell’ultima hit arrivata dal momento della prima hit della sessione. Esso include i bounce, ma tanto quanto prima non può includere il tempo sull’ultima pagina (sempre escludendo gli eventi).
Se prendiamo l’esempio di prima, il tempo medio sul sito è 37 secondi (30+60+20 diviso 3).

Di questo ne abbiamo parlato addirittura nel 2008, accidenti se è anziano questo blog 😉

Questo post vale un po’ come aggiornamento del vecchio post “comprendere in pieno il tempo sul sito“, ed è in realtà una traduzione pressoché totale di un post di Justin Cutroni: lo faccio perché è spiegato bene ed è esaustivo sulla vicenda:

Capire le “engagement hits”

La chiave per comprendere come GA calcoli gli intervalli di tempo è capire i dati che vengono inviati a Google. Ci riferiamo a loro affettuosamente come “HITS”. Lo so, è un termine terribile da usare quando si parla di web analytics, ma sono proprio hits.
Le hits in Google Analytics sono le richieste alla __utm.gif. Ce ne sono sei diversi tipi possibili:

• Pagine viste
• Eventi
• Transazioni Ecommerce
• Singoli prodotti Ecommerce
• Dati definiti dall’utente (gli antesignani delle variabili personalizzate)
• Richieste generate dai social plugin

Sebbene queste siano tutte le possibili richieste, non tutte sono “engagement hits”. Con questo termine ci si riferisce a richieste non contrassegnate come “non interattive” e non contenenti esclusivamente dati definiti dall’utente. Filtrando la lista di prima con questa nuova informazione, ci ritroviamo con cinque tipi di engagement hits:

• Pagine viste
• Eventi che non siano non interattivi
• Transazioni Ecommerce
• Singoli prodotti Ecommerce
• Richieste generate dai social plugin

Ti starai domandando “e questo che c’entra con i calcoli sul tempo?” Molti sistemi di web analytics usano il tempo trascorso tra le pageviews per tracciare il tempo. Google Analytics usa gli engagement hits per avere un quadro più dettagliato e preciso del tempo sulle pagine e sul sito.

come è calcolato il tempo sulla pagina
Il tempo sulla pagina è calcolato in due differenti modi, e il calcolo dipende dal fatto che la visita abbia una sola o più pagine viste

Quando ci sono più pagine viste
è piuttosto facile da capire, il calcolo è basato sulla differenza di timestamp tra la richiesta alla pagina successiva e quella corrente. Ad esempio

facile no? Molti sistemi di web analytics lavorano in questo modo, ma questo porta a qualche problema: non possiamo calcolare il tempo sull’ultima pagina, perché non ce n’è una successiva da cui sottrarre il timestamp. Ma di questo ne parliamo dopo.

Quando c’è una sola pagina
Molte persone credono che Google Analytics non possa calcolare, e non calcoli, il tempo trascorso sulla pagina quando essa è l’unica della visita; questo è solo parzialmente corretto. Se non c’è un’altra pagina vista nella sessione, Analytics usa il tempo trascorso tra l’apertura della pagina e l’ultimo engagement hits che segue quella pagina vista.

Tempo sulla pagina = timestamp dell'ultimo engagement hit sulla pagina - timestamp della pagina

Chiariamo, se una visita è di una sola pagina, Google Analytics può calcolare il tempo su quella pagina usando (se ci sono, ndMC) altri engagement hits. Se aggiungete molteplici engagement hits alla pagina, avrete una misurazione più accurata del tempo sulla pagina e sul sito, come mostrato ad esempio nella seguente figura:

Come è calcolata la lunghezza della visita
Anche la lunghezza totale della visita usa gli engagement hits per avere numeri più accurati. Invece di usare il solo tempo tra i timestamp delle pagine, la misurazione del tempo totale di una sessione include il tempo trascorso tra il timestamp della prima pagina vista (la landing page) e il timestamp dell’ultimo engagement hit disponibile nella sessione.

Tempo sul sito = timestamp dell'ultimo engagement hit della visita - timestamp della prima pagina vista

Vediamo un esempio reale: qui sotto abbiamo 3 pagine in una visita. Normalmente, se contassimo la lunghezza della visita basandoci solo sulle pagine viste ci perderemmo il tempo trascorso sull’ultima pagina. Ma siccome c’è un evento su di essa (e un evento E’ un engagement hit, ndMC) possiamo avere una fotografia più completa.

E’ importante sottolineare che in questo esempio Google Analytics userà l’engagement hit anche per calcolare il tempo trascorso sulla pagina di uscita. Nell’immagine #1 non era invece possibile perché non c’era nessun engagement hit dopo l’apertura di pagina 3. Nell’immagine #3 invece c’è un engagement hit sulla pagina di uscita, quindi GA è in grado di usare quel pezzo di informazione per calcolare il tempo.

E ricordate, ci sono anche altri engagement hits, come ad esempio le transazioni ecommerce, che possono essere ugualmente usate per calcolare più precisamente la lunghezza di una visita.

“GA sarà quasi in real-time” è una delle mie tre previsioni per il 2010 di Google Analytics, fatte per gioco a inizio anno. Effettivamente una o due volte al mese mi capita di tornare sull’argomento con clienti o attraverso le vostre email.

Direi che ci ho preso, almeno a giudicare da questo screenshot di un mio profilo

e da quanto dice Avinash rispondendo alla prima domanda della web analytics TV episodio #7

alle 15:58 erano già visibili due visite delle ore 15, e Avinash dice che – sebbene ancora non per tutti i profili – per alcuni la velocità di analisi dei dati è stata aumentata. Come ho detto nel post di previsioni, ritengo difficile che si arrivi al real-time completo, ma per ora l’incremento mi sembra non trascurabile.

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)

(valori di tempo sul sito in GA)

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”