Aug 19 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

La fine di _setAllowHash()

autore: Marco Cilia categoria: funzioni tag: ,

Uno degli aggiornamenti al changelog di Google Analytics di Agosto riporta questa interessante informazione

The call to _setAllowHash(false) is no longer required when configuring cross-domain tracking. Pages that already include a call to _setAllowHash(false) will continue to work, but it is no longer required when setting up a new site.

il che equivale a dire che la funzione è deprecata (e infatti è segnata deprecata anche nella documentazione).
Non c’è bisogno che vi precipitiate a modificare alcunché: se infatti toglieste il _setAllowHash(false) da un sito in cui è presente, causereste il reset di tutti i cookies dei vostri visitatori: la modifica quindi si intende solo a partire dalle nuove installazione che farete. Inoltre il processo di creazione automatica dello script non è ancora stato aggiornato, e scegliendo l’opzione “più domini di primo livello” propone ancora l’uso di _setAllowHash(false).


Jan 19 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

Tracciamento dei sottodomini: best practices

autore: Marco Cilia categoria: codice di monitoraggio tag: , , ,

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]


Dec 06 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

_setXDomain su GAaddons

[GAADDONS NON E' PIU' SUPPORTATO DALL'AUTORE]

Qualche tempo fa vi ho parlato di GAaddons, un piccolo javscript scritto da Stéphan Hamel per automatizzare ed estendere alcune funzionalità di Google Analytics. Una novità di questi giorni è l’introduzione, in versione beta, della funzione _setXDomain, che serve a semplificare – e di molto aggiungerei – la normale gestione del cosiddetto crossdomain tracking, ovvero la gestione di Google Analytics quando si ha a che fare con stoddomini e domini multipli.

Nella pagina di documentazione della funzione Stéphane ha ripreso i casi dell’help ufficiale di Analytics e li ha tradotti nella sintassi per il suo addon, e così le due chiamate necessarie a tracciare un dominio e un sottodominio nello stesso profilo passerebbero da

 _gaq.push(['_setDomainName', '.example-petstore.com']);
  _gaq.push(['_setAllowHash', false]);

a un più semplice

_gaq.push(['_setXDomain', {
      domainName: '.example-petstore.com'
      }]);

Fino qua niente di che. Vediamo adesso il codice per domini multipli e sottodomini. Normalmente ci sarebbe un setdomainname, un setallowlinker e un setallowhash sul dominio principale e sul sottodominio, e un setdomainname differente con setallowlinker e setallowhash nell’altro dominio principale. Inoltre tutti i passaggi da un dominio all’altro andrebbero gestiti con le funzioni link() e linkByPost(), e bisognerebbe fare molta attenzione a non dimenticarsi qualcuno di questi link.
Con la funzione di GAaddons il tutto si riduce a

_gaq.push(['_setXDomain', {
      domainName: '.example-petstore.com',
      include: /(my-example-blogsite.com|otherdomain.com)/
      }]);

e questo farà anche si che tutti i link “incrociati” abbiano le giuste funzioni per passare i cookie. Esistono poi i casi con domini e sottodirectory, ma poiché sono minoritari non ve li riporto e vi rimando ancora alla pagina di documentazione [che non è più online].

Una cosa da tenere presente è che esistono ancora due casi reali possibili per il crossdomain tracking, e cioè il tracciamento di due sole sottodirectory nello stesso dominio e gli iframe con contenuto su dominio esterno, ma che questi non sono (ancora, si spera) contemplati da GAaddons. Per il resto, questa mi sembra veramente una buona novità ed una semplificazione molto grossa: nella mia esperienza di consulente il tracciamento su più domini è sempre un momento di grande tensione e spesso rappresenta un momento in cui il tracciamento fa perdere consistenza ai dati. Avere una semplificazione in tal senso è estremamente positivo, e speriamo che anche Google se ne renda conto e magari copi l’idea :)

[In chiusura, vi ricordo che la funzione è in beta: se decidete di provarla scaricate la versione del file GAaddons appropriata, e fatelo avendo ben chiari i rischi cui andate incontro usando una versione sperimentale di qualcosa]


Apr 13 2009

Uso di _setVar() su più domini

Quando le cose da tenere d’occhio iniziano ad essere molte e variegate bisogna fare attenzione: Google Analytics fornisce gli strumenti, ma bisogna stare attenti a possibili effetti collaterali non documentati. Prendiamo ad esempio l’ultimo post di Lunametrics, che riporta una situazione con un codice di monitoraggio per più domini di questo tipo:


var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._setVar(’buyer’);
pageTracker._setAllowAnchor(true);
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();

questo codice inizializza l’oggetto di tracciamento, poi scrive nel cookie __utmz il valore buyer (ovvero assegna il visitatore al segmento compratori), poi permette l’uso del cancelletto nelle campagne, poi permette di trasportare il cookie da un dominio a un altro, disabilita il check dell’integrità dei cookie basato sul dominio (quando si raccolgono dati da più sottodomini in un unico account), e infine raccoglie i dati e li invia al server di Google.

Quale è il problema di questo codice? il problema è che _setAllowHash di fatto cambia il formato di scrittura del cookie, e ci sono due funzioni che scrivono cookie: _setVar che si trova prima di setAllowHash e trackPageview che invece si trova dopo.
In questo modo GA va in confusione e perde informazioni sulla sessione e sul referrer, assegnando a traffico diretto la seconda – falsa – visita.

La soluzione è quella di chiamare _setVar() sempre dopo _setAllowHash() (o _setDomainName(‘none’); se lo usate); bisogna sempre tenere presente che il javascript di Google Analytics ha a che fare con i cookie, e che alla fine sono loro che “comandano” quel che poi vediamo nei nostri report.