Google Analytics in 30 secondi

Riprendendo l’idea di Brian Clifton di raggruppare tutte le visite provenienti da social network in modo da poterle analizzare aggregate, ho testato e modificato la sua regular expression per riflettere meglio il traffico italiano.
Naturalmente ogni sito ha una sua storia e una sua collocazione, e fonti di traffico diverse, per cui non è affatto detto che la mia regex calzi a pennello: penso tuttavia che sia un buon punto di partenza per le vostre personalizzazioni.

Il filtro è di tipo avanzato personalizzato.
Campo A -> Estrai A: Sorgente Campagna. Espressione regolare:
wikipedia|stumbleupon|netvibes|groups\.google|bloglines|groups\.yahoo\.com|linkedin|facebook|oknotizie|del\.icio\.us|digg|twitter|technorati|faves\.com|newsgator|segnalo|wikio|liquida\.it|blogbabel|kipapa|bookmark\.it
Campo B -> Estrai B: vuoto
Output in -> Constructor: Mezzo della campagna. Nome: social network
Campo A obbligatorio: Sì
Campo B obbligatorio: Sì
Sostituisci campo di output: Si
Maiuscole/minuscole: No

Questo filtro lo si vedrà in azione nel report Sorgenti di traffico -> tutte le sorgenti di traffico e selezionando la dimensione Mezzo, come in figura:

Una cosa da notare è che il filtro cambia il mezzo di arrivo sul sito da parte dei visitatori, per cui tutti i siti di riferimento che inviano visitatori scompaiono dal report referrer e vengono mostrati solo qui. E’ una precisazione importante che va fatta prima di decidere se applicare o meno la modifica ai profili.

un sentito grazie a Maurizio Petrone per la consulenza sui social network italiani, che forse userò anche per un’altra cosa da proporvi

Secondo la guida ufficiale di Google Analytics in lingua inglese, il campo “lookup table” dei filtri personalizzati (“tabella di ricerca” in italiano) serve a

Lookup Table: (Currently unavailable) Selecting this filter allows you to select a lookup table name which may be used to map codes to human intelligible labels.

selezionare questo filtro permette di scegliere una tabella di ricerca che può essere usata per trasformare codici in informazioni utili ed etichette leggibili.

In sostanza potete avere una tabella che trasforma una serie di numeri in nomi parlanti di prodotti (un po’ come avere una serie molto grande di filtri “cerca e sostituisci”). Praticamente una tabella di ricerca era costituita da un foglio di calcolo con due colonne: la prima conteneva il parametro dell’URL da tradurre e la seconda la traduzione che avremmo letto nei report. Il problema è che questa funzionalità è disattivata da parecchio tempo, e da quando mi occupo di filtri su Google Analytics l’ho vista attiva per pochissimo tempo; comunque era necessario inviare la tabella via email indicando l’account e aspettare che gli ingegneri la caricassero.

Mi stavo domandando quanto tempo ci vorrà prima che Google abiliti una feature che mi sembra abbastanza banale e immediata: l’upload di questo file sul Google Docs esistente tramite lo stesso Google Account di Analytics. Nominando il file secondo una convenzione si potrebbe far confluire in uno specifico account, e poi sarebbe disponibile nei filtri. E si sgraverebbero anche gli ingegneri dal lavoro: sostituendo il file su GDocs si avrebbe una nuova tabella automaticamente.

[image credit: jayfreshuk on flickr]

La funzione _setDomainName(stringa) serve a impostare o forzare il dominio nei cookie di GA; questa informazione scritta nel cookie è infatti la sola che Google Analytics usa per determinare su quale dominio stia avvenendo la visita dell’utente. _setDomainName può assumere tre soli valori, cioè “auto”, “none” o il nome del dominio, e per definizione – ovvero quando non è invocata esplicitamente – è impostata su “auto”: questo fa si che GA scriva nel cookie il dominio estrapolandolo dall’oggetto location del DOM (Document Object Model).

Un esempio tipico in cui è necessario utilizzare questa funzione è la tracciatura di un dominio e un sottodominio nello stesso profilo, poniamo www.miosito.it e sub.miosito.it. Per prima cosa bisogna aggiungere al codice di monitoraggio la seguente riga
pageTracker._setDomainName(".miosito.it");
facendo bene attenzione al punto prima del dominio (è all’incirca equivalente a dire *.miosito.it), dopodiché è consigliato impostare un filtro per discernere le pagine all’interno dei report. Essendo i domini tracciati come fossero una sola cosa, infatti, le visite corrispondenti a www.miosito.it/index.asp e sub.miosito.it/index.asp verrebbero sommate a livello di pageview. Il filtro è questo:

e scrive al posto dell’URI della richiesta (index.asp) la stringa completa host-URI (www.miosito.it/index.asp).

L’ultima modalità di chiamata a _setDomainName() è “none” e va usata nel caso in cui si voglia disabilitare il tracciamento tra domini differenti o in quello molto più frequente in cui si voglia farlo avendone però il preciso controllo, quindi usandolo in congiunzione alle funzioni _setAllowLinker(), Link() e Linkbypost() che vedremo prossimamente.

Se non vi piace il filtro che ho proposto nel post “filtrare solo il proprio dominio mantenendo la cache di Google” perché non trovate così rilevante il problema o perché volete avere ugualmente sotto controllo anche le visite tracciate dal vostro codice di monitoraggio su domini esterni (che non comprendono solo la copia cache di Google, ma anche i servizi di traduzione, o le cache degli altri motori di ricerca o di servizi terzi) esistono due filtri che vi permettono di raggruppare tutte queste visite per poter effettuare selettivamente efficaci segmentazioni. E’ una soluzione che propone Chadwick A. Wood in un suo post, e che è simile concettualmente a quella che ho proposto io in ambito leggermente differente.

primo filtro:

nome: Organize traffic by domain
campo A -> Estrai A: Hostname | ^(.*)$
campo B -> Estrai B: Request URI | ^(.*)$
Output in -> Constructor: Request URI | /otherdomains/$A1$B1
Campo A obbligatorio SI
Campo B obbligatorio SI
Sostituisci Campo di output SI
Maiuscole/minuscole NO

secondo filtro:

nome: Don’t organize my traffic by domain
Campo A -> estrai A: Request URI | ^/otherdomains/www\.mydomain\.com(.*)$
Campo B -> estrai B: –
Output in -> Constructor: Request URI | $A1
Campo A obbligatorio SI
Campo B obbligatorio NO
Sostituisci Campo di output SI
Maiuscole/minuscole NO

L’ordine dei due filtri è fondamentale. In sostanza questi due filtri riscrivono sempre e comunque l’hostname nella forma hostname+URI della richiesta, salvo poi cancellare l’hostname nel caso in cui combaci con il nostro dominio. All’atto pratico una visita dalla cache di Google viene trasformata in otherdomain/www.google.com/search=q… e una dal nostro dominio otherdomain/www.goanalytics.info/index.php, mentre al secondo passaggio la prima visita rimante tale e quale, la seconda torna a essere www.goanalytics.info/index.php

Si fa un lavoro doppio, ma il report Visitatori > Nomi host ora dovrebbe essere molto più ordinato

L’altro giorno un cliente è rimasto stupito quando gli ho detto che Google Analytics non fa distinzione sul dominio di provenienza dei dati raccolti dal GATC, sorprendendosi che fosse quindi relativamente semplice “inquinare” i report degli altri. La sua obiezione era che il sistema durante la configurazione iniziale chiede all’utente quale sia il dominio sul quale il codice sarà installato, e che quindi è assolutamente in grado di distinguere e filtrare a monte la provenienza: tutto corretto, tecnicamente è possibile ma… Google non lo fa (ho condotto io stesso un test tempo fa), e non lo fa per una scelta ben precisa presa dagli ingegneri che lo hanno progettato. Secondo la mia interpretazione è perché è più facile che l’utente medio debba tracciare con lo stesso codice pagine su più domini, piuttosto che il contrario, e tramite i filtri è possibile ugualmente fare una scrematura, ribaltando però l’onere a chi sa operare in modo avanzato.

Non è possibile impedire che qualcuno – in buona o cattiva fede – copi il nostro codice di Analytics sulle sue pagine, quindi l’unico modo per scremare i dati è impostare un filtro personalizzato di inclusione basato sul nome dell’host la cui regex in italiano dice “prendi esclusivamente quel che inizia con il nome a dominio specificato” ( ^www\.miodominio\.it ), come in figura

Nell’ordine dei filtri assegnati a ogni profilo, se presente, questo deve essere il primo applicato.

Il primo perfezionamento possibile riguarda il caso in cui sul webserver risieda solo il nostro sito, o se comunque digitando l’indirizzo IP del server il nostro sito viene correttamente visualizzato. Poiché il dato dell’host viene trasmesso così com’è visualizzato nel browser, un eventuale URL nella forma http://123.123.123.123/nomedellapagina.htm verrebbe rifiutato dal filtro originale. E’ quindi necessario inserire questa eccezione, tramite un semplice OR. Trasformeremo la regex in ^www\.miodominio\.it|123\.123\.123\.123

Il secondo perfezionamento riguarda la cache di Google: essendo una copia fedele dell’originale, le pagine in cache contengono il nostro codice di Analytics, e ogni volta che sono visualizzate generano una visita e una pagina vista nel nostro profilo di monitoraggio. Ritengo utile non perdere questa informazione, perché un elevato numero di visualizzazioni della copia cache dovrebbe farci venire in mente alcune domande: “perché la gente clicca spesso la copia cache invece di visitare il sito?” “vogliono una informazione che ho rimosso?” “la pagina ha problemi tecnici e quindi tutti optano per la copia?” eccetera. Tipicamente la URL di una copia cache è fatta così:

http://74.125.39.104/search?q=cache:sfwEWjsUtwIJ:www.goanalytics.info/+goanalytics&hl=it&ct=clnk&cd=2&gl=it

I problemi sono due: il primo è che in GA non è possibile fare un filtro che operi in parallelo su due campi differenti, nel nostro caso il nome dell’host (che contiene il nostro dominio quando una visita è “buona”) e l’URI della richiesta (che contiene il dominio di Google ma ha nell’URL l’indicazione che una visita viene fatta sulla copia cache); il secondo problema è che l’elenco dei server di Google che forniscono la copia cache è molto grande e difficile da tenere aggiornato (e sicuramente sorpasserebbe il limite massimo di 256 caratteri possibili per comporre una regex). La soluzione è un filtro in due passi che concettualmente raggruppa host e URI in un unico campo e poi applica una regex che in italiano dice “o inizia con il mio nome a dominio, o il mio IP, oppure ha nell’url la stringa cache:{caratteri}:miodominio”

Il primo filtro

Filtro personalizzato avanzato
Nome: solomiodominio+cache – step1
Campo A -> Estrai A: Nome dell’host (.*)
Campo B -> Estrai B: URI della richiesta (.*)
Output in -> Constructor: Campo personalizzato 1 $A1$B1
Campo A obbligatorio SI
Campo B obbligatorio SI
Sostituisci Campo di output SI
Maiuscole/minuscole NO

Il secondo filtro

Filtro personalizzato di inclusione
Nome: solomiodominio+cache – step2
Campo filtro: Campo personalizzato 1
Pattern filtro: (^www\.miodominio\.it)|(123\.123\.123\.123)|(cache\:[a-zA-Z0-9_-]+\:www\.miodominio\.it)
Maiuscole/minuscole NO

L’ordine dei due filtri è fondamentale, e se applicati ad un profilo devono essere i primi due