Google Analytics in 30 secondi

Usando Google Analytics prima o poi tutti si trovano ad avere a che fare con le regular expression, c’è poco da fare. Che sia la configurazione di un obiettivo, la creazione di un filtro o di una regola per filtrare le colonne di un report, la sola parola “regular expression” è in grado di far scappare molte persone a gambe levate.

Eppure ricorrendo ad una buona dose di buon senso si riesce spesso ad averne ragione, perché tipicamente le espressioni che servono alle persone sono abbastanza semplici; per i casi più complessi esistono i consulenti mica per nulla

Robbin Steif di Lunametrics ha messo insieme un grazioso ebook intitolato proprio “regular expressions for Google Analytics“, che dovrebbe togliere almeno i dubbi principali a chi si accinge – o non ha mai compreso fino in fondo il funzionamento – a creare regex nello strumento di Google.
Non ho finito di leggerlo tutto, ma mi sembra che la lettura scorra fluida e i concetti siano chiari. L’unica pecca è che è scritto in inglese, e questo potrebbe creare un ulteriore livello di difficoltà in alcune persone.

L’ebook è scaricabile gratuitamente dal sito di Lunametrics oppure è consultabile direttamente online, tramite un lettore in Flash.

Già che ci siamo voglio inserire in questo post altre risorse che nel tempo mi sono trovato a consigliare quando mi hanno chiesto lumi in merito: nella mia libreria ci sono “Espressioni Regolari” di Marco Beri – livello facile – e “Mastering Regular Expression” della O’Reilly – livello tremendamente complicato.
Per fare le prove (fate SEMPRE le prove, mi raccomando!) uso Regex Designer

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)

Se il vostro sito offre una funzione di invio degli articoli per email, ha una newsletter o semplicemente i vostri lettori usano segnalare pagine ad altre persone utilizzando la mail, è probabile che guardando il report “tutte le sorgenti di traffico” dentro a Google Analytics abbiate molte righe del genere:

wmail-new.libero.it / referral
webmailcommunicator.alice.it / referral
mail.google.com / referral
mail.tiscali.it / referral
it.mg40.mail.yahoo.com / referral
fastmail.fastwebnet.it / referral
it.mg41.mail.yahoo.com / referral
it.mc236.mail.yahoo.com / referral
co109w.col109.mail.live.com / referral
it.mc238.mail.yahoo.com / referral
co115w.col115.mail.live.com / referral
it.mc279.mail.yahoo.com / referral
by110w.bay110.mail.live.com / referral
by111w.bay111.mail.live.com / referral
by104w.bay104.mail.live.com / referral
webmail.interfree.it / referral

questo accade perché le webmail, specialmente quelle dei grandi provider che ne gestiscono decine di migliaia, risiedono su differenti server, e generano di conseguenza referrer differenti. Per ovviare a questo problema il blog francese wagablog.com propone un filtro avanzato di riscrittura, che permette di raggruppare le visite da uno stesso provider di posta elettronica.
Il filtro prende come campo A il “sorgente campagna” con espressione regolare:

mail(.*)\.(.*)\..{2,4}

Il campo B non è necessario.
L’output (il constructor) è lo stesso campo “sorgente campagna” con espressione:

webmail - $A2

In pratica effettua una sovrascrittura del campo eliminando le parti superflue, come il nome esatto del server della webmail. Non ho testato il filtro in sé, ma ho fatto parecchie prove con il mio programma preferito di test delle espressioni regolari, verificando che la regex è buona e funziona per bene anche con i provider italiani. Per i più curiosi, l’espressione regolare guarda dove vi sia scritto “mail” nel dominio, e raggruppa qualsiasi cosa vi sia da lì fino al dominio primario memorizzandolo dentro alla variabile $A1. Il dominio (con esclusione dell’estensione) viene estrapolato e memorizzato nella variabile $A2, che è poi quella che viene mostrata nei report.

Se avete un account Adwords collegato a quello di Analytics è probabile che abbiate sentito parlare del famoso doppio filtro per avere le chiavi cercate invece di quelle acquistate. Le istruzioni per creare il filtro sono in questo post su semvironment, e una discussione sull’argomento è sul forum Seonida.
Non mi dilungo sul filtro perché non è oggetto di questo post.

Una domanda che mi è stata fatta ieri è questa:

Il Campo A del filtro personalizzato del primo passo di estrazione delle chiavi cercate, tira fuori dal Referral la sequenza (\?|&)(q|p|qs|_nkw)=([^&]*)

Il Campo B tira fuori dal Mezzo della Campagna cpc|ppc
L’output finisce in Campo personalizzato 1, con la stringa $A3

Ma allora, il campo B a che serve, visto che nel campo personalizzato 1 non si prende il considerazione?

La risposta sta in questa immagine, presa dal post di semvironment

Il campo B in effetti guarda dentro al mezzo della campagna e capisce se questo mezzo è cost per clic o pay per clic, ma non fa altro. L’output di quella parte di filtro non solo non viene estratto, ma non verrebbe nemmeno salvato per un uso successivo nè trascritto in un altro campo. A tutti gli effetti quello è un campo che potremmo definire “di controllo“, poiché è un campo obbligatorio ma non genera un output. Se però la condizione non è soddisfatta, se l’output fosse vuoto, il filtro non agirebbe, perché appunto l’impostazione è “campo B obbligatorio”.

Nello specifico un controllo sul solo referrer non è sufficiente, perché non è affatto scontato che il referrer (un qualsiasi referrer) non contenga almeno un parametro tra q, p e qs. Più difficile, ma non impossibile, _nkv…
Il campo B quindi serve solo ed esclusivamente a prevenire che un referrer con uno di quei parametri possa mettere erroneamente in azione il filtro.

C’è una cosa che Google Analytics non fa nativamente, al contrario di strumenti considerati “più professionali” e costosi: i cosiddetti Content Group, ovvero gruppi più o meno omogenei di pagine o contenuti categorizzati con un nome, la cui analisi può essere fatta in forma aggregata.
In realtà GA consente di analizzare gruppi di URL in forma aggregata tramite il report “dettaglio contenuto“, ma in questo caso i gruppi sono determinati dalla struttura degli URL del sito (directory e sottodirectory, fisiche o create ad arte tramite riscrittura degli URL), oppure si possono analizzare gruppi di pagine che abbiano una parte comune di title tramite il report “contenuti per titolo“.

La soluzione di E-nor è quella di applicare dei filtri avanzati (ad un profilo-copia, aggiungerei) in grado di sostituire ad esempio tutti gli URL che contengono la parola ADIDAS con un url secco tipo /adidas.html

Allargando il discorso si può ipotizzare un tentativo “alla webtrends” in cui il raggruppamento avviene tramite una regular expression (o una regular expression per il nome della pagina + un parametro particolare), sempre tramite filtro avanzato, oppure una via più elegante che modifichi il title della pagina aggiungendo il nome del content group, lasciando intatto l’URL per eventuali altre analisi.
La soluzione proposta è indubbiamente valida, ma non mi fa impazzire per almeno due motivi:

1. il primo, come ho avuto di dire nei commenti a quel post, è che su siti di grandi dimensioni potrebbero esserci problemi con url che contengono due termini da sostituire, nel qual caso il primo filtro farebbe tutto il lavoro trattenendo la pagina dentro al relativo content-group. Più in generale il sistema proposto è più facile da implementare in siti con URL rewrite attivo, mentre risulta più difficoltoso con url “criptici”
2. il secondo, più importante, è che questo è un workaround: i content group dovrebbero funzionare come i tag, evitando il problema di cui al punto precedente e permettendo ad una pagina di essere conteggiata in due o più gruppi di contenuto

Come sempre, se sapete esattamente cosa state facendo e quali dati in uscita avrete potete operare; diversamente bisognerà aspettare che Google implementi nativamente questa funzione, oppure suggerirla tramite il form apposito

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…

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