Jan 06 2016

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

Sessioni, utenti, conversion rate

autore: Marco Cilia categoria: generale tag: , , ,

Ciao, e buon anno innanzitutto. Le meritate ferie mi hanno dato il tempo di leggiucchiare qua e là alcune cose su Google Analytics, e sono rimasto un po’ colpito da questo articolo di qualche settimana fa: Why You Shouldn’t Trust the Conversion Rate in Google Analytics. Il titolo, come al solito, mi sembrava un po’ troppo altisonante per essere davvero concreto, per cui mi sono immerso nella lettura.

Il presupposto esplicitamente citato in apertura è: “che succede se il tool non riporta quel che la gente si aspetta che riporti? che accade se non puoi fidarti di tutte le metriche su GA?” roba bella tosta, non credete? e così ci addentriamo nella lettura e scopriamo che il motivo per cui – secondo l’articolo – non potete fidarvi dei dati è che… le sessioni non sono i visitatori. Pensa te! (peraltro l’ultimo dei quattro punti – se un visitatore inizia la sessione su un sottodominio e poi passa al principale, inizia una nuova visita – è anche falso se avete configurato bene tutto o se usate Universal Analytics). L’articolo prosegue, cito traducendo, con la frase “L’errore è di equiparare una sessione a un visitatore”. Il conversion rate dell’ecommerce è calcolato sulle sessioni (transazioni * 100 / sessioni). La soluzione è usare delle custom dimension che registrino uno userID.

PERBACCO NO! la soluzione è: IMPARA A LEGGERE I REPORT PER QUEL CHE SONO! (e se proprio vuoi usare uno userID, abilita una vista userID enabled con Universal Analytics!). Ma chi ha mai detto che il fulcro di GA siano i visitatori? GA è da sempre uno strumento “session based”, e tutti i report sono costruiti su questo concetto. Soltanto da qualche tempo si inizia a parlare di report “user based”, e ovviamente il futuro è di trasformare tutto il sistema in qualcosa incentrato sull’utente. Ma sino a che questo non accade, lo strumento fa i report per come è progettato, e questo non c’entra nulla con la fiducia nei dati sottostanti!

Il secondo punto è a mio avviso ancora più debole: in soldoni dice che il bounce rate di per sé non indica nulla sulla bontà o meno della qualità della visita ricevuta. Bella forza! Se l’utente arriva, e senza fare nulla legge un numero di telefono sulla pagina, chiama e compra servizi per 4000 euro, GA segna un bounce a fronte di un grosso incasso. L’articolo ci rende edotti sull’esitenza di un “adjusted bounce rate”, di cui ho parlato secoli fa, e su cui ho anche già espresso le mie perplessità: dovrebbe essere basato sullo scrolling? o sul tempo di permanenza? se è basato sullo scrolling e il numero di telefono dell’esempio sopra è above the fold non cambia nulla. Se è basato sul tempo bisogna trovare un tempo sensato, e in ogni caso il sistema continua a non dirci se l’utente ha letto davvero la pagina o se gli ha squillato il telefono e s’è alzato dalla sedia…
Quindi ti ritrovi con più casistiche da interpretare, e con interpretazioni che dipendono strettamente da cosa hai scelto di fare. Anche questo però, ovviamente, non ha niente a che fare con quel che il sistema ti da di base e con la fiducia nei dati sottostanti.

Allora, già che ci sono, voglio porvi una domanda: voi nutrite dei seri dubbi sui dati di Google Analytics? se si, quali, in quale area, per quale motivo? intavoliamo una discussione sensata, nel caso…


Oct 15 2014

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

Il bounce rate accomodato nell’era di Universal e TagManager

autore: Marco Cilia categoria: tagmanager tag: ,

Vi ricordate del post in cui parlavo del bounce rate “accomodato”, cioè dell’ipotesi di non considerare bounce le visite che restano sul sito oltre un tot di tempo? Sebbene io sia contrario a questo genere di modifiche, resta un fatto che invece molte persone lo usano, per cui ho pensato di aggiornare la sintassi ai tempi di Universal Analytics. In sostanza la sintassi da usare sarebbe questa:


<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-XXXXXX-1', 'auto');
  ga('send', 'pageview');
  setTimeout("ga('send', 'event', '15_seconds', 'read')",15000);

</script>

Se invece usate il TagManager la cosa si risolve in un altro modo:

1) Create un nuovo tag di tipo “listener timer” fatto così:

Schermata 2014-10-12 alle 18.05.55

2) Create una regola come questa:

Schermata 2014-10-12 alle 18.07.24

3) create un tag di tipo evento, con Category ’15_seconds’ e Action ‘read’ e fatelo partire sulla base della regola creata al punto 2

4) create e pubblicate una nuova versione del contenitore.

Facile, no? 🙂


Jul 28 2014

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

4 metriche che si confondono facilmente

autore: Marco Cilia categoria: generale tag: ,

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 😉


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%