Google Analytics in 30 secondi

E nemmeno si sottraggono, se è per quello!
Qualche giorno fa una persona mi ha chiamato in chat per sottopormi un problema su Google Analytics. Dato un insieme di contenuti, intesi come URL, essi avevano un certo bounce rate (diciamo 80% per semplificare). Dato un loro sottoinsieme, esso aveva un altro bounce rate (60%), ma l’insieme complementare non aveva un bounce del 20%. Ci siamo, Google Analytics sbaglia i calcoli!

No, niente paura: il bounce rate, ve lo ricordo, è l’espressione di una frazione che ha al denominatore il numero di ingressi su una data pagina (o insieme di pagine, o sito) e al numeratore il numero di bounce, cioè visite che non hanno proseguito con l’apertura di una ulteriore pagina. Già che siamo in vena di preamboli, vi ricordo anche che l’unico posto sensato in cui il bounce rate va guardato è il report “pagine di destinazione” e NON “contenuti principali”.

Bene, torniamo a noi: innanzitutto il bounce rate del sito non è la somma dei bounce rate delle singole pagine, e non ne è nemmeno la media; è un numero calcolato prendendo i rimbalzi di tutto il sito diviso il numero di ingressi (o di visite, se preferite, dato che ogni visita rappresenta certamente almeno un ingresso). Non essendo una somma fatta e finita, non essendo “countable” come direbbero gli inglesi, non si può pensare di fare sottrazioni o altre operazioni su questo numero. Il bounce rate viene calcolato “al volo” una volta che è noto l’insieme di pagine di riferimento, il numero di volte in cui esse sono state la prima pagina di una visita e il numero di volte in cui esse sono state anche un rimbalzo.

Ma andiamo avanti e vediamo un paio di casi pratici estremizzati:

• ho un sito di due sole pagine: la pagina A ha bounce rate 100%, la B 50%. Il bounce rate del sito di sicuro non è 150%. E non è detto nemmeno che sia 75%, questo è un fatto che dipende esclusivamente da due informazioni che al momento non abbiamo. Se ad esempio la pagina A avesse 4 ingressi e 4 rimbalzi (100% di bounce rate, appunto) e la pagina B 8 ingressi e 4 rimbalzi (50%), il bounce rate del sito sarebbe 8/12 = 66,67%. Se la pagina A avesse ugualmente 4 ingressi e 4 rimbalzi (100% di tasso di rimbalzo) e la B 100 ingressi e 50 rimbalzi (sempre 50%), il bounce rate del sito sarebbe 54/104 = 51,92%. Se ancora tenendo costante la pagina A, la pagina B avesse 2 entrate e 1 rimbalzo (ancora 50%), il totale del sito sarebbe 5/6 = 83,33%.
• Per una combinazione BRAND + KEYWORD Analytics mi dice che ho 100 pagine. Esse totalizzano 1 solo rimbalzo. Bounce rate per questo insieme 1%, facile. Il sottoinsieme di pagine relativo alla sola KEYWORD contiene 30 pagine, e nessuna di esse è un rimbalzo, quindi bounce rate 0%. Il sottoinsieme di pagine relativo al solo BRAND contiene allora 70 pagine, e una di esse deve essere un rimbalzo. Tasso di rimbalzo 1/70 = 1,42%, addirittura superiore al bounce rate dell’insieme più ampio.

I casi estremi servono ovviamente a piegare gli esempi per nostra praticità, ma spero sia chiaro il funzionamento di Google Analytics, e dei sistemi di web analytics che in generale utilizzano la metrica “bounce rate”: il tasso di rimbalzo viene calcolato SEMPRE sulla base di visite e numero di rimbalzi, e ogni insieme fa storia a sé. Cambiato un solo parametro dell’insieme, sezionato, segmentato, variato o diviso, il bounce rate va ricalcolato per il nuovo insieme, non si può derivare dal numero precedente.

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]