Google Analytics in 30 secondi

Il post precedente ha riscosso un certo interesse nel mondo dei SEO e di chi fa web analytics. Una delle critiche più grandi mosse al metodo riportato è che non è molto chiaro che start=30 non significa pagina 30, ma pagina 2. Per questo motivo Damon Gudaitis ha scritto alcuni altri filtri per sistemare la cosa. Purtroppo il grado di complicazione introdotto non giustifica sempre lo sforzo richiesto, per cui il mio consiglio è di procedere solo se non siete soddisfatti del metodo precedente e se leggendo questo post avrete tutto chiaro.

Il “metodo Damon” estende il tracking anche a Yahoo e MSN. Vi traduco le istruzioni step-by-step, da applicare naturalmente sempre ad un profilo copia:

Filtrare solo il traffico organico:

1. selezionare la gestione filtri dalla schermata principale
2. cliccare su aggiungi filtro
3. assegnare al filtro il nome Traffico Organico
4. scegliere filtro personalizzato dal menu a tendina e selezionare includi
5. nel Campo filtro selezionare Mezzo della Campagna
6. nel Pattern filtro inserire organic
7. applicare il filtro al profilo-copia desiderato
8. salvare le modifiche

Restringere il profilo a Google, Yahoo e MSN:

1. cliccare aggiungi filtro
2. assegnare al filtro il nome Visitatori da motori di ricerca
3. scegliere filtro personalizzato dal menu a tendina e selezionare includi
4. nel campo filtro selezionare Referral
5. nel Pattern filtro inserire (google|yahoo|msn|live)\.[a-z]+
6. assegnare il filtro al profilo-copia desiderato
7. salvare le modifiche

Estrarre le informazioni desiderate dalle SERP di riferimento:

1. cliccare aggiungi filtro
2. assegnare al filtro il nome Search Ranking
3. scegliere filtro personalizzato dal menu a tendina e selezionare avanzato
4. Campo A -> Estrai A, selezionare Termine Campagna e inserire (.*)
5. Campo B -> Estrai B, selezionare Referral e inserire (\?|&)(start|first|b)=([^&]*)
6. Output in -> Constructor, selezionare Definito dall’utente e inserire $A1 | pagina: $B3
7. applicare il filtro al profilo-copia desiderato
8. salvare le modifiche

Formattare correttamente la pagina 1:

1. cliccare aggiungi filtro
2. assegnare al filtro il nome Pagina 1
3. scegliere filtro personalizzato dal menu a tendina, poi selezionare Cerca e sostituisci
4. Campo filtro, selezionare Definito dall’utente. Cerca stringa, scrivere pagina:$
5. Sostituisci stringa, scrivere pagina: 1
6. applicare il filtro al profilo-copia desiderato
7. salvare le modifiche

Formattare correttamente le pagine 2,3, eccetera:
[la ragione per cui le espressioni regolari comprendono 10 e 11, ad esempio, è che Google fa iniziare pagina 2 dal risultato #10, Yahoo e MSN invece dal risultato #11]

1. per ogni pagina che si vuole tracciare, cliccare aggiungi filtro
2. assegnare al filtro il nome Pagina 2 (o 3, 4, eccetera…)
3. scegliere filtro personalizzato dal menu a tendina, poi selezionare Cerca e sostituisci
4. Campo filtro, scegliere Definito dall’utente
5. Cerca stringa, inserire pagina: 1[0-1]$ (o pagina: 2[0-1]$ per pagina 3, pagina: 3[0-1]$ per pagina 4 ecetera…)
6. Sostituisci stringa, inserire pagina 2 (o pagina 3 eccetera…)
7. applicare il filtro al profilo-copia desiderato
8. salvare le modifiche

Ordine dei filtri:
Mai come in questo caso l’ordine dei filtri è importante; i filtri che riformattano i numeri di pagina vanno in rigoroso ordine numerico crescente, pena il caos.
L’ordine dei filtri funzionante è questo:

- Traffico Organico
- Visitatori da motori di ricerca
- Search Ranking
- Pagina 1
- Pagina 2
- Pagina 3, eccetera…

La soluzione non mi fa impazzire di gioia, se ricevete visite anche da pagina 12 delle SERP avrete bisogno di 12 filtri per riformattare correttamente i numeri di pagina, ma d’altronde i filtri cerca e sostituisci non sono così versatili da includere una regular expression unica che modifichi tutto. Se proprio sentite l’esigenza di avere i numeri di pagina corretti, questo è quel che dovete fare…

La primissima versione di Google Analytics aveva due viste predefinite sui dati, una più dedicata ai webmaster e una più dedicata al reparto marketing; questa differenziazione si è poi perduta con l’introduzione della versione 2.0. Per i SEO invece non c’è mai stato niente di esplicito, anche se tutti sappiamo quanto lo strumento possa essere utile a chi si occupa di ottimizzazione.
André Scholten, olandese, ha scritto sul suo blog e tradotto su Yoast.com un articolo interessante che permette di creare un profilo-copia in cui ogni keyword usata per arrivare al sito è accompagnata dal numero di pagina in cui era ospitata sulle SERP (pagine dei risultati dei motori).
In realtà si tratta di tre filtri, il terzo dei quali fa il grosso del lavoro mentre i primi due si occupano di ripulire il traffico da tutto quel che non sono visite provenienti da Google organico. Perciò eccovi i tre filtri (usateli in ordine, anche se l’unica cosa importante è che il tre venga dopo gli altri due):

Ranking 1
filtro personalizzato – includi
campo filtro: sorgente campagna
pattern filtro: google
maiuscole/minuscole: no

Ranking 2
filtro personalizzato – includi
campo filtro: mezzo della campagna
pattern filtro: organic
maiuscole/minuscole: no

Ranking 3:
filtro personalizzato – avanzato
campo A -> estrai A: Referral (\?|&)q=([^&]*)
campo B -> estrai B: Referral (\?|&)start=([^&]*)
Output in -> Constructor: Definito dall’utente $A2 (posizione: $B2)
Campo A obbligatorio: si
Campo B obbligatorio: no
Sostituisci campo di output: si
maiuscole/minuscole: no

in sostanza questo filtro prende il referral di una visita da una ricerca, come http://www.google.it/search?num=20&hl=it&lr=lang_it&pwst=1&q=tambu&start=20&sa=N ed estrae le due informazioni in neretto, ricostruendole nella forma keyword (posizione: numero) dentro al campo “definito dall’utente” del pannello visitatori. Se non compare nessun numero significa che la visita arriva da pagina 1. Posizione inoltre non consente di conoscere la posizione esatta del click, ma rappresenta il risultato minimo che compare sulla SERP. Per cui posizione 20 significa in pratica pagina 3, come potete verificare guardando un po’ gli indirizzi delle SERP di Google.

Così come sono i tre filtri funzionano solo per Google, con un po’ di modifiche ai filtri uno e due si possono intercettare anche Yahoo e Live Search e modificare poi il terzo filtro come indicato nel post.
Ho provato questa soluzione per qualche giorno e i risultati sono interessanti: sebbene la maggior parte delle visite arrivi da pagina uno, allargando un po’ l’orizzonte delle keyword si arrivano a scoprire anche visite di persone che sono arrivate a pagina 10 o oltre, visite che mi sento quindi di ritenere molto interessate (non scorro dieci pagine di risultati per cliccare poi “a caso”). Come sempre, se qualcosa è in grado di darci uno sguardo diverso sui dati, vale la pena di provarlo.

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: No
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