Google Analytics in 30 secondi

[in questo periodo sono talmente impegnato che ho dimenticato il terzo compleanno di questo blog! il 22 maggio 2011 🙂 ]

Da qualche tempo a questa parte Facebook ha dato la possibilità di inserire sulle proprie pagine dei frame contenenti sorgenti esterni, ad esempio pagine ospitate sul nostro dominio, o pagine del nostro sito esistente. Questo porta alla non trascurabile possibilità di “iniettare” Google Analytics per tracciare cosa accade lì sopra; in passato avevamo già visto alcune soluzioni per provarci, ma erano tutte poco pratiche e anche piuttosto inefficaci a causa di problemi tecnici in larga parte attribuibili a Facebook stesso.

Inserire un frame con una pagina che possiede il necessario codice di GA invece porta al risultato atteso: si può tracciare l’interazione tra gli utenti e il contenuto del frame (ma non ad esempio con quel che accade in bacheca). Per farlo è necessario usare come sorgente del frame una pagina che contenga il nostro codice di Google Analytics, magari dopo aver creato un profilo-copia che include solo le pagine del frame per poterle analizzare in dettaglio. Se state usando lo stesso codice del sito, ad esempio, i cookies saranno i medesimi quindi GA sarà in grado di riconoscere gli utenti e tracciarli come di ritorno, di conteggiare gli unici, eccetera.

Esiste una modifica interessante, che ci suggerisce Lunametrics, e che riguarda le fonti di traffico; se stiamo usando Facebook come landing page di una campagna (ad esempio una pagina tipo apps.facebook.com/my-app-name), usaremo i soliti tag delle campagne per valorizzare correttamente la sorgente di visita.
Se stiamo mandando gli utenti alla pagina con il frame (un tab di un profilo, ad esempio), Facebook oscura il referrer e non lo rende disponibile al frame, per cui sarà sempre qualcosa del tipo static.ak.facebook.com/platform/page_proxy.php. Il workaround consiste nel creare una pagina sul sito con un redirect al tab di Facebook, e impostarlo come landing page della campagna con gli appositi tag delle campagne. Su questa pagina prima di fare il redirect vero e proprio è necessario eseguire il codice di Analytics. Aggiungere poi la funzione _addIgnoredRef(“static.ak.facebook.com”) al GATC della pagina contenuta nel frame.

In questo modo il cookie __utmz viene impostato quando si è ancora sul nostro sito, e ha i parametri corretti, poi quando si arriva su Facebook esso non viene aggiornato per via della funzione addIgnoredRef.

Un po’ macchinoso, forse, ma ingegnoso! 🙂

Traduco un post di ROIrevolution, perché mi sembra interessante: riguarda alcuni consigli per il tracciamento dei sottodomini

Non esiste un articolo specifico nell’help ufficiale dedicato al tracciamento dei sottodomini. Il più vicino è questo, che raccomanda quanto segue:

// questa è solo la parte modificata
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', '.example-petstore.com']);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_trackPageview']);

Propongo invece alla maggior parte dei siti con sottodomini, di usare il codice seguente:

// questa è solo la parte modificata
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', 'example-petstore.com']);
_gaq.push(['_addIgnoredRef', 'example-petstore.com']);
_gaq.push(['_trackPageview']);

Cosa c’è di sbagliato nel codice raccomandato da Google? ci sono tre aspetti che potrebbero generare problemi evitabili:

1. Disabilitare l’hashing è male

Disabilitare l’hashing del sito, tramite [‘_setAllowHash’, false] oppure [‘_setDomainName’,’none’] è necessario affinché il tracciamento cross-domain abbia successo. E’ una necessità sfortunata, tuttavia, perché l’hashing del dominio è una cosa veramente utile.

Per definizione, uno script non può identificare il dominio di un cookie; questa informazione non è disponibile a meno che essa non faccia parte del nome del cookie o sia scritta nel suo contenuto. Includere l’hash fornisce quella informazione, così il codice di Google Analytics può leggere il set di cookie corretto in situazioni dove potrebbero essercene più d’uno.

Disabilitare l’hash significa che il codice non ha modo di capire quale set di cookie sia quello corretto. La maggior parte delle volte esiste un solo set, quindi non è un problema. Ma se avete già usato Google Analytics senza il tracciamento dei sottodomini, allora finirete per avere due set di cookie per lo stesso dominio nel caso di un visitatore di ritorno (dopo la modifica, ndMC): un set creato dal codice vecchio, e un set creato dal codice nuovo. Questo accade più spesso nei sottodomini, ma può anche accadere sul dominio principale.

Eduardo Cereto ha un post che approfondisce questo problema con più dettagli e fornisce un altro caso in cui _setAllowHash genera problemi. La morale qui è che avete bisogno di _setAllowHash per il tracciamento cross-domain, ma se invece avete solo a che fare con sottodomini non è necessario e anzi potrebbe causarvi problemi.

2. Il punto messo come prefisso causa il reset dei cookie

Le pagine del Google Code offrono la seguente spiegazione per l’uso del punto prima del dominio quando si usa _setDomainName:

“se volete tracciare attraverso differenti sottodomini:
* dogs.petstore.example.com e
* cats.petstore.example.com

è richiesto un punto prima del nome di dominio”.

Se il vostro sito usa sottodomini allora avrete indubbiamente bisogno di quel punto, pena il non funzionamento del tracciamento. Se il vostro sito non usa sottodomini, comunque,sarebbe meglio non usare il punto.
Il motivo è ancora una volta l’hash. L’hash che viene generato dal codice di Google Analytics quando si usa il punto è differente da quello generato quando invece il punto non si usa. Ma l’hash generato quando non si usa il codice per tracciare i sottodomini sul sito principale è identico a quello generato quando si tracciano i sottodomini senza l’uso del punto.

Questo significa che se non si stavano tracciando i sottodomini in precedenza, usare il punto istruirà il codice di GA a distruggere i vecchi cookie perché l’hash non combacia, che è appunto simile a quanto descritto al punto 1.

Semplicemente, non includere il punto se non è necessario significa avere minori probabilità di reset dei cookie, cosa che facilità la transizione al tracciamento dei sottodomini.

3. Non utilizzare _addIgnoredRef causa problemi di auto-referrer

Se il vostro sito non ha sottodomini il GATC è capace di riconoscere quando la sessione di visita è scaduta tra due pagine visualizzate ed evitare di sovrascrivere il referrer esistente con un auto-referrer o un referrer-interno (cioè evita di far comparire il vostro stesso sito come referrer ndMC).

Questa “protezione” è tuttavia rimossa quando ci sono dei sottodomini, anche se il vostro codice usa la soluzione standard per il loro tracciamento. Questo può risultare in una percentuale elevata di auto-referrer anche se sembra che abbiate fatto le cose per bene.

La soluzione è usare _addIgnoredRef, ma come usarla spesso non è capito fino in fondo. Le raccomandazioni di Google sono di usare un codice simile a questo:

_gaq.push(['_addIgnoredRef', 'www.sister-site.com']);

Ho guardato in profondità nel sorgente di ga.js e osservato che una cosa così effettivamente non funziona. La ragione è che il codice di tracciamento considera www.sister-site.com identico a sister-site.com, quindi aggiungere www.sister-site.com come referrer ignorato non risolve granché. Usare un punto prima del dominio fallisce anche qui. Questo invece funziona benone:

_gaq.push(['_addIgnoredRef', 'sister-site.com']);

e ancora meglio

_gaq.push(['_addIgnoredRef', 'sister-site']);

Il GATC controlla ogni riga di referrer ignorati che aggiungete e usa il metodo javascript IndexOf per determinare se la stringa è contenuta o meno nel dominio referente. Se uno di questi controlli risulta essere positivo, allora il referrer è ignorato. Poiché il dominio principale senza il punto sarà contenuto anche in tutti i sottodomini, passarlo a _addIgnoredRef funziona bene. Questo elimina anche la necessità di aggiungere un _addIgnoredRef separato per ogni sottodominio.

Possono comunque esserci auto-referrer residui, ma non più di quanti ce ne sarebbero senza i sottodomini. La ragione è che _addIgnoreRef funziona soltanto quando il cookie contiene già informazioni di referrer. Se un nuovo visitatore arriva al vostro sito su una pagina senza codice di Analytics e poi naviga verso una pagina che invece ce l’ha, il risultato sarà che il vostro sito compare tra i referrer, a prescindere dalle accortezze che avrete usato per evitarlo.

Questi tipi di auto-referrer possono essere evitati assicurandosi di aver taggato ogni pagina del sito. Quindi se ci sono pagine che hanno questo problema, potete utilizzare GA per determinare esattamente quali esse siano, e siccome state usando _addIgnoredRef sarà facile isolarle dato che non avrete altri falsi positivi generati senza apparente ragione.

La cosa importante da ricordare, quindi, è che _addIgnoredRef dovrebbe essere inclusa per definizione ogni volta che si tracciano sottodomini, non solo se si notano auto-referrer

[update 27/1: Analyticpros chiarisce ancora meglio come funziona la routine per l’aggiornamento del cookie __utmz; le condizioni per aggiornarlo sono due: se nel DOM document.referrer è diverso da document.domain e se si tratta di una nuova sessione. Ne consegue che anche nell’ipotesi di codice ottimale se un visitatore è nel sito principale e ci resta 40 minuti, e poi clicca un link che lo porta ad un sottodominio, poiché entrambe le condizioni sono verificate il codice di GA provvederà ad aggiornare il cookie, causando un auto-referrer]

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();