Jan 24 2009

La web analytics non è tutto!

autore: Marco Cilia categoria: web analytics tag: , , ,

Cool Mirror by dprevitePuò sembrare strano detto da me e su questo blog, ma è esattamente quel che penso e l’occasione per ribadirlo mi viene da un caso pratico che ho affrontato qualche giorno fa da un cliente.
Durante l’analisi del traffico degli ultimi tre mesi, e dopo alcune considerazioni sulle fonti, ci imbattiamo in un fenomeno strano: molti URL dei contenuti del sito appaiono duplicati, e funzionanti e visitabili, ancorché non linkati da nessuna parte in apparenza. Alcuni hanno la struttura

/directory/sottodirectory/index/id_contenuto.html

e altri invece

/sottodirectory/index/id_contenuto.html

Il cliente mi avverte che in passato avevano avuto grossi problemi di questo tipo, ma che dopo un lavoro certosino avevano bonificato la situazione, e Google Webmaster Tool lo confermava.
L’analisi dei percorsi di navigazione, delle sorgenti delle visite a questi URL e delle keyword di ingresso portavano tutti a una fonte: Google. A questo punto la web analytics si ferma, ma il cliente ha bisogno di capire. Facendo alcune prove di ricerca e attraverso l’uso degli operatori site: e inurl: riesco a isolare due URL presenti delle pagine dei risultati di Google, ma ancora questo non ci dice nulla. Da dove Google pesca questi indirizzi sbagliati?

L’illuminazione mi è venuta dopo aver notato che gli URL con più visite (quelli esistenti nei link interni al sito) avevano la copia cache, mentre quelli “sbagliati” non avevano la copia cache e recavano la scritta “XX ore fa”. Di che cosa Google non fa la copia cache e conosce bene l’ora di pubblicazione? la prima risposta è “delle news”, perché il sito è presente come fonte in google news, ma anche lì l’operatore site: non fornisce una risposta soddisfacente, il secondo bersaglio sono i feed RSS, e infatti lì vi era l’errore e i link errati.
Ma queste risposte non ce le può dare Google Analytics, nè la web analytics in generale, ed è per questo che dico che la web analytics non è tutto. Sono conscio del fatto che è impossibile essere esperti in mille campi, ma conoscere le basi di funzionamento dei motori di ricerca, l’uso degli operatori e un po’ di SEO non può di certo essere un ostacolo all’attività di WA, anzi.

Avete esperienze simili e altri campi di cui è bene conoscere le basi da suggerire?

image credits: dprevite on flickr


Jun 23 2008

filtrare solo il proprio domino mantenendo la cache di google

autore: Marco Cilia categoria: filtri tag: , ,

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

filtro solo mio dominio

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