Google Analytics in 30 secondi

[questo post tecnico è stato scritto da Paolo Ciarrocchi; dopo avermi chiesto una mano per risolvere un problema, ha iniziato a voler capire più a fondo il principio di funzionamento di Google Analytics. Ne è scaturito questo post, perché comunque è un argomento che non avevo ancora affrontato 🙂 ]

Installazione del codice di monitoraggio.

Utilizzare Google Analytics per tracciare gli accessi ad un sito e’ molto semplice, e’ sufficiente inserire il codice di monitoraggio in tutte le pagine del sito che vogliamo tracciare.
Esempio di codice di monitoraggio:

<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">
try {
var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._trackPageview();
} catch(err) {}</script>

xxxxxxx indica l’account number e y indica il property number. Questa coppia identifica in modo univoco il profilo utilizzato per collezionare e analizzare le statistiche.
E’ consigliabile inserire il codice di monitoraggio appena prima del tag di chiusura del body della pagina:

</body>

Ora che avete inserito il codice non resta che aspettare fino a 24 ore per iniziare a collezionare ed analizzare i primi dati.

Ma come fa Google Analytics a monitorare il vostro sito?

Ogni volta che una pagina monitorata viene caricata il codice javascript che avete inserito effettua una richiesta GET verso la URL http://www.google-analytics.com/__utm.gif inserendo al suo interno una serie di parametri.

Ecco un esempio:

http://www.google-analytics.com/__utm.gif?utmwv=4.3.1&utmn=2028990980&utmhn=xxxxxx&utmcs=UTF-8&utmsr=1280x1024&utmsc=32-bit&utmul=it&utmje=1&utmfl=10.0%20r32&utmdt=xxxxx&utmhid=941747535&utmr=-&utmp=/xxxxx&utmac=xxxxxx&utmcc=__utma%3D1.3953800709497065000.1248852507.1251792483.1251811994.60%3B%2B__utmz%3D1.1248852507.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B

Una chiara spiegazione di tutti i parametri che possono essere inviati verso google-analytics e’ presente al seguente URL:

code.google.com/intl/it-IT/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html

Troubleshooting del codice di monitoraggio.

Avete di dubbi sul corretto funzionamento del vostro codice di monitoraggio?
Volete capire meglio quali informazioni vengono inviate ai server di Google?

Vi consiglio di utilizzare i seguenti plugin per Firefox per tracciare le chiamate verso http://www.google-analytics.com/__utm.gif

• Live HTTP Headers
• Firebug

Live HTTP Headers

Il plug-in e’ disponibile al seguente URL:
https://addons.mozilla.org/en-US/firefox/addon/3829

Questo add-on vi permetterà di visualizzare tutti gli header HTTP inviati e ricevuti durante la navigazione di un sito web.
Terminata l’installazione del plugin andate in strumenti e selezionate Live HTTP Headers, attendete che il plugin si avvii e selezionate il tab Generator. Selezionate quindi le opzioni indicate nel seguente screenshot:

Firebug

Il plug-in e’ disponibile al seguente URL:
http://getfirebug.com/

Questo plugin vi permetterà di fare editing, debugging e monitoring delle componenti HTML, Javascript e CSS delle pagine caricate dal vostro browser.
Per monitorare le interazioni con Google Analytics andremo quindi ad utilizzare un piccolo sottoinsieme delle sue funzionalità.

Terminata l’installazione del plugin dovrete attivarlo premendo l’icona

Attivate ora il pannello Net e selezionate la tipologia Immagini:

Potete ora provare questi due ottimi strumenti per fare troubleshooting del codice di monitoraggio di Google Analytics. Utilizzateli per intercettare tutte le chiamate verso la URL http://www.google-analytics.com/__utm.gif e analizzate, con molta attenzione, i parametri che vengono passati all’interno della GET.

Non vedo GET verso http://www.google-analytics.com/__utm.gif !!

Probabilmente non state utilizzando correttamente gli strumenti, verificate le configurazioni e ricordatevi che:

• Ogni volta che caricate una pagina contenente lo snippet di codice di Google Analytics viene inviata una GET verso __utm.gif. Quando fate troubleshooting potete fare un semplice refresh della pagina per cercare nuovamente di intercettare la GET.
• Ogni volta che cliccate su di un link marcato come “virtual page view” viene inviata una GET verso __utm.gif. Questo scenario e’ particolarmente interessante dal punto di vista del troubleshooting in quanto richiede una conoscenza della configurazione di Google Analytics superiore al semplice “copia e incolla” del suo codice di tracking
• Potreste essere di fronte ad un BUG di Google Analytics (o delle relative API usate da altri prodotti Google), questa possibilita’ e’ indubbiamente remota ma non e’ da escludere a priori (Io stesso ho iniziato a fare troubleshooting del codice di monitoraggio di Google Analytics in quanto mi sono trovato di fronte ad un BUG di un prodotto di Google).

Cosa cercare all’interno della GET?

Ottima domanda!
Ci sono indubbiamente alcune variabile che devono essere sempre analizzate con attenzione:

• utmac – Indica il vostro account di GA. Controllate che sia valorizzato correttamente.
• utmdt – Indica il titolo della pagina che include il tracking code di GA
• utmp – Indica la page request della pagina in questione
• utmr – Indica il referral

Ci sono poi variabili che forniscono informazioni relativamente sia al browser che al “computer” che state utilizzando:

• utmcs – Indica il language encoding del browser
• utmje – Indica se Java e’ abilitato nel browser (in quel caso la variabile e’ valorizzata a 1)
• utmul – Indica la “lingua” del browser
• utmfl – Indica la versione di Flash
• utmhn – Indica il nome dell’host
• utmsc – Indica la profondidita’ di colore del vostro monitor
• utmsr – Indica la risoluzione del vostro monitor

Ci sono poi variabili strettamente legate alle campagne e all’e-commerce, come gia’ indicato in precedenza vi invito a leggere la guida al troubleshooting di Google (in inglese) per maggiori informazioni:

code.google.com/intl/it-IT/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html

[Molti dei problemi che risolvo per me, amici o clienti, li risolvo proprio guardando gli header HTTP verso i server di Google Analytics. In quell’unica stringa di testo ci sono tutte, TUTTE, le informazioni che il vostro browser invia ad Analytics. Se c’è un problema lì non c’è filtro che tenga: GA registrerà un dato erroneo, o peggio non registrerà nulla. Se visitando la pagina non vedete nemmeno partire la richiesta per la gif, siete già a metà dell’opera e potete concentrarvi solo sul vostro codice, lasciando del tutto perdere I pannelli di GA 😀 ]

Una delle più accese discussioni nel forum ufficiale e nella twittersfera ultimamente è quella relativa ad un presunto problema di sicurezza del codice di Google Analytics, per cui i visitatori vengono infettati. Un ottimo riassunto della questione la fa Stéphane Hamel sul suo blog.

Il problema non è relativo al codice di GA, ma prende di mira il codice di GA. In sostanza attraverso un accesso non autorizzato allo spazio sul server che ospita il sito, viene introdotta una regular expression javascript nel codice del sito in grado di cambiare la chiamata a http://www.google-analytics.com/ga.js in ttp://91.212.65.148/ga.js. Questo file poi esegue un’altro script php che sfrutta una vulnerabilità di Adobe Reader per infiltrarsi nei PC dei visitatori. Come già detto, questo non è un problema di Google Analytics, ma è un problema che prende di mira Google Analytics per via del fatto che è molto usato sui siti (ricordate? più del 50% dei diecimila siti più popolari secondo Alexa) di tutto il mondo.

Il modo migliore per capire se si ha a che fare con il problema è dare un’occhiata al codice sorgente di una propria pagina: se il codice di GA è sempre il solito, come lo conosciamo, non c’è problema; Se al contrario sono presenti caratteri strani ( @ # $ eccetera) allora è il caso di preoccuparsi. Nel qual caso è bene pulire il proprio PC con antivirus, antitrojan e antispyware, cambiare le password FTP del sito (e magari usare sFTP (secure File Transfer Protocol) invece del normale FTP, e reincollare il codice corretto di GA, che trovate ovviamente in modifica del profilo -> verifica stato

Quello che vedete nell’immagine qui a fianco è un pezzo del codice sorgente del javascript di Google Analytics, per capirsi quello che è visibile all’indirizzo http://www.google-analytics.com/ga.js. Si tratta del file contenente tutte le funzioni di base che permettono al codice di catturare ed inviare i dati che poi leggiamo nei nostri report.

A tutti gli effetti è un normale file javascript, ma per contenerne le dimensioni gli ingegneri di Google hanno fatto due cose: hanno eliminato gli spazi superflui e gli “a capo” e hanno chiamato tutte le variabili e le funzioni con nomi di lettere, due cose che gli esseri umani non fanno mai quando scrivono codice, per leggibilità e manutenzione, ma che non dà nessun fastidio ai computer che le istruzioni le eseguono.

Se per caso avete necessità di leggere il sorgente, perché volete capire cosa fa una certa funzione, perché volete estenderla o per curiosità, è indubbiamente più utile far tornare almeno gli spazi e i ritorni di riga, visto che non è possibile riassegnare alle funzioni nomi parlanti in modo automatico. Per avere un file leggibile basta andare all’url del sorgente, selezionarlo tutto e copiarlo, e poi incollarlo nello strumento Javascript Beautifier, che ce ne renderà una versione decisamente più digeribile per i nostri occhi. Le prime righe ad esempio diventano:

var _gat = new Object({
    c: "length",
    lb: "4.3.1",

il che tra l’altro mi fa notare al volo che la versione corrente dello script è passata da 4.3 a 4.3.1. Probabilmente in concomitanza con l’introduzione di Bing tra i motori di ricerca riconosciuti.

[tnx to AnalyticsPros]

La domanda che mi fa Francesca in un commento è semplice:

Ciao!
La mia è più che altro una curiosità:
ma se inserisco due volte lo stesso identico codice in una pagina cosa succede? Raddoppiano tutti i dati??

La risposta avrebbe dovuto essere abbastanza semplice, ma siccome avevo tempo ho messo su un piccolo esperimento per avere più dati. All’inizio, lo ammetto, ero sconcertato; poi mi sono accorto di un mio errore e la cosa è tornata ad avere un senso.
La situazione, piuttosto atipica invero, è quella in cui lo stesso identico codice di monitoraggio è presente due o più volte sulla stessa pagina. Potrebbe essere perché due persone differenti lo hanno inserito – magari uno in header e uno prima di /body – o perché si sta usando un plugin automatico ma il codice era già stato messo a mano nel template. Quali che siano le ragioni, Google Analytics non effettua nessun tipo di controllo su questa casistica, quindi i javascript vengono eseguiti entrambi e i dati vengono inviati due volte.

Questo però non si traduce in un raddoppio totale di tutti i dati. O meglio, raddoppiano solo i dati che ha senso siano doppi, quelli che tecnicamente potrebbero effettivamente derivare da una situazione di quel tipo. Ad esempio le visite non raddoppiano, perché una visita ha una durata predefinita di trenta minuti. Il fatto che in in una frazione di secondo vengano viste due pagine non intacca il concetto di sessione, per cui le due esecuzioni del GATC sono attribuite correttamente alla visita giusta. Raddoppiano invece le pagine viste, poiché vi sono due chiamate alla funzione trackpageview(). Queste chiamate, tra l’altro, avvengono a una frazione di secondo di distanza l’una dall’altra, per cui non falsano il tempo medio trascorso sulla pagina. Falsano invece, e di molto, il bounce rate. Poiché un bounce è una visita di una sola pagina vista, se sono presenti due codici di monitoraggio sulla pagina, ogni visita sarà composta sempre di almeno due pagine viste, per cui il vostro sito avrà un bounce rate dello 0%.

Il modo più semplice per accorgervi di un errore simile è appunto quello di guardare il bounce rate. se è zero o siete bravissimi o potete avere un errore di questo tipo. Un altro modo, meno immediato, è quello di guardare la pagine viste: con un doppio codice esse non possono mai essere in numero dispari 🙂

Royal Pingdom, il blog ufficiale del servizio di monitoraggio dell’uptime dei siti pingdom, ha pubblicato un interessante post dopo aver condotto un test sui diecimila siti più popolari secondo la classifica di Alexa, trovando che almeno la metà di essi usa Google Analytics, e che il 40% di questi usa ancora il vecchio codice.

Si parla di grossi nomi come foxnews.com, wired.com, istockphoto.com, e ironicamente anche di blogger.com e doubleclick.com, che sono di proprietà di Google stessa. Dei 9758 siti che sono stati in grado di rispondere alle chiamate automatiche di pingdom.com, 4872 hanno lo script di GA sulla home page, e di questi 1992 ancora chiamano urchin.js, che è la vecchia versione dello script.

Questi siti, tra le altre cose, non possono avvantaggiarsi di una serie di funzionalità che sono specifiche di ga.js, la nuova incarnazione del javascript introdotta nel dicembre del 2007:

• logica ad oggetti
• interazioni più facili con elementi AJAX nelle pagine
• monitoraggio degli eventi
• un codice più leggero e veloce da eseguire
• auto riconoscimento del protocollo usato dalle pagine, se http o https

Stando alle informazioni disponibili, e a una frase di un Google Analytics Authorized Consultant nel post citato, il supporto al vecchio urchin.js cesserà in qualche momento durante l’estate, intorno ai famosi diciotto mesi proclamati quando venne introdotta la nuova versione.

Se nel vostro sito state ancora usando urchin.js, è bene sapere che probabilmente avete ancora solo tre o quattro mesi di tempo per migrare. Se fatta con le dovute cautele la migrazione è indolore, e vi permetterà di dimenticarvi della “dead line” di Google; inoltre avrete accesso alle nuove funzionalità. Anzi, la transizione potrebbe essere un buon momento per applicare tutte quelle piccole migliorie che avete letto in questo blog e che avete sempre rimandato per mancanza di tempo. Se il sito è generato dinamicamente da un sistema di gestione dei contenuti, ci sono buone probabilità che il vostro programmatore di fiducia sia in grado di effettuare la transizione in poco tempo, e spesso modificando un solo file. Se avete centinaia di pagine statiche in HTML, è adesso il momento buono per iniziare, giacché è possibile far convivere urchin.js e ga.js sullo stesso sito MA NON sulla stessa pagina.

In ogni caso avrete a che fare con la pagina ufficiale della migrazione, che vi linko per comodità

[edit 11 aprile: In questo post sul blog ufficiale Brett Crosby smentisce che urchin.js sarà dismesso durante l’estate, contraddicendo sia quanto venne detto all’introduzione del codice a oggetti sia quanto detto dal Google Analytics Authorized Consultant. Io continuo a rimanere dell’idea che compatibilmente con tempi e costi di ognuno sia bene migrare tutto a ga.js, e mi comporto di conseguenza con i clienti]

Durante i giorni scorsi, poco prima del Festival di Sanremo, all’indirizzo www.rai.it è andato online il nuovo portale internet della televisione pubblica italiana, che fa uso della tecnologia Microsoft Silverlight per lo streaming dei contenuti. Per chi non lo sapesse, Silverlight è il “concorrente” di Adobe Flash per quel che concerne le cosiddette “Rich Internet Application”, ovvero quelle applicazioni – soprattutto web – sofisticate che difficilmente riescono ad essere realizzate con i canonici HTML, CSS e Javascript.

Nei sistemi Windows, se non erro, Silverlight dovrebbe essere installato insieme agli aggiornamenti di Miscrosoft Update, ma è sempre comunque possibile installarlo a mano la prima volta che si tenta di accedere ad un contenuto realizzato con quella tecnologia. Google Analytics contiene un intero report dedicato a Flash player che riepiloga quali versioni di Flash sono installate nei browser dei visitatori e in che percentuale essi hanno visitato il sito, ma non ha nessun tipo di report per Silverlight. Se avete la necessità di conoscere anche le percentuali delle due versioni esistenti di Silverlight, Hello Szabi! ha migliorato un precedente script di Mark Monster per farlo.

Dopo aver scaricato e uploadato sul sito lo script ufficiale per il test della versione Silverlight (fornito da Miscrosoft stessa) sarà sufficiente aggiungere queste righe di codice

<script type="text/javascript" src="silverlight.js"></script>
<script type="text/javascript">
  var hasSilverlight = Boolean(window.Silverlight); 
  var hasSilverlight1 = hasSilverlight && Silverlight.isInstalled('1.0'); 
  var hasSilverlight2 = hasSilverlight && Silverlight.isInstalled('2.0'); 
  if (hasSilverlight1) { pageTracker._trackEvent("silverlight", "v1"); }
  if (hasSilverlight2) { pageTracker._trackEvent("silverlight", "v2"); }
  if (!hasSilverlight1 && !hasSilverlight2) { pageTracker._trackEvent("silverlight", "none"); }
</script>

subito DOPO la chiusura del tag SCRIPT di Google Analytics. Nella sezione eventi del vostro profilo troverete un evento di nome “silverlight” con tre azioni: none, v1 e v2. “none” è naturalmente il numero di visitatori che non hanno il plugin installato, mentre v1 e v2 sono rispettivamente il numero di coloro che hanno la prima e la seconda (l’ultima disponibile al momento in cui scrivo) versione

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:

1. i dati sono fermi a tre ore prima il momento in cui li si visualizza
2. i dati si aggiornano ogni ora
3. 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:

1. Un browser richiede una pagina correttamente configurata con il GATC
2. il GATC crea e inizializza un oggetto di tracciamento associato con il numero di account inserito nel GATC stesso
3. Vengono eseguiti i metodi di tracciatura personalizzati
4. 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)
5. 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
6. 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…