Google Analytics in 30 secondi

Google Analytics è un sistema di web analytics lato client basato su un pezzetto di codice javascript: ne consegue che tutto quel che non è taggato, per lui è invisibile. Detto così sembra banale, però non lo è quando si cerca di rispondere alla domanda “che succede quando si passa da una pagina senza tag?”
Di fronte a questa domanda ho sentito le risposte più fantasiose, e anche le più irrazionali. La risposta è: niente! La risposta completa in realtà sarebbe “dipende da QUANTO tempo trascorre sulla pagina non taggata” e il tutto parte dal presupposto che la pagina sia nello stesso dominio che si sta tracciando.

Se infatti la pagina non tracciata fa parte di un ALTRO dominio, o di un sottodominio che genera un altro set di cookie, o di un dominio terzo con lo stesso codice di GA ma non gestito con le apposite funzioni di passaggio dei cookie, allora il ritorno ad una pagina tracciata rientra nel caso di una visita da referrer: se il cookie __utmz contiene qualsiasi altra informazione, viene cambiato, viene generata una nuova visita e si vede un referrer.

Se invece si sta parlando di una normale navigazione A -> B -> C, dove la pagina B NON CONTIENE il codice di GA e le altre due si, quel che arriva ai server di Analytics è semplicemente A -> C; B non esiste, non avrebbe modo di sapere che esiste e non può essere tracciata. All’arrivo sulla pagina C Analytics si chiede “e questo visitatore chi è, da dove arriva?”, controlla se è presente il cookie __utmb (che scade dopo 30 minuti di inattività dell’utente), e se lo è semplicemente accoda la pagina C alla visita, e la piazza dopo la pagina A.

Se invece sulla pagina B l’utente trascorre più mezz’ora, allora si genera un nuovo cookie __utmb, quindi una nuova visita, con referrer il proprio sito. Ma questo accade in ogni caso in cui l’utente lascia scadere la sessione di visita, anche nei siti taggati perfettamente.

C’è però una cosa da tenere presente, che è una conseguenza del cambio di calcolo delle visite operato da Google Analytics nell’Agosto 2011: siccome prima di allora il modo per controllare se iniziare o meno una nuova sessione era il cookie __utmc (che veniva distrutto alla chiusura del browser), una sequenza come A -> browser chiuso -> B (il tutto entro mezz’ora) veniva vista come due distinte visite. Da dopo il cambio si tratta invece di una sola visita.

Una delle cose che dico sempre a clienti e durante i corsi, e che sottolineo finché non viene recepita bene, è che Google Analytics sottostima il traffico diretto, perché semplicemente le visite potenziali da tracciare come DIRECT non sovrascrivono il cookie __utmz se in esso è presente un’altra campagna (che non sia direct, ovvio). La cosa l’ho spiegata tempo fa nel post in cui illustravo un’eccezione: tabella di conversione delle sorgenti.

La cosa si può spiegare in parte anche con le ipotesi “maliziose”. Se un utente fa un clic su un annuncio AdWords ma non converte, se poi torna con visita diretta e converte, la conversione viene attribuita al cpc, facendolo sembrare più redditizio di quanto non sia realmente. Ma la cosa come abbiamo detto vale anche per ricerche organiche, referral e campagne, vorrei che restasse chiaro. Dal punto di vista dell’analista d’altronde la cosa nemmeno mi dispiace troppo: il traffico diretto è un po’ un punto morto delle analisi, si possono fare ipotesi (e a volte si riescono anche a verificare), si può vedere la landing page, ma non ci sono molti altri spunti possibili, al contrario di tutte le altre fonti di traffico.

Cosa succede però nei Funnel multicanale, dove la sorgente usata (e addirittura l’ordine delle sorgenti) ha un ruolo fondamentale per la comprensione dei report? se si seguisse la stessa logica si avrebbero GROSSI problemi a comporre quei report, e le valutazioni conseguenti ne sarebbero inficiate. Infatti, come ci informa questo articolo della guida, nelle Canalizzazioni Multicanale – E SOLO IN QUEL SET DI RAPPORTI – il traffico diretto è puntualmente tracciato a prescindere dal cookie __utmz. Nell’esempio precedente al cpc verrebbe attribuita una conversione indiretta (e verrebbe raffigurato come una freccia nel report “canalizzazioni indirette”) e al traffico diretto verrebbe attribuita la conversione (e verrebbe indicato con un rettangolo).

E’ una differenza fondamentale da tenere ben presente quando si guardano i funnel multichannel.

Nel proseguo dell’articolo vengono menzionati altri due fatti interessanti, che riporto per comodità:

• ci possono volere fino a due giorni di tempo per vedere i dati delle canalizzazioni multicanale. Meglio non fare analisi per il giorno precedente.
• Il totale conversioni indicato è sempre dato dalla somma di GOAL + transazioni ECOMMERCE

Nel complesso mi sembrano tre cose molto utili da tenere a mente quando si analizzano i multichannel funnel. Voi li usate? li avete personalizzati?

Se vi ricordate, a maggio scrissi un post lamentandomi dei concetti relativi alla web analytics contenuti nella versione preliminare delle linee guida per i siti web della Pubblica Amministrazione. So di essere una persona che si lamenta molto (sono genovese, ce l’ho nel DNA ), ma siccome è un argomento cui tengo mi armai di buona pazienza e feci l’iscrizione al forum dove si raccoglievano le osservazioni: le potete leggere a questo indirizzo.

Ieri è uscito l’aggiornamento delle linee guida, la versione finale, e indovinate un po? le mie osservazioni sono state prese in considerazione, infatti la nota è diventata

Il conteggio dei visitatori unici dipende da molteplici variabili. Ai fini statistici, si consiglia di calcolare, tramite cookie, il numero complessivo di visitatori unici in un periodo di tempo limitato a 30 giorni

(ancora perfettibile ma sicuramente migliore di prima), in compenso mi è caduto l’occhio su un’incongruenza mica male. Infatti a pagina 54, nella nota sopra riportata, si raccomanda l’uso dei cookies come avevo suggerito, mentre a pagina 53 essi sono vietati! Cito:

né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. L’utilizzo di cookies permanenti è ammissibile unicamente qualora esso sia necessario alla resa di un servizio che rientri nelle funzioni istituzionali dell’Amministrazione.

e direi che la web analytics non è un servizio istituzionale delle Pubbliche Amministrazioni.

In sostanza è obbligatorio pubblicare i dati di visite (v. pagina 55), pagine viste e visitatori unici, si raccomanda di distinguere gli unici tramite cookie, ma è vietato usare i cookies!

Bravi, bene, avanti così! :-/

Per lavoro mi occupo di siti per la pubblica amministrazione, e per questo motivo mi sono trovato davanti agli occhi la versione 11 maggio 2011 delle linee guida per i siti web della PA. Mentre mi addentravo nella lettura mi è caduto l’occhio su questa pagina del capitolo 4 e in particolare sulla nota a fondo pagina

[21] Si raccomanda di considerare, per le statistiche web, un visitatore unico ogni 30 minuti per IP.

La cosa ovviamente non ha senso: un visitatore unico prescinde da un intervallo di tempo, e di sicuro se io faccio una visita di un’ora e mezza non sono tre visitatori, ma uno solo. Inoltre sono anni che si dice che basarsi sugli IP è arcaico, perché le visite aziendali fatte da dietro a un proxy (ma anche gli accessi dalla rete geografica di Fastweb) vengono “annegati” dietro a un unico indirizzo. Migliaia di persone che risultano come una sola, che però ogni mezz’ora va conteggiata come fosse un’altra :-/

Perché – mi direte voi – una scelta così palesemente sbagliata? non lo so, ma di sicuro fa il paio con quanto scritto nel paragrafo “Policy” a proposito dei cookies, che sarebbero la soluzione al problema di cui sopra:

…né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. [omissis] L’utilizzo di cookies permanenti deve essere strettamente limitato all’acquisizione di dati statistici relativi all’accesso al sito e/o per mantenere le preferenze dell’utente (lingua, layout, etc.)

Due frasi in antitesi tra di loro: da un lato sembrerebbe che non si possano utilizzare cookies per il tracciamento, ma per le statistiche si. Ma allora se posso utilizzare i cookies, perché definire gli unici attraverso gli IP?

Infine, tanto per non farsi mancare nulla, le linee guida impongono che i dati del monitoraggio vengano pubblicati periodicamente. Tralasciamo un attimo il fatto che se ogni PA usa un sistema di web analytics differente, i dati non saranno mai confrontabili, e concentriamoci su un altro aspetto: i tre dati da pubblicare sono (sic!) pagine viste, sessioni utente (visite) e visitatori unici.

Solo che, se non si da un intervallo di tempo, parlare di unici non ha senso, per il noto “problema dell’hotel“. Alla linea guida manca fondamentalmente l’indicazione del periodo di tempo da considerare per l’indicazione degli unici. Ogni mese si deve dare il totale annuale degli unici, oppure ogni mese si deve dare il numero di unici del mese precedente?

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]

Come ho detto più volte su questo blog, Google Analytics è un sistema di web analytics “last cookie win”, dove cioè la conversione all’obiettivo viene attribuita all’ultima fonte di traffico che ha generato la visita. Per la precisione il modello esatto è descritto nel mio vecchio post “tabelle di conversione delle sorgenti“. Per non sovrascrivere la fonte di traffico è necessario che la pagina di atterraggio del visitatore abbia il parametro “no_override”.
Altri sistemi invece usano il paradigma contrario, cioè il “first cookie win” dove la conversione è attribuita alla PRIMA fonte di traffico e le successive non apportano modifiche a questa informazione. Infine in passato abbiamo parlato anche di sistemi che cercano di ovviare a questo problema con metodologie varie, una su tutte il supercookie ideato e sviluppato da ConversionWorks.

Tutto questo preambolo serve a fare il punto della situazione prima di introdurre un nuovo sistema di cattura e calcolo della cosiddetta “multitouch analytics”, cioè l’analisi delle varie sorgenti che hanno portato ad una conversione: www.multitouchanalytics.com. Il sistema è composto da uno script da scaricare, mettere online e richiamare sulle proprie pagine (e nelle pagine di conferma dell’ordine) e da un pacchetto di report che però – ahinoi – necessitano di un server dove gira Perl per poter essere usati. Questo fatto limita parecchio le possibilità di adozione da parte dei semplici utenti e lo relega al momento solo agli esperti, o a chi ha un esperto a disposizione. Ma confidiamo che in futuro riescano a renderlo più accessibile.
I dati vengono raccolti tramite gli eventi di Google Analytics, immagazzinati in un cookie nel computer del visitatore, e vengono poi interrogati tramite il pacchetto Perl che si poggia sulle API di GA. Un esempio dei report disponibili è nella pagina Examples

In questo report ad esempio vi è l’elenco delle combinazioni dei canali e i relativi conteggi: la maggior parte degli acquisti viene fatta con una sola attribuzione, un po’ meno con due e solo 149 hanno bisogno di quattro differenti canali. Più sotto c’è il dettaglio di quanto è stato incassato ad esempio grazie alla combinazione di Adwords + Campagne email + referral (11 transazioni, 651 dollari di revenue). I report possibili sono:

• Channel Overlap: un riepilogo delle sovrapposizioni dei canali e delle loro combinazioni
• All attribution: mostra tutte le transazioni e le revenue in cui compare almeno una volta un canale
• Even Attribution: Attribuisce conversioni e revenue in proporzioni uguali ad ogni canale
• Distribuited Attribution: Attribuisce conversioni e revenue in proporzione al numero di visite generate da ogni canale
• First Touch, Last Touch, 50-50: Le attribuzioni sono basate sul canale della prima visita (first cookie win), dell’ultima visita (last cookie win) oppure divise al 50% tra il canale della prima e dell’ultima visita
• Transaction Distribution: mostra il numero di transazioni con un solo canale, con due, tre, eccetera…
• Transactions Report: mostra ogni singola transazione i canali che hanno contribuito
• Touchlist: mostra ogni singola transazione e la sequenza dei canali, in ordine cronologico

Sostanzialmente permette di fare quel che oggi si può fare con i Search Funnel Reports di Adwords (e anche qualcosa in più) senza però essere limitati al solo canale Adwords. Una aggiunta mica da ridere per chi ha bisogno di conoscere puntualmente le ripartizioni dei budget di investimento sui vari canali di promozione online.

Google ha scritto sul proprio blog ufficiale di Analytics che sta testando un plugin per browser in grado di evitare che gli utenti che non lo desiderano vengano tracciati.
Esistono già parecchi modi per fare questa operazione, ma la maggior parte di essi presuppone conoscenze tecniche; gli altri non hanno quasi mai avuto la fama necessaria. Il fatto che il plugin sia sviluppato da Google stessa invece ci fa ben sperare sulla sua possibilità di arrivare a una massa critica.

Dal punto di vista di chi invece le statistiche le guarda, invece, questa forse non è una buona notizia: significa che chi lo desidererà diventerà completamente invisibile ai vostri occhi. Si tratta di un altro passo verso il pieno rispetto dei requisiti che un sistema di web analytics serio deve rispettare: Yahoo Web Analytics offre già un link dove impedire che i futuri cookie del suo sistema vengano scritti sul proprio computer (qua l’indirizzo), idem Webtrends (ecco la pagina, il link è piccolo in fondo). Esiste anche una specifica pagina che raccoglie tutti questi link, su world privacy forum.
Il problema di questi sistemi è che si basano su cookie tanto quanto i sistemi di web analytics, quindi soffrono del problema della cancellazione dei cookie da parte dell’utente/azienda. Il sistema di Google sarà basato sul browser (quale browser, però? tutti?) e dovrebbe esserne immune: chissà se anche altri vendor di sistemi di web analytics vorranno salire sul carro e approfittare dell’occasione, o se resteranno con i loro invisibili link e un metodo che prima o poi tende a far ritracciare l’utente.

Recentemente le autorità tedesche avevano ribadito la necessità di un sistema di opt-out chiaro per i sistemi di web analytics, e poiché anche per questo GA era finito sulle prime pagine delle testate informative in Germania, la mossa mi sembra alquanto scontata.

Ecco un interessante script realizzato da Allaedin Ezzedin di e-nor, che permette di conoscere in tempo reale quale è la fedeltà del visitatore. La fedeltà è espressa in Google Analytics dal numero di visite – compresa quella corrente – che ogni utente ha fatto sul vostro sito. Nei report trovate questa informazione cliccando su VISITATORI -> fedeltà visitatori -> fedeltà.

Nei segmenti avanzati è invece possibile guardare solo il traffico realizzato – ad esempio – da chi è alla decima visita (e SOLO alla decima) creando un segmento con i parametri conteggio delle visite -> corrisponde esattamente -> valore: 10.
Se ad esempio vi accorgeste che in generale l’utente converte meglio tra la quarta e la sesta visita, come potreste usare questa informazione? non sarebbe bello potergli presentare una call-to-action personalizzata, magari in una posizione ancora più favorevole? o al contrario, potreste usare l’informazione per cercare di migliorare le conversioni nelle visite che il report vi dice non convertono mai.

Lo script di Allaedin serve proprio a questo: permette di leggere il cookie __utma del visitatore e quindi di sapere il numero di visita nel quale esso ricade. Lo script è questo

function get_visit_count(str)
{
var i, vc='-';
if (str != '-') {
   i = str.lastIndexOf(".");
   i++;
   vc = str.substring(i);
   }
return vc;
}

e restituisce un numero intero corrispondente al numero di volte in cui l’utente che sta navigando è stato sul vostro sito.

Esiste anche la versione con il numero di pagine viste, però all’interno di una sessione: ad esempio potrebbe servirvi per “premiare” un visitatore che ha sorpassato le 20 pagine viste in una sola visita. Di nuovo, ecco il codice, questa volta basato sul cookie __utmb:

function get_pageview_count(utmb,utmc)
{
var i, j, pc='-';
if(utmb != '-' && utmc != '-'){
   utmc=utmc+'.';
   i=utmc.length;
   j=utmb.indexOf(".", i);
   pc=utmb.substring(i,j);
   }
return pc;
}

entrambi gli script sono disponibili in un file, scaricabile dal sito di e-nor.com, che contiene anche un altro pezzo di codice essenziale al funzionamento. Il file è disponibile nel post, e le istruzioni dicono di aggiungere la chiamata a SessionTracker.js subito DOPO il codice di Google Analytics, in modo che alle funzioni vengano passati i valori già aggiornati di visita e numero di pagine viste.

Marco, non mi ricordo mai quali sono i parametri obbligatori quando si crea una URL per una campagna di Google Analytics

Tranquillo, sei solo l’ultimo della serie, è una cosa comune (e comunque anche io ogni tanto devo dare una rinfrescatina ). Come ho detto nel post dettagliato in cui descrivo come si gestiscono le campagne, i parametri obbligatori sono utm_campaign, utm_medium, e utm_source.

Ma che mondo sarebbe se qualcuno non si fosse preso l’onere di controllare se questa affermazione è totalmente vera? Così hanno fatto quelli di Lunametrics, arrivando a una conclusione inaspettata: fintanto che si include utm_source, la campagna funzionerà e il cookie __utmz verrà aggiornato correttamente, se invece il parametro manca il cookie non viene modificato affatto (esattamente come avviene usando il parametro utm_nooverride=1). L’inclusione del solo utm_source genera correttamente un record nel report campagne, attribuendo però al mezzo e alla fonte il valore di (not set).

Il consiglio dei ragazzi inglesi è quindi di mettere sempre per primo nell’URL l’utm_source, in modo che siano minimizzate le possibilità che esso venga troncato (si pensi ad esempio a un client email che fa l’accapo automatico dopo un tot di caratteri).

La cosa veramente buffa è che ho avuto un esempio sotto gli occhi per molto tempo, ma non ci ho mai fatto caso. Al vecchio URL cui puntava la campagna di Google Acqua che ho ospitato a inizio anno, e che è da poco tornata online, mancava del tutto il parametro utm_campaign, a meno che non fosse generato automaticamente lato server assumendo che tutti gli ingressi a quella pagina fossero provenienti dalla stessa – e unica – campagna.

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