Google Analytics in 30 secondi

Abbiamo già visto in passato come una API, un’interfaccia verso i dati per programmatori, sia una delle richieste che la maggior parte degli utenti fa a Google e come questa potrebbe aprire la strada verso una diffusione universale di Google Analytics anche al di fuori della ristretta cerchia della web analytics. La mia opinione è che prima o poi questa API arriverà (d’altronde Google offre API per la maggior parte dei suoi servizi), ma nel frattempo non posso evitare di segnalarvi questo lavoro di Sal Uriasev per Juice Analytics: una API non ufficiale.

Per utilizzarla è necessario installare e conoscere almeno un po’ Python, un potente linguaggio di programmazione venuto alla ribalta negli ultimi anni; io purtroppo al momento non so dirvi molto di più di quel che scritto nella documentazione ufficiale. Farò indubbiamente delle prove in futuro, ma se nel frattempo qualcuno vuole cimentarsi, ne trarremo tutti beneficio 🙂

La funzione _setCookiePath(stringa) è un po’ particolare e forse non è nemmeno utile alla maggior parte di noi, però ci permette di risparmiare tempo nel setup del profilo e consente una interpretazione migliore dei dati. Sebbene il nome tragga in inganno, serve a definire quale sia la directory predefinita per il cookie del vostro sito, e non a definire in quale directory del PC dell’utente salvare i cookie di GA (come molti erroneamente pensano). Poniamo un caso pratico e semplificato:
Continua a leggere “funzioni: _setCookiePath() e _getCookiePath()”

Abbiamo parlato spesso del possibile futuro di GA e di come io e altre persone che lo usano vorremmo che si trasformasse, ma la sostanza è che le previsioni o i desideri restano tali finché Google non li realizza. Eppure esiste un intero ecosistema di programmatori che utilizzano una famosa estensione del broswer Firefox per aggiungere piccole funzioni a GA che normalmente non sono presenti.

Trattandosi di un addon di Firefox, è evidente, tutte le funzioni citate in questo post funzioneranno solo con il browser di casa Mozilla. In secondo luogo non si tratta di un post alla portata di tutti: sebbene la maggior parte delle operazioni siano click e download, in alcuni casi potrebbe essere necessario editare dei file o addentrarsi nello specifico dei problemi. Terzo punto da tenere in considerazione è che essendo sviluppati da americani e basati sugli url delle pagine, funzionano solo se accedete a www.google.com/analytics, non sul .it.

Il primo passo da fare è scaricare il plugin GreaseMonkey e riavviare Firefox: in basso a destra dovrebbe comparirvi una simpatica faccia di scimmia, segno che il plugin è correttamente installato. Per inciso, esistono migliaia di script per GreaseMonkey, alcuni molto semplici e altri molto potenti, per moltissimi siti web e non solo per Google Analytics. Poiché gli script sono realizzati dagli utenti e non da Google o Mozilla, abbiate particolare cura nella selezione che fate quando decidete di installare qualcosa: prendete informazioni, chiedete a un esperto di controllare i sorgenti. Installare script di dubbia provenienza è un errore da evitare assolutamente!

Detto questo, il primo script da installare è Keyword Trends di Juice Analytics, che aggiunge un pulsante “who sent me unusual traffic” ai report delle keyword e delle fonti di traffico. Azionando il pulsante lo script scaricherà in background i dati delle keyword del periodo temporale selezionato e li confronterà con queli degli ultimi 7 giorni, mostrandoci il risultato di questo confronto, cioè le keyword (o le fonti di traffico) con un incremento superiore al 20% (nel caso dei referrer i giorni sono 3 e la percentuale è il 50). Per modificare il periodo o la percentuale potete fare riferimento al post e alle istruzioni contenute.

Altro script interessante è Report Enhancer di Roi Revolution, uno script che aggiunge un sacco di dati interessanti, ad esempio il numero di conversioni (invece del tasso), il “vero” tempo sul sito (spiegato in questo post su cui magari torneremo in futuro), e aggiunge al menu delle segmentazioni una voce Source/Medium che normalmente non è presente (sono presenti Sorgente e Mezzo ma non la combinazione dei due). Inoltre se abbiamo abilitato e usiamo i rapporti e-commerce. potremo segmentare per prodotto, gruppo di prodotti, SKU e transazione, anche queste segmentazioni che normalmente non sono accessibili da questo menu. Un piccolo effetto collaterale di questo script è che rende inglese il menu contestuale delle segmentazioni anche se usate l’interfaccia in italiano. In tutta sincerità a me funziona tutto tranne il True Time on site e le informazioni aggiuntive, ma potrei aver fatto qualche casino installando gli script. [UPDATE: funziona solo settando l’inglese come lingua di Analytics]

Il terzo script è stato pubblicato da Michael Freeman, probabilmente dopo aver letto il post che ho in parte tradotto tempo fa sull’integrazione tra GA e Google Docs.

Quel che fa è infatti aggiungere una opzione di export dei dati, proprio in Google Spreadsheet. Con un solo click si può esportare un report e poi elaborarlo tramite il foglio elettronico online di Google, con i vantaggi aggiuntivi delle revisioni e delle modifiche collaborative distribuite, oltre al fatto di poterlo condividere in sola lettura con clienti o altri fornitori senza dare accesso diretto a GA. Dei tre è quello che mi ha dato i problemi maggiori: tende a funzionare quando si accede a GA immettendo la password (e non scrivendo direttamente https://www.google.com/analytics/) e nonostante ciò alcune volte ritorna un errore 500. E’ sicuramente ancora uno script giovane, ma potrebbe presto diventare un addon definitivo, quindi lo seguiamo con interesse.

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

La funzione _setDetectTitle(booleano) serve a dare disposizione al codice di tracciamento di Analytics di tracciare o meno il title HTML della pagina visitata. Per default il title viene registrato e mostrato nel report Sezioni del sito > Sezioni per titolo, ma possiamo disabilitare questa feature richiamando prima di trackpageview() la riga
pageTracker._setDetectTitle(false);

L’esempio che sento spesso fare è quello di un sito che non ha i title, o li ha tutti uguali. Questo è uno dei peggiori errori che si possano commettere pubblicando un sito web, e piuttosto che settare false in questo parametro bisognerebbe concentrarsi sul sistemare i title! Se non potete mettere le mani sul sito (magari perché non è il vostro) e volete far risparmiare un po’ di elaborazioni a Google, allora potete anche invocare setDetectTitle.

La funzione _getDetectTitle() serve a conoscere, in uno script complesso, lo stato della variabile di tracciamento dei title HTML della pagina; restituisce 1 se il tracciamento è abilitato (situazione di default) oppure 0 se è disabilitato. E’ una funzione di servizio, può essere invocata ovunque vogliamo nella pagina e la sintassi è
pageTracker._getDetectTitle();

Come detto poco fa, queste due funzioni sono abbastanza inutili, poiché ogni sito web dovrebbe avere pagine con title unici e originali, e quindi giovare dell’utilità del report dei contenuti per titolo. In ogni caso tenete a mente che esistono, e rileggetevi questo articolo sulle differenze tra il report per titolo e quello per pagina

Quando vi proposi la libreria di Brian Clifton per tracciare automaticamente link e download, dissi che soffriva di un problema. A molti sembrerà un problema di poco conto, una cosa che usano in pochissimi, ma ha realmente una sua utilità che vado a spiegarvi: la libreria di Clifton funziona solo con l’oggetto predefinito di GA, pageTracker. Se voi istanziate più oggetti per più profili, non va. Dovete modificare il sorgente e conoscere a priori il nome dell’oggetto di monitoraggio. Insieme a Francesco Terenzani (lui l’autore materiale del codice, io ci ho messo alcune idee e test) ci siamo subito messi a pensare a una soluzione più snella ed efficace per colmare questa lacuna, e l’abbiamo trovata e descritta nel post di Francesco.

Le istruzioni sono molto chiare e non ve le riporto (e tra l’altro non c’è nemmeno bisogno di una chiamata onload), vorrei invece porre l’accento ancora una volta sulla flessibilità della soluzione che abbiamo trovato. Possiamo istanziare due o più oggetti di tracciamento e tracciare gli stessi download su due o più account diversi, oppure possiamo tracciare cose diverse su account diversi come mostrato da Francesco. Invece di fare dei filtri a monte di profili-copia, con una semplice riga nel GATC otteniamo lo stesso risultato.

Guardate questo codice (realmente testato):

<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="_ftTrack.js"></script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXX-5");
pageTracker._initData();
pageTracker._trackPageview();
_ftTrack(pageTracker, "link|doc|rtf|pdf|zip");

var miopersonalTracker = _gat._getTracker("UA-XXXXX-12");
miopersonalTracker._initData();
_ftTrack(miopersonalTracker, "doc|rtf");
</script>

se notate, al secondo oggetto di tracciamento manca la chiamata a trackpageview(), che è quella che trasmette i dati ai server di Analytics. Questo perché trackpageview viene richiamata già al momento della creazione delle pagine virtuali, cui viene passato come argomento il percorso delle pagine virtuali stesse. Con il codice che ho scritto sopra avremo due profili, magari copie, il primo dei quali traccia tutto come sempre con in più i link esterni, i documenti doc, rtf e pdf e gli archivi zip, mentre il secondo traccia SOLO i documenti doc e rtf. ma avendo escluso la chiamata ordinaria di trackpageview, questo oggetto non traccia tutte le altre pagine, la home page ad esempio. Traccia SOLO i documenti, così possiamo fare analisi segmentata già dall’origine (ad esempio, gli arrivi da motore di ricerca ci indicheranno quali sono i documenti meglio indicizzati e per quali keyword).
Ecco un esempio di bacheca nel profilo copia di cui ho parlato:

Oggi mi sposo, all’incirca in questo momento. Ho schedulato qualche post per i prossimi giorni, mentre io sarò qui

se qualcosa però andasse male e i post non comparissero, sappiate che il progetto “Google Analytics in 30 secondi” non è naufragato di colpo. Anzi, i primi bilanci sono molto positivi e ci sono succose novità per i prossimi mesi!

La funzione _setDetectFlash(booleano) ci permette di specificare se Google Analytics deve tracciare o meno la presenza e la versione del player flash del visitatore. Per default il tracciamento è abilitato e le informazioni sono raccolte (vengono mostrate nel report Visitatori > Funzionalità del browser > Versioni Flash), ma se per qualsiasi motivo non volessimo che ciò accadesse dovremmo impostare una riga aggiuntiva
pageTracker._setDetectFlash(false);

Prima della chiamata a trackpageview().

La funzione _getDetectFlash(), come intuibile, ci permette di risalire allo stato del flag di monitoraggio del player Flash, e ritorna 1 se la raccolta dei dati è abilitata e 0 se invece è disabilitata. La sintassi è una semplice chiamata a
pageTracker._getDetectFlah(); ed essendo una funzione informativa può essere chiamata in qualunque punto della pagina.

Finalmente qualcuno mi scrive con una domanda:

Perché trovo tra l’elenco delle parole chiave “visite” di zero pagine, quindi zero tutto il resto? Come vanno interpretate?

Non è un errore, tanto per fugare subito il primo dubbio lecito.

É una situazione che si presenta ogni volta che un visitatore effettua una ricerca su un motore con una chiave (poniamo “chiave1”), effettua qualche attività o un bounce e poi ritorna con un’altra ricerca e un’altra chiave entro 30 minuti, quindi nell’ambito della stessa visita (e posto che non abbiate modificato il valore di questo tempo limite). Tecnicamente il visitatore ha effettuato una sola visita, ma è arrivato con due keyword diverse. Potrebbe ad esempio convertire con la chiave2, ma se GA registrasse solo la prima perderemmo una importante informazione: per questo motivo ci vengono mostrate tutte le keyword effettivamente usate, e vengono settati a zero tutti gli altri valori. Diversamente avremmo dati sballati per visite, visitatori eccetera.

(tnx to Anil Batra)

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