Google Analytics in 30 secondi

Google Analytics è un sistema di tracciamento delle visite tramite javascript, come abbiamo visto più volte; significa che ogni volta che un browser con javascript abilitato visita una pagina contenente il GATC, esso invia immediatamente una serie di informazioni ai server di Google. Siti con traffico molto alto, nell’ordine delle milioni di pagine viste al mese, generano una mole di richieste molto alta, ma naturalmente il problema non è certo la banda che l’infrastruttura di Google può dedicare ad Analytics, bensì il problema potrebbero essere i report.

I dati accumulati dai server vengono processati e messi “ordinati” nel database di GA, ma non viene fatto quasi nessun precalcolo. I dati sono sostanzialmente grezzi, altrimenti non si potrebbero creare i nuovi rapporti personalizzati. Questo però comporta lo svantaggio di dover effettuare i calcoli “al volo” ogni volta che apriamo un report, infatti più dati ci sono più il sistema può risultare lento (e con i segmenti avanzati la cosa è accentuata parecchio). Per questo motivo i profili con molte pageviews potrebbero presentare la dicitura “questo rapporto si basa su dati di esempio. Ulteriori informazioni” e i dati avere una percentuale di scostamento a fianco: significa che il numero visualizzato non è preciso ma è appunto in un intorno percentuale di quanto indicato.

La funzione _setSampleRate(stringa) serve a dire a Google Analytics di non conteggiare tutti i visitatori, ma solo la percentuale passata come parametro alla funzione. Ad esempio impostando la funzione così:
pageTracker._setSampleRate("70");
verranno tracciati solo sette visitatori ogni 10. Su siti di grandi dimensioni è un’operazione statisticamente possibile, e non inficia i rapporti generati anche perché Google Analytics si comporta in maniera coerente rispetto ai visitatori che ritornano. Ogni visitatore viene “marchiato” dalla funzione: se GA decide di tracciarlo, lo traccia sempre. Se decide di non tracciarlo, non lo traccia mai. In questo modo il suo comportamento è sempre registrato e l’esperienza utente sul sito non viene stravolta nei report.

Se il dubbio che vi ha assalito durante la lettura di questo articolo è “non sono sicuro di voler tralasciare parte delle visite”, la creazione di due oggetti di tracciamento distinti che puntano a due profili differenti è la soluzione che fa per voi: un profilo conterrà tutti i dati, un altro solo un sample. Potrete fare le analisi sul profilo agile e approfondire le questioni dubbie su quello completo, diminuendo il tempo di attesa del caricamento dei dati. Ecco un esempio di codice

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write("<script src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'></script>" );
</script>

<script type="text/javascript">
var firstTracker = _gat._getTracker("UA-12345-1");
firstTracker._setSampleRate("70"); // traccia il 70% delle visite
firstTracker._trackPageview();

var secondTracker = _gat.getTracker("UA-67890-1");
secondTracker._trackPageview(); //traccia tutte le visite
</script>

Esiste un modo alternativo di gestire le campagne in Google Analytics rispetto a quanto è stato illustrato nel post “la gestione delle campagne“: la gestione illustrata (e quella maggiormente utilizzata) inizia e finisce con la composizione e la diffusione di un link opportunamente taggato. Non è necessario fare altro, poiché il codice di tracciamento di Analytics sa già cosa deve fare, cosa deve raccogliere e cosa deve inviare ai server di Google senza bisogno di modificare nulla.

Il modo alternativo consiste nel tracciare come campagne anche URL che non sono stati pensati e progettati per GA; indirizzi magari precedenti all’installazione dello script, o indirizzi inviati per email per errore senza i parametri necessari, o altre cause. La condizione necessaria è che questi url presentino dei parametri riconoscibili, e la gestione si realizza tramite cinque funzioni (una per parametro possibile) in grado di convertire parametri che per Analytics non avrebbero senso in parametri di una campagna.

La prima funzione che affrontiamo è _setCampContentKey(stringa), e permette di convertire un parametro dell’url della landing page nel parametro utm_content inviato ai server. Supponendo che l’url inviato per email a migliaia di persone sia
http://www.miosito.it/xr100.php?fonte=newsletter&da=email&offerta=lancio-xr100&contenuto=sconto&chiave=casco

si può tramutare il parametro “contenuto” in “utm_content” aggiungendo la funzione
pageTracker._setCampContentKey("contenuto");
prima della chiamata a _trackPageview(); del GATC.

La funzione analoga _setCampMediumKey(stringa) effettua la medesima operazione ma consente di decidere da dove prendere il contenuto del parametro utm_medium. Nel caso succitato il parametro “da” viene catturato e trasformato aggiungendo la riga
pageTracker._setCampMediumKey("da");
prima della chiamata a _trackPageview();

Le altre tre funzioni da utilizzare in casi del genere, con le medesime modalità, sono:

• _setCampNameKey(stringa), cattura l’equivalente del parametro utm_campaign (”offerta” nell’esempio)
• _setCampSourceKey(stringa), cattura l’equivalente del parametro utm_source (”fonte” nell’esempio)
• _setCampTermKey(stringa), cattura l’equivalente del parametri utm_term (”chiave” nell’esempio)

Ovviamente le aggiunte di queste funzioni prima di trackPageview vanno fatte solo ed esclusivamente nella landing page che è oggetto della campagna “sbagliata”.

La gestione delle campagne è uno strumento molto potente in Google Analytics e alcuni si spingono addirittura a dire che sia la cosa meglio riuscita del prodotto. Quale che sia la vostra opinione, è indubbia una cosa: la gestione è talmente semplice che basta visitare un link con i parametri di una campagna per iniziare a vedere i relativi dati nei report. Non ho volutamente scritto “iniziare a diffondere link con i parametri” perché intendo proprio quel che ho detto: basta che qualcuno visiti un vostro indirizzo con i parametri di una campagna, una qualsiasi.
Per chiarire ancora meglio, se io visito il vostro sito tramite questo indirizzo
http://www.tuosito.it/index.php?utm_source=ilmiobrowser&utm_medium=miainiziativa&utm_campaign=melasonoinventata

voi inizierete a vedere le mie visite sotto la campagna “melasonoinventata”. C’è da dire che nei grossi numeri è improbabile che qualcuno riesca a far emergere una campagna inventata, e se ci riesce significa che porta abbastanza traffico da meritare una campagna vera, ma in siti con traffico relativamente basso è una possibilità che esiste. Se vogliamo è lo stesso discorso fatto a riguardo della copia dello script su domini diversi: la scelta progettuale è una, ed è degli ingegneri di Google, ma il sistema mette a tua disposizione gli strumenti per proteggerti. Nel caso in cui non si vogliano tracciare le campagne (nessuna campagna!) si può usare la funzione _setCampaignTrack(booleano), che disattiva il relativo tracciamento. E’ sufficiente aggiungere la riga
pageTracker._setCampaignTrack(false);
prima di trackPageView().

Essendo una funzione booleana, il tracciamento è spento o acceso; o escludete tutti i tracciamenti - e quindi non userete le campagne nemmeno volendolo - o li accettate tutti, compresi quelli “fasulli”. Alternativamente si può pensare a un filtro di inclusione solo per le proprie campagne, ma sarebbe un filtro da aggiornare molto spesso e comporterebbe qualche restrizione alla gestione stessa delle campagne.

La seconda funzione di cui parliamo oggi è _setAllowAnchor(booleano) e serve ad abilitare la gestione degli url delle campagne anche tramite il separatore # (cancelletto), oltre ai classici ? (punto di domanda) e & (e commerciale). Se devo essere sincero non ho mai visto utilizzare questa funzione da quando mi occupo di GA (anzi, ho visto URL taggati col cancelletto ma nelle pagine di destinazione non c’era la funzione _setAllowAnchor), ma poiché espande le possibilità di utilizzo è bene conoscerla. L’utilizzo è semplice, basta aggiungere la riga
pageTracker._setAllowAnchor(true);

prima della chiamata a trackPageView()

La funzione che va maggiormente tenuta da conto quando si instaurano delle campagne è _setCookietimeout(stringa); il motivo risiede nella gestione del cookie __utmz da parte dello script di Analytics: il cookie contiene le informazioni relative alla provenienza, ad esempio:
205114892.1220963346.1.1.utmccn=(organic)|utmcsr=google|utmctr=world+browser+stats |utmcmd=organic
(si viene da una ricerca su google con chiave “world browser stat”)

oppure:
219072577.1223545748.1.1.utmgclid=CITpr_XumZYCFQVOtAodAmkD7g|utmccn=(not%20set)|utmcmd=(not%20set)|utmctr=hotel%20roma
(provenienza campagna AdWords con chiave “hotel roma”)

Questo cookie ha una vita predefinita di sei mesi, o meglio 15.552.000 secondi, e le informazioni contenute sono sovrascritte secondo le famose 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.

Questo significa che se un visitatore arriva sul vostro sito tramite una ricerca da Google per “hotel roma” e poi se ne va, per i successivi sei mesi una sua eventuale visita diretta con conversione verrà attribuita a Google organico. Allo stesso modo, se proviene da una campagna fatta su una mailing list, si salva l’indirizzo nei preferiti e poi torna dopo cinque mesi e converte, la conversione è assegnata alla campagna della mailing list.

Per vari motivi questo tempo può essere ritenuto inaccettabile: Google Analytics mette a disposizione la funzione setCookieTimeout per prendere il controllo della data di scadenza del cookie __utmz. La funzione prende in ingresso come parametro il numero di secondi trascorsi i quali il cookie scadrà e il visitatore smetterà di essere marchiato con la campagna. Si usa così:
pageTracker._setCookieTimeout("5184000");

Vi lascio anche un breve elenco di date convenzionali trasformate in secondi:
1 giorno = 86400 secondi
7 giorni = 604800 secondi
14 giorni = 1209600 secondi
15 giorni = 1296000 secondi
30 giorni = 2592000 secondi
60 giorni = 5184000 secondi
90 giorni = 7776000 secondi
120 giorni = 10368000 secondi
180 giorni = 15552000 secondi

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;" onclick="javascript:pageTracker._trackPageview ('/outbound/www.shopmiosito.com');">inizia l'acquisto delle tue scarpe</a>

Bisogna notare che il cookie in questo caso è passato con una richiesta GET, e quindi è visibile nell’url del browser. Per passare da un sito a un altro con una richiesta in POST, ad esempio 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)">

La funzione _setDomainName(stringa) serve a impostare o forzare il dominio nei cookie di GA; questa informazione scritta nel cookie è infatti la sola che Google Analytics usa per determinare su quale dominio stia avvenendo la visita dell’utente. _setDomainName può assumere tre soli valori, cioè “auto”, “none” o il nome del dominio, e per definizione - ovvero quando non è invocata esplicitamente - è impostata su “auto”: questo fa si che GA scriva nel cookie il dominio estrapolandolo dall’oggetto location del DOM (Document Object Model).

Un esempio tipico in cui è necessario utilizzare questa funzione è la tracciatura di un dominio e un sottodominio nello stesso profilo, poniamo www.miosito.it e sub.miosito.it. Per prima cosa bisogna aggiungere al codice di monitoraggio la seguente riga
pageTracker._setDomainName(".miosito.it");
facendo bene attenzione al punto prima del dominio (è all’incirca equivalente a dire *.miosito.it), dopodiché è consigliato impostare un filtro per discernere le pagine all’interno dei report. Essendo i domini tracciati come fossero una sola cosa, infatti, le visite corrispondenti a www.miosito.it/index.asp e sub.miosito.it/index.asp verrebbero sommate a livello di pageview. Il filtro è questo:

e scrive al posto dell’URI della richiesta (index.asp) la stringa completa host-URI (www.miosito.it/index.asp).

L’ultima modalità di chiamata a _setDomainName() è “none” e va usata nel caso in cui si voglia disabilitare il tracciamento tra domini differenti o in quello molto più frequente in cui si voglia farlo avendone però il preciso controllo, quindi usandolo in congiunzione alle funzioni _setAllowLinker(), Link() e Linkbypost() che vedremo prossimamente.

_trackTrans() è l’ultima funzione della serie e-commerce ed è l’equivalente di trackPageview(). Dopo che altre funzioni hanno raccolto i dati necessari, entrambe si occupano di spedire il contenuto ai server di Google, completando la transizione delle informazioni dai browser ai server collettori.
_trackTrans() va usata tipicamente in congiunzione con _addTrans() e _addItem(), ma sempre e comunque dopo la chiamata a trackPageview(), altrimenti non funzionerà. Per cui, riprendendo gli esempi dei post precedenti, una transazione tipica e completa avrà il seguente codice:

pageTracker._trackPageView();
pageTracker._addTrans(
     "12345", // id_ordine
     "libreria ponte vecchio", // affiliazione
     "35.99", // totale
     "3.00", // tasse
     "5.99", // spedizione
     "Palermo", // città
     "Sicilia", // area
     "Italia" // nazione
     );
pageTracker._addItem(
   "12345", // id_ordine
   "TA2676", //sku
   "GAin30sec", // nome
   "Libri", // categoria
   "35.99", // prezzo
   "1"  //quantità
 );
pageTracker._trackTrans();

Sempre nell’ambito delle funzioni specificamente pensate per l’e-commerce, _addTrans(id_ordine, affiliazione, totale, tasse, spedizione, città, area, nazione) crea un oggetto-transazione del valore specificato. Come nel caso di _addItem() se un visitatore chiama due volte la funzione con uno stesso id_ordine (non sku, che in questo caso non è previsto) la seconda chiamata sovrascrive la prima. I parametri che _addTrans prevede, tutti stringhe, sono i seguenti:

• id_ordine: l’identificativo dell’ordine (lo stesso di _addItem - obbligatorio)
• affiliazione: nome del negozio o del partner che produce la transazione (facoltativo)
• totale: il costo totale sostenuto dal cliente (obbligatorio)
• tasse: l’ammontare dei costi per tasse sostenuti dal cliente (facoltativo)
• spedizione: l’ammontare dei costi di spedizione sostenuti dal cliente (facoltativo)
• città: la città associata alla transazione facoltativo)
• area: l’area associata alla transazione (può essere lo stato USA, o la regione italiana ad esempio - facoltativo)
• nazione: la nazione associata alla transazione (facoltativo)

Questa funzione ha anche un elemento di ritorno, utile in caso di debug. Questo oggetto è _gat.GA_Ecomm_.Transactions_ ed è l’identificativo dell’oggetto-transazione che è stato modificato dalla chiamata alla funzione.
Un utilizzo tipico di _addTrans() è quello che segue:

pageTracker._addTrans(
     "12345", // id_ordine
     "libreria ponte vecchio", // affiliazione
     "35.99", // totale
     "3.00", // tasse
     "5.99", // spedizione
     "Palermo", // città
     "Sicilia", // area
     "Italia" // nazione
     );

Anche questa volta, nel caso di parametri facoltativi, è necessario inserire le virgolette e lasciare vuoto il contenuto.

La funzione di oggi serve nel caso in cui abbiamo attivato i rapporti e-commerce dalle opzioni generali del profilo, e appunto popola i relativi report. _addItem(id_ordine, sku, nome, categoria, prezzo, quantità) aggiunge un elemento acquistato da un visitatore all’oggetto di tracciamento specificato; _addItem traccia gli oggetti per sku (Stock Keeping Unit, identificativo univoco del prodotto), per cui se nella stessa sessione viene chiamata due volte per lo stesso sku, viene registrato soltanto l’ultimo oggetto. La funzione prende sei parametri, tutte stringhe, in ingresso, che più precisamente sono:

• id_ordine: l’identificativo dell’ordine (fortemente consigliato)
• sku: l’identificativo univoco dell’oggetto (obbligatorio)
• nome: il nome dell’oggetto (facoltativo)
• categoria: la categoria merceologica dell’oggetto, se presente (facoltativo)
• prezzo: il prezzo dell’oggetto (obbligatorio)
• quantità: il numero di oggetti acquistati (obbligatorio)

Un esempio di uso della funzione è questo:

pageTracker._addItem(
   "12345", // id_ordine
   "TA2676", //sku
   "GAin30sec", // nome
   "Libri", // categoria
   "35.99", // prezzo
   "1"  //quantità
 );

Per i parametri non obbligatori, è facoltativo solo l’inserimento del valore all’interno delle virgolette, non la presenza del parametro nella chiamata alla funzione. Per intenderci, l’esempio soprastante si può modificare così:

pageTracker._addItem(
   "12345", // id_ordine
   "TA2676", //sku
   "",
   "",
   "35.99", // prezzo
   "1"  //quantità
 );

Il parametro id_ordine è fortemente consigliato poiché le documentazioni ufficiali sono contrastanti: la mia interpretazione è che si possa omettere solo nel caso di chiamata a _addItem() senza la relativa _addTrans(), per cui in casi tutto sommato abbastanza anomali. Nelle implementazioni che ho visto il parametro era sempre presente, per cui io consiglio di inserirlo.

Come sicuramente saprete e abbiamo avuto modo di dire, Google Analytics è un sistema di web analytics lato client che fa uso di un javascript per raccogliere informazioni da inviare a un server remoto, il quale provvederà ad elaborarle e a produrre i report (vedi lo schema di funzionamento).

Google tuttavia fornisce un altro strumento di analisi degli accessi, Urchin software (al momento versione 6), al costo di 1895 euro; si tratta di un software in grado di analizzare anche i logfiles prodotti dal websever, quindi un principio “opposto e complementare” a quello usato da Google Analytics. Esistono però delle funzioni che possono essere invocate nello script di tracciamento degli utenti che permettono di scegliere dove inviare tutti o parte dei dati.

La funzione _setLocalRemoteServerMode() serve a dire a GA di inviare i dati che registra sia al server remoto di Google sia a un nostro server locale, di fatto permettendoci di effettuare un backup dei dati grezzi (anche se poi sarà necessario Urchin per elaborarli). E’ una funzione senza argomenti che si invoca semplicemente richiamandola così
PageTracker._setLocalRemoteServerMode();
prima della chiamata a InitData().

E’ anche possibile fare in modo che i dati vengano inviati esclusivamente al nostro server, escludendo completamente Google dalla gestione dei dati, sempre a patto di possedere Urchin per effettuare le analisi. Bisogna impostare una chiamata alla funzione _setLocalServerMode() in questo modo
PageTracker._setLocalServerMode();
prima della chiamata a InitData(). L’utilità di questa funzione per i possessori di Urchin è grande: si possono utilizzare la sintassi e le funzioni del codice di tracciamento di Google Analytics ed elaborare i dati in locale, e contemporaneamente usare Urchin per analizzare i logfiles e capire, ad esempio, il comportamento degli spider (che vi ricordo NON sono tracciati da GA).

La funzione opposta, _setRemoteServerMode(), è quella invocata per definizione da Google Analytics, e invia i dati ai server collettori dell’azienda di Mountain View. Analogamente alla funzione precedente, tuttavia, i possessori di Urchin potrebbero decidere che parte delle analisi debbano essere svolte dai server di Google. Richiamando la funzione in questo modo
PageTracker._setRemoteServerMode();
prima di InitData() faremo svolgere allo script proprio questo mestiere.

Esiste un’ultima parte di codice da prendere in esame in questo post, e va usata ogni qualvolta si invochi una funzione che invia i dati a un nostro server: è la funzione _setLocalGifPath(stringa). Al punto 5 del workflow illustrato nel post “l’ordine è importante” ho detto che il GATC richiede una immagine gif trasparente di 1 pixel per 1 pixel; anche nel caso di Urchin - usato utilizzando il GATC e non tramite logfiles - è necessario usare la gif trasparente, e la funzione _setLocalGifPath() serve a specificare il percorso di questo file, e quindi di conseguenza il percorso del webserver che riceverà in risposta i dati tracciati dallo script, e va invocata prima ancora della riga che setta la destinazione dei dati.