Aug 11 2012

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Exit rate e bounce rate

autore: Marco Cilia categoria: report tag:

C’è un buon articolo dell’help che spiega la differenza tra tasso di uscita e tasso di rimbalzo, e siccome in poco tempo mi sono capitate due domande in proposito, ve lo riassumo e traduco qui dato che in italiano non è ancora disponibile (avevo già comunque parlato della questione anni fa)

Molte persone pensano che siccome il tasso di uscita è basato sull’ultima pagina vista, esso dovrebbe essere almeno uguale al bounce rate, che tratta le visite in cui vi è una sola pagina (la prima e l’ultima). In realtà la cosa è leggermente diversa, poiché il tasso di uscita è la percentuale di pagine viste in cui la pagina oggetto è stata l’ultima della sessione, mentre il bounce rate è la percentuale di visite in cui la pagina in oggetto è stata l’unica della sessione.
Inoltre come dovremmo sapere benissimo, il tasso di rimbalzo è calcolato soltanto sulle visite che iniziano sulla pagina oggetto.

Chiariamo prima di tutto quest’ultimo punto, con un esempio: sito di 3 pagine, 1 sola visita al giorno
Lun: Page A > Page B > Page C
Mar: Page B > Page A > Page C
Mer: Page A > exit

Il report dei contenuti per la pagina A mostrerà 3 pagine viste e un tasso di rimbalzo del 50% (quante volte è landing page? 2. quante volte la visita non prosegue? 1. quindi 50%).

Modifichiamo l’esempio così

Lun: Page B > Page A > Page C
Mar: Page B > Exit
Mer: Page A > Page C > Page B
Gio: Page C > Exit
Ven: Page B > Page C > Page A

Il tasso di uscita è
Page A: 33% (la pagina A fa 3 pageview, di cui una è l’ultima della sessione 1/3=33%)
Page B: 50% (la pagina B fa 4 pageview, di 2 sono le ultime della sessione 2/4=50%)
Page C: 50% (la pagina C fa 4 pageview, di 2 sono le ultime della sessione 2/4=50%)

Il bounce rate invece è:
Page A: 0% (è landing page 1 volta – Mercoledì – ma la visita continua)
Page B: 33% (è landing page 3 volte, e 1 volta la visita finisce lì. 1/3=33%.)
Page C: 100% (è landing page 1 volta – Giovedì – ma la visita finisce lì)

Tra le due metriche quindi non c’è nessuna relazione, dato che sono calcolate in modo separato basandosi su presupposti diversi. Exit rate guarda alle pageview, tasso di rimbalzo alle visite.


Jul 25 2012

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

Dovrei usare il bounce rate accomodato?

autore: Marco Cilia categoria: javascript tag: , ,

Bounce rate “accomodato” è la mia traduzione per “adjusted bounce rate”, come lo chiamano su questo post del blog ufficiale di Google Analytics. Si tratta di un escamotage per evitare di considerare come rimbalzi visitatori che trascorrono più di tot tempo sulla pagina di atterraggio.

In pratica si aggiunge una funzione javascript che trascorso un intervallo di tempo predefinito spara un evento, che essendo una hit di engagement annulla il bounce rate. Il codice di base delle pagine diventerebbe quindi


var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXXX-1']);
  _gaq.push(['_trackPageview']);
  setTimeout("_gaq.push(['_trackEvent', '15_seconds', 'read'])",15000);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

bounce rateA seconda di quanti millisecondi utilizzerete nella vostra implementazione, il vostro bounce rate si abbasserà in modo maggiore o minore.

Ma ragioniamo un attimo su quel che succede:
Normalmente un visitatore atterra su una vostra pagina, e se non compie nessuna azione (cioè se non invia nessun’altra engagement hit), viene considerato un bounce; questo naturalmente può accadere sia se il visitatore trascorre sulla pagina 3 secondi, sia se invece ci resta 5 ore. L’esempio della pagina super ottimizzata del ristorante, che trovo al primo colpo su Google e che contiene anche il numero di telefono, quindi soddisfa in pieno il mio desiderio (e magari si mangia pure bene, e anzi come dice sempre Francesco de Francesco – magari poi ci torno per il matrimonio e gli porto un incasso di seimila euro, e lui vede un bounce! :) ), è perfetta. E’ una pagina che è naturale abbia un alto tasso di rimbalzo, almeno per il segmento di visite organico.

Bene, abbiamo detto quindi che non sappiamo quanto tempo sia stato effettivamente sulla pagina, e benché meno sappiamo se la pagina l’ha letta davvero oppure no!

Implementiamo allora il bounce rate accomodato, e consideriamo bounce solo chi va via prima di 15 secondi. Questo cosa mi dice più di prima? quanti stanno più di 15 secondi, ovvio. Ma è in grado di cambiare la vera informazione che mi servirebbe, cioè se la pagina è stata letta o no? assolutamente no! se uno non la legge, può non leggerla in 8 secondi, ne in 32, ne in 4 ore (perché ha lasciato il browser aperto ed è andato in riunione).

Non sto dicendo che il metodo sia da evitare a tutti i costi, sia chiaro: dico solo che va utilizzato per la reale informazione che mi da, cioè una modifica del tempo sulla pagina; ma trascorrere più tempo sulla pagina non significa che è stata compiuta un’azione!
Se proprio volessimo fare degli aggiustamenti, allora punterei di più sul sistema di Justin Cutroni per tracciare lo scroll della pagina (parte 1parte 2), magari in una sua forma alleggerita per sparare l’evento antibounce allo scroll della pagina, che mi sembra una azione molto più del trascorrerci più di 15 secondi.


Jun 13 2012

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Colonna “accessi” nel report dei contenuti

autore: Marco Cilia categoria: generale tag: ,

Da qualche giorno nel report delle pagine principali, all’interno della sezione dei contenuti, è comparsa la colonna delle metriche ACCESSI. In realtà è equivalente a dire visite, ma siccome è riferito alle landing page lo chiamano così. Il problema è che in realtà non siamo nel report delle landing pages, delle pagine di destinazione, ma nel report dei contenuti. E quindi?

E quindi questa è la risposta sbagliata ad un problema che esiste da sempre: la frequenza di rimbalzo nel report dei contenuti non è riferita al numero di pagine viste di ogni pagina, ma al numero di volte in cui quella pagina è stata la prima di ogni visita; una landing page, appunto. Questa cosa l’avevo già evidenziata tempo fa, auspicando che la metrica “frequenza di rimbalzo” fosse rimossa da quel report; l’unico posto sensato in cui guardare la frequenza di rimbalzo è infatti il report delle landing page.

Il team di Google invece ha deciso di perseguire la strada contrario, mettendo la metrica accessi nel report dei contenuti: esattamente l’opposto di quanto sperato. Per fortuna si può sempre ovviare con un custom report…


Nov 16 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Rinnovato il report “Landing pages”

autore: Marco Cilia categoria: report tag: , ,

Daniel Waiseberg su searchengineland porta alla nostra attenzione il fatto che il report delle pagine di destinazione è stato da poco rinnovato. Fino a poco tempo fa esso presentava una lista di pagine che sono state le prime di ogni visita nel periodo temporale selezionato e le incrociava con tre metriche: Entrate, Rimbalzi e % di rimbalzo.
Come sanno all’incirca tutti quelli con cui ho avuto modo di parlarne, quello era l’unico report dove aveva senso guardare la frequenza di rimbalzo, per evitare di incorrere in un errore piuttosto diffuso: applicare la percentuale alle visite anziché alla metrica entrate.

Il nuovo report invece presenta le metriche più classiche dei report dei contenuti: pagine/visita, tempo medio sul sito, % nuove visite e frequenza di rimbalzo. Questo ci dà delle informazioni maggiori sull’engagement dei visitatori con il nostro sito, perché è sempre vero che la visita da qualche pagina deve iniziare; inoltre sono state aggiunte al report anche le tab dei GOAL e dell’ECOMMERCE, per cui è possibile segmentare i risultati ottenuti senza fare altro: ogni landing page avrà un certo tasso di conversione globale e per obiettivo, e ci dirà quanti introiti hanno generato le visite che da lì sono iniziate. Niente che non si potesse fare anche prima con segmenti e custom report, ma negli ultimi tempi Google Analytics si sta anche concentrando nell’uniformare e rendere più facili da trovare le informazioni. Meno clic per tutti.

Quel che non mi va giù, tuttavia, è che io trovato utile anche il report precedente; me lo sono ricostruito molto brevemente con un custom report, ve lo condivido per comodità: http://goo.gl/LP6vg. Con un po’ più di cura si potrebbero unire il precedente e l’attuale usando due schede.


Oct 21 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Usare eventi che non influenzino il bounce rate

autore: Marco Cilia categoria: funzioni tag: ,

Un evento su Google Analytics è una azione che l’utente compie sul sito e che non è connessa al caricamento di una pagina. Essendo una azione, essa influenza il bounce rate, per cui se un visitatore atterra su una pagina, ed è l’unica della sua sessione esso sarà un bounce. Se però su quella stessa pagina viene “sparato” un evento, fino ad oggi la visita non risultava nei bounce.

Dall’ultima release del file ga.js – del 17 ottobre – è stato introdotto un nuovo parametro nella funzione _trackEvent: questo parametro si occupa di definire se l’evento inviato deve o non deve influenzare il bounce rate. Il nuovo parametro è opzionale e si posiziona alla fine della chiamata alla funzione, così che non dobbiate modificare nulla se non i soli eventi che volete rendere ininfluenti ai fini del bounce rate. La nuova funzione _trackEvent nella sua forma completa ha questa forma:


_gaq.push(['_trackEvent', 'category', 'action', 'opt_label', opt_value, opt_noninteraction]);

dove opt_noninteraction è un valore a scelta tra false (cioè “questo evento influenza il bounce rate”) e true (“questo evento non influeenza il bounce rate”).

Ovviamente il tutto ha senso solo sulla PRIMA pagina vista di ogni vista, l’unica dove si può realizzare un bounce, perché dalla seconda in poi la visita non sarà più un rimbalzo, eventi o meno…


Jul 15 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

I bounce rate non si sommano! mai!

autore: Marco Cilia categoria: web analytics tag:

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.


Nov 30 2009

Exit rate e bounce rate

autore: Marco Cilia categoria: report tag:

bounceballMi è 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%


Jun 02 2009

Ho messo due volte lo stesso codice! E ora?

autore: Marco Cilia categoria: javascript tag: , , ,

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 :)


May 18 2009

Il rimbalzo nel report “contenuti principali”

autore: Marco Cilia categoria: report tag: , ,

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?


Jan 28 2009

Il vostro bounce rate salirà, ma niente panico!

autore: Marco Cilia categoria: generale tag: , ,

Bounce by GreencolanderHo 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