Mi fanno notare via email che tempo fa avevo scritto: «Se fatta con le dovute cautele la migrazione è indolore, e vi permetterà di dimenticarvi della “dead line” di Google»
In realtà non c’è mai stata nessuna “dead line” e urchin.js è ancora lì, vivo e vegeto. E’ però stato sorpassato DI FATTO da ga.js, in sordina. Google ha preferito evitare un evento traumatico per l’utente come la sostituzione del codice entro una certa data, preferendo continuare a investire sul nuovo codice e lasciando ad ogni webmaster l’onere di capire se e quando sarebbe stato il momento di abbandonare il vecchio codice. Penso che la mossa sia vincente, perché da sempre uno dei punti forti di Google Analytics è “iscriviti, copia il codice e basta”, che è uno dei tanti motivi per cui oggi è così diffuso. Troppo spesso noi che lavoriamo in questo settore ci dimentichiamo che la maggior parte delle persone non ha approfondite conoscenze di javascript e linguaggi lato server, e che non sa nemmeno che esistono una marea di funzioni che si possono aggiungere al codice di monitoraggio. Copiaincollano oppure usano un plugin/modulo per il loro CMS e vivono felici.
Queste persone piano piano si rendono/renderanno conto che le nuove funzionalità offerte da GA sono pensate espressamente per il nuovo codice di monitoraggio e migreranno volontariamente – o con l’aiuto di qualcuno – a ga.js, rendendo di fatto inutile costringere alla migrazione. Ritengo che in effetti questa sia stata una mossa azzeccata per non intaccare nemmeno di una unità l’ampia base di utilizzatori della nostra piattaforma preferita di web analytics
Andrea mi pone un quesito, ma in verità ultimamente molti mi fanno domande che sono riconducibili alla stessa soluzione. La domanda di Andrea riguarda il fatto che su un profilo vede il suo stesso sito nei referrer.
Innanzitutto chiariamo una cosa: TUTTE le pagine viste generate da un click hanno un referrer, anche quelle interne (potete verificarlo guardando i cari vecchi logifles generati dal webserver). Se digito una URL e vado sulla home di un sito faccio una visita diretta, se poi clicco la prima voce di menu, la pagina corrispondente avrà come referrer la home page, e così via per le successive. Il fatto che i referrer interni siano esclusi in modo predefinito dai sistemi di web analytics (ma non tutti, infatti nelle definizioni della Web Analytics Association il referrer interno esiste ed è vivo e vegeto – vedi il documento di definizione degli standard, pagina 18) spesso ci porta a dimenticarci di questo fatto.
Detto questo, Andrea si è accorto da solo del possibile problema: su un sottodominio c’è lo stesso codice usato per il dominio di primo livello, e secondo lui questo genera l’errore. Vorrebbe quindi sapere come filtrare le visite che hanno quel referrer, e qui sta il suo sbaglio: la soluzione corretta è quella di usare _setDomainName(“.miosito.it”); che forza la scrittura del cookie di Google Analytics in modo che mio sito.it e sottodominio.miosito.it usino lo stesso cookie. Senza quella funzione infatti GA scrive due cookie differenti per il dominio principale e il sottodominio, e ovviamente interpreta le visite che “travasano” da uno all’altro come appartenenti a due siti differenti, generando quindi un referrer.
Ci sono controindicazioni ad usare _setDomainName? no, nessuna. Per questo motivo secondo me dovrebbe essere inserita di default nei vostri codici di tracciamento, anche se non avete sottodomini. Perché se un domani li avrete non perderete la congruenza dei cookie già creati e rilasciati sui browser dei visitatori passati.
[photo credit: orphanjones' on Flickr]