Google Analytics in 30 secondi

Il problema delle keyword (not provided), non fornite da Google per gli utenti che fanno ricerche mentre sono loggati, è destinato ad aggravarsi nei prossimi giorni, con la progressiva adozione della “censura” anche nelle declinazioni nazionali del famoso motore di ricerca.
Per fortuna non ho ancor avuto modo di scontrarmi con profili con alti numeri di keyword nascoste, ma siccome nella vita non si può mai sapere, vi segnalo questo post di Ani Lòpez che descrive un metodo per “spalmarle” proporzionalmente sulle chiavi branded e su quelle non-branded. Rispetto all’approccio “non tocco niente e considero le (not provided) come una terza categoria di chiavi”, il metodo di Ani ha il vantaggio della semplicità – ci sono due formule sempre uguali da applicare – e lo svantaggio che al crescere della percentuale di (not provided) sul totale diminuisce l’affidabilità del sistema.

Se volete cimentarvi, le formule sono quelle illustrate in figura

mentre in calce al suo post trovate anche un link ad un foglio Excel già pronto dove dovrete soltanto immettere i dati.

Poiché questo blog tratta anche di web analytics, e poiché il nome Web Analytics Association ricorre anche abbastanza spesso su queste pagine, volevo segnalarvi che ieri durante l’Emetrics di San Francisco è stato annunciato il rebranding dell’associazione, che adesso si chiama Digital Analytics Association.

E’ un cambiamento che riflette una tendenza in atto da qualche tempo, perché è vero che ormai il sito web è solo una delle tante forme che la presenza in rete può avere, e soprattutto che è solo una delle tante azioni di marketing che si possono/devono mettere in campo per promuovere le proprie attività e per raggiungere i propri obiettivi di business.
Tra l’altro è una cosa che avevo anche già detto nel 2009, nella slide conclusiva della presentazione al Rimini Web Marketing Event 2009 (ora Be-Wizard – a proposito, ci sarai?). Allora dicevo che la “web analytics” sarebbe diventata solo “analytics”, oggi in realtà scopriamo che la chiameremo “Digital Analytics” 🙂

Nel changelog delle modifiche allo script di Analytics è comparsa Venerdì scorso questa piccola ma importante nota:

The maximum allowed site speed sample rate (_setSiteSpeedSampleRate) has been increased from 10% to 100%. [Il massimo tasso di campionamento per la velocità del sito (_setSiteSpeedSampleRate) è stato incrementato dal 10 al 100%]

Come ricorderete la funzione _setSiteSpeedSampleRate serve a dire a Google Analytics quanta parte di pagine viste vogliamo che siano usate per calcolare la velocità delle nostre pagine: quando è stata introdotta aveva un limite del 10% (fino a 10 mila pagine al giorno – 1% se il sito fa oltre un milione di pageviews al giorno) ed era immodificabile, da Venerdì questo limite è stato rilassato.

Questo è molto importante, specialmente per siti di piccole dimensioni, perché fino ad ora il campione statistico era quasi irrilevante. Sapere che una pagina si carica in 25 secondi è inutile, se in un mese ha un campione di 1 pagina soltanto. Se quindi in passato vi ho detto di fare poco affidamento su quei report in presenza di campioni infinitesimali, da oggi potete aggiustare la vostra frequenza di campionamento: più il sito è piccolo, più vi consiglio di alzarla (anche André Scholten la pensa come me); se viceversa siete oltre le 10000 pageviews al giorno, impostate una percentuale che corrisponda appunto a circa 10 mila: tanto quelle eccedenti Analytics non le registrerebbe.

Insieme con i report in cache è stato rilasciato anche un aggiornamento dell’interfaccia: a Mountain View ci tengono proprio a farci sapere che lavorano sodo! 🙂
Vediamo le principali novità:

Nuova sidebar

Il menu di navigazione sinistro è stato ridisegnato: spariscono le scritte in azzurro e le frecce verticali e compaiono delle icone. A mio avviso erano più belle quelle della prima interfaccia v4 (queste, per intenderci), ma così è sicuramente meglio delle scritte azzurre che c’erano fino a ieri. Cliccando una voce essa si espande, e il report corrente viene evidenziato in grassetto.

lucidata generale ai pulsanti
I nuovi pulsanti della barra sotto al titolo del report sono stati rifatti, direi quasi in stile “Google+”. Spariscono le linee di separazione e ora c’è un’unica barra grigia con le scritte “segmenti avanzati”, “personalizza”, “Esporta” e “aggiungi alla dashboard”. Anche il menu “Esporta” è cambiato, e non apre più una barra orizzontale, bensì è un menu a tendina (dove si spera che presto riappaia anche il PDF tra le opzioni).
Anche l’icona a forma di ingranaggio per accedere all’area amministrativa è sparita, sostituita da una esplicativa scritta “Amministrazione”, ed è stato aggiunto il pulsante “Guida”.
Ancora, i pulsanti per far passare il grafico dalla visualizzazione per giorno, settimana e anno sono stati migliorati, sono stati aggiunti i pulsanti per passare da grafico lineare a motion chart (prima era un’opzione molto nascosta) e la metrica utilizzata nel grafico è stata spostata sulla sinistra e resa più visibile. Adesso i report si aprono come prima, ma a fianco del pulsante compare una “e Seleziona una metrica”, che rende più facile accedere al confronto tra due metriche sullo stesso grafico (altra opzione che prima era parecchio nascosta).

report cache e controllo di precisione
Nella stessa barra grigia compare, quando necessario, l’icona a scacchiera per il controllo di precisione dei report.

La traduzione esatta italiana è: “Controllare il numero di visite utilizzate per calcolare questo rapporto:” e lo slider può essere spostato da “Elaborazione più veloce” a “Maggiore precisione”

migliorate le legende
Quando si attivano più metriche su un grafico appare una legenda dei colori utilizzati. Ancora meglio, quando si attivano dei segmenti avanzati, nel riepilogo delle metriche viene esplicitata l’etichetta e il colore utilizzato nel grafico, in modo che sia subito chiaro a quale segmento si riferiscono i dati

Stessa cosa se si attiva anche un confronto temporale

ritocco ai grafici
E’ stato reso più evidente il punto selezionato, adesso ha un contorno bianco, e sono stati migliorati i grafici su lunghi periodi temporali. Lo spessore della linea si adegua al numero di dati presenti nel grafico, e se selezionate un arco di due anni vedrete che la linea più sottile vi aiuta a visualizzare meglio i micro cambiamenti nei sottoperiodi. Quel che ho notato – ma potrebbe essere un bug temporaneo – è che selezionando un giorno non c’è la possibilità di aggiungere annotazioni, che vanno invece aggiunte a mano col link “crea nuova annotazione” e specificando a mano la data; piuttosto scomodo in realtà.

nuove schede
Le vecchie schede grigie sono state sostituite da link azzurri più grandi. Probabilmente prima erano troppo slegate dal contesto e quindi difficili da individuare, anche a causa della dimensione non troppo generosa

cosa manca ancora?
Beh, secondo me dovrebbero decidersi a ripristinare una forma di visualizzazione delle percentuali di cambiamento quando si attiva un confronto temporale, quel che qualche interfaccia fa era reso con le frecce verdi e rosse che salivano o scendevano. Sono una delle cose di cui sento di più la mancanza. e voi?

[EDIT: CONDIVISONE DI DASHBOARD!
Si possono finalmente condividere le dashboard, e finalmente basta con telefonate o lunghe mail di istruzioni ai clienti. Se c’è bisogno in fretta di una dashboard, la si crea e la si condivide con un link per email 🙂 ]

Questo post vale un po’ come aggiornamento del vecchio post “comprendere in pieno il tempo sul sito“, ed è in realtà una traduzione pressoché totale di un post di Justin Cutroni: lo faccio perché è spiegato bene ed è esaustivo sulla vicenda:

Capire le “engagement hits”

La chiave per comprendere come GA calcoli gli intervalli di tempo è capire i dati che vengono inviati a Google. Ci riferiamo a loro affettuosamente come “HITS”. Lo so, è un termine terribile da usare quando si parla di web analytics, ma sono proprio hits.
Le hits in Google Analytics sono le richieste alla __utm.gif. Ce ne sono sei diversi tipi possibili:

• Pagine viste
• Eventi
• Transazioni Ecommerce
• Singoli prodotti Ecommerce
• Dati definiti dall’utente (gli antesignani delle variabili personalizzate)
• Richieste generate dai social plugin

Sebbene queste siano tutte le possibili richieste, non tutte sono “engagement hits”. Con questo termine ci si riferisce a richieste non contrassegnate come “non interattive” e non contenenti esclusivamente dati definiti dall’utente. Filtrando la lista di prima con questa nuova informazione, ci ritroviamo con cinque tipi di engagement hits:

• Pagine viste
• Eventi che non siano non interattivi
• Transazioni Ecommerce
• Singoli prodotti Ecommerce
• Richieste generate dai social plugin

Ti starai domandando “e questo che c’entra con i calcoli sul tempo?” Molti sistemi di web analytics usano il tempo trascorso tra le pageviews per tracciare il tempo. Google Analytics usa gli engagement hits per avere un quadro più dettagliato e preciso del tempo sulle pagine e sul sito.

come è calcolato il tempo sulla pagina
Il tempo sulla pagina è calcolato in due differenti modi, e il calcolo dipende dal fatto che la visita abbia una sola o più pagine viste

Quando ci sono più pagine viste
è piuttosto facile da capire, il calcolo è basato sulla differenza di timestamp tra la richiesta alla pagina successiva e quella corrente. Ad esempio

facile no? Molti sistemi di web analytics lavorano in questo modo, ma questo porta a qualche problema: non possiamo calcolare il tempo sull’ultima pagina, perché non ce n’è una successiva da cui sottrarre il timestamp. Ma di questo ne parliamo dopo.

Quando c’è una sola pagina
Molte persone credono che Google Analytics non possa calcolare, e non calcoli, il tempo trascorso sulla pagina quando essa è l’unica della visita; questo è solo parzialmente corretto. Se non c’è un’altra pagina vista nella sessione, Analytics usa il tempo trascorso tra l’apertura della pagina e l’ultimo engagement hits che segue quella pagina vista.

Tempo sulla pagina = timestamp dell'ultimo engagement hit sulla pagina - timestamp della pagina

Chiariamo, se una visita è di una sola pagina, Google Analytics può calcolare il tempo su quella pagina usando (se ci sono, ndMC) altri engagement hits. Se aggiungete molteplici engagement hits alla pagina, avrete una misurazione più accurata del tempo sulla pagina e sul sito, come mostrato ad esempio nella seguente figura:

Come è calcolata la lunghezza della visita
Anche la lunghezza totale della visita usa gli engagement hits per avere numeri più accurati. Invece di usare il solo tempo tra i timestamp delle pagine, la misurazione del tempo totale di una sessione include il tempo trascorso tra il timestamp della prima pagina vista (la landing page) e il timestamp dell’ultimo engagement hit disponibile nella sessione.

Tempo sul sito = timestamp dell'ultimo engagement hit della visita - timestamp della prima pagina vista

Vediamo un esempio reale: qui sotto abbiamo 3 pagine in una visita. Normalmente, se contassimo la lunghezza della visita basandoci solo sulle pagine viste ci perderemmo il tempo trascorso sull’ultima pagina. Ma siccome c’è un evento su di essa (e un evento E’ un engagement hit, ndMC) possiamo avere una fotografia più completa.

E’ importante sottolineare che in questo esempio Google Analytics userà l’engagement hit anche per calcolare il tempo trascorso sulla pagina di uscita. Nell’immagine #1 non era invece possibile perché non c’era nessun engagement hit dopo l’apertura di pagina 3. Nell’immagine #3 invece c’è un engagement hit sulla pagina di uscita, quindi GA è in grado di usare quel pezzo di informazione per calcolare il tempo.

E ricordate, ci sono anche altri engagement hits, come ad esempio le transazioni ecommerce, che possono essere ugualmente usate per calcolare più precisamente la lunghezza di una visita.

Nella costante ricerca di miglioramenti dell’interfaccia, ecco una delle ultime variazioni grafiche apportate dal team di Google Analytics: le mappe. Sebbene il report principale LOCALITA’ possa sembrare invariato, quello relativo alle città è piuttosto differente da prima. La novità è che i dischi – che sono tanto più grandi quante più visite si riceve da quella città – non si sovrappongono più, o meglio hanno differenti gradazioni di colore e i dischi più piccoli appaiono adesso sopra a quelli più grandi, e possono essere quindi selezionati più facilmente. Inoltre quando si posiziona il mouse su un disco che ne ha almeno uno al di sopra, appare una comoda lente di ingrandimento della zona che permette di selezionare anche le città più piccole. Ecco un esempio reale del “classico” nugolo di cittadine dell’hinterland milanese

Come potete vedere dopo aver posizionato il mouse su Milano appare un ingrandimento (che in verità non coincide graficamente con il report principale) che mi permette agevolmente di sapere quanti visitatori arrivano da Milano (1382) ma anche da Cinisello Balsamo (7), Monza (8), Concorezzo (3), Desio (4) e così via…

La stessa identica feature è disponibile anche nei report real-time, sia nella Panoramica sia nel report Località, sia nei report Mobile -> dispositivi -> scheda Overlay Mappa.

Una cosa che invece ancora il team non si è decisa a sistemare è la rilevazione delle regioni italiane: per la maggior parte dei paesi essa è disponibile cliccando su un paese dalla mappa principale (paesi che ho controllato a caso mentre scrivo: Brasile, Venezuela, Svezia, Giappone, Sud Africa), per l’Italia no.

Ieri sera sul blog ufficiale è apparso un post interessante: il team di Google Analytics annuncia l’attivazione progressiva di alcune funzionalità che renderanno ancora più veloci i vostri report. Chi mi legge da tempo, e ancora più chi mi ha sentito parlare di persona, sa quanto io punti sulla capacità di calcolo di Analytics, e di Google in generale, e di come questa capacità di elaborare dati in fretta renda il prodotto molto accattivante sia in termini di possibilità (si veda ad esempio l’intelligence) sia in termini di “appeal” presso l’utente.
Mi ricordo come se fosse ieri una conversazione con Cesarino Morellato alla prima SEObirra milanese, che mi diceva come lui, abituato al servizio analytics on demand di $NOTO-GRANDE-BRAND che impiegava decine di minuti (non minuti, decine!) per produrre un report leggermente complesso, fosse allibito dalla estrema facilità con cui Analytics applicava al volo segmenti avanzati e creava custom report.

Non è un segreto che Google voglia un web più veloce e che si stia impegnando per darcelo: non avrebbe senso se i suoi prodotti fossero lenti e macchinosi, specialmente in un campo dove bisogna fare molta analisi e dove spesso il tempo è denaro. Quali saranno allora queste nuove caratteristiche?

• Indicatore di caricamento: se il report ha bisogno di tempo per caricarsi (avete mai applicato 4 segmenti avanzati in un confronto temporale?) Google Analytics mostrerà un indicatore di caricamento, la classica barra che avanza fino al completamento dell’operazione.
• Report in cache: Attualmente se si guarda un certo report con determinate caratteristiche, poi si cambia completamente rapporto e si torna al precedente, GA chiede nuovamente i dati al server. Tipicamente i dati non cambiano, se non sono variate le condizioni iniziali o le interrogazioni (e se non è presente anche il giorno odierno nell’intervallo di tempo considerato), per cui l’operazione è inutile: quindi finché avrete l’interfaccia aperta, i report saranno memorizzati nel vostro browser, senza bisogno di aspettare una nuova interrogazione dei server. Se tuttavia vorrete rinfrescarli, sarò presente in fondo ai report un link per forzare l’operazione, l’equivalente dell’F5 dei vostri browser
• Controllo di precisione: Se avete siti con molte visite o analizzate periodi temporali estesi, potrebbe esservi capitato di vedere i vostri report generati in modalità “fast access mode” (rapporto basato su dati campionati, in italiano): era una modalità che assicurava che l’utente non dovesse attendere interminabili minuti davanti al monitor per il suo report, e basava i calcoli su un campione statisticamente significante di visite, indicando anche l’intervallo di confidenza. Questa modalità sparirà, e verrà introdotto uno slider che permetterà di controllare il numero di visite utilizzate nel campionamento (oltre che indicarne il numero esatto): si potrà scegliere un report generato più velocemente oppure più accurato, dove evidentemente uno limita l’altro e viceversa.

C’è uno scotto da pagare, hai detto!

La modalità campionata è da sempre oggetto di polemiche e malumori, perché le persone tendono a identificare “campionato” con “inaffidabile”. Premesso che il discorso è leggermente più complicato, e comprende anche algoritmi e decisioni che sono solo nella testa degli ingegneri di Mountain View, la situazione ad oggi era semplice: se qualcosa all’interno di GA necessitava di oltre 500.000 visite per essere calcolato, si attivava la modalità campionata. Quando queste novità saranno in pista per tutti, il nuovo limite verrà ridotto a 250.000 visite. Per avere un campione maggiore bisognerà utilizzare lo slider di cui sopra, e quindi rinunciare un po’ alla velocità dei report.

Una delle feature più potenti delle canalizzazioni multicanale sono i raggruppamenti di canali, sia automatici sia personalizzati, perché con poche regole ci permettono di raggruppare molte fonti, spesso in modi completamente diversi da come siamo abituati a vedere nei report delle sorgenti di traffico. E’ tuttavia altrettanto utile guardare alle conversioni indirette o ai percorsi di conversione usando alcune delle dimensioni che invece sono proprie di Analytics e che conosciamo e maneggiamo meglio, ad esempio il Mezzo, o la Sorgente; In questo ambito credo che tutti almeno una volta abbiamo selezionato la parola chiave, ad esempio nel report dei percorsi di conversione. Ecco un esempio reale di pattern preso dal mio Google Analytics

Questa conversione ha richiesto 22 sessioni, 9 delle quali da motore di ricerca con le parole chiave illustrate, che si sono concluse tra l’altro con una conversione durante una visita con chiave brand. Quando nel report viene scritto “non disponibile” significa che la sorgente e il mezzo non sono ORGANIC, e che quindi non c’è nessuna keyword. Non sarebbe bello se, dato che una keyword non c’è, Analytics lasciasse la combo sorgente / mezzo? è comunque un’informazione in più, ed è meglio che una in meno…

Ecco, nei funnel multicanale c’è proprio la dimensione “alternativa” Percorso parola chiave (o mezzi/sorgente) che fa esattamente quel che desideriamo; in verità c’è anche Percorso campagna (o mezzi/sorgente), e fa esattamente quel che dice. Le potete trovare entrambe nel classico menu a tendina delle dimensioni:

Attivando quella dimensione il report si modifica così:

Nel mio caso purtroppo ho solo visite direct in mezzo alle keyword, ma siccome i percorsi dei visitatori sono molti è probabile che voi vediate tutt’altro, o che abbiate anche altre combinazioni di sorgenti/mezzi inframezzate alle vostre visite da organico. E’ un modo comodo per avere due informazioni sullo stesso report e farsi un colpo d’occhio sulla situazione.

Justin Cutroni, che ormai è una fonte ufficiale Google, ha annunciato su Google+ che da qualche giorno sono disponibili dei nuovi campi filtro, che potrete utilizzare per filtrare i dati nei vostri profili. Più precisamente si tratta di:

• Cellulare del visitatore? (orrenda traduzione di “visitor Mobile?”) che identifica se l’utente naviga da mobile o no
• Categoria Evento
• Azione Evento
• Etichetta Evento
• Continente del visitatore

I campi filtro sono inoltre stati riorganizzati e raggruppati logicamente, così da poter essere trovati più facilmente. Con mio sommo disappunto non è stato implementato il filtro sulle variabili personalizzate (quantomeno su quelle impostate con scope=1, cioè permanenti nei browser degli utenti). Questo, ad esempio, ci costringe a usare soluzioni “con la toppa” quando si tratta ad esempio di escludere le proprie visite con un IP dinamico: si veda in proposito questo articolo di Enrico Pavan, in cui si è costretti ad usare ancora la deprecata funzione _setVar (e la sintassi sincrona, anche se io ed Enrico dobbiamo ancora fare due test congiunti per verificare la sua ipotesi illustrata nei commenti).

Altra bella segnalazione, sempre di Justin e sempre su G+, è questa relativa allo script per GreaseMonkey AnnotationManager, che vi consente di copiare annotazioni tra profili/account, rimuoverne molte con un solo clic o anche esportarle. Mi è di recente capitato di dover inserire una annotazione su un profilo: l’ho dovuta ripetere nel profilo di quel sito, nel profilo master senza filtri e in un altro profilo in cui quel sito era combinato con due sottomini. Con AnnotationManager probabilmente avrei risolto con 3 click. Essendo uno script per GreaseMonkey però, è disponibile solo per Firefox/Chrome.

Ultima segnalazione è questo post di Brian Clifton (tra l’altro, come ho detto in questo commento, sta per uscire la versione 3.0 del suo ottimo libro) che riassume gli ultimi studi usciti sulla diffusione di Google Analytics nel web: vari post che più o meno vi avevo segnalato a tempo debito, ma che riassunti così fanno comunque una certa impressione: il 50% del web usa GA, il 45% delle top500 Fortune companies, l’86% di un campione di 800 imprenditori… più esplicativo di così…

Oggi mentre facevo alcune prove con Google Analytics e avevo il fedele Fiddler aperto per ispezionare gli header HTTP inviati, mi è caduto l’occhio su un parametro che non avevo mai notato, e di ho trovato solo una flebile traccia in rete (questo twit del sempre attento André Scholten): il parametro utmvp. Come dice André e come ero arrivato a dedurre, “vp” sta per viewport (mentre utm sta per “urchin tracking monitor” ed è il prefisso standard – storico – dei parametri di GA), dove per viewport si intende la dimensione effettiva della finestra, anzi lo spazio effettivamente disponibile.
Analytics infatti ha un report sulla risoluzione dello schermo, intesa come impostazione del monitor, ma una cosa è avere un browser a finestra massimizzata, un altro è averlo come riquadro nello schermo. Senza considerare poi lo spazio effettivo utilizzabile a parità di condizioni: Chrome nel suo minimalismo ha un viewport più grande di Firefox Ed Explorer, e installare toolbar non fa che peggiorare la situazione, spingendo il contenuto verso la linea del “below the fold”, cioè fuori dalla portata degli occhi dell’utente anche senza scrollare la pagina.

Guardate questo esempio reale:

Come potete vedere la risoluzione del mio schermo è sempre e comunque 1920×1200, ma nel primo caso (primo riquadro rosso) sto guardando la home di un sito che ha una pagina più lunga dell’altezza del mio schermo, per cui mi compare a destra la scrollbar del browser e il viewport si riduce orizzontalmente a 1903 pixel disponibili; nel secondo caso guardo una pagina senza scrollbar, e il viewport sale a 1920. Nel terzo caso ho rimpicciolito la finestra del browser e ricaricato la pagina: 1171×400 è esattamente lo spazio disponibile per renderizzare la pagina del sito monitorato.

Tutto questo presumo che porterà presto ad avere una nuova metrica nel sistema, una metrica che è ancora più utile della mera risoluzione dello schermo perché è più vicina al reale utilizzo del browser da parte dei navigatori, e che sarà in grado di darci preziose informazioni in fase di redesign del sito (a proposito di redesign, vi suggerisco la lettura di questo bel post di Andrea Vit, che credo sarà contento quando questa novità sarà ufficialmente introdotta 🙂 ).