Dec 19 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

Automatizzare il passaggio tra domini

autore: Marco Cilia categoria: javascript tag: , , ,

Ogni volta che ho a che fare con il passaggio dei visitatori tracciati da un dominio all’altro è un dramma: è un dramma spiegare ai clienti perché bisogna farlo (ma di solito la frase risolutiva è “ma allora perché il vostro sito non legge le informazioni nei cookie di gmail e facebook? 🙂 ), è quasi sempre un dramma implementarlo se non posso farlo direttamente, perché i tempi di reazione sono allungati. Comunque sia, come tutti voi dovreste ormai sapere, ogni dominio imposta un differente set di cookie, ed è il motivo per cui esiste la funzione _setAllowLinker e le relative _link e _linkByPost, con cui bisogna taggare TUTTI i link che inviano i visitatori all’altro – o agli altri – siti.

Lunametrics ha aggiornato un suo vecchio script per automatizzare la cosa alla sintassi asincrona:

Le istruzioni dicono di assicurarsi che siano presenti la _setDomainName impostata sul dominio di secondo livello nel quale è lo script di Analytics e la _setAllowLinker, condizioni di partenza necessarie, poi di scaricare e modificare lo script inserendo nella riga 5 i domini possibile sui quali si potranno inviare i visitatori, ed eventualmente nella riga 6 le estensioni dei file di cui si vuole tracciare i download.
Poi bisogna caricare il file nei domini e aggiungere una riga in cui si richiama il file; poiché il sistema è basato su jQuery è necessario un riferimento alla libreria, se già non l’avete (vanno bene anche le versioni basilari offerte su CDN, tipo google, microsoft, eccetera).

A quel punto ogni link che punta ad uno dei domini interessati conterrà la funzione _link e _linkByPost, e il processo sarà completamente automatizzato. Un po’ come accadeva con setXDomain su GAaddons, che però è stata dismessa dall’autore


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]


Feb 27 2009

Due codici di monitoraggio nella stessa pagina

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

Lego gemelliUna delle domande che mi viene rivolta più spesso – e che noto essere un evergreen tra le frasi di ricerca dei visitatori in arrivo – riguarda la presenza di due o più codici di monitoraggio di Google Analytics sulla stessa pagina/sito. Con la vecchia versione dello script, quella che fa riferimento a urchin.js, le cose erano leggermente più complicate di adesso, ma non ne parleremo. Cosa aspettate ad aggiornare il GATC a ga.js? 🙂

Poiché il nuovo codice di monitoraggio è scritto seguendo la logica della programmazione a oggetti, per inviare i dati a due profili differenti è sufficiente creare due distinti oggetti di tracciamento. In GA gli oggetti di tracciamento sono quelli identificati dalla riga di codice
var pageTracker = ...

In effetti quando nei post ci si riferisce a pageTracker si commette una imprecisione: quello è il nome dell’unico oggetto creato per definizione dal codice che Google ci mette a disposizione, ma nulla vieta di cambiargli nome o, appunto, crearne più d’uno. Ecco allora che un codice fatto così:


<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">
var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-99999-3");
MarcoTracker._trackPageview();
</script>

è perfettamente legale e funzionante, ed invierà i dati all’account 12345 profilo 1 e 99999 profilo 3. Se la necessità è quella di inviare dati a più di due account si procederà di conseguenza creando ulteriori oggetti di tracciamento con nomi differenti. Questi oggetti sono (o meglio, dovrebbero essere, ma lo vediamo più tardi) completamente indipendenti l’uno dall’altro, per cui è possibile aggiungere funzioni al primo piuttosto che al secondo.

Nella realtà le cose sono leggermente differenti, e Lunametrics ci spiega perché: nonostante i codici di tracciamento facciano riferimento ad account differenti, i cookie – che ricordo sono scritti in base al dominio e non all’account Analytics – sono gli stessi per tutti e due (o più) oggetti di tracciamento.
Tra i casi di “sicuro insuccesso” relativi alla presenza di più codici di monitoraggio in una stessa pagina, Lunametrics ne cita tre che vale la pena di riportare:

1 – Codici differenti


var pageTracker = _gat._getTracker("UA-11111-1");
pageTracker._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-22222-1");
MarcoTracker._trackPageview();

Nell’esempio di Lunametrics il primo oggetto di tracciamento include le funzioni _setAllowHash e _setAllowLinker e il secondo no. In questo caso i due oggetti tentano di scrivere lo stesso cookie con intenzioni e formati diversi.

2 – Pagine differenti

Nel caso in cui uno dei due codici non sia inserito in tutte le pagine, magari in seguito a una condizione if impostata male o non realizzata, alcune pagine vengono tracciate in un account e in un altro no. Il codice di tracciamento “in difetto” vedrà i cookie che erano originariamente stati creati da una pagina che non ha quel codice. La prima pageview registrata dal secondo codice avrà informazioni di referrer diverse, poiché penserà di essere la prima pagina della visita mentre in realtà è la seconda, e così via…

3 – Segmenti personalizzati in base a _setvar()

Il segmento personalizzato “Valore definito dall’utente” viene impostato tramite la funzione _setVar() e immagazzinato nel cookie __utmv. Siccome i due codici usano gli stessi cookie, un segmento personalizzato creato dal primo codice è automaticamente creato e disponibile anche per il secondo. Questo comporta l’impossibilità di avere, ad esempio, un valore impostato su “loggato/non loggato” per il primo oggetto e “maschio/femmina” per il secondo. Poiché l’esecuzione di javascript è sequenziale nella pagina, il secondo codice sovrascriverà sempre il cookie e l’unica informazione disponibile per il segmento, alla visita/pagina successiva, sarà quella impostata dal quell’oggetto di tracciamento.

Se decidete di implementare più codici di monitoraggio di Google Analytics su uno stesso sito, o una stessa pagina, dovete prestare attenzione alle possibili conseguenze.
[photo credit: oskay su flickr]


Sep 11 2008

funzioni: _setAllowLinker(), _link() e _LinkByPost()

autore: Marco Cilia categoria: funzioni tag: , , , , ,

Riprendendo il post precedente, dicevo che _setDomainName() andava impostato su “none” nel caso in cui si volesse avere il controllo completo dei casi in cui i visitatori avrebbero dovuto passare da un dominio a un altro mantenendo lo stesso cookie. Questa operazione è particolarmente importante quando i domini sono completamente differenti, e non sono solo uno il sottodominio dell’altro, ad esempio www.miosito.it e www.shopmiosito.com.

La funzione _setAllowLinker(booleano) permette di abilitare su Google Analytics la gestione manuale della migrazione dei cookie, e di default è disabilitata. Va invocata esplicitamente nel GATC insieme a _setDomainName() 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">
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._setDomainName("none");
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();
</script>

sia sul sito origine sia sul sito destinazione. A questo punto è necessario aggiungere un pezzo di codice a ogni singolo link che porta da un dominio all’altro e che non vogliamo dia origine a una nuova visita (come appunto il caso di un carrello acquisti) con la funzione _link(url_destinazione), per esempio così:
<a href="http://www.shopmiosito.com/?negozio=scarperosse" onclick="pageTracker._link(this.href); return false;">inizia l'acquisto delle tue scarpe</a>

Bisogna notare che il cookie in questo caso è passato in ogni caso con una richiesta GET, e quindi è visibile nell’url del browser. Per passare da un sito a un altro usando una form, è necessario usare l’analoga funzione _linkByPost(oggetto_form), per esempio usando il codice:
<form action="http://www.shopmiosito.com/paginaprocesso.php" name="alcarrello" method="post" onsubmit="pageTracker._linkByPost(this)">