Google Analytics in 30 secondi

Come vi ho detto qualche tempo fa, nei nuovi codici di monitoraggio che copiaincollate da Google Analytics è sparita la riga relativa a initData(), funzione soppressa dagli ingegneri di Google e chiamata implicitamente ed automaticamente dallo script. Se non avete provveduto a modificare i vostri codici di tracciamento (GATC) avete, appunto, uno zombie in casa: una funzione morta che cammina ancora tra le vostre pagine

Non fa male, di per sé, tranne per il caso citato oggi da Lunametrics, ovvero se avete alcune pagine con initData e alcune pagine senza; ad esempio perché avete aggiunto delle pagine nuove e avete copiato il codice dal pannello di Analytics invece che da una vostra pagina vecchia. In questo caso i cookie di GA possono essere scritti in forme leggermente differenti, e questo è fonte di errori e perdita del tracciamento del percorso del visitatore, quindi è male.
E’ un problema che nemmeno i controlli automatici come SitescanGA possono individuare, per cui è vostra cura assicurarvi di avere un GATC coerente su tutte le pagine.

Ricapitolando quindi le due regole fondamentali:

• non possono coesistere chiamate a urchin.js e ga.js nella stessa pagina; possono coesistere nello stesso sito, ma è sconsigliato. Se possibile usate solo ga.js
• se avete codici che contengono la chiamata a initData() dovrete scegliere se rimuoverla da tutte le pagine in cui è presente o aggiungerla in tutte le pagine in cui è assente

Quando le cose da tenere d’occhio iniziano ad essere molte e variegate bisogna fare attenzione: Google Analytics fornisce gli strumenti, ma bisogna stare attenti a possibili effetti collaterali non documentati. Prendiamo ad esempio l’ultimo post di Lunametrics, che riporta una situazione con un codice di monitoraggio per più domini di questo tipo:

var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._setVar(’buyer’);
pageTracker._setAllowAnchor(true);
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();

questo codice inizializza l’oggetto di tracciamento, poi scrive nel cookie __utmz il valore buyer (ovvero assegna il visitatore al segmento compratori), poi permette l’uso del cancelletto nelle campagne, poi permette di trasportare il cookie da un dominio a un altro, disabilita il check dell’integrità dei cookie basato sul dominio (quando si raccolgono dati da più sottodomini in un unico account), e infine raccoglie i dati e li invia al server di Google.

Quale è il problema di questo codice? il problema è che _setAllowHash di fatto cambia il formato di scrittura del cookie, e ci sono due funzioni che scrivono cookie: _setVar che si trova prima di setAllowHash e trackPageview che invece si trova dopo.
In questo modo GA va in confusione e perde informazioni sulla sessione e sul referrer, assegnando a traffico diretto la seconda – falsa – visita.

La soluzione è quella di chiamare _setVar() sempre dopo _setAllowHash() (o _setDomainName(‘none’); se lo usate); bisogna sempre tenere presente che il javascript di Google Analytics ha a che fare con i cookie, e che alla fine sono loro che “comandano” quel che poi vediamo nei nostri report.

Ho letto questa notizia su tre diversi blog, ma ho aspettato a segnalarla finché non è apparsa su una fonte che ritengo autorevole: Google ha modificato il modo in cui conteggia i bounce rate in presenza della funzione _setVar(). [edit: ecco il post sul blog ufficiale | e in italiano]

Fino ad oggi se un visitatore guardava una sola pagina, non veniva conteggiato come bounce se nella stessa pagina chiamavate la funzione _setVar(), che serve ad attribuire il visitatore ad un segmento personalizzato tramite scrittura del cookie aggiuntivo __utmz. Infatti per ovviare a questo problema Lunametrics aveva proposto un workaround che vi segnalai a tempo debito.

Da oggi questo fatto non è più vero, e una visita di una sola pagina vista sarà considerata un bounce a prescindere dalla presenza della funzione. Tra le altre cose questa modifica si rifletterà anche sul tempo medio sul sito e sulla pagina, poiché in presenza di due timestamp GA è in grado di calcolare un tempo, cosa che invece ovviamente non può essere vera per un utente che rimbalza. In precedenza invece Analytics assegnava tempi brevissimi (zero, uno o due secondi, a seconda della velocità di caricamento della pagina e del tempo trascorso tra la chiamata a _trackPageview() e _setVar() ) alla pagina.

Da quel che ho capito, il comportamento non cambia in presenza di un evento, come scrissi in questo post

Image credit: Greencolander on Flickr

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

Uno dei grafici più noti e familiari che si vedono quando si accede alla dashboard dei profili è quello delle fonti di traffico, a meno che non sia stato eliminato per scelta. Rappresenta, come noto, la ripartizione percentuale delle provenienze dei visitatori, e di solito ha tre colori, rosso, verde e blu che rappresentano le tre fonti “classiche” di traffico: le visite dirette, i siti di riferimento e le visite da motore di ricerca.

(due diversi grafici delle fonti di traffico)

In alcuni casi però il grafico si presenta con quattro colori, aggiunge il giallo, e la quarta fonte è “altro”; questo significa che abbiamo iniziato a usare e gestire le campagne. La gestione delle campagne è un passaggio praticamente obbligato nella vita del monitoraggio di un sito web tramite Google Analytics, poiché ci consente di sapere con esattezza quale fonte invia quali visitatori, quale banner porta più conversioni, quale servizio porta visite più qualificate. A differenza delle fonti “tradizionali” le campagne sono impostate da noi e sono molto più granulari: possiamo avere una campagna su una sola pagina di un sito, su tutte le pagine di un sito oppure tre campagne diverse sulla stessa pagina. si può usare la stessa campagna su una newsletter oppure usare una campagna per ogni tipologia di destinatario, e ancora usare campagne differenti per due link differenti nella stessa newsletter. Poiché la gestione è nostra, non c’è limite di utilizzo, salvo poi la difficoltà di lettura dei report.

Come si crea una campagna? A differenza degli obiettivi non c’è bisogno di fare nulla nell’interfaccia di GA, una campagna parte nel momento in cui la prima visita arriva tramite un link opportunamente preparato (“taggato”) con alcuni parametri. Questi parametri possono essere fino a cinque, e precisamente:

• utm_campaign: è il nome della campagna. Va pensato come a un “contenitore” delle varie attività di promozione tramite campagne che ci apprestiamo a fare. Ad esempio per lanciare un prodotto potremmo fare campagne su newsletter, link da siti partner e banner, ma il nome della campagna sarà comune e sempre uguale, ad esempio “lancio XR100″
• utm_medium: è il mezzo della campagna, il veicolo attraverso il quale la campagna giunge ai potenziali clienti. Va pensato rispondendo alla domanda “tramite quale mezzo sto lanciando il messaggio?” (ad esempio: email, banner, affiliazione, ecc.)
• utm_source: è la fonte delle visite, la provenienza dei visitatori per quella campagna e risponde alla domanda “chi?” (esempio: goanalytics.info, google, sito honda italia)
• utm_content: è il contenuto dell’annuncio, e può essere usato per dare maggior dettaglio o per scopi di test, ad esempio facendo un test A/B per capire quale annuncio genera i risultati migliori.
• utm_term: è il termine comprato, nel caso si stia taggando una campagna di keyword advertising.

Di questi cinque parametri, solo i primi tre sono obbligatori. Tecnicamente non è del tutto vero, ma per comodità si assume che sia così: usandoli tutti e tre si usufruirà in toto dei benefici della gestione delle campagne. Per avviare una campagna si dovrà quindi provvedere a modificare il link che punta al nostro sito aggiungendo questi parametri. Ipotizziamo che stiamo lanciando il prodotto XR100 e che abbiamo approntato una pagina apposita sul nostro sito, www.miosito.it/xr100.php. la prima campagna viene effettuata sulla newsletter in questo modo:
http://www.miosito.it/xr100.php?utm_source=newsletter&utm_medium=email&utm_campaign=lancio-xr100

la seconda campagna è un banner sul sito di honda italia
http://www.miosito.it/xr100.php?utm_source=honda-italia&utm_medium=banner&utm_campaign=lancio-xr100

il terzo caso riguarda due link presenti su un sito affiliato, che decidiamo di studiare particolarmente perché in passato campagne simili hanno dato risultati contrastanti. Saranno inseriti due link, uno nella sidebar di tutte le pagine e uno nel footer di tutte la pagine.
Il link nella sidebar sarà
http://www.miosito.it/xr100.php?utm_source=sitoaffiliato.com&utm_medium=link&utm_content=sidebar&utm_campaign=lancio-xr100

mentre quello nel footer
http://www.miosito.it/xr100.php?utm_source=sitoaffiliato.com&utm_medium=link&utm_content=footer&utm_campaign=lancio-xr100

In questo modo, andando a scavare nel report sorgenti di traffico -> campagne sarà possibile capire con esattezza quale di questi mezzi ha generato più conversioni e addirittura quale sia la posizione più redditizia per inserire un link su sitoaffiliato.com nella prossima campagna.
Per facilitare la creazione di url taggati correttamente Google mette a disposizione uno strumento di costruzione degli URL raggiungibile a questa pagina del supporto.

E’ necessario ricordare ancora una cosa sulle campagne: quando un visitatore clicca uno dei link taggati in questo modo il cookie utmz viene opportunamente modificato per registrare questa informazione; come già visto in precedenza, però, per due click da campagne successive il cookie viene sempre modificato, e la conversione viene attribuita all’ultima campagna cliccata. Per ovviare a questo comportamento vi ho già parlato del parametro aggiuntivo utm_nooverride=1.

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

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.

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.

La funzione _setCookiePath(stringa) è un po’ particolare e forse non è nemmeno utile alla maggior parte di noi, però ci permette di risparmiare tempo nel setup del profilo e consente una interpretazione migliore dei dati. Sebbene il nome tragga in inganno, serve a definire quale sia la directory predefinita per il cookie del vostro sito, e non a definire in quale directory del PC dell’utente salvare i cookie di GA (come molti erroneamente pensano). Poniamo un caso pratico e semplificato:
Continua a leggere “funzioni: _setCookiePath() e _getCookiePath()”