Google Analytics in 30 secondi

La funzione _setClientInfo(booleano) ci permette di specificare se vogliamo o meno che Google Analytics tracci le informazioni sui client dei visitatori. GA per definizione traccia un numero abbastanza elevato di informazioni sui client utilizzati dai visitatori, come ad esempio il nome del browser, il sistema operativo, la risoluzione dello schermo o il supporto di Java, e ce le mostra nella sezione VISITATORI o nei segmenti standard. Se per particolari esigenze non si desiderano questi dati è possibile disabilitare il monitoraggio inserendo le rigapageTracker._setClientInfo(false);

prima della chiamata a TrackPageview()

La funzione _getClientInfo() invece ci permette di conoscere quale sia l’impostazione di tracking dei dati sul browser data a un determinato oggetto istanziato. Ritornerà 1 se il tracciamento è abilitato (impostazione di default) oppure 0 se è disabilitato. In script particolarmente complessi questa funzione ci permette di conoscere lo stato di quella impostazione ed eventualmente di fare o non fare ulteriori altre azioni basate su quello stato; essendo una funzione “di servizio” può essere utilizzata in qualsiasi punto della pagina semplicemente richiamandola così:
pageTracker._getClientInfo();

o inserendo il valore risultante in una variabile o in un’altra funzione.

Una delle maggiori critiche che mi sento opporre quando parlo di Google Analytics suona circa come “si, ma non è in tempo reale”. Questo è indubbiamente vero, ma molto meno di quanto si sospetti.

Innanzitutto sarebbe utile fare un esame della propria attività e chiedersi se è realmente necessario avere i dati in tempo reale: molto spesso infatti il desiderio delle persone è di avere i dati fino all’ultimo minuto quelle due o tre volte alla settimana in cui sbirciano le statistiche. Il dato real-time invece è pensato (e dovrebbe essere rivolto) a chi fa web analytics di mestiere e sta tutto il giorno con i dati aggiornati davanti, dovendo decidere in tempo reale modifiche alla strategia o ai budget o dovendo tenere sotto controllo le vendite minuto per minuto.
Questo come premessa generale, non è mia intenzione dire a nessuno come deve fare analisi, ma vorrei solo porre l’accento sul fatto che larga parte di chi mi pone questa obiezione non lo fa perché ne ha realmente bisogno, ma per sottolineare una mancanza di GA.

Mancanza che, come dicevo prima, è molto minore di come appare. Quando accediamo ai rapporti, GA ci mostra per impostazione predefinita (e ahimé immutabile) gli ultimi 30 giorni di dati, partendo dal giorno precedente, e questo basta a molte persone per pensare che i dati siano fermi, e che i dati di oggi saranno disponibili domani. Tramite una semplice selezione nel calendario è possibile rendersi conto che le cose stanno diversamente: selezionando la data odierna infatti il sistema ci mostra i dati di oggi in modo incompleto, sottostando a queste tre regole:

1. i dati sono fermi a tre ore prima il momento in cui li si visualizza
2. i dati si aggiornano ogni ora
3. i dati possono variare entro 24 ore

Per capire come mai questo accade è necessario fare un ulteriore passo nella comprensione del percorso che i dati fanno da quando il vostro sito viene visualizzato a quando voi guardate i report, percorso che ho iniziato a spiegare nel post “l’ordine è importante“. Quando si richiama la gif trasparente __utm.gif da http://www.google-analytics.com in realtà non si sta interrogando un solo server. www.google-analytics.com viene risolto dai dns in www-google-analytics.l.google.com, che è un round robin di server sparsi per la rete: facendo un nslookup da vari server nel mondo si ottengono indirizzi IP differenti, per minimizzare il percorso che i dati trasmessi dai client dei visitatori devono fare. E’ quindi assolutamente normale che un visitatore italiano e un visitatore cinese “sparino” i dati dello stesso codice di Analytics su due server Google differenti.

Una volta ogni ora Google li recupera dalle sue macchine in giro per il mondo e li analizza, e a causa del numero di analisi necessarie li presenta con tre ore di ritardo. Inoltre, poiché non è garantito che il recupero dei dati avvenga da tutti i server del mondo, ogni 24 ore Google Analytics effettua una rianalisi del giorno precedente per colmare eventuali lacune e garantire la solidità del dato. Per questo motivo i dati vanno considerati definitivi solo dal giorno successivo, e per questo motivo all’accesso Google presenta gli ultimi 30 giorni escludendo la data odierna.

Questo post in realtà è più vecchio dei due precedenti sullo stesso argomento, ma contiene spunti altrettanto interessanti e l’ho trovato casualmente durante una ricerca. Stephan Hàmel in Aprile provava a indovinare il futuro del nostro strumento di web analytics preferito, con alcuni spunti interessanti:

Innanzitutto l’onnipresente API, richiesta a gran voce da praticamente tutti coloro i quali fanno web analytics a un certo livello. Sono convinto anche io che prima o poi Google dovrà cedere su questo punto, sarebbe LA killer features definitiva. In secondo luogo i report personalizzabili, con la possibilità di incrociare tutte le metriche e le dimensioni e di creare drilldown personalizzati. Per finire le metriche personalizzabili, cioè l’abilità di integrare e incrociare dati da qualsiasi fonte esterna. Fin qui cose di impatto, ma più o meno già sentite.

Gli spunti interessanti vengono dalla seconda parte del post: l’import/export in Google Docs, così come avviene attualmente per gli allegati di Gmail, permetterebbe di rielaborare velocemente i dati dei report più complessi senza passare dal download (e avendoli ugualmente a disposizione online già rielaborati). In particolar modo sarebbe apprezzato l’export verso Google Docs Spreadsheet, che peraltro permette la collaborazione online di più account, anche diversi da quelli che hanno accesso ai dati di Google Analytics. Come spunto ulteriore, da Google Docs Spreadsheet è molto facile ricavare grafici personalizzati sofisticati completamente diversi da quelli standard di Analytics, potendo contare anche su serie temporali o indicatori a tachimetro. E infine Spreadsheet dispone delle notifiche automatizzate quando una cella viene modificata; l’ottimo sarebbe aggiungere la possibilità di mandare la notifica se la cella sorpassa un certo valore.

Dal mio punto di vista è tutto esatto, tranne forse il fatto che la maggior parte di queste cose potrebbero essere incluse nativamente in GA senza bisogno di esportare in Spreadsheet. Oppure, sempre grazie a una API, l’export dovrebbe essere reso temporizzato, schedulabile o “fluido”, per far avere un senso alla notifica. Qualcosa come “avvisami se la cella A4, dove ho messo il tasso di rimbalzo della homepage, sale oltre il 75%“.

(photo credit AdamL212 on Flickr)

Le funzioni del giorno servono a ripulire scelte effettuate in precedenza con omologhe funzioni prima che i dati vengano trasmessi ai server collettori di Google. Tutte e tre non necessitano di nessun parametro in ingresso. _clearIgnoredOrganic() ripulisce la lista di parole chiave da trattare come visita diretta impostata tramite addIgnoredOrganic mentre _clearIgnoredRef() ripulisce la lista dei referrer da ignorare e trattare come visite dirette impostata tramite addIgnoredRef. Non mi è mai capitato di usare queste funzioni nè di vederle implementate in qualche sito di cui ho guardato il sorgente.

_clearIgnoredOrganic() invece è interessante e ci permette di azzerare completamente la lista dei motori di ricerca, sia quelli impostati tramite addOrganic sia quella predefinita da Google. C’è quindi una differenza fondamentale da tenere a mente: le prime due funzioni servono a resettare impostazioni date da noi, mentre clearOganic è in grado di azzerare anche una impostazione predefinita da Google. Nel momento in cui viene chiamata la funzione cancella completamente la lista dei motori di ricerca. L’uso tipico di questa funzione è quello di azzerare la lista dei motori e costruirsene una personalizzata, ad esempio distinguendo ogni estensione nazionale di Google (.it .fr. .co.uk eccetera). Un altro uso potrebbe essere quello di aggiungere la ricerca di immagini di Google come una fonte organica invece che come referrer in un sito-raccoglitore di foto.

Il solito Brian Clifton, nella sezione del suo blog dedicata agli script, ha una funzione già pronta per fare questo mestiere, sebbene in beta. Per utilizzarlo bisogna salvare il file sul proprio server e richiamarlo dopo la chiamata a ga.js ma prima dell’inizializzazione del GATC, quindi in questo modo

<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="custom_se-ga.js" />

  <script type="text/javascript">
    var pageTracker = _gat._getTracker("UA-XXXXXX-X");
    pageTracker._initData();
    pageTracker._trackPageview();
  </script>

Brian Clifton ha appena pubblicato una versione aggiornata del suo script per taggare automaticamente tutti i link in uscita, i download e i click sui mailto:, indirizzata a chi usa ga.js come codice di monitoraggio.

Il sorgente è abbastanza chiaro, per essere utilizzato dovete salvare quel file e personalizzare la variabile extTrack con il dominio (o i domini) su cui lo script è installato e che quindi saranno considerati “interni” e la variabile extDoc con le estensioni dei file da monitorare. La variabile extTrack è interesante, e ci permette anche di escludere dal tracciamento tutti i link verso un intero dominio esterno.
A quel punto dovrete includere nella sezione HEAD delle vostre pagine una riga come
<script type="text/javascript" src="addLinkerEvents-ga.js" />

Dopo di che la funzione va richiamata sull’onload del BODY, modificandolo come segue
<body onload="addLinkerEvents();">

Nei report i link esterni sono tracciati come pagine virtuali della cartella /ext/, i download come pagine virtuali della cartella /downloads/ e i clic sulle email come pagine virtuali della cartella /mailto/.

E’ una soluzione interessante che ci permette di automatizzare un lavoro fondamentale come il tracciamento dei download e dei click esterni, che incorpora una buona idea ma che ne manca completamente un’altra, anche se minore: nei prossimi giorni conto di segnalarvi una risorsa cui sto lavorando insieme a un amico che dovrebbe includere l’idea che manca allo script di Clifton. (eccola: the italian way)

La funzione del giorno è _addOrganic(dominio, parametrodiricerca) e ci consente di dire a Google Analytics di trattare un determinato dominio come fosse un motore di ricerca invece di un referrer, e quale deve essere il parametro nel quale trovare le keyword cercate dall’utente. GA ha una lista predefinita di motori di ricerca e relativi parametri che vengono identificati automaticamente durante l’esecuzione del GATC, che al momento della scrittura di questo articolo sono:

(“google”,”q”)
(“yahoo”,”p”)
(“msn”,”q”)
(“aol”,”query”)
(“aol”,”encquery”)
(“lycos”,”query”)
(“ask”,”q”)
(“altavista”,”q”)
(“netscape”,”query”)
(“cnn”,”query”)
(“looksmart”,”qt”)
(“about”,”terms”)
(“mamma”,”query”)
(“alltheweb”,”q”)
(“gigablast”,”q”)
(“voila”,”rdata”)
(“virgilio”,”qs”)
(“live”,”q”)
(“baidu”,”wd”)
(“alice”,”qs”)
(“yandex”,”text”)
(“najdi”,”q”)
(“aol”,”q”)
(“club-internet”,”query”)
(“mama”,”query”)
(“seznam”,”q”)
(“search”,”q”)
(“wp”,”szukaj”)
(“onet”,”qt”)
(“netsprint”,”q”)
(“google.interia”,”q”)
(“szukacz”,”q”)
(“yam”,”k”)
(“pchome”,”q”)
(“kvasir”,”searchExpr”)
(“sesam”,”q”)
(“ozu”,”q”)
(“terra”,”query”)
(“nostrum”,”query”)
(“mynet”,”q”)
(“ekolay”,”q”)
(“search.ilse”,”search_for”)

I parametri che la funzione accetta in ingresso sono due stringhe, la prima è il nome del motore di ricerca che ritroveremo poi nei report, il secondo è il parametro nel quale il motore passa in GET le keyword ricercate. Ad esempio nell’URL
http://www.google.it/search?q=google+analytics&sourceid=navclient-ff&ie=UTF-8

le keyword stanno nel parametro q, nell’URL
http://arianna.libero.it/search/abin/integrata.cgi?regione=9&query=google%20analytics
le keyword si trovano nel parametro query, per cui per aggiungere Libero tra i motori di ricerca la funzione da usare è
pageTracker._addOrganic("libero","query");

poiché però il nome del motore fa il match con qualsiasi parte del dominio, andrebbe bene anche la funzione chiamata così
pageTracker._addOrganic("arianna","query");

La conversione dei referral in Google Analytics è sempre stata fonte di incomprensioni e perdite di tempo durante l’analisi dei dati: effettivamente la spiegazioni erano abbastanza risicate e la soluzione affidata a un parametro aggiuntivo scarsamente documentato.
Come abbiamo visto nel post dedicato ai cookie di Google Analytics, quando si inizia una visita il GATC provvede a scrivere o aggiornare la sorgente della visita all’interno del cookie utmz. Nel momento in cui la scrittura viene eseguita, la precedente informazione viene perduta. A tutti gli effetti Google Analytics si comporta come uno strumento “last cookie win”, e la conversione viene attribuita di conseguenza.

In web analytics si usa suddividere i referrer possibili in quattro grandi ordini:

• Il traffico diretto: ovvero nessun referrer (è improprio definirlo un referrer, ma serve a tornare al 100% del traffico), cioè le visite effettuate digitando direttamente l’indirizzo del sito nel browser, cliccando un bookmark nel browser, cliccando un link su un client email o provenendo da un server che ha i referrer disabilitati.
• I referrer: ovvero le visite provenienti da altri siti in cui sono presenti link diretti
• Le visite da organico: ovvero le visite provenienti da motori di ricerca
• Le campagne: ovvero visite provenienti da campagne cpc o ppc, da banner, ads, email e in generale da link propriamente taggati da noi per essere considerate e monitorate come campagne

Google Analytics aggiorna il cookie utmz secondo le seguenti regole:
– Le visite provenienti da una campagna, un referral, una visita organica o un adword aggiornano sempre il cookie.
– Il traffico diretto viene sempre sovrascritto da referrer, organico e campagne taggate o adword.

In pratica una visita proveniente da una campagna di email marketing correttamente taggata verrà conteggiata come campagna. Se il visitatore non effettua la conversione durante la prima visita, e dopo due giorni torna digitando direttamente l’URL nel browser (traffico diretto) e converte, Google Analytics non aggiorna il cookie utmz e la conversione viene attribuita alla campagna. Se dopo dieci giorni lo stesso visitatore clicca un annuncio ppc e converte, la conversione viene assegnata alla campagna ppc.

Esiste una eccezione a questo metodo di lavoro, impostabile dall’utente: questo metodo consiste nell’aggiungere un parametro agli url del sito raggiunti da campagne che dice a GA di non sovrascrivere il cookie utmz. Il parametro da aggiungere ai nostri url è
&utm_nooverride=1

ed è assimilabile a comunicare in italiano a GA la frase “per le visite che arrivano su questi url vige la regola del first cookie win”

La funzione del giorno è _addIgnoredRef(dominio) e ci consente di dire a GA di trattare un referrer come se fosse una visita diretta. Questa funzione è utile ad esempio nel caso in cui possediamo un secondo dominio che tracciamo con lo stesso codice e vogliamo trattare le visite provenienti da esso come accessi diretti, sebbene esistano funzioni più efficaci per fare questa operazione.

L’unico parametro che accetta in ingresso è una stringa, ed è il dominio che vogliamo escludere dalla lista dei referrer. Quindi per trattare i link a questo sito da blog.tambuweb.it come traffico diretto la funzione sarà:
pageTracker._addIgnoredRef("blog.tambuweb.it");

da inserire ovviamente prima della chiamata a InitData();

Tutto da leggere questo post di Ian Thomas, frutto di una chiacchierata con Avinash Kaushik all’E-metrics summit e di una successiva vacanza in Messico (beato lui!). La linea tracciata parte da una considerazione comune a tutti quelli che si pongono la domanda sul futuro della piattaforma di analisi Google: “come hanno intenzione di renderlo un prodotto di alto livello adatto alle grandi aziende?”

La prima previsione di Ian è il rilascio di una API che permetta di accedere ai dati contenuti nei database di Google Analytics, una API eventualmente a pagamento (per non rischiare di sovraccaricare i server con esose e inutili richieste di dati) in grado virtualmente di attingere qualsiasi dato e riprocessarlo in applicazioni terze e nuovi report. Questa previsione si ramifica in due scenari: Google stessa userebbe questa API (e non è detto che in segreto già non lo faccia) e il codice javascript di tracciamento potrebbe diventare uno standard, se permettesse di tracciare variabili a piacimento e successivamente recuperarle richiedendole via API.

La seconda previsione è che questo creerebbe di fatto una nuova industria di strumenti di web analytics di terze parti. Queste nuove aziende non dovrebbero preoccuparsi di pensare a come collezionare e memorizzare i dati in modo che si possano espandere le funzionalità in futuro (lo farebbe Google) e potrebbero concentrarsi sul renderli fruibili attraverso la loro manipolazione. Di contorno, si inizierebbero a vedere “pezzi” di web analytics ovunque ce ne sia bisogno, ad esempio direttamente dentro a CMS o sistemi di e-commerce.

La terza previsione – estrema – si interroga sul perché a quel punto i grossi nomi del settore (Omniture, Webtrends, ecc.) dovrebbero investire ancora risorse nella collezione dei dati, operazione che nonostante tutto ha un costo per i vendor (in termini di banda e server) e per i clienti quando decidono di cambiare piattaforma e non possono travasare i dati pregressi. Adottando lo “standard API” di Google sarebbe più semplice convincere i clienti a cambiare vendor (quindi anche ad abbandonare GA, chiaro) perché si tratterebbe solo di farsi dare accesso ai dati attraverso le API e ricreare nel nuovo strumento i report e la personalizzazioni presenti nel vecchio. Questo permetterebbe anche di risolvere il problema delle installazioni indipendenti di GA da parte di settori periferici delle aziende, problema che i grandi vendor stanno già affrontando. L’utilizzo dell’API Google aggirerebbe questo problema aggregando anche i dati di queste installazioni “dissidenti”.

(photo credit purpleslog on flickr)

La funzione del giorno è _addIgnoredOrganic(keyword) e ci consente di dire a GA di non considerare visite provenienti dai motori di ricerca con determinate parole chiave come organiche, e di tracciarle come fossero traffico diretto. Questa funzione è utile ad esempio nel caso in cui ricevessimo molte visite con parole chiave come l’url del nostro sito, ovvero da persone che scrivono l’url nella casella di ricercaa dei motori invece che nella barra degli URL dei browser.

L’unico parametro in ingresso che questa funzione vuole è una stringa, per cui per escludere la keyword www.pizza.com la sintassi sarà:
pageTracker._addIgnoredOrganic("www.pizza.com");

da inserire prima della chiamata a InitData();

La particolarità di questa funzione è che nella mia personale esperienza… non funziona! L’ho provata sia nello script nuovo che in quello vecchio (quando si chiamava _uOno[0] ) e non c’è verso di farla funzionare. Anche prendendo in considerazione il fattore override (il fatto che le visite dirette vengono conteggiate come organiche se la prima visita era proveniente da organico) e scremando solo i nuovi visitatori, i dati sono assolutamente inconsistenti: o meglio, è come se se la funzione non facesse il suo dovere. Come estrema-ratio oggi ho analizzato gli header HTTP inviati ai server di Google e non ho rilevato differenze tra una visita con una parola chiave che dovrebbe essere ignorata e una che dovrebbe essere conteggiata. Sono segnalate entrambe come organiche.