Google Analytics in 30 secondi

Google Analytics Certified Partners è il nuovo nome che da oggi assumono i vecchi Google Analytics Authorized Consultants. Spesso ci siamo riferiti a loro semplicemente con la sigla GAAC, e non sono da confondere con i GAIQ, cioè gli individui certificati individualmente.

Il cambio segue a ruota quello relativo alle agenzie AdWords, e ne condivide anche la grafica e la possibilità di approfondire la conoscenza con l’agenzia e il suo rapporto con Google tramite un link di verifica. La lista completa dei badge per Adwords, Analytics e Website Optimizer è disponibile qui.
Mi sembra una mossa scontata nell’ottica di fornire una visione completa e uniforme degli strumenti di supporto ai tre programmi, che sono strettamente legati fra di loro e quindi spesso necessitano di consulenti altamente specializzati nei tre settori. La lista dei requisiti per divenire GACP mi pare non sia cambiata, ed è sempre comunque bella tosta 🙂

I fortunati potranno/dovranno fregiare i loro siti web con questo nuovo badge:

Martedì 4 maggio, alle 13:50 (fuso orario della California), Brett Crosby terrà uno speech di dieci minuti dal titolo “What’s New with Google Analytics”. Per la mia esperienza, interventi di quella durata a quella conferenza hanno sempre significato succose novità, infatti non credo che Brett si prenda dieci minuti per ricordare ai presenti che “da qualche mese potete aggiungere annotazioni ai grafici” 😉

Da noi saranno le 22:50 e per quanto possibile cercherò di essere online o di informarmi prima possibile, ma intanto: cosa pensate / sperate che verrà annunciato?

Ci sono alcune novità in Google Analytics, ci informa il bollettino dei changelog. La più importante di tutte è che è stato finalmente corretto il baco che non permetteva di invocare la funzione _trackEvent() senza invocare anche _trackPageview() o _initData() (si veda questo vecchio post in proposito: initdata e tracciamento eventi). Da questo momento è quindi possibile avere una pagina che contiene il codice di monitoraggio di Google Analytics SENZA che essa generi una pagina vista ma che è in grado di tracciare eventi che accadono su di essa.

Un’altra novità è che è stato leggermente variata la sintassi del nuovo script asincrono, in modo da risolvere un problema che si generava su Internet Explorer 6 e 7 quando si posizionava lo script nell’HEAD della pagina; vi consiglio di dare un’occhiata al nuovo snippet – lo trovate qui – perché è abbastanza differente dalla prima versione apparsa.

Per chi invece usa il codice “classico”, è bene sapere che la funzione _getTracker() è stata deprecata. Non l’avete mai usata? dite? secondo me invece si, è una funzione che avete incollato OGNI SINGOLA VOLTA che avete aggiunto un codice di GA a una pagina.

<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-53707-19");
pageTracker._trackPageview();
} catch(err) {}</script>

Fa parte del codice standard e si invoca quando si crea il più famoso oggetto pageTracker. Sebbene l’interfaccia web ancora non rifletta questa modifica quando si crea un nuovo codice di monitoraggio, la funzione _getTracker non esisterà più, e al suo posto andrà usata _createTracker(), cui dedicheremo un post apposito appena avrò qualche notizia più certa. Sostanzialmente il nome dell’oggetto di tracciamento verrà impostato come un parametro di questa nuova funzione, come nella sintassi di esempio

_gat._createTracker('UA-65432-2', 't2');

Se non ho capito male poi ci si potrà riferire all’oggetto semplicemente con t2._trackPageview().
Non è un cambiamento epocale, ma rende il codice di monitoraggio classico più coerente con quello asincrono.

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.

Me l’ha detto direttamente Avinash Kaushik in video. Non ci credete? ecco qua, minuto 2:26 🙂

La domanda l’ho posta tramite Google Moderator, dopo aver provato invano ad avere risposta sul forum ufficiale. La domanda riguarda l’influenza di AdSense nel calcolo dell’indice index$, che al momento è calcolato (per ogni pagina) con la formula
(Entrate ecommerce + valore obiettivo) / pagine visualizzate uniche

Lo scopo dell’index$ è di fornire un’idea del “valore” di ogni singola pagina che concorre a realizzare una entrata monetaria, che sia un obiettivo o una vendita. Poiché anche AdSense rappresenta una entrata monetaria (anche se è calcolato per pagina e non per sessione) volevo sapere se gli introiti AdSense avevano una qualche influenza nel calcolo dell’index$, dopo aver collegato i due account.

E la risposta è no, sono due sistemi indipendenti e AdSense non contribuisce al calcolo. Però all’inizio della frase Avinash dice “actually”, il che non esclude che forse un giorno invece si potrà fare…

Con un po’ di ritardo, vi segnalo che le slide che ho utilizzato durante la presentazione a SMAU business Roma lo scorso marzo sono ora su Slideshare, con il titolo “web analytics pratica e funzionale“.

Mi rendo conto che essendo uno strumento di supporto alla presentazione, senza il commento potrebbero risultare un po’ oscure, ma magari qualche spunto riescono a passarlo ugualmente. Come potete notare alcuni concetti sono ispirati a cose che Avinash Kaushik ripete da tempo, a voce e nei suoi post. Il target dell’intervento infatti non era tecnico, e chi meglio di Avinash può aiutare a spiegare a cosa serve la web analytics? 🙂

Piuttosto interessante l’ultimo post sul blog ufficiale di Google Analytics: “How to measure the quality of an online form“, che si prefigge lo scopo di usare il sistema di web analytics made in Google per avere un tasso di errore sull’invio delle form, cioè per capire se e quanto gli utenti sbagliano a compilare i campi prima di riuscire ad inviare un modulo. Ovviamente il prerequisito è di avere una form che effettui il controllo dei valori prima dell’invio vero e proprio.

Il primo concetto introdotto è il FER, cioè il Form Error Rate (tasso di errore della form), e viene calcolato dividendo il numero di invii rifiutati per il numero totale di invii tentati, e moltiplicando per cento. Se per esempio un visitatore deve compilare una form con 25 campi, e ci riesce al terzo tentativo, il FER è 2/3*100, cioè il 66%. Se un visitatore ce la fa alla prima, il secondo alla terza e il terzo visitatore non ci riesce dopo tre invii, il FER sarà 5/7*100, cioè 71%. Più il tasso è alto e più la nostra form risulta problematica e ostica per gli utenti.

Come hanno pensato di fare questa analisi in Google Analytics? usando la funzione _trackPageview() per generare pagine virtuali “codificate” in modo da avere nel nome della pagina il numero di campi compilati male. Nel post si fa riferimento ad una semplice form con due campi, in cui ognuno di essi viene codificato a 1 se non riesce ad essere validato (se l’utente ha commesso un errore, quindi) e a 0 se invece è correttamente valorizzato. Ad ogni invio della form bisogna chiamare la funzione _trackPageview(“/onlineform/00”); dove 00 sono le due codifiche dei campi menzionati poco fa. Ad esempio una form con il primo campo errato e il secondo corretto genererà una pagina virtuale che si chiama /onlineform/10, mentre una con entrambi i campi errati genererà /onlineform/11.

L’analisi è piuttosto semplice: fatto un filtro di visualizzazione nel report “contenuti principali” che mostri solo le pagine /onlineform/ bisognerà prendere il numero totale di pagine viste meno quelle della sola /onlineform/00 e dividerlo per la somma delle pagine viste. Sempre ricalcando l’esempio del post sul blog ufficiale, in una situazione del genere, in cui i successi sono stati 5,

il FER è 18/23*100, cioè il 78%. La form in questione, pur avendo due soli campi, risulta parecchio problematica per gli utenti e necessita di revisione, o di maggior chiarezza nelle istruzioni. Se la vostra form ha otto campi, naturalmente, avrete pagine virtuali tipo /onlineform/00000000 e così via.

Sono rimasto molto colpito dal post, che nella sua semplicità mette a disposizione uno strumento molto potente per l’analisi delle interazioni utente-sito. Fare form analysis con GA è sempre stato un mio pallino, ma non ho mai trovato un modo soddisfacente; questa non sarà form analysis vera e propria, ma è un buon inizio!

Se siete interessati all’analisi delle form tramite GA, vi ricordo anche questo vecchio post

Creare degli avvisi personalizzati nell’intelligence di Google Analytics significa dire esplicitamente a GA cosa vogliamo tenere sotto controllo, per quali eventi vogliamo essere avvisati.

Per farlo bisogna cliccare su “Intelligence” -> “crea un avviso personalizzato”, dopodiché bisogna dare un nome all’avviso, in modo che sia chiaro a cosa si riferisce; ad esempio “traffico in calo di oltre il 20%”. Per impostazione predefinita GA crea l’avviso nel profilo corrente, ma è comunque possibile estenderlo anche ad altri profili su cui abbiamo il controllo selezionandoli dal menu a tendina sottostante. Poi bisogna decidere il periodo di confronto, ovvero se l’avviso deve fare il paragone con il giorno precedente, la settimana precedente o il mese precedente. Dopodiché bisogna mettere la spunta all’opzione “inviami una mail quando si attiva questo avviso”.
La parte inferiore della schermata serve a definire le regole per l’attivazione dell’avviso. La parte in verde determina la dimensione da monitorare: ad esempio se vogliamo un avviso per il calo del traffico dovremo lasciare “applicabile a: tutto il traffico”, mentre se vogliamo un avviso sulle variazioni dei nuovi visitatori dovremo selezionare “applicabile a: tipo di visitatore”. Altri esempi di dimensioni sono città, campagna, pagina di destinazione, parola chiave, mezzo. Dopo aver selezionato la dimensione avremo la possibilità di inserire un filtro, analogamente a quanto avviene per i segmenti avanzati (ed infatti questo non è altro che un segmento di traffico).
L’ultima selezione invece determina la condizione vera e propria, ovvero quando dovrà scatenarsi l’avviso. Per restare nel semplice esempio iniziale, diremo ad Analytics “avvisami quando: visite” -> “condizione: % diminuisce di oltre” -> “20%”. l’ultimo campo è controllato dalla scelta temporale che abbiamo fatto più sopra.

Ecco la schermata per la creazione dell’avviso in questo esempio (clicca sull’immagine per ingrandirla):

In realtà gli avvisi intelligenti, cioè le email di allerta quando si verifica una o più condizioni specificate nell’Intelligence di Google Analytics, avrebbero dovuto funzionare da subito. Nessuno ha mai detto che sarebbero state attivate in un momento successivo, e nonostante svariati solleciti sul forum ufficiale nessun impiegato di Google è mai intervenuto per chiarire la situazione.

Da qualche giorno invece gli avvisi arrivano, in base a come sono stati impostati, come potete vedere dallo screenshot qui sotto

Si tratta di uno di quei casi in cui anche io sono costretto a tirare le orecchie a Google, che “dimentica” di aggiornare noi poveri mortali di ritardi nell’introduzione di feature o malfunzionamenti conclamati o meno.

Comunque adesso gli avvisi arrivano, buona analisi a tutti!

Ci sono alcune novità che chi usa le API di Google Analytics potrebbe ritenere interessanti:

• il segmento che prima era riferito all’Iphone ora riporta tutto il traffico da terminali mobili. l’ID del segmento è invariato (-11), ma il nome è cambiato: ora si chiama Mobile Traffic
• il tasso di campionamento usato dalle API è lo stesso dell’interfaccia web. Precedentemente alcuni sviluppatori che accedevano a profili ad altro traffico tramite API lamentavano difformità nei dati, dovuti appunto ad un diverso tasso di campionamento (vi ricordo che anche l’interfaccia, quando deve mostrare dati relativi a oltre 200.000 visite effettua spesso un campionamento, informando l’utente della percentuale di scostamento possibile)
• sono cambiati i limiti di utilizzo, che adesso sono diventati: 10.000 richieste al giorno, non più in totale ma bensì per ogni web property (cioè per ogni codice UA-XXXXX-X); 10 richieste al secondo; 10.000 risultati per ogni query; massimo 4 richieste contemporanee (questo per evitare di lanciare decine di richieste che hanno bisogno di molto tempo per essere elaborate)

Il changelog completo, come al solito, si trova nel google code di Analytics