Google Analytics in 30 secondi

Ho scoperto soltanto da poco che i cookie possibili scritti da Google Analytics sono sei, e non cinque come ho scritto nel relativo post. Ho quindi proveeduto ad aggiornare quel post piuttosto che riportare tutte le informazioni in uno nuovo, mi sembrava più sensato. Il nuovo cookie, __umk, viene comunque scritto e utilizzato solo in presenza di due funzioni specifiche che vi ho descritto pochi giorni fa: link() e linkByPost().

Secondo la guida ufficiale di Google Analytics in lingua inglese, il campo “lookup table” dei filtri personalizzati (“tabella di ricerca” in italiano) serve a

Lookup Table: (Currently unavailable) Selecting this filter allows you to select a lookup table name which may be used to map codes to human intelligible labels.

selezionare questo filtro permette di scegliere una tabella di ricerca che può essere usata per trasformare codici in informazioni utili ed etichette leggibili.

In sostanza potete avere una tabella che trasforma una serie di numeri in nomi parlanti di prodotti (un po’ come avere una serie molto grande di filtri “cerca e sostituisci”). Praticamente una tabella di ricerca era costituita da un foglio di calcolo con due colonne: la prima conteneva il parametro dell’URL da tradurre e la seconda la traduzione che avremmo letto nei report. Il problema è che questa funzionalità è disattivata da parecchio tempo, e da quando mi occupo di filtri su Google Analytics l’ho vista attiva per pochissimo tempo; comunque era necessario inviare la tabella via email indicando l’account e aspettare che gli ingegneri la caricassero.

Mi stavo domandando quanto tempo ci vorrà prima che Google abiliti una feature che mi sembra abbastanza banale e immediata: l’upload di questo file sul Google Docs esistente tramite lo stesso Google Account di Analytics. Nominando il file secondo una convenzione si potrebbe far confluire in uno specifico account, e poi sarebbe disponibile nei filtri. E si sgraverebbero anche gli ingegneri dal lavoro: sostituendo il file su GDocs si avrebbe una nuova tabella automaticamente.

[image credit: jayfreshuk on flickr]

Questo è un articolo che interesserà sicuramente Fello, che ci ha proposto una questione simile nei commenti al post “keyword con valori a zero” e io non sono mai riuscito a riprodurla nei miei report. Adesso Lunametrics ci spiega per filo e per segno perché questo accade: io non ci sarei mai arrivato, devo ammettere i miei limiti, perché comunque sia mi sembra un comportamento sbagliato da parte del codice di tracciamento. La sostanza del problema è che se avete la funzione _setVar() che imposta un valore nel cookie del visitatore, essa subito dopo aver scritto o modificato il cookie lo comunica a Google Analytics.

Quindi anche nel caso di una visita di una sola pagina vista, se c’è _setVar avvengono DUE interazioni con GA, e lui le interpreta come se non fossero un bounce, anche se di fatto non sono due pagine viste.

La soluzione è un workaround che inganna il codice di Analytics, creando un oggetto di tracciamento legato a un account che non esiste, e facendo scrivere il cookie a lui, e poi chiamando _trackPageView() usando l’oggetto legato all’account corretto, che genererà la pagina vista corretta portandosi già dietro il valore della variabile definita dall’utente tramite setVar, così:

var fakeTracker = _gat._getTracker("UA-1");
fakeTracker._setVar('/eyes=blue');
var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._trackPageview();

L’ho verificato personalmente e funziona senza problemi. i cookie scritti sono infatti indipendenti dall’account analytics specificato usando solo queste funzioni. Il rovescio della medaglia è che se usate questo metodo dovrete portarvi dietro il secondo oggetto di tracciamento per tutte le altre funzioni di GA che vorrete usare.

Niente di eclatante, solo una veloce segnalazione per dirvi che da oggi è stata riorganizzata la barra che consente di scegliere l’arco temporale, il tipo di visualizzazione (giornaliera, settimanale o mensile) e il parametro visualizzato nel grafico (visite, pagine viste, ecc).
Una riorganizzazione funzionale ed estetica, che comprime tutta quella parte di schermo a beneficio dei dati, che adesso risaltano di più.

Clicca sull’immagine per vederla a risoluzione piena.

La nuova barra superiore di Google Analytics

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.

Come quasi sicuramente saprete, ieri Google ha rilasciato, un po’ a sorpresa, un nuovo browser di nome Chrome: bello, pulito, essenziale e molto molto veloce. Pensato principalmente per essere usato in combinazione servizi Google, e più in generale alle cosiddette Rich Internet Application, è in fase Beta per Windows XP e Vista.

Come sarà visualizzato nella sezione Visitatori | Browser? al momento semplicemente non è visualizzato (si veda l’annuncio ufficiale sul blog di Analytics

Q. Will I see Google Chrome listed as a browser in my Google Analytics reports?
A. Yes, very soon. We’ll let you know immediately once the change happens.

tra l’altro il post è stato modificato dopo la sua pubblicazione: ieri diceva che sarebbe stato tracciato come Firefox fino alla modifica di Analytics. E non sono il solo che si è chiesto “perché Firefox, se è basato sul motore di Safari, cioè WebKit?), non appena faranno la modifica lo troveremo con il suo User Agent corretto.
[edit 4/9/2008: in realtà io stasera lo vedo già nel report browser di Analytics. Hanno fatto la modifica senza annunciarla.]
[edit 5/9/2008: ora c’è il post, e le modifiche saranno retroattive]

L’impatto che ritengo più evidente, una volta che il browser si sarà diffuso, è sul traffico da motore, che prevedo in discesa a vantaggio del traffico diretto. Il motivo è la scomparsa del box di ricerca, tipico di Firefox, Opera e gli altri browser moderni, e della Google Toolbar (a meno che non la rilascino successivamente, che sarebbe strano visto che hanno avuto tutto il tempo di gestazione del nuovo browser per prapararla). Scrivendo le query direttamente nella barra degli URL si può si cercare su Google, e quindi visitare una SERP, ma ci vengono anche proposti risultati pronti da cliccare, che provengono sia dalla cronologia, sia soprattutto direttamente dal motore, e ci permettono di cliccare direttamente il sito di destinazione senza passare dalla SERP. Un esempio nella figura qui sotto, dove non ho mai visitato la pagina di IMDB con Chrome

Il secondo impatto forte sarà sulle percentuali di visitatori nuovi e di ritorno, giacché Chrome (come il futuro Internet Explorer 8, pare) ha una modalità di protezione della privacy che consente di non salvare cookie, cronologia, password, ecc. sul proprio computer. Il diffondersi di quest’ultima opzione (e la relativa facilità di attivazione, dato lo scarno pannello delle opzioni del browser – “scarno” per scelta di usabilità) avrà impatto sui report che fanno uso del cookie per ricavare dati sul visitatore: oltre al già citato nuovi/di ritorno mi vengono in mente anche unici assoluti, fedeltà e recency.

Non sono il solo ad interessarsi del futuro di Google Analytics, evidentemente. Un po’ perché lo strumento che usiamo bene o male lo conosciamo già e quindi è un buon esercizio immaginare cosa potrà essere domani, un po’ perché se le previsioni saranno azzeccate potremo fare un bel post “ve l’avevo detto” 🙂
Comunque sia, i ragazzi di EpikOne hanno ragionato su 3 ulteriori indizi:

1. il pulsante per l’accesso diretto non è un cambiamento minore o estetico, ma il preludio di una maggiore integrazione, stanti anche le modifiche al layout di Website Optimizer. Tra le altre cose leggo per la prima volta il nome “Google Business Platform” e penso che d’ora in poi mi riferirò anche io così al prodotto definitivo come lo immagino.
2. all’accesso abbiamo sott’occhio il dominio associato ad ogni profilo, cosa che ci permetterà di nominare meglio i profili, e dovrebbe far capire meglio alle persone che i profili sono solo segmentazioni di traffico. Il profilo che raggruppa tutto – cioè l’implementazione di default di molta gente – è solo un caso particolare molto usato.
3. Google ha cambiato la label del campo “segmento”, che ora si chiama “dimensione”. E’ un cambiamento che potrebbe apparire marginale, ma che invece ha un ruolo determinante per chi fa web analytics di mestiere. Le dimensioni sono un concetto fondamentale in web analytics, e questo potrebbe farci presupporre che in futuro Google Analytics permetterà di definire dimensioni personalizzate.

Colgo l’occasione anche per comunicarvi che parlerò proprio (anche) di dimensioni, metriche e misurazioni durante il Corso di Web Analytics che YoYo – Formazione rotolante organizza a Verona il 16 e 17 dicembre 2008

Hanno destato parecchio scalpore le immagini postate da Digital Inspiration, e soprattutto quelle di searchengineland (a loro volta prelevate da un post poi rimosso da thegooglecache) a proposito di una presunta feature che Google vorrebbe introdurre in Analytics, ovvero i report sull’attività Adsense dei siti monitorati; tramite questi screenshot possiamo capire che le informazioni riportate da questi ipotetici report includerebbero il numero di click per pagina, la revenue generata per pagina, il CTR e CPM di ogni pagina e quali referrer generano più click sui nostri adsense.

Sebbene gli screenshot possano essere frutto di abile mano con photoshop, è assolutamente indubbio che questi report verranno integrati in GA, prima o poi. Questo perché, come ho già avuto modo di dire, a mio avviso Google Analytics è destinato a diventare il centro della misurazione della nostra attività online a tutto tondo. Un Analytics universale che integrerà anche alcuni servizi che comunque rimarranno accessibili anche dall’interfaccia esterna, e secondo me comprenderà:

• Google Analytics come lo conosciamo adesso
• i report di AdWords
• i report di Adsense, come mostrati negli screenshot o in forma simile
• i dati sui video di Youtube insights, o di nostri video tracciati tramite gli Eventi
• i dati delle ricerche di Google Search Insight
• i dati di Google Trends e Trends for Webmasters
• i dati sui feed RSS di feedburner e Google reader
• una parte dei dati che ora ci vengono mostrati su Google Webmaster tools

Questo naturalmente senza sapere quali altri servizi stanno preparando a Mountain View? Voi siete d’accordo con questa visione? secondo voi cosa altro potrebbe essere integrato in un “Google Analytics Totale”?

Inserire transazioni negative in un sistema di web analytics, principalmente quando si parla di e-commerce, ha il vantaggio di tenere sempre allineata la situazione dei ricavi reali con quelli presentati dal sistema. Vediamo come si inserisce una transazione negativa in Google Analytics: innanzitutto è necessario creare una pagina html qualsiasi ed editarla, incollando lo script di Analytics e le funzioni che si vogliono annullare, _addTrans(), _addItem() (o entrambe) e sicuramente _trackTrans().

E’ poi necessario assicurarsi di inserire lo stesso id_ordine della transazione che si vuole annullare. Infine il campo “totale” conterrà un numero negativo, il campo “quantità” un numero sempre negativo ma un “prezzo” positivo (in modo che la moltiplicazione dei due generi un numero negativo), i campi “tasse” e “spedizione” devono azzerare gli stessi campi della transazione con totali negativi.
A questo punto salvando la pagina e visualizzandola su un browser mentre si è connessi ad internet verrà eseguita _trackTrans() e i dati saranno inviati ai server di Google, che provvederà ad annullare la transazione nei conteggi e nei report.
E’ importante notare due cose: la prima è che bisogna assicurarsi di eseguire la pagina una e una sola volta, altrimenti si rischia di inserire transazioni negative pure (+100, -100, -100 fa -200), la seconda è che le singole transazioni restano visibili anche dopo l’annullo. Per cui se il primo del mese si registra una transazione per 3 oggetti e 300 euro, e il 15 del mese una transazione negativa per 1 oggetto e 100 euro, il totale considerando un periodo uguale o superiore al 1-15 del mese sarà 2 oggetti e 200 euro, guardando invece solo l’1 o un suo intorno sempre 3 e 300 e guardando solo il 15 o un suo intorno sarà -1 e -100 (nel caso semplificato in cui non ci siano altre transazioni nel mese).

Alcuni prodotti di e-commerce integrano la possibilità di tracciare le transazioni con Analytics, facilitando la gestione, e alcuni di questi permettono nativamente la gestione di ordini negativi, quindi evitano di dover editare a mano file HTML.

Veniamo alla mia opinione: Brian Clifton nel suo libro sconsiglia l’uso delle transazioni negative, perché falsano la metrica del ritorno dell’investimento. Se investi in advertising una somma X e poi vendi per 10volte X il tuo ROI è quello, e inserendo i resi si modificherebbe falsando le tue decisioni sui prossimi investimenti.

Eppure bisogna anche considerare che indipendentemente da quanto investi, se torna indietro il 100% della merce è giusto che il tuo ROI sia zero: primo perché così sarai costretto a interrogarti sulla qualità dei tuoi prodotti, secondo perché forse non è il caso di puntare su una categoria di prodotti che non soddisfano il pubblico. Quando si tratterà di allocare il prossimo budget di web marketing, si potranno fare scelte più oculate.

Alla fine l’inserimento o meno delle transazioni negative è un’opportunità da considerare attentamente: se si stanno valutando le performance del sito e i ritorni degli investimenti pubblicitari, cioè se si analizza il sito in modo slegato dal mondo fisico, può avere ragione Clifton. Se si fa una valutazione più globale, che abbracci tutta la filiera – dall’acquisizione di un nuovo cliente alla sua soddisfazione finale col prodotto in mano – può sicuramente avere senso inserire le transazioni negative.

[photo credit: jaqian on flickr]