Google Analytics in 30 secondi

Oggi voglio segnalare due strumenti che potrebbero tornarvi utili se usate Google Analytics e spesso avete necessità di avere i dati anche fuori dalla sua interfaccia.

Il primo strumento è carino anche se relativamente utile, ma è indubbiamente più performante della carta geografica dei visitatori che propone GA: si tratta della possibilità di visualizzare la provenienza geografica delle visite su un comodo livello di Google Earth.
Per utilizzarlo bisogna andare nel report Visitatori -> Overlay carta geografica, selezionare il periodo temporale e il livello di dettaglio desiderato (città o paese, gli altri due non rendono bene), esportare tutto in xml e dare in pasto il file alla pagina che ho linkato, che restituirà un file .klm da aprire in Google Earth. I simbolini colorati rappresentano il numero di visite provenienti da quella città o da quel paese; ad esempio una puntina gialla significa tra le 0 e le 50 visite, mentre un segnaposto verde tra le 4000 e le 8000 visite.

Il secondo strumento invece è decisamente più utile, e sfrutta le API di esportazione per “tirare dentro” Excel i dati di Google Analytics. Quante volte infatti durante le analisi più spinte e gli incroci di dati più estremi siamo stati costretti ad esportare i report da GA in CSV (o direttamente in Google Docs, se avete letto questo mio vecchio post), per poi importarli in Excel? e quante volte abbiamo dovuto rifare il procedimento perché avevamo un nuovo set di dati offline e dovevamo allineare i dati di Analytics? da oggi tutto questo fa parte di un modo di lavorare passato, i dati saranno sempre aggiornati e nella cella giusta!

Per fare ciò è necessario aprire Excel, poi strumenti -> macro -> visual basic editor. da lì tasto destro su VBAproject (Cartel1) – che dovrebbe essere il nome predefinito del progetto, almeno su Excel 2003 – e inserisci -> modulo.
A questo punto andare sulla pagina personale di Mikael Thuneberg, copiare tutto il codice e incollarlo nella finestra del modulo di Excel. Poi andare su strumenti -> riferimenti e aggiungere una selezione su Microsoft XML, v6.0, premere OK e poi salvare il lavoro Cartel1. Chiudere la finestra di Visual Basic Editor e salvare il file tramite file -> salva con nome… scegliere come tipo di file componente aggiuntivo di Microsoft Excel (*.xla) e salvarlo nella cartella AddIns (che su Windows vista è in /nomeutente/AppData/Roaming/Microsoft/Addins, ma su altri sistemi operativi potrebbe trovarsi altrove. Di norma Excel propone da solo la cartella giusta alla selezione degli xla) con il nome – ad esempio – di GA.xla. Ora da strumenti -> componenti aggiuntivi mettere la spunta su GA e premere OK e riavviare Excel.

Le due funzioni sono disponibili dal menu Inserisci -> funzione nella sezione definite dall’utente, e sono:

• getGAautheticationToken: dati una email e una password richiama una stringa necessaria per le interrogazioni successive
• getGAdata: dati una serie di parametri di ingresso (il numero dell’account, il periodo temporale, le metriche e i filtri) richiama da Google Analytics i dati necessari e li memorizza in Excel

Da notare che il sistema non funziona se si è dietro a un proxy, richiede una connessione a internet diretta.
Per fare lo stesso mestiere esisterebbe anche Excellent Analytics, ma ha come prerequisito Excel 2007, per cui non l’ho potuto provare.

[edit: 13 agosto: Il blog ufficiale ha un nuovo post con altri strumenti per integrare GA ed Excel]

Nel post in cui spiegavo l’uso di _setVar() ho detto che Google mette a disposizione un unico cookie contenente un solo valore e che quindi l’unico modo per avere più dati riferiti ad un unico visitatore dentro al segmento “definito dall’utente” senza sovrascriverne altri era di separarli con un segno pipe (o altri segni convenzionali); inoltre auspicavo che Google aumentasse questo limite di Analytics.

Ebbene, mi ero dimenticato che in realtà il prolifico blog di Lunametrics aveva già ovviato a questa situazione nell’aprile del 2008, con un magnifico lavoro di John Henson. In verità la tecnica non è molto difforme dalla precedente, ma aggiunge dei controlli che potrebbero risultare utili.

Ad esempio – seguendo l’esempio di John – impostando due chiamate a

superSetVar('/eyes=blue');
superSetVar('/hair=blonde');

il cookie __utmv li conterrà entrambi. Ma se l’utente diventasse calvo ( 😀 ) e volesse informarne il sito, John ci mette a disposizione una comoda funzione di “unset”:

unSetVar('/hair=');

in grado di ripulire solo i valori associati ai capelli, per poi eventualmente riscriverli.
Per usare questo nuovo set di funzioni è sufficiente scaricare il file super_set_var.js dal sito di Lunametrics e caricarlo sul proprio sito, poi modificare il GATC di Google Analytics aggiungendo una riga

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript" src="/path/to/super_set_var.js"></script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-xxxx-y");
. . .
</script>

dove /path/to/ è il percorso dove si trova il file, UA-xxxx-y è il vostro profilo di GA e . . . sono eventuali altre funzioni aggiuntive del codice di monitoraggio.
Una cosa da tenere presente è che le modifiche fatte al cookie __utmv valgono solo dalla sessione successiva del visitatore.

Con un messaggio postato sul gruppo di notifica ufficiale delle API di esportazione dei dati, Google ha reso note alcune novità che probabilmente faranno felici gli sviluppatori:

• sono state allentate alcune restrizioni sulle combinazioni tra metriche e dimensioni incrociabili. ga:pagePath e ga:source, ad esempio, è adesso una combinazione valida. (vi ricordo che la lista delle combinazioni possibili la potete trovare in questa pagina)
• il numero totale di righe che possono essere domandate con una singola richiesta è adesso 10000 (mentre prima era 1000, che rimane sempre l’opzione di default, ma può essere variato. Se sia un potenziamento dell’infrastruttura o una conseguenza per lo scarso uso che finora è stato fatto delle API non è dato saperlo)
• Google sta forzando il sistema affinché in ogni richiesta sia presente almeno una metrica valida

Avete già iniziato ad usare le API per qualche vostro progetto? avete intenzione di farlo?

Mi sono accorto che pur avendone parlato più volte non ho mai scritto il post di riferimento della funzione _setVar(stringa). Questa funzione serve a scrivere un valore all’interno del cookie __utmv, e il valore è a discrezione del webmaster del sito; una volta che il contenuto del cookie è impostato, esso verrà trasmesso in tutti i successivi invii di codice a Google Analytics (ovvero ogni volta che verrà richiamata la gif trasparente), permettendo così di “taggare” il visitatore (attenzione: il visitatore e non le visite).
Un esempio tipico è quello di assegnare tramite _setVar il valore “loggato” a chi effettua il login sul sito, in modo da poter discernere la sua attività da quella di chi non l’ha fatto.

L’uso è molto semplice, si tratta di impostare la riga

trackPageview._setVar('miovalore');

in un punto qualsiasi della pagina, sull’onclick di un elemento, sull’onload del body. Ovunque insomma ci sia bisogno di impostare il cookie che da lì in poi – e per i successivi due anni – manterrà il valore, a meno che esso non sia sostituito da un’altra funzione _setVar impostata dal medesimo codice di GA (quindi le _setVar di due siti diversi non interferiscono, come è ovvio che sia). Su un blog WordPress, ad esempio, sarebbe possibile assegnare un valore corrispondente al livello dell’utente che si collega (Administrator, Editor, Contributor, ecc.).
Il famoso sistema supercookie per tracciare tutte le fonti di una conversione separa diversi valori di setvar con un segno | (pipe), e lo fa per ovviare all’unico vero grande limite di questa gestione da parte di GA: esiste un solo cookie __utmv, quindi si può attribuire un solo valore ad ogni utente; oppure si possono assegnare più valori come nel supercookie, ma essi verranno sempre riportati come aggregati (per intenderci, ogni valore è una riga del report).
La speranza di tutti noi è che un giorno Google decida di aumentare i possibili valori di questo cookie mantenendoli però separati, perché la gestione della funzione _setVar() è molto comoda.

A livello di report il valore impostato da _setVar() viene scritto nel campo “Definito dall’utente” (User Defined se usi l’interfaccia inglese) e lo si può trovare nel report omonimo all’interno del gruppo “visitatori” oppure come valore utilizzabile nel menu a tendina delle segmentazioni. Una lettura esaustiva, in inglese, sui report relativi alla segmentazione viene da morevisibility.com, da cui si evincono due informazioni interessanti:

• nel caso in cui un utente cambi il valore di _setVar() durante una sessione di visita, GA attribuirà l’eventuale conversione al primo valore letto per quella sessione.
• le pagine viste, al contrario, vengono tutte attribuite all’ultimo valore

Un’altra cosa su cui vale la pena di ragionare è che _setVar() rappresenta l’unico punto di ingresso in GA in cui è possibile inserire un valore arbitrario. Tutti gli altri valori infatti dipendono dall’attività di navigazione e sono dati puri o derivati da calcoli. Questo cosa significa? significa che, fatte salve le limitazioni sulla privacy imposte dai termini del servizio, dentro al cookie __utmv possiamo infilare qualsiasi cosa ci sia utile avere direttamente dentro all’interfaccia di Google Analytics affinché possa essere incrociata con gli altri dati, ad esempio i dati demografici dei visitatori da utilizzare successivamente per il bidding demografico di AdWords.

[edit: è uscito giusto in questi giorni un post sul blog ufficiale che parla dei segmenti definiti dall’utente e di _setVar()]

In passato vi ho descritto l’uso della funzione _trackEvent(), utile per usare il tracciamento degli eventi sulle pagine ed evitare di generate troppe pagine virtuali o per tracciare comportamenti complessi dell’utente indipendentemente dalla sua attività (ad esempio per tenere traccia degli eventi in AJAX, che tipicamente non ricaricano la pagina e quindi non generano un nuovo invio di dati a Google Analytics).

Un caso un po’ anomalo è capitato ad un utente del forum di supporto: venablc ha bisogno di chiamare la funzione _trackEvent() senza richiamare anche _trackPageview(), probabilmente perché sta inviando i soli dati degli eventi ad un altro profilo e non vuole vedere le pagine viste; omettendo semplicemente la chiamata il codice non funziona e la consolle degli errori javascript riporta un laconico errore di “oggetto non definito”.

La soluzione al problema è resuscitare la defunta funzione _initData(), soppressa qualche tempo fa. L’oggetto che manca a _trackEvent infatti viene creato da _initData(), che a sua volta è richiamata automaticamente da _trackPageview(). Ma nessuno ci vieta di chiamarla esplicitamente, evitando di inviare i dati della pagina vista ma consentendo a _trackEvent() di funzionare regolarmente!
[ovviamente quanto detto vale per il caso specifico e può essere adattato alle vostre esigenze senza dimenticare quanto detto in questo altro post: o initData ce l’avete in tutte le pagine o non ce l’avete in nessuna, per quanto riguarda il profilo che raccoglie i dati]

Una delle più accese discussioni nel forum ufficiale e nella twittersfera ultimamente è quella relativa ad un presunto problema di sicurezza del codice di Google Analytics, per cui i visitatori vengono infettati. Un ottimo riassunto della questione la fa Stéphane Hamel sul suo blog.

Il problema non è relativo al codice di GA, ma prende di mira il codice di GA. In sostanza attraverso un accesso non autorizzato allo spazio sul server che ospita il sito, viene introdotta una regular expression javascript nel codice del sito in grado di cambiare la chiamata a http://www.google-analytics.com/ga.js in ttp://91.212.65.148/ga.js. Questo file poi esegue un’altro script php che sfrutta una vulnerabilità di Adobe Reader per infiltrarsi nei PC dei visitatori. Come già detto, questo non è un problema di Google Analytics, ma è un problema che prende di mira Google Analytics per via del fatto che è molto usato sui siti (ricordate? più del 50% dei diecimila siti più popolari secondo Alexa) di tutto il mondo.

Il modo migliore per capire se si ha a che fare con il problema è dare un’occhiata al codice sorgente di una propria pagina: se il codice di GA è sempre il solito, come lo conosciamo, non c’è problema; Se al contrario sono presenti caratteri strani ( @ # $ eccetera) allora è il caso di preoccuparsi. Nel qual caso è bene pulire il proprio PC con antivirus, antitrojan e antispyware, cambiare le password FTP del sito (e magari usare sFTP (secure File Transfer Protocol) invece del normale FTP, e reincollare il codice corretto di GA, che trovate ovviamente in modifica del profilo -> verifica stato

Quello che vedete nell’immagine qui a fianco è un pezzo del codice sorgente del javascript di Google Analytics, per capirsi quello che è visibile all’indirizzo http://www.google-analytics.com/ga.js. Si tratta del file contenente tutte le funzioni di base che permettono al codice di catturare ed inviare i dati che poi leggiamo nei nostri report.

A tutti gli effetti è un normale file javascript, ma per contenerne le dimensioni gli ingegneri di Google hanno fatto due cose: hanno eliminato gli spazi superflui e gli “a capo” e hanno chiamato tutte le variabili e le funzioni con nomi di lettere, due cose che gli esseri umani non fanno mai quando scrivono codice, per leggibilità e manutenzione, ma che non dà nessun fastidio ai computer che le istruzioni le eseguono.

Se per caso avete necessità di leggere il sorgente, perché volete capire cosa fa una certa funzione, perché volete estenderla o per curiosità, è indubbiamente più utile far tornare almeno gli spazi e i ritorni di riga, visto che non è possibile riassegnare alle funzioni nomi parlanti in modo automatico. Per avere un file leggibile basta andare all’url del sorgente, selezionarlo tutto e copiarlo, e poi incollarlo nello strumento Javascript Beautifier, che ce ne renderà una versione decisamente più digeribile per i nostri occhi. Le prime righe ad esempio diventano:

var _gat = new Object({
    c: "length",
    lb: "4.3.1",

il che tra l’altro mi fa notare al volo che la versione corrente dello script è passata da 4.3 a 4.3.1. Probabilmente in concomitanza con l’introduzione di Bing tra i motori di ricerca riconosciuti.

[tnx to AnalyticsPros]

Keep it simple, stupid è una locuzione anglosassone che viene spesso indicata tramite il suo acronimo K.I.S.S. e significa “falla semplice, stupido”. Viene spesso associata al mondo dell’informatica, dove il grado di complicazione tende a salire molto velocemente e dove esistono sempre soluzioni e accorgimenti che, con molto lavoro in più, riescono a fare quello che ci prefiggiamo.

Bruno Munari, che di informatica penso ne sapesse ben poco, diceva in un suo celebre scritto:

Complicare è facile, semplificare è difficile. Per complicare basta aggiungere, tutto quello che si vuole: colori, forme, azioni, decorazioni, personaggi, ambienti pieni di cose. Tutti sono capaci di complicare. Pochi sono capaci di semplificare.
Piero Angela ha detto un giorno è difficile essere facili. Per semplificare bisogna togliere, e per togliere bisogna sapere cosa togliere

e questa è la frase che riporto sempre quando parlo con qualcuno delle famigerate regular expression di Google Analytics. Prendiamo questo caso reale dal forum di assistenza inglese:

Filter: Exclude traffic from IP addresses in the range of 1 to 9 and 11 to 255.
Filter design: ^(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[2-9][0-9]|1[1-9]|[0-9])\.
Result in Google: 0 page views.

Che gli IP possibili sono solo 256 (da 0 a 255) spero sia chiaro anche all’autore, altrimenti serve un ripassino di base sulla tecnica di internet, e non ha senso lanciarsi a fare un filtro senza sapere cosa e come si deve filtrare. Ora, assunto che la regola sia chiara, perché mai fare un filtro complicato per escludere tutti gli IP da 1 a 9 e da 11 a 255?

Fai un filtro che include solo 0 o 10! eccolo:
(0|10)
🙂

Mi sembra di intravedere una certa regolarità negli upgrade ad Analytics da parte di Google; a giro si dedica alll’interfaccia, alle funzionalità e all’integrazione. Direi che questo è il periodo dell’integrazione, e infatti abbiamo due novità relative ad AdWords nel giro di pochi giorni.

La prima è che adesso si possono importare gli obiettivi di conversione e le transazioni e-commerce da Analytics ad AdWords, per ottimizzare le campagne direttamente dentro ad esso e poter usare lo strumento di ottimizzazione delle campagne. Stiamo parlando però, ovviamente, di obiettivi che ricevono traffico (e conversioni) da campagne AdWords.
I passi da effettuare per avere questa integrazione sono abbastanza semplici: per prima cosa è necessario abilitare la condivisione dei dati almeno con i prodotti Google (“Solo con altri prodotti Google”), dal menu Modifica dell’account -> Condividi i miei dati Google Analytics, dopodiché dall’interfaccia AdWords, pagina delle conversioni, cliccare su “collega obiettivi e transazioni di Analytics”, selezionare quali obiettivi importare dalla lista e salvare.

La seconda novità è che Google ha sanato una situazione che si era venuta a creare a Marzo, quando per motivi di sicurezza venne richiesto che l’import dei costi AdWords verso Analytics fosse possibile solo dopo aver collegato i due account. Coloro i quali avevano gli account collegati, avevano l’auto tagging delle campagne ma non applicavano l’import dei costi si erano ritrovati a vedere come diretto del traffico che in realtà veniva da AdWords. Da oggi questo problema non si presenta più e il traffico torna ad essere conteggiato come mezzo cpc e sorgente google.

Giovanni mi segnala per email un articolo molto molto interessante per chi ha il cruccio del last cookie win / first cookie win. Ricordo infatti a tutti che Google Analytics è un sistema “last cookie win”, in cui la conversione viene attribuita all’ultima sorgente che ha portato la visita, con alcune regole specifiche per il traffico diretto. Altri sistemi invece preferiscono la logica del “first cookie win” (e su GA possiamo impostarla sulle campagne taggate tramite il parametro no_override), ma quale che sia la logica applicata il difetto che tutti riconoscono è quello di non consentire di tenere traccia di tutte le diverse sorgenti che hanno contribuito a formare nel cliente la decisione di convertire.

So che alcuni sistemi stanno provando (non l’ho mai provato, e correggetemi se sbaglio, ma mi pare che sitovivo abbia una soluzione di questo tipo) a sviluppare logiche miste di attribuzione di una conversione a più sorgenti, ma da oggi grazie al lavoro di un Google Analytics Authorized Consultant possiamo avere qualcosa di similare – ancorché abbastanza di base – per tracciare tutte le sorgenti che hanno concorso ad una conversione: loro lo chiamano “super cookie“.

Questo super cookie si occupa di raccogliere il referrer di ogni visita, di salvarlo in un nuovo cookie chiamato _utmcw e di chiamare la funzione _setVar() impostando il valore di questo cookie come parametro della funzione stessa. I vari referrer non vengono sovrascritti ma messi in coda e separati da un carattere |.
Attraverso un rapporto personalizzato, composto almeno dal parametro “totale completamenti all’obiettivo” e della dimensione “valore definito dall’utente”, avremo modo di verificare tutte le sorgenti che hanno generato conversioni, nella forma (e nell’ordine esatto) ad esempio di:

direct|google(organic)(keyword1)|yahoo(organic)(keyword2)|direct|referral(www.sitoesterno.it)

che ad esempio si riferisce ad una conversione avvenuta alla quinta visita, la prima delle quali diretta (digitazione dell’url o bookmark, ad esempio), la seconda da google con ricerca keyword1, la terza da yahoo con ricerca keyword2, la quarta diretta e la quinta tramite un link dal sito sitoesterno.it. Tramite il super cookie si possono ad esempio conoscere esattamente TUTTE le parole chiave e le frasi che sono state cercate dall’utente prima di convertire

Il punto forte di questo script è che ricostruisce da solo la sorgente, evitando il problema della discrepanza di scrittura del cookie quando avvengono due referral nella stessa sessione di cui vi ho già parlato.

Il punto debole, come ho fatto notare nel post degli autori, è che non è previsto (ma non saprei nemmeno come implementare) un meccanismo di pulizia del super cookie, che continua ad essere aggiornato anche dopo la conversione. Per un visitatore regolare che non pulisce mai i cookie c’è il rischio che esso si gonfi senza sosta. Un punto intermedio è che il supercookie traccia e scrive solo visite provenienti dalle sorgenti “standard”, quindi traffico diretto, referral, ricerche organiche e CPC. Per tracciare anche le campagne, ad esempio le campagne email taggate, il sorgente javascript dello script andrebbe modificato, e sono sicuro che essendo GAAC loro possono sicuramente farvi avere un preventivo per questa operazione 🙂

L’utilizzo dello script è abbastanza semplice. si tratta di scaricare il file dal post linkato, aprire il file cw-algorithm.js e modificare la riga 7
var __ignore = "www.ignore.co.uk";
inserendo l’indirizzo del sito che ospita lo script. Dopodiché caricare i due file sul server web e modificare il codice di tracciamento di Analytics come segue:

<script type="text/javascript"> 
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script> 
 
<script type="text/javascript" src="/cw-setup.js"></script> 
 
<script type="text/javascript"> 
var cookieTracker = _gat._getTracker("UA-XXXXXX-X");
cookieTracker._trackPageview();
</script> 
 
<script type="text/javascript" src="/cw-algorythm.js"></script> 
 
<script type="text/javascript"> 
cookieTracker._setVar(ConversionWorks);
</script> 
 
<script type="text/javascript"> 
var pageTracker = _gat._getTracker('UA-XXXXXX-X');
pageTracker._trackPageview();
</script> 

sostituendo ai vari UA-XXXXXX-X il vostro numero di UA. Notare che la parte di codice riferita a cookieTracker non è un errore, e serve a non sporcare i vostri cookie di default con i valori del super cookie.

In definitiva mi sembra un’aggiunta utile a chi non è soddisfatto del modo in cui vengono attribuite le conversioni alle sorgenti, e una fonte di informazioni utili a prescindere per tutti gli altri. Se il vostro “Valore definito dall’utente” (e/o la vostra funzione _setVar() ) è vuoto, questo può sicuramente essere un sistema valido per usarlo.

Post originale su conversion works e pacchetto da scaricare

image credit: conversionworks.co.uk