Google Analytics in 30 secondi

Questa mattina Mauro Ginelli mi ha avvisato che c’era una novità in Google Analytics: la selezione della dimensione secondaria avviene tramite una interfaccia ridisegnata. Vi allego uno screenshot (clicca per vederlo ingrandito):

Innanzitutto si nota il bordino verde, per coerenza di interfaccia: da qualche tempo infatti tutto ciò che in Analytics ha a che fare con le dimensioni è verde e tutto ciò che ha a che fare con le metriche è azzurro. A prima vista quindi è chiaro in quale campo si andrà ad operare con il nuovo strumento. In secondo luogo la vecchia tendina era diventata troppo lunga per essere usabile: si era costretti a scrollare su e giù per il monitor in continuazione alla ricerca della dimensione desiderata. Adesso le dimensioni sono raggruppate per tipologia (ed ognuna ha una breve spiegazione), oppure sono selezionabili direttamente dalla schermata principale, che però essendo orizzontale non genera problemi. Infine è presente un box di ricerca che può scremare le selezioni possibili man mano che lo compiliamo, esattamente come avviene per i campi dei report personalizzati.

Sono quei ritocchi “di fino” che però fanno sempre piacere: fare analisi è la parte centrale del lavoro, ma farlo senza impazzire per via dell’interfaccia è indubbiamente più gratificante e meno faticoso

[in vista di questo caldo week end, un post un po' diverso dal solito ]

Sono sempre stato combattuto tra il credere che l’abito “faccia il monaco” e il non crederlo affatto: diciamo che mi regolo a seconda delle situazioni. Quando però faccio consulenze in giro per l’Italia, paradossalmente, ho più la tendenza a presentarmi senza giacca e cravatta.

L’altro giorno di ritorno da un pranzo e in atmosfera cordiale e informale, ero in ascensore con due responsabili dell’azienda cui davo assistenza, e uno dei due dice all’altro: “sai, questa mattina io e Marco abbiamo preso l’ascensore insieme, ma non ho mica capito che era lui”. Gli rispondo che mi capita spesso, dovendo la gente basarsi sulla foto in bianco e nero nella pagina “about“. “E comunque – aggiungo – io ti ho scambiato per un vostro classico cliente. Si vede che hai più la faccia da cliente ”. “Questo allora significa che tu non hai affatto la faccia da esperto di web analytics ” replica pronto. “scherzo, invece secondo me si vede che ne sai, si vede da come ti vesti…”.

La cosa mi incuriosisce: “in che senso? non capisco…”. “nel senso che non hai bisogno di apparire meglio di come sei, di colmare lacune nelle conoscenze sfoggiando un bel vestito per colpire il cliente. Sei sicuro del fatto tuo e quindi ti rilassi con jeans e maglietta “.

Ripeto, non sono del tutto certo che l’abito non faccia il monaco, ma quell’osservazione – quel punto di vista che non avevo mai considerato – mi ha fatto molto piacere!

[photo credit: Randy son of Robert on flickr]

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.

In un mio vecchio post su come sfruttare Google Analytics e WordPress – a quanto pare di successo – regolarmente compaiono commenti di ringraziamento di persone che scoprono quanto sono comodi i plugin descritti: va bene che non tutti usano WordPress, che ci possono essere siti nuovi, eccetera, ma c’è davvero qualcosa che WordPress non può fare tramite i suoi beneamati plugin?

Ebbene, da qualche giorno Joost de Valk ha aggiornato il suo plugin per il nostro sistema di web analytics preferito alla versione 4, e le novità sono piuttosto interessanti, per cui voglio rendervene conto qui:

• Integrazione con le API: è sempre possibile inserire a mano il proprio identificativo UA, ma ora è anche possibile fare in modo che il plugin ci presenti una lista di profili esistenti e con pochi click indirizzare i dati del sito verso uno di essi. Piuttosto comodo…
• Codice asincrono, finalmente! Ammetto che sono stato tentato di abbandonare il plugin quando ho visto che Joost tardava a passare all’ultima versione del GATC, ma ho resistito. Il codice può essere inserito dal plugin nella sezione HEAD del blog oppure incollato a mano da voi nel template (ma consiglio la prima, raccomandata anche da Google)
• Variabili personalizzate: Da adesso il plugin è in grado di segmentare automaticamente le visite inserendo delle variabili personalizzate sui seguenti parametri: utenti loggati, autore, cateogira singola del post, categorie multiple, tag, anno di pubblicazione e tipo di post (a partire da WordPress 3.0)
• link in uscita e download: ovviamente li può tracciare, sia come eventi sia come pagine viste. Altresì si possono scegliere le estensioni dei file da considerare download, se tracciare l’url completo dei link uscenti o solo il dominio e quale prefisso aggiungere alle pagine virtuali create (per default inserisce /yoast-ga/, così nel report sono facilmente filtrabili).
• varie: possibilità di tracciare la form di login di WordPress, di scegliere a partire da quale livello utente ignorare le visite (tutti coloro che sono loggati, solo l’Administrator o a partire da Autore in su, ad esempio), di impostare _setDomainName se si tracciano anche i sottodomini, se tracciare i click su Adsense – se si sono legati i due profili, motori di ricerca aggiuntivi, i link nei feed RSS (ma solo se non si usa l’analoga funzione su Feedburner) e di anonimizzare gli IP tramite la nuova funzione _anonymizeIP()

Insomma, una release bella corposa. Complimenti a Joost! Il plugin può essere scaricato da questa pagina, oppure direttamente dall’interfaccia di amministrazione di WordPress

Google TV arriverà nelle mani dei consumatori entro fine 2010. Google ha annunciato una partnership con Sony, Intel e Logitech per trasformare ogni schermo HD in un PC dedicato al multimediale. Google ha rilasciato alcune note agli sviluppatori che vogliono disegnare siti TV-friendly. Tutto questo mi ha fatto pensare che Google TV avrà un impatto non trascurabile sulla web analytics ridefinendo il come dobbiamo pensare all’esperienza utente.

Ecco una lista parziale di modi in cui Google TV potrebbe cambiare lo scenario della web analytics

Il traffico dalle TV potrebbe essere difficile da riconoscere
Saremo in grado di capire quali visite avvengono da un TV? forse. Potrebbero essere identificate attraverso una descrizione del Sistema Operativo differente, ma nei casi più comuni potrebbero apparire identiche a quelle effettuate da altri dispositivi. Sebbene le TV siano più grosse, hanno la stessa risoluzione della maggior parte dei monitor dei computer (e ormai anche di alcuni cellulari!). Useranno un browser Chrome completo, capace di eseguire Flash e tutto il resto. Gireranno con Android. Avranno la stessa velocità di connessione del vostro PC di casa.

La metrica “visitatore” perde significato
Al crescere delle visite al vostro sito dalle TV, misurare qualsiasi tipo di metrica “visitatore” si discosta sempre più dalla realtà. Innanzitutto le TV sono solo un altro modo con cui un visitatore accede a internet, e nemmeno il primario. E’ lecito aspettarsi che una visita da una TV sarà accompagnata da un’altra visita della stessa persona da un altro dispositivo. Se la media dei visitatori usa due, o tre o quattro device per accedere regolarmente a Internet, è pressoché impossibile misurare cose come “visitatore unico”, “nuove visite”, “tempo dall’ultima visita”, eccetera. Tutte queste misurazioni dovranno concentrarsi sulle visite anziché sul visitatore. [E' un problema che si perde nella notte dei tempi: prima con la questione PC del lavoro - PC di casa, poi con le visite da più browser, oggi con la moltiplicazione dei dispositivi connessi a internet. ndT].
In secondo luogo, a differenza di computer e telefonini, le TV tendono a essere usate da gruppi composti da più di una persona. Questo significa che una visita da una TV può in effetti rappresentare tante persone, facendo perdere alla metrica “visitatore” ancora più senso.

Attribuzione della conversione
Attribuire una conversione a una specifica fonte di traffico diventerà ancora più complesso. Immaginate questo scenario: una persona viene introdotta al vostro sito mentre usa Google TV da un’altra persona, ma decide di finire di esplorare il sito da solo sul proprio computer o cellulare. Come si attribuisce questa conversione? non ci sarà modo di connettere la conversione alla visita dalla TV. E non sarà nemmeno possibile comparare il numero di conversioni al numero di persona che hanno visto la pubblicità in TV.
E ancora, come misurerete le conversioni quando una visita è stimolata da una persona che ha già visto il vostro sito? è una nuova visita? una visita diretta? un referral? Se vi trovano dopo avervi cercato, a che serve sapere che la visita viene da un motore di ricerca, se la prima è stata “spinta” da un vostro affezionato lettore? Questi non sono certo problemi nuovi, ma verranno ulteriormente accentuati.
Potremmo presto accorgerci che l’intero dibattito dell’industria della web analytics sull’attribuzione multi-sorgente delle conversioni sta puntando al problema sbagliato. Quello che dobbiamo assolutamente capire è come la media dei nostri visitatori usa molti dispositivi e in quale ordine. Ben distanti dalla quadratura del cerchio sulle converisioni, il progresso della tecnologia puà solo far aumentare il gap.

Dinamiche di gruppo
Ancora qualche parola sull’audience della TV. Scopriremo presto che i gruppi hanno percorsi di navigazione molto differenti rispetto ai singoli. Immaginate di navigare un sito in gruppo con altri amici. Non importa chi ha il controllo fisico, il gruppo eserciterà una certa influenza sul modo in cui voi interagite col sito. Potreste avere chi vi urla suggerimenti, o chi vi indica aree di interesse su cui cliccare direttamente sullo schermo. Sarete meno in grado di terminare con calma la lettura della pagina per non annoiare il gruppo. Quello che farete online con una TV in salotto rivelerà molto più sulle dinamiche di gruppo rispetto alle tendenze dell’individuo. Le decisioni probabilmente saranno meno stravaganti e più critiche. Esse favoriranno anche convenzioni morali o culturali.
I gruppi hanno anche obiettivi differenti. Saranno meno propoensi a effettuare un acquisto, ad esempio, a meno che esso non coinvolga l’intero gruppo. Le pagine dovranno essere ottimizzate per i gruppi anziché per gli individui.

Applicazioni spearate per siti e TV
Una cosa che rende unica Google TV è il suo approccio nel tentativo di sposare internet e TV è la disponibilità di applicazioni create dagli utenti. A partire dal 2011 il Market di Android avrà applicazioni progettate appositamente per le TV. Queste plasmeranno il modo in cui le TV saranno usate e come siamo abituati a pensare ad esse. Appurate quali saranno le differenti restrizioni che le TV imporranno nella navigazione, le aziende inizieranno a sviluppare siti specifici per le TV, come adesso fanno per i telefonini. Sia per le applicazioni sia per i siti TV la web analytics avrà bisogno di guardare ai report con una prospettiva differente.

Cosa significa Google TV per la web analytics?
Questa lista potrebbe scoraggiare un web analyst. Google TV – e altre tecnologie emergenti – prenderanno la web analytics per l’orecchio. Stiamo appena iniziando a prendere confidenza col significato di alcuni numeri, e questi diventeranno irrilevanti o cambieranno significato. Ma questo non segna la fine della web analytics, né le rende meno affidabile di per sé. Significa solo che gli analisti e le aziende che stanno online un qualche modo dovranno ingegnarsi a interpretare meglio i report.
La cosa eccitante di questa industria è che nessuno ha mai determinato “il modo migliore” di misurare l’attività online. Il dibattito su cosa e come misurarlo deve ancora raggiungere la maturità. L’emergere di Google TV terrà i buoni web analytics sulle spine e aggiungerà nuova linfa al dibattito.

[questa è la traduzione del post "Google TV and web analytics" di Analytics Market. Voi cosa ne pensate?]

Come la maggior parte di voi sa, lo script javascript di Google Analytics è in grado di creare e utilizzare differenti oggetti di monitoraggio per differenti profili e/o account, in modo abbastanza semplice e senza bisogno di incollare due o più volte l’intero codice di monitoraggio. Il metodo con il codice “classico” l’ho descritto nel post “due codici nella stessa pagina“, insieme a potenziali problemi derivati, ma come si fa la stessa cosa con il nuovo codice asincrono?

Alcuni pensano erroneamente che ci sia bisogno di creare un altro oggetto gaq, magari gaq2. Ma gaq è solo una coda in cui i comandi vengono inseriti per essere “smaltiti” appena il processo ha inizio (in modo asincrono rispetto all’esecuzione del codice di Analytics, lo ricordo). E allora cosa bisogna duplicare? l’oggetto di tracciamento, che nella versione standard del codice è sottinteso. Per cui un doppio codice valido è:

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-65432-1']);
_gaq.push(['_trackPageview']);

_gaq.push(['tracker2._setAccount', 'UA-12345-2']);
_gaq.push(['tracker2._trackPageview']);

come vedere, nel primo pezzo di GATC il nome dell’oggetto viene dato per scontato (sarebbe quello che nel codice classico è pageTracker) e non compare, mentre nella seconda porzione è necessario specificarne uno. Tutte le successive chiamate a funzioni legate all’oggetto due, naturalmente, vanno fatte con la sintassi

_gaq.push(['tracker2._nomefunzione', 'eventuali_parametri_aggiuntivi']);

Tracciare automaticamente i link in uscita dal sito è una cosa che tutti chiedono da sempre. E’ vero che ci sono delle soluzioni (alcune anche molto eleganti, una a caso fatta da Francesco Terenzani e me ), ma quel che vuole la gente è qualcosa di semplice. Ebbene, perché non provate ad andare in un report, magari contenuti principali, e segnarvi il contenuto del parametro id= che vedete nell’url?

Poi incollate questo link nella barra degli indirizzi del browser:

https://www.google.com/analytics/reporting/outbound_links?id=XXXXXXXX&pdr=20091201-20100131&cmp=average&view=1#lts=1278179398888

e al posto delle X mettete l’id del vostro profilo. Cosa vedete? (cliccate sull’immagine per ingrandirla)

Per adesso c’è il report, nascosto, ma prima o poi esso verrà mostrato a tutti. Per tracciare automaticamente i link ci sarà bisogno di aggiungere una funzione al codice di tracciamento, ma di questo parleremo a tempo debito, anche se il nome della funzione è già noto.

[hat tip al prode PPC_guru, Top contributor del forum ufficiale di Google Analytics]

Come abbiamo già avuto modo di notare in passato, Google Analytics non ha mai costretto nessuno a effettuare migrazioni del codice di monitoraggio; esse sono semplicemente consigliate. Se anche non usate il nuovo codice asincrono non cambia nulla. Se addirittura avete ancora il vecchio urchin.js, i vostri dati vengono raccolti ugualmente. In questo ultimo caso non potete avvantaggiarvi di alcune delle ultime funzionalità, tipo il tracciamento degli eventi o molte funzioni che esistono solo per ga.js, ma i vostri dati di base ci sono, vengono analizzati.

Mi è venuta in mente questa cosa perché ho letto che da fine luglio la versione v.4 del codice di tracciamento di Yahoo Web Analytics smetterà di funzionare, in favore della v.5. Da un alto trovo giusto che ogni sistema agisca come vuole – ed in Yahoo avranno sicuramente le loro ragioni ed esigenze – dall’altro mi stavo domandando quale dei due metodi sia preferibile. In Google effettivamente fanno fatica a star dietro ai tre metodi con la documentazione, ed ogni situazione andrebbe descritta tre volte, ma così facendo nessuno ha mai perso un dato. Esisteranno clienti di YWA che non hanno letto, in questi anni, o che non si ricordano della deadline? qualcuno perderà dei dati?

quale pensate che sia la soluzione migliore?

[a margine, già che ci siamo: le richieste HTTP alla gif fatte da codice asincrono (leggi questo post se non sai di cosa sto parlando) contengono un parametro aggiuntivo &gaq=1, che non produce nessun dato in Google Analytics, ma che immagino consenta a Google di conoscere puntualmente il numero di installazioni che usano l'ultimissima versione del GATC]

YoYo formazione rotolante ha organizzato per il 12 novembre a Verona un corso avanzato di Google Analytics, chiedendomi se ero disponibile ad esserne il docente. La mia risposta è stata si, perché le premesse erano chiare: “daremo per scontato che tutti conoscano lo strumento base, e non spiegheremo cosa è un bounce o come si installa lo script di monitoraggio.”

Bene, detto fatto! Sappiate che ho intenzione di metterci dentro tutte le robe più toste che conosco, e anche tutte quelle che ancora non conosco Sarà divertentissimo, e devastante!

Se siete interessati, vi rimando al post con tutte le informazioni necessarie.

Se la cosa vi spaventa, sappiate invece che a breve cercherò di definire un paio di cose che mi permetteranno di fissare una seconda data per il corso GA live che ho tenuto il mese scorso, i cui feedback sono stati positivi.

A ulteriore riprova di quanto detto nel post precedente, cioè che ci sarebbe bisogno di una pagina di status unica e universalmente conosciuta dagli utenti di Analytics, sul blog ufficiale è comparso un avviso di “riprocessamento” dei dati, evento raro e mistico che viene scatenato quando ci sono gravi errori nei dati visualizzati nei report.

Traduco:

La scorsa settimana abbiamo fatto una modifica che ha comportato il processamento errato di alcuni dati relativi a visite e campagne. Tutti i dati sono stati correttamente raccolti, ma nei vostri report potrebbero mancare visite per i giorni compresi tra il 24 e il 29 giugno. Stiamo riprocessando i dati e ci aspettiamo che tutti i report siano corretti entro l’inizio della settimana prossima.

Per cui se state per prendere decisioni vitali basandovi su dati relativi a quei giorni, rimandete di un pochino se potete. Il problema è più grande tanto più alto è il numero delle visite del sito.