Google Analytics in 30 secondi

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

Nei prossimi mesi mi toccherà viaggiare un pochino, a causa di corsi/lezioni cui ho dato la disponibilità a raccontare qualcosa di quel che so. E quindi, in rigoroso ordine cronologico:

• Il 17 marzo sarò nella sessione advanced del be-wizard, per raccontare qualcosa dei funnel multicanale e provare a renderli meno complicati di quel che sembrano alla platea. L’organizzazione mi aveva omaggiato di un ingresso gratuito per la due giorni, ma l’ho già dato via con un post su Google+
• Il 24 aprile sarò presente al MasterLab in Digital Economics & Entrepreneurship di Digital Accademia, per una chiaccherata sull’importanza della web analytics in qualsiasi progetto online.
• Il 25 maggio sarà invece la volta dell’e-commerce academy, un master di 8 giornate, acquistabile in blocco o singolarmente, totalmente incentrato sul commercio elettronico. Inutile che vi spieghi quanto Google Analytics sia importante in un e-commerce, no? L’organizzazione mi ha messo a disposizione un codice sconto del 30% che potete utilizzare per l’iscrizione: 137tK

Ho inoltre un’altro appuntamento, ma ne scriverà quando avrò maggiori dettagli, mentre quest’anno ho dovuto rinunciare alla consueta presenza a SMAU Business Roma a causa di concomitanti e gravosi impegni familiari. Cercherò di non mancare almeno a Milano, ma c’è ancora tempo…

Qualche tempo fa ho voluto creare un KPI per provare una mia certa teoria (più che altro la fattibilità e l’effettiva utilità del KPI stesso usando dati reali e non astratti), una cosa facile facile tutto sommato, ma ne ho approfittato per giocare un po’ con le API di Urchin, immaginando che non fossero poi troppo diverse da quelle di Analytics. Ho così messo insieme alcune pagine php che assolvevano alla funzione desiderata.

La settimana scorsa volevo adattare il lavoro alle API di GA, ma ho scoperto che da qualche tempo Analytics richiede che le applicazioni siano registrate sulla Google APIs consolle, e che per farlo devono essere su rete pubblica. Poiché il mio sistema è su rete interna (e ho avuto qualche problema con OAuth 2.0, lo ammetto), ne ho approfittato per provare qualcuno dei sistemi per importare dati dentro a Excel, tipo excellentanalytics, nextanalytics, GA data grabber o Tatvic.

Tralasciando quelli a pagamento, il problema principale che riscontro è che spesso la presenza di un proxy impedisce a Excel di connettersi a GA. Mi sono così orientato verso una soluzione che collegasse Analytics a Google Docs, così che il passaggio dei dati sia server-server e si possano evitare intoppi. Per prima cosa sono capitato su questo post di SEOmoz, che sembra promettente ma che non ho ancora sperimentato. La soluzione più immediata – per le mie limitate esigenze del momento – è stato leggere questo post di peakconversion.com.

Le istruzioni sono piuttosto semplici:

• bisogna aprire questo google docs e farsene una copia tramite File->Crea una copia…
• si imposta l’id del profilo da cui prendere i dati (lo si può trovare nell’interfaccia cliccando l’icona delle impostazioni, selezionando il profilo corretto se non lo è già e poi passando alla tab “impostazioni profilo” e guardando a ID profilo)
• si apre l’editor di script Strumenti->editor di script…
• si seleziona la funzione Run|getSettingGADataToSheet e si autorizza una prima volta l’applicazione
• si lancia di nuovo la stessa funziona e si autorizza definitivamente il foglio di calcolo a estrarre i dati
• a questo punto compare una nuova voce di menu “GA”. Si cambiano il resto dei parametri nel foglio _settings e si lancia GA->activate settings query

Il risultato è un nuovo foglio di lavoro con i dati richiesti. Alterntivamente si può chiamare in qualsiasi cella la funzione

getMetric(profile, metric, startdate, enddate, [dimensions], [segment], [filter], [sort], [maxresults])

a cui si passano i primi quattro parametri obbigatoriamente e gli altri cinque opzionalmente e che provvede a caricare direttamente i risultati. Fatto questo i dati sono pronti per essere ulteriormente aggregati, elaborati, resi su un grafico o combinati per avere i nostri KPI sempre aggiornati direttamente sul foglio di calcolo.

Una delle cose che più spesso mi sento chiedere quando parlo dei custom report è “perché non ci forniscono delle basi su cui lavorare? perché bisogna partire da zero?”. Partire da zero può essere una buona idea quando si sta disegnando un report completamente nuovo, molto molto personalizzato e con incroci di metriche e dimensioni inusuali. Alcune altre volte il custom report è solo un modo per dare una sistemata ad un report standard dal quale sentiamo la mancanza di una certa metrica, o dal quale invece vorremmo togliere una metrica.

Ad esempio dico sempre che la metrica bounce rate nel report delle Pagine non ha senso (si veda il perché in questo vecchio post) e che l’unica soluzione è ricostruire il report utilizzando i report personalizzati. Da qualche ora su alcuni rapporti di Google Analytics è presente un nuovo pulsante, PERSONALIZZA, che non fa altro che attivare l’interfaccia di creazione dei custom report riportando esattamente le metriche e le dimensioni del report corrente, facendoci risparmiare molto tempo se l’operazione da effettuare è proprio quella di sistemare un pochino un report che al 90% va bene così com’è.

I report su cui ho verificato che al momento funziona sono:

• dati demografici -> lingua
• dati demografici -> variabili personalizzate
• dati demografici -> definito dall’utente
• comportamento -> nuovi e di ritorno
• tecnologia -> browser e sistema operativo
• tecnologia -> report
• sociale -> interazione sociale
• sociale -> azione
• sociale -> pagine
• mobile -> panoramica
• tutti i report del gruppo AdWords
• tutti i report del gruppo ottimizzazione per i motori di ricerca
• pagine -> dettaglio contenuti
• pagine -> pagine di uscita
• ricerca su sito -> utilizzo
• ricerca su sito -> termini di ricerca
• ricerca su sito -> pagine
• eventi -> principali eventi
• eventi -> pagine
• adsense -> pagine adsense
• adsense -> referrer adsense
• obiettivi -> url dell’obiettivo
• obiettivi -> percorso inverso per l’obiettivo
• e-commerce -> rendimento prodotti
• e-commerce -> rendimento delle vendite
• e-commerce -> transazioni

Mi sono imbattuto in una estensione per Chrome, Table Booster, e non ho resistito alla tentazione di provarla. E’ prodotta da e-dialog, un Google Analytics Certified Partner austriaco, e quindi ha subito avuto la mia fiducia. L’estensione aggiunge un pulsantone azzurro in alto a sinistra, subito sotto all’elenco dei profili, che una volta cliccato fa apparire in cima alle intestazioni di ogni tabella sulla pagina tre ulteriori pulsanti: il primo provvede a far comparire degli istogrammi, fatto 100 il valore massimo visibile nella colonna le altre celle avranno un istogramma proporzionale. Il secondo colora le cella di rosso o di verde, e fatto rosso il valore massimo e verde il minimo (o viceversa) si preoccupa poi di fare le gradazioni di colore. L’ultimo pulsante provvede a far comparire delle barrette riferite alla media della metrica rappresentata nella colonna: se il valore è superiore alla media barretta verde e positiva, rossa e negativa se al contrario il valore è inferiore alla media. Al secondo click del pulsante compaiono anche le percentuali di scostamento dal valore medio.

Il punto negativo è che l’app non accede alle API di Google Analytics, quindi può solo lavorare sui dati presenti sulla pagina; con questo intendo dire che se avete 10 righe nel report e passate a 25, dovrete riattivare l’estensione, perché tra le altre cose dovrà ricalcolare tutti i valori. Stessa cosa se cambiate report. Piuttosto frustrante alla lunga, mentre per analisi spot su una singola metrica può essere utile. Sono sempre bene accetti gli strumenti che ci consentono di variare la monotonia dei dati tabellari, giusto?

Questa mattina ho notato che il report “dettaglio contenuti”, nella sezione CONTENUTI -> CONTENUTI DEL SITO era leggermente differente dal solito. Sono state infatti aggiunte due icone per differenziare le cartelle dalle pagine, e c’è anche l’indicazione del livello di profondità raggiunto.

In alto si legge “livello 1 percorso pagina”, e ovviamente se si clicca su una cartella la scritta cambia in “livello 2 percorso pagina”, dandoci sempre modo di capire (il famoso contesto che dobbiamo sempre dare alle analisi) a che livello di nidificazione sono i contenuti che stiamo analizzando.
Inoltre l’icona a fianco di ogni riga del report ci dà una indicazione immediata del fatto che la riga analizzata abbia al proprio interno altre pagine o sia una foglia terminale dell’alberatura del nostro sito.

Sempre nell’ottica di rendere più agevoli le nostre analisi…

Le variabili personalizzate sono un grande e prezioso tesoro di Google Analytics; come ho modo di ripetere durante corsi e consulenze, quando si tocca l’argomento, sono uno dei pochi modi che abbiamo per inserire dati arbitrari – scelti da noi – dentro al sistema di analytics. Infatti se un visitatore è nuovo o di ritorno lo decide lo script, guardando i cookies, idem per la keyword usata nella ricerca che ha veicolato la visita. Invece nelle custom var possiamo scrivere quel che vogliamo, e “appiccicare” valori arbitrari al visitatore, alla visita o alla pagina vista in quel momento.

I limiti delle custom var sono sempre stati: non più di 5 slot usati contemporaneamente (50 su Analytics Premium) e la lunghezza di nome + valore della variabile non eccedente i 64 caratteri. L’ultima revisione del changelog di Analytics ci informa invece che questo limite è stato raddoppiato: adesso nome + valore possono arrivare a 128 caratteri. L’ultima frase “Additionally, the length is now checked before URL encoding” mi fa tornare in mente un vecchio post letto chissà dove che affermava che in presenza di caratteri “non standard” essi andavano a erodere molti caratteri (per via dell’encoding). Pare che adesso la lunghezza venga controllata PRIMA di effetture l’econdig e l’invio a GA.

Altre modifiche di questo aggiornamento sono l’aumento del limite di eventi inviabili e un diverso modo di registrare il cookie __utmv (usa il separatore ^ invece della virgola).
Dato che c’è una nuova versione del codice di monitoraggio (la 5.2.4) e che è un po’ che non lo faccio, posto la lista dei motori di ricerca conosciuti dallo script. Sicuramente Babylon è nuovo, perché in alcuni miei profili lo vedo sempre nei referrer, altri nuovi non ne vedo (e manca sempre l’italiano arianna):

daum:q
eniro:search_word
naver:query
pchome:q
images.google:q
google:q
yahoo:p
yahoo:q
msn:q
bing:q
aol:query
aol:q
lycos:q
lycos:query
ask:q
netscape:query
cnn:query
about:terms
mamma:q
voila:rdata
virgilio:qs
live:q
baidu:wd
alice:qs
yandex:text
najdi:q
seznam:q
rakuten:qt
biglobe:q
goo.ne:MT
wp:szukaj
onet:qt
yam:k
kvasir:q
ozu:q
terra:query
rambler:query
conduit:q
babylon:q
search-results:q
avg:q
comcast:q
incredimail:q
startsiden:q