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.
Una delle maggiori critiche che mi sento opporre quando parlo di Google Analytics suona circa come “si, ma non è in tempo reale”. Questo è indubbiamente vero, ma molto meno di quanto si sospetti.
Innanzitutto sarebbe utile fare un esame della propria attività e chiedersi se è realmente necessario avere i dati in tempo reale: molto spesso infatti il desiderio delle persone è di avere i dati fino all’ultimo minuto quelle due o tre volte alla settimana in cui sbirciano le statistiche. Il dato real-time invece è pensato (e dovrebbe essere rivolto) a chi fa web analytics di mestiere e sta tutto il giorno con i dati aggiornati davanti, dovendo decidere in tempo reale modifiche alla strategia o ai budget o dovendo tenere sotto controllo le vendite minuto per minuto.
Questo come premessa generale, non è mia intenzione dire a nessuno come deve fare analisi, ma vorrei solo porre l’accento sul fatto che larga parte di chi mi pone questa obiezione non lo fa perché ne ha realmente bisogno, ma per sottolineare una mancanza di GA.
Mancanza che, come dicevo prima, è molto minore di come appare. Quando accediamo ai rapporti, GA ci mostra per impostazione predefinita (e ahimé immutabile) gli ultimi 30 giorni di dati, partendo dal giorno precedente, e questo basta a molte persone per pensare che i dati siano fermi, e che i dati di oggi saranno disponibili domani. Tramite una semplice selezione nel calendario è possibile rendersi conto che le cose stanno diversamente: selezionando la data odierna infatti il sistema ci mostra i dati di oggi in modo incompleto, sottostando a queste tre regole:
- i dati sono fermi a tre ore prima il momento in cui li si visualizza
- i dati si aggiornano ogni ora
- i dati possono variare entro 24 ore
Per capire come mai questo accade è necessario fare un ulteriore passo nella comprensione del percorso che i dati fanno da quando il vostro sito viene visualizzato a quando voi guardate i report, percorso che ho iniziato a spiegare nel post “l’ordine è importante“. Quando si richiama la gif trasparente __utm.gif da http://www.google-analytics.com in realtà non si sta interrogando un solo server. www.google-analytics.com viene risolto dai dns in www-google-analytics.l.google.com, che è un round robin di server sparsi per la rete: facendo un nslookup da vari server nel mondo si ottengono indirizzi IP differenti, per minimizzare il percorso che i dati trasmessi dai client dei visitatori devono fare. E’ quindi assolutamente normale che un visitatore italiano e un visitatore cinese “sparino” i dati dello stesso codice di Analytics su due server Google differenti.
Una volta ogni ora Google li recupera dalle sue macchine in giro per il mondo e li analizza, e a causa del numero di analisi necessarie li presenta con tre ore di ritardo. Inoltre, poiché non è garantito che il recupero dei dati avvenga da tutti i server del mondo, ogni 24 ore Google Analytics effettua una rianalisi del giorno precedente per colmare eventuali lacune e garantire la solidità del dato. Per questo motivo i dati vanno considerati definitivi solo dal giorno successivo, e per questo motivo all’accesso Google presenta gli ultimi 30 giorni escludendo la data odierna.
Processo generale
In genere i dati provenienti da una pagina che contiene il codice di monitoraggio di Analytics (d’ora in poi GATC) vengono processati in questo ordine:
- Un browser richiede una pagina correttamente configurata con il GATC
- il GATC crea e inizializza un oggetto di tracciamento associato con il numero di account inserito nel GATC stesso
- Vengono eseguiti i metodi di tracciatura personalizzati
- Il codice di monitoraggio viene inizializzato e viene eseguito il metodo principale, _trackPageview()
- Viene determinato il dominio
- Vengono scritti o aggiornati i cookie
- Vengono registrate le caratteristiche del browser, le informazioni sulla pagina e i tracciamenti delle campagne (se ci sono)
- Il codice richiede una immagine sui server di Google, __utm.gif
- La gif, composta di un singolo pixel trasparente, viene inviata al browser del visitatore
- L’URL della gif contiene un insieme di parametri derivati dall’inizializzazione del codice di monitoraggio. Questa URL viene registrata nei logfiles del webserver di Google.
- Tipicamente la gif risiede sul server di Analytics, ma nel caso di Urchin stand-alone essa risiede su un server locale del cliente
- Questo insieme di parametri viene estrapolato dai logfiles e viene usato per popolare i database, che poi vengono usati per generare i report nell’interfaccia.
Il riferimento al codice di monitoraggio
Le prime cinque righe del tag script di default che incolliamo nelle pagine servono a determinare dinamicamente il protocollo HTTP usato dalla pagina e a richiamare il javascript appropriato dai server di Google. Tramite queste righe possiamo evitare di preoccuparci di dover cambiare il codice se usiamo un misto di pagine sicure e non sicure (http e https).
L’esecuzione del codice di monitoraggio
Il secondo set di tag javascript include i metodi necessari a eseguire la chiamata per la collezione dei dati. Questa parte del codice deve anche contenere i metodi personalizzati che vogliamo applicare alle pagine del sito. L’ordine di chiamata dei metodi fornito nel codice di default è importante, ed bisognerebbe sempre seguire queste linee guida quando si altera il GATC per le proprie necessità:
- La prima linea dello script di tracking dovrebbe sempre inizializzare l’oggetto di tracking
var pageTracker = _gat._getTracker("UA-123456-1");
Questa prima linea inizializza l’oggetto con l’ID del dominio che forniamo come parametro. I metodi che seguono useranno questo oggetto
- Le righe finali del codice dovrebbero chiamare i metodi _initData() e _trackPageview().
Qualsiasi metodo personalizzato che imposta o inizializza un valore dovrebbe essere inserito prima di _initData().
(traduzione e adattamento di Google Analytics Custom Tracking)
Quando si installa il tracking code di Google Analytics su un sito si spende molto tempo ad assicurarsi che il codice sia presente su ogni pagina che vogliamo tracciare, su ogni elemento e su ogni download, nel caso ci interessino in modo specifico anche questi due ultimi elementi. Quello che nella quasi totalità dei casi si tralascia è l’installazione del codice anche sulle pagine di errore 404.
Le pagine di errore 404 sono particolari pagine che il webserver mostra ai navigatori quando richiedono una risorsa che non esiste in quel sito; l’esempio tipico è quando si digita in modo errato il nome di una pagina.
Le persone più attente le conoscono e inseriscono il codice tradizionale anche su quelle, ma pochi sanno che con un piccolo tuning si può ottenere un risultato ancora maggiore: fare in modo che la pagina di errore, oltre che venire conteggiata nei report, ci dia una informazione: in particolare quale era la pagina originale richiesta. Questo per far si che noi possiamo apportare le opportune correzioni al nostro sito ed eliminare il disservizio all’utente. Per far questo bisogna modificare come segue il codice di tracciamento, nella sola pagina 404 che il webserver usa come modello (su Apache si trova in /error_docs/not_found.html e su IIS nelle proprietà del sito - messaggi di errore personalizzati - errore HTTP 404 - modifica proprietà):
<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-12345-1");
pageTracker._initData();
pageTracker._trackPageview("/404.html?page="+document.location.pathname+document.location.search);
</script>
404.html è il nome della pagina modello di errore che il webserver fornisce
document.location.pathname è il nome della pagina richiesta
document.locarion.search sono i parametri eventuali della pagina richiesta.
Ovviamente, anche se si tratta di una pagina fittizia creata da GA tramite la funzione trackpageview(), essa è segmentabile esattamente come le altre, per cui è possibile conoscere la provenienza, la parola chiave di arrivo se c’è e tutte le altre informazioni tipiche dei report…
