Google Analytics in 30 secondi

Durante questa settimana sono accadute tre cose piuttosto importanti nel mondo di Google Analytics, due delle quali nella sola giornata di Venerdì.

Per prima cosa è tornato l’index$, anche se adesso si chiama Valore Pagina. Me ne ero accorto un paio di settimane fa, ma non avevo fatto in tempo a dire “rieccolo”, che già era scomparso… probabilmente erano prove tecniche. Dell’importanza dell’index$ abbiamo già parlato in passato, ed esso effettivamente è una metrica che aiuta molto quei webmaster che non monetizzano direttamente i loro siti web, ad esempio i publisher; non averla era una mancanza che loro soffrivano.

La seconda cosa è che finalmente il team di Google Analytics ha rilasciato un’applicazione ufficiale per Android, la trovate nel Play Store: invece di replicare quel che le altre app già presenti fanno più o meno bene (si veda questo mio vecchissimo post, e questa recensione), cannibalizzando il mercato degli sviluppatori, il team ha rilasciato una app che fa solo 4 cose: mostra i dati Real-time, mostra una dashboard personalizzabile, e mostra gli avvisi automatici e personalizzati. In questo modo avere l’app ufficiale non rende superflua la presenza di un’altra app, ma piuttosto la integra. Justin Cutroni la descrive in un post piuttosto lungo.

La terza, che è anche la più grossa, è il rilascio di un nuovo SDK per tracciare le applicazioni mobile. Si tratta ovviamente di qualcosa di molto superiore a quanto è già possibile fare: al momento le applicazioni vengono tracciate su Google Analytics come se fossero siti, con pagine ed eventi. In futuro, al momento della creazione di un profilo, ci verrà chiesto se vorremo tracciare un sito o una app. Nel secondo caso i rapporti standard di GA appariranno così:

I report ci daranno informazioni sugli utenti, quanti scaricano e quanti davvero usano l’applicazione, da quali paesi, che versione dell’app stanno usando e da quali device. Questo ovviamente legato alla sorgente di traffico che ha portato l’utente a scaricare l’app dal Play store, come già si può fare adesso.
Dopodiché si potranno avere informazioni sulle sessioni (che si chiamano schermate), sui crash dell’applicazione e sulle sequenze di azioni fatte dagli utenti sull’applicazione: è un flow visualization che incrocia le schermate viste con le azioni intraprese (ad esempio quale pulsante viene premuto). Non mancano infine report sui goal, definibili come nel “normale” GA, o sugli acquisti effettuati all’interno dell’applicazione.

Se siete sviluppatori di applicazioni Android e siete interessati, c’è da compilare una form per avere il nuovo SDK in prova: i nuovi report saranno disponibili a partire dalla fine dell’estate.

Il post precedente ha sollevato qualche interrogativo, ed in effetti non ho mai parlato dell’index$ prima di quell’articolo.
Secondo l’help ufficiale l‘index$ rappresenta il “valore medio” di una pagina visitata dall’utente prima di raggiungere un obiettivo o di effettuare una transazione. La prima considerazione che possiamo fare è abbastanza banale: tutte le pagine viste DOPO aver realizzato una transazione o aver completato un obiettivo hanno index$ uguale a 0. La seconda considerazione è meno banale, ma la esplicitiamo lo stesso: se non avete transazioni ecommerce, le pagine obiettivo hanno index$ uguale al valore monetario che abbiamo attribuito all’obiettivo (ed ecco perché sarebbe bene attribuire sempre un valore ai goal).

Prima di introdurci nelle formule dobbiamo chiarire ancora una cosa, cioè che cosa si intende con “pagine visualizzate uniche”. Se un utente durante una visita fa 10 pagine viste, ma in realtà continua a saltare tra – ipotizziamo – la home page e la pagina del chi siamo, in realtà farà 2 pagine visualizzate uniche. Ovvero, ogni pagina viene conteggiata solo una volta nel corso della sessione di visita, a prescindere da quante volte essa viene effettivamente visualizzata. Il conteggio delle UPV si può vedere ad esempio nella dashboard della sezione report VISITATORI oppure nei report dei contenuti
La formula generale per il calcolo dell’index$ per qualsiasi pagina è
(entrate e-commerce della sessione + valore obiettivo della sessione) / pagine visualizzate uniche della pagina in esame.

Vediamo adesso i due esempi presenti nella guida.

In questo esempio di una sola sessione la pagina obiettivo D ha un valore di 10 dollari, e la pagina E genera una transazione da 100 dollari.
La pagina B viene vista una sola volta durante la sessione, e la sessione genera un introito di 110 dollari. L’index$ della pagina B sarà (100+10)/1 cioè proprio 110$. Lo stesso discorso si applica alle pagine A e C

In questo esempio con due sessioni, la pagina B viene visualizzata tre volte, ma nella seconda sessione essa viene vista due volte: ai fini delle UPV essa conta 1, per la seconda sessione. La seconda sessione genera un introito di 10$.
Quindi il calcolo dell’index$ per la pagina B è (100+20)/2, cioè 60$

Vediamo un ultimo esempio, senza transazioni ecommerce ma con più sessioni complesse (clicca sull’immagine per ingrandirla):

La pagina A viene vista solo una volta, e prima di un obiettivo di valore 10$ 10/1 fa dieci, e quello sarà il suo index$
La pagina B ha 4 UPV (viene infatti vista almeno una volta in tutte e quattro le sessioni) ma soltanto in tre sessioni viene raggiunto l’obiettivo. 30/4 fa 7,5
La pagina F ha 2 UPV, e nelle sessioni in cui è vista vengono generati introiti per 10$. 5 sarà il suo index$
La pagina G viene vista unicamente in due sessioni: in una non si generano introiti, nell’altra viene vista DOPO la pagina obiettivo. Ha index$ pari a zero

Da questa immagine possiamo capire che più è alto l’index$ più il passaggio su quella pagina è probabile che porti a realizzare un obiettivo. Tutte le volte che viene vista la pagina A poi si realizza un obiettivo. Questo potrebbe essere d’aiuto quando si vuole capire su quali pagine concentrarsi quando si fa ottimizzazione, o per avere indicazioni sui percorsi di visita che gli utenti fanno e che non magari non avevamo previsto.