Google Analytics in 30 secondi

Mi è giunta un paio di volte la domanda riguardante la differenza tra exit rate e bounce rate, in varie forme. Riassumo qui: la percentuale di uscita, calcolata per pagina, è la percentuale di visite che terminano con la visione della pagina analizzata. Il tasso di rimbalzo, calcolato sempre per pagina, è la percentuale di visite che iniziano e terminano con la visione della pagina analizzata (e infatti va guardato dal report “pagine di destinazione” e non da “contenuti principali”, se vi ricordate)

Non molto tempo fa lunametrics ha scritto un post a riguardo con alcuni chiarimenti relativi proprio a questo settore, che vi riporto per comodità e completezza:

1. Nel riepilogo navigazione, le uscite includono i rimbalzi? si. se fate un filtro avanzato che includa solo pagine viste = 1, tasso di rimbalzo = 100% e % uscita = 100% avrete una lista di pagine che corrisponde sempre a quelle che nel riepilogo navigazione sono seguite dalla voce “uscite”
2. I rimbalzi e le uscite sono calcolati separatamente? Le uscite includono i rimbalzi, l’abbiamo detto prima. I rimbalzi non sono altro che un sottoinsieme delle uscite: non solo l’utente è uscito da quella pagina, ma è anche entrato da lì
3. Le uscite implicano il fatto che vi sia una pagina vista prima? no, ma se volete possiamo pensare a due tipi di uscite: quelle che hanno visto un’altra pagina prima durante la visita, e quelle che non l’hanno fatto. La seconda categoria ha un nome speciale: rimbalzi
4. Se le uscite includono i rimbalzi, come posso avere tasso di rimbalzo 100% e % uscita 50%? facciamo un esempio pratico con quattro visite: la prima atterra ed esce dalla pagina che prendiamo in considerazione, la seconda e la terza vi transitano solamente, la quarta arriva da pagine precedenti ma termina la visita sulla nostra pagina.

   - visita uno: un rimbalzo (che è anche un’uscita)
   - visita due: né rimbalzo né uscita
   - visita tre: né rimbalzo né uscita
   - visita quattro: un’uscita

   il tasso di rimbalzo per la pagina è 100%, perché l’unica volta che la pagina è stata la prima della visita è stata anche l’ultima. La percentuale di uscita è del 50%, perché due visite (la prima e la quarta) sono uscite dopo aver visto questa pagina, che però è stata vista in totale quattro volte: 2/4 = 50%

La domanda che mi fa Francesca in un commento è semplice:

Ciao!
La mia è più che altro una curiosità:
ma se inserisco due volte lo stesso identico codice in una pagina cosa succede? Raddoppiano tutti i dati??

La risposta avrebbe dovuto essere abbastanza semplice, ma siccome avevo tempo ho messo su un piccolo esperimento per avere più dati. All’inizio, lo ammetto, ero sconcertato; poi mi sono accorto di un mio errore e la cosa è tornata ad avere un senso.
La situazione, piuttosto atipica invero, è quella in cui lo stesso identico codice di monitoraggio è presente due o più volte sulla stessa pagina. Potrebbe essere perché due persone differenti lo hanno inserito – magari uno in header e uno prima di /body – o perché si sta usando un plugin automatico ma il codice era già stato messo a mano nel template. Quali che siano le ragioni, Google Analytics non effettua nessun tipo di controllo su questa casistica, quindi i javascript vengono eseguiti entrambi e i dati vengono inviati due volte.

Questo però non si traduce in un raddoppio totale di tutti i dati. O meglio, raddoppiano solo i dati che ha senso siano doppi, quelli che tecnicamente potrebbero effettivamente derivare da una situazione di quel tipo. Ad esempio le visite non raddoppiano, perché una visita ha una durata predefinita di trenta minuti. Il fatto che in in una frazione di secondo vengano viste due pagine non intacca il concetto di sessione, per cui le due esecuzioni del GATC sono attribuite correttamente alla visita giusta. Raddoppiano invece le pagine viste, poiché vi sono due chiamate alla funzione trackpageview(). Queste chiamate, tra l’altro, avvengono a una frazione di secondo di distanza l’una dall’altra, per cui non falsano il tempo medio trascorso sulla pagina. Falsano invece, e di molto, il bounce rate. Poiché un bounce è una visita di una sola pagina vista, se sono presenti due codici di monitoraggio sulla pagina, ogni visita sarà composta sempre di almeno due pagine viste, per cui il vostro sito avrà un bounce rate dello 0%.

Il modo più semplice per accorgervi di un errore simile è appunto quello di guardare il bounce rate. se è zero o siete bravissimi o potete avere un errore di questo tipo. Un altro modo, meno immediato, è quello di guardare la pagine viste: con un doppio codice esse non possono mai essere in numero dispari

Ecco un interessante (anche se un po’ datato) post su e-nor.com a proposito dell’interpretazione del bounce rate nel report “contenuti principali”. A prima vista infatti la frequenza di rimbalzo nella relativa colonna potrebbe essere interpretata come una percentuale della colonna “pagine visualizzate”, soprattutto ad un neofita che non ricorda l’assioma secondo cui il bounce rate (i rimbalzi, appunto) è una metrica per le visite e non per le pagine viste. Anzi, per dirla come l’autore del post (da cui trarrò traduzioni letterali):

“Bounce rate is the percentage of single-page visits in which the person left your site from the entrance (landing) page,” by Google Analytics.
“Single page view visits divided by entry pages,” by the Web Analytics Association.

“La frequenza di rimbalzo è la percentuale di visite di una sola pagina in cui una persona ha abbandonato il vostro sito dalla stessa pagina di atterraggio”, definizione di Google Analytics.
“Visite di una sola pagina vista diviso pagine di ingresso”, secondo la Web Analytics Association.

Il problema dell’autore del post diventa evidente quando si guarda alla pagina di conferma di un ordine in un sito e-commerce e questa ha un bounce-rate del 100%. La pagina in questione non dovrebbe generalmente essere una pagina cui si può arrivare direttamente, e dovrebbe altrettanto generalmente essere l’ultima di un percorso che ha almeno due pagine viste: ordine e ringraziamento, quando non anche il pagamento.
Le spiegazioni per questo fenomeno possono essere molteplici:

- The thank you page was bookmarked by the visitor for future reference.
- The visitor hit the refresh button on the non-landing page window after 30 minutes of no activity.
- A direct visit to the non-landing page by developers/site owner. Excluding the internal traffic will solve this one.

- La pagina di ringraziamento è stata messa nei segnalibri dall’utente.
- Il visitatore ha premuto il tasto di refresh su quella pagina dopo più di mezz’ora di inattività (nuova sessione).
- Una visita diretta a quella pagina da parte di chi conosce il sito (proprietario/sviluppatore) in un contesto in cui il traffico interno non viene filtrato.

Sostanzialmente, quindi, guardare alla frequenza di rimbalzo nel report “contenuti principali” è fuorviante, e sarebbe meglio farlo nel report “pagine di destinazione principali”. Potete rendervene conto da soli guardando una riga del report “contenuti principali”, ad esempio nel mio caso la pagina /about/: 121 pagine viste (98 PV uniche), 50% secco di bounce rate; a parte il fatto che la metà di 121 è 60,5 e la mezza visita non esiste, il problema si risolverebbe dicendo in italiano che “la metà di 121, cioè 60, pagine viste sono rimbalzi”. Non regge. Ma in ogni caso è ugualmente sbagliato fare quel calcolo. La colonna ci dice che il 50% di coloro che sono arrivati direttamente su quella pagina hanno poi abbandonato il sito. E quanti sono giunti direttamente su quella pagina? lo scopriamo guardando il report “pagine di destinazione principali”, ove leggo: 6 entrate, 3 rimbalzi, 50% frequenza di rimbalzo. Così quadra, e 3 è ben diverso da 60 non vi pare?

Ho letto questa notizia su tre diversi blog, ma ho aspettato a segnalarla finché non è apparsa su una fonte che ritengo autorevole: Google ha modificato il modo in cui conteggia i bounce rate in presenza della funzione _setVar(). [edit: ecco il post sul blog ufficiale | e in italiano]

Fino ad oggi se un visitatore guardava una sola pagina, non veniva conteggiato come bounce se nella stessa pagina chiamavate la funzione _setVar(), che serve ad attribuire il visitatore ad un segmento personalizzato tramite scrittura del cookie aggiuntivo __utmz. Infatti per ovviare a questo problema Lunametrics aveva proposto un workaround che vi segnalai a tempo debito.

Da oggi questo fatto non è più vero, e una visita di una sola pagina vista sarà considerata un bounce a prescindere dalla presenza della funzione. Tra le altre cose questa modifica si rifletterà anche sul tempo medio sul sito e sulla pagina, poiché in presenza di due timestamp GA è in grado di calcolare un tempo, cosa che invece ovviamente non può essere vera per un utente che rimbalza. In precedenza invece Analytics assegnava tempi brevissimi (zero, uno o due secondi, a seconda della velocità di caricamento della pagina e del tempo trascorso tra la chiamata a _trackPageview() e _setVar() ) alla pagina.

Da quel che ho capito, il comportamento non cambia in presenza di un evento, come scrissi in questo post

Image credit: Greencolander on Flickr

Immeria riporta un’altra testimonianza del fatto che Google sta attivando le funzioni di tracciamento degli eventi progressivamente su tutti gli account, come vi dicevo nel post precedente.

In aggiunta a quanto vi ho riportato bisogna dire che il numero di eventi registrabili è limitato a 500 per ogni sessione di visita. Se tramite gli eventi tracciate l’uso di un video probabilmente non avrete problemi, per altri usi più particolari potrebbe rappresentare un ostacolo ed è una cosa di cui tenere conto.
Inoltre se un evento viene creato e inviato ai server collettori durante la visione della prima pagina di una visita, quella visita non verrà mai conteggiata come un bounce anche se poi la visita si concluderà. In sostanza una visita di una sola pagina vista, se contiene un evento tracciato, non è più un bounce.

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]