Google Analytics in 30 secondi

Della funzione _addOrganic() abbiamo già parlato in passato: essa serve ad aggiungere un motore di ricerca alla lista predefinita che Google Analytics riconosce autonomamente, lista che viene modificata nel tempo e che rispetto al post di luglio 2008 è diventata:

images.google:q
google:q
yahoo:p
msn:q
bing: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:q
sesam:q
ozu:q
terra:query
nostrum:query
mynet:q
ekolay:q
search.ilse:search_for
rambler:words

fino ad oggi i vostri motori di ricerca venivano aggiunti in coda a questa lista, ma poiché il match viene effettuato in ordine e interrotto alla prima occorrenza (perché una visita con keyword non può certo essere attribuita a due motori differenti!) c’era la remota possibilità che un motore predefinito intercettasse la visita e la keyword prima del motore da voi specificato. Per questo motivo a partire dal mese scorso è stato aggiunto un parametro opzionale alla funzione che serve a dire a GA di consultare prima la lista dei motori personalizzata, e dopo quella predefinita.
Il nuovo parametro è opzionale, è un booleano (quindi 1 o 0, vero o falso) e se non specificato è automaticamente impostato su falso, in modo da replicare la situazione già esistente.

Riprendendo l’esempio che feci nel post originale, la nuova sintassi per aggiungere il motore di Libero e metterlo in cima alla lista (quindi prima di images.google) è

pageTracker._addOrganic("libero","query",1);

Sono piccoli miglioramenti che ai più possono risultare inutili, ma che sicuramente risolvono grossi problemi a qualcuno nel mondo…

Mi sono accorto che pur avendone parlato più volte non ho mai scritto il post di riferimento della funzione _setVar(stringa). Questa funzione serve a scrivere un valore all’interno del cookie __utmv, e il valore è a discrezione del webmaster del sito; una volta che il contenuto del cookie è impostato, esso verrà trasmesso in tutti i successivi invii di codice a Google Analytics (ovvero ogni volta che verrà richiamata la gif trasparente), permettendo così di “taggare” il visitatore (attenzione: il visitatore e non le visite).
Un esempio tipico è quello di assegnare tramite _setVar il valore “loggato” a chi effettua il login sul sito, in modo da poter discernere la sua attività da quella di chi non l’ha fatto.

L’uso è molto semplice, si tratta di impostare la riga

trackPageview._setVar('miovalore');

in un punto qualsiasi della pagina, sull’onclick di un elemento, sull’onload del body. Ovunque insomma ci sia bisogno di impostare il cookie che da lì in poi – e per i successivi due anni – manterrà il valore, a meno che esso non sia sostituito da un’altra funzione _setVar impostata dal medesimo codice di GA (quindi le _setVar di due siti diversi non interferiscono, come è ovvio che sia). Su un blog WordPress, ad esempio, sarebbe possibile assegnare un valore corrispondente al livello dell’utente che si collega (Administrator, Editor, Contributor, ecc.).
Il famoso sistema supercookie per tracciare tutte le fonti di una conversione separa diversi valori di setvar con un segno | (pipe), e lo fa per ovviare all’unico vero grande limite di questa gestione da parte di GA: esiste un solo cookie __utmv, quindi si può attribuire un solo valore ad ogni utente; oppure si possono assegnare più valori come nel supercookie, ma essi verranno sempre riportati come aggregati (per intenderci, ogni valore è una riga del report).
La speranza di tutti noi è che un giorno Google decida di aumentare i possibili valori di questo cookie mantenendoli però separati, perché la gestione della funzione _setVar() è molto comoda.

A livello di report il valore impostato da _setVar() viene scritto nel campo “Definito dall’utente” (User Defined se usi l’interfaccia inglese) e lo si può trovare nel report omonimo all’interno del gruppo “visitatori” oppure come valore utilizzabile nel menu a tendina delle segmentazioni. Una lettura esaustiva, in inglese, sui report relativi alla segmentazione viene da morevisibility.com, da cui si evincono due informazioni interessanti:

• nel caso in cui un utente cambi il valore di _setVar() durante una sessione di visita, GA attribuirà l’eventuale conversione al primo valore letto per quella sessione.
• le pagine viste, al contrario, vengono tutte attribuite all’ultimo valore

Un’altra cosa su cui vale la pena di ragionare è che _setVar() rappresenta l’unico punto di ingresso in GA in cui è possibile inserire un valore arbitrario. Tutti gli altri valori infatti dipendono dall’attività di navigazione e sono dati puri o derivati da calcoli. Questo cosa significa? significa che, fatte salve le limitazioni sulla privacy imposte dai termini del servizio, dentro al cookie __utmv possiamo infilare qualsiasi cosa ci sia utile avere direttamente dentro all’interfaccia di Google Analytics affinché possa essere incrociata con gli altri dati, ad esempio i dati demografici dei visitatori da utilizzare successivamente per il bidding demografico di AdWords.

[edit: è uscito giusto in questi giorni un post sul blog ufficiale che parla dei segmenti definiti dall’utente e di _setVar()]

Come detto nel post precedente, la funzione che si usa in Google analytics per controllare la durata di una sessione di visita, ovvero il tempo massimo che può intercorrere tra la vista di due pagine prima che la visita venga considerata (forzatamente) conclusa, è _setSessionTimeout(stringa).

La funzione accetta come parametro una stringa – sebbene in realtà si tratti di numeri – e precisamente vuole il numero di secondi trascorsi i quali la sessione verrà considerata conclusa. Ad esempio aggiungendo prima della chiamata a trackpageview() la riga

pageTracker._setSessionTimeout(“900”);

si imposteranno sessioni di 15 minuti (60*15 = 900).
Questa funzione va maneggiata con cura, non tanto perché distruttiva nei confronti dei dati inviati, ma poiché è in grado di variare pesantemente i risultati delle analisi. Impostare sessioni molto brevi porta fisiologicamente ad aumentare il numero di visite (e di visitatori di ritorno), mentre allungarle sortisce l’effetto inverso. Usatela se ne avete realmente bisogno perché conoscete bene il tipo di utenza del vostro sito e perché avete esigenze particolari.

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

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