Google Analytics in 30 secondi

Detto, fatto! Il nuovo codice da copiaincollare proposto da Google Analytics è adesso quello asincorno. Ecco infatti come mi si presenta la schermata relativa alle 16:00 di oggi 17 maggio (clicca per ingrandire):

La cosa vale anche per i siti vecchi, ovvero se andate su “impostazioni profilo” -> “verifica stato” vedrete che il codice proposto dall’interfaccia è il nuovo codice asincrono.
Dal 4 al 17 maggio, tredici 14 maggio, dieci giorni (tnx to Cristian) tra l’annuncio e la realizzazione: magari tutte le novità fossero così veloci

Dieci intensi minuti con Twitter surriscaldato dai refresh ci hanno finalmente svelato le attese novità.

In primo luogo è stata lanciata una galleria delle applicazioni utili a estendere le funzionalità di Google Analytics, siano esse siti esterni basati sulle APi, plugin per browser o applicazioni da installare. Tutto quel che vi può essere utile per avere più dati a disposizione è ora elencato e categorizzato nella Google Analytics Application Gallery (al momento sono elencate 32 applicazioni).

Il secondo annuncio è che il tracking code asincrono è uscito dalla fase beta, e in accordo con la politica di rendere più veloce il web presto diventerà il codice di monitoraggio predefinito (quello che per intenderci copiate e incollate quando create un profilo) per tutti.

Infine presto ci saranno nuove integrazioni con AdWords, e più report. La cosa che più piacerà ad alcuni di voi (Fradefra? Gorino? ) sarà la possibilità di vedere finalmente la query cercata insieme a quella pagata, senza più bisogno di doppi e tripli filtri. Nel video che spiega brevemente le novità si vede – e sente – più volte “actual search query” come nuova dimensione possibile, oltre al match type e altre cosette interessanti.

Inoltre nelle API di Google Analytics sono state introdotte 5 nuove dimensioni relative ad Adwords

Ci sono alcune novità in Google Analytics, ci informa il bollettino dei changelog. La più importante di tutte è che è stato finalmente corretto il baco che non permetteva di invocare la funzione _trackEvent() senza invocare anche _trackPageview() o _initData() (si veda questo vecchio post in proposito: initdata e tracciamento eventi). Da questo momento è quindi possibile avere una pagina che contiene il codice di monitoraggio di Google Analytics SENZA che essa generi una pagina vista ma che è in grado di tracciare eventi che accadono su di essa.

Un’altra novità è che è stato leggermente variata la sintassi del nuovo script asincrono, in modo da risolvere un problema che si generava su Internet Explorer 6 e 7 quando si posizionava lo script nell’HEAD della pagina; vi consiglio di dare un’occhiata al nuovo snippet – lo trovate qui – perché è abbastanza differente dalla prima versione apparsa.

Per chi invece usa il codice “classico”, è bene sapere che la funzione _getTracker() è stata deprecata. Non l’avete mai usata? dite? secondo me invece si, è una funzione che avete incollato OGNI SINGOLA VOLTA che avete aggiunto un codice di GA a una pagina.

<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-53707-19");
pageTracker._trackPageview();
} catch(err) {}</script>

Fa parte del codice standard e si invoca quando si crea il più famoso oggetto pageTracker. Sebbene l’interfaccia web ancora non rifletta questa modifica quando si crea un nuovo codice di monitoraggio, la funzione _getTracker non esisterà più, e al suo posto andrà usata _createTracker(), cui dedicheremo un post apposito appena avrò qualche notizia più certa. Sostanzialmente il nome dell’oggetto di tracciamento verrà impostato come un parametro di questa nuova funzione, come nella sintassi di esempio

_gat._createTracker('UA-65432-2', 't2');

Se non ho capito male poi ci si potrà riferire all’oggetto semplicemente con t2._trackPageview().
Non è un cambiamento epocale, ma rende il codice di monitoraggio classico più coerente con quello asincrono.

Sempre il buon Andrea mi pone una domanda, e ne approfitto di nuovo per un post: mi fa sempre piacere scoprire cosa non è chiaro alle persone, dato che io con Google Analytics ci faccio anche colazione e quindi tendo a dare per scontate troppe cose

Il suo quesito è all’incirca “Non sono d’accordo con una persona che sostiene che trackpageview può essere utilizzato anche per rimappare l’url corrente della pagina e fare in modo che sia possibile poi utilizzare il nuovo indirizzo all’interno dei goals per verificare chi converte e chi no. Io ritengo che la funzione del trackpageview è quella si di assegnare una pagina virtuale, ma nel caso in cui si scateni un evento a cui questo è stato associato”

L’errore nasce dal fatto che _trackPageview noi lo vediamo solo in due forme. La prima è all’interno del codice di monitoraggio classico, dove viene sempre richiamata senza parametri, la seconda è quando creiamo pagine virtuali e quindi le passiamo come parametro un indirizzo fittizio. La funzione in realtà è sempre la stessa, e il suo scopo è quello di “fare il punto della situazione” nel codice di monitoraggio, scrivere i cookie nel computer del visitatore e sparare i dati verso i server di Google. Se non gli si passa un parametro, essa invia per impostazione predefinita l’url corrente della pagina così com’è.
Ma nessuno ci vieta, ad esempio, di usare una funzione lato server per inserire dinamicamente all’interno di un codice di monitoraggio degli indirizzi più leggibili ai fini delle nostre analisi.

Ipotizziamo di non avere modo di riscrivere le URL attraverso i metodi “normali” – quali .htaccess o filtri ISAPI per webserver Microsoft – e di aver scritto una funzione in PHP (abbellisciURL() ) che ci restituisce un simil-URL nella forma /categoria/marca/nomeprodotto.html

Se modificassimo il GATC così

<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-xxxxxx-x");
pageTracker._trackPageview(<?php abbellisciURL(); ?>);
} catch(err) {}</script>

dentro a Google Analytics avremmo SOLO ED ESCLUSIVAMENTE i nostri url abbelliti.

Potrete poi usare questi url per definire gli obiettivi? ASSOLUTAMENTE SI, dato che non sappiamo esattamente QUANDO GA elaborerà i dati, e dato che gli url modificati sono I SOLI ad essere stati inviati ai server di Google, è assolutamente lecito e possibile definire dei goal usando gli url fittizzi. Anzi, non potreste fare altrimenti!

_trackPageview() quindi si rivela anche un potente strumento per rendere i vostri report più semplici e chiari, più leggibili, ed eventualmente anche per facilitarvi la vita nell’impostazione degli obiettivi.

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

Secondo me sicuramente si, l’ho già detto in passato. Mi sembra un passaggio naturale e obbligatorio, dato che lo scopo di Website Optimizer è quello di migliorare le conversioni del sito facendo test A/B e il modo per capire cosa è meglio e cosa no è il tracciamento puntuale delle visite.
Gli strumenti sono già visivamente simili, ed esistono anche soluzioni per integrare i dati dentro a Google Analytics, ma sono piutosto macchinose e non ve ne ho mai parlato (anche perché mi piacerebbe, prima o poi, fare dei test con GWO e parlarvene qui).

Curiosamente però entro le prossime due settimane entrambi gli strumenti subiranno una manutenzione evolutiva; ecco il comunicato del blog di Analytics e quello del blog di Website Optimizer. Prima che qualcuno di voi si spaventi mettiamo subito in chiaro che nessun dato andrà perso e i sistemi continueranno a funzionare regolarmente. In GWO non sarà possibile creare o modificare esperimenti, in Analytics non sarà possibile creare profili, aggiungere utenti o filtri o modificare la configurazione dei profili esistenti. Per entrambi i prodotti sarà invece possibile consultare i dati.

Ma perché insieme? e perché adesso? per come la vedo io l’intervento è teso ad armonizzare i database sui quali si reggono le due applicazioni, e se tutto andrà bene tra qualche mese i due strumenti si fonderanno: d’altronde Google Analytics ha già un sistema di generazione del codice di monitoraggio, e GWO richiede dei codici aggiuntivi da mettere sulle pagine. Se fosse possibile creare e gestire esperimenti direttamente da Analytics si potrebbe demandare a lui la generazione del codice necessario, salvando nel contempo le configuraizoni avanzate, e avere i dati direttamente integrati in Analytics sarebbe indubbiamente vantaggioso e affascinante!

[update 11:27. In realtà la scritta che avvisa della manutenzione dentro al pannello di GA recita:

A partire dal giorno 2-mar-2010, Google Analytics non sarà disponibile approssimativamente dalle ore 7.00 alle ore 23.00 (fuso orario del Pacifico).
Durante questo periodo, potresti non riuscire a visualizzare i dati aggiornati. Tuttavia, i dati continueranno ad essere raccolti ed elaborati e potrai visualizzarli al termine dell'operazione di manutenzione.
Apprezziamo la tua pazienza.

La manutenzione quindi sarà tra le 16:00 del 2 Marzo e le 8:00 del 3]

Facebook è ovunque, e forte dei suoi 400 milioni di utenti macina record su record. Facebook è sulla bocca di tutti, e tutti vogliono sfruttarlo per promuovere se stessi o la propria attività, a volte anche in modo inappropriato (per non dire peggio). A prescindere da tutte queste considerazioni – però – non è mai stato possibile inserire il codice di Google Analytics sulle fan page del famoso social network. Al massimo si poteva utilizzare un tag di FBML (una versione modificata di HTML che si usa nelle pagine di FB), ma esso poteva venire usato solo sulla pagina di presentazione di un’applicazione.

Da qualche giorno è invece disponibile uno strumento esterno che si basa sull’uso di una immagine generata “al volo” da php, in grado di intercettare i dati necessari e di inviarli ai server di Google al posto del javascript che usiamo normalmente. Senza dilungarmi troppo vi segnalo il post di Tiziano Fogliata e il post originale degli autori, dove è anche possibile scaricare il tutto e ospitarlo sui propri server per avere ulteriori personalizzazioni possibili.

E’ un primo timido tentativo di unificare dati provenienti da fonti diverse, problema sempre più annoso, ma secondo me questa mossa a Facebook non piacerà affatto e temo che lo strumento presto cesserà di esistere. Facebook non ha mai supportato troppo l’inserimento di script esterni sulle proprie pagine, basti pensare che il codice di GA generato dal tag usa ancora la vecchia versione dello script, quello con urchintracker().

NO!
In realtà, se vogliamo, esistono due id diversi: uno è l’ID dell’account (nella forma UA-123456) e uno è l’ID di ogni profilo contenuto in ogni account (nella forma UA-123456-1, UA-123456-2 e così via…).
In nessuno dei due casi potete variare questi dati, che vengono generati al momento della creazione di un account e di un profilo, rispettivamente.

Se prendete due qualsiasi codici di monitoraggio, nella loro forma basilare senza personalizzazioni, vedrete che differiscono per una e una sola cosa, la riga:

var pageTracker = _gat._getTracker("UA-xxxxxx-x");

se cambiate i numeri che ci sono al posto delle x semplicemente inviate i dati ad un altro account / profilo (questo si può fare, lo ricordate?). Quindi variare i numeri a livello di codice di monitoraggio è inutile. D’altra parte non si possono fare modifiche a questi dati nella configurazione di GA, quindi abbiamo le mani legate.
Il motivo della domanda presumo sia iniziare un nuovo profilo mantenedo lo storico, cosa che non è possibile dato il legame stretto che abbiamo visto lega codici di monitoraggio a profili e account.

Anche io inizio a far fatica a stare dietro agli aggiornamenti del nostro sistema di web analytics preferito, e vi garantisco che ho innumerevoli fonti che leggo spessissimo. Basta distrarsi un giorno e gli ingegneri di Mountain View lanciano nuove funzionalità, aggiornano l’interfaccia, fanno annunci. Vediamo quindi cosa troveremo nel pacchetto che Google Analytics ha deciso di lasciarci sotto l’albero di Natale:

• Annotazioni: ne aveva già parlato Enrico sul blog di TSW, ma volevo aspettare un post ufficiale. Si tratta di una funzionalità richiesta a gran voce da molti, specie quando si usa GA in team grandi o geograficamente distribuiti. Si tratta di poter aggiungere annotazioni, etichette, scritte, direttamente sui grafici, in modo che sia chiaro a tutti cosa è successo in un dato punto del grafico, oppure che si possa aggiungere un promemoria per una analisi successiva o annotare un down del server. Che siate del reparto marketing, vendite o tecnici informatici, troverete questa funzione molto utile per far sapere a tutti coloro che hanno accesso al profilo cosa succede ai dati.
• Variabili personalizzate nei segmenti avanzati: vi sarà finalmente la possibilità di utilizzare le nuove variabili personalizzate (di cui parleremo a breve) per definire segmenti basati sui dati in esse contenuti.
• Variabili personalizzate nei report personalizzati: come conseguenza del punto precedente, le variabili personalizzate appariranno anche nell’interfaccia di creazione dei rapporti personalizzati, e saranno incrociabili con le altre metriche/dimensioni.
• Nuovo processo di creazione del codice di monitoraggio: questo è interessante. Uno degli scogli più grandi nell’uso di alcune funzioni avanzate è il loro collocamento nello script di tracciamento, dopo aver capito quale fosse la funzione adatta allo scopo (l’esempio classico è il tracciamento multidominio o multisottodominio). D’ora in poi Google Analytics proporrà un processo di creazione del codice guidato, e rispondendo ad alcune domande sarà possibile avere il codice già bello e pronto da incollare. Come bonus c’è la possibilità di inviare per email il codice finito.
  
  [immagine di Google]
• Nuova versione delle API: per ora solo un annuncio, le novità devono essere così corpose che stanno preparando un post a parte solo per le API

Che ne dite, Babbo Natale Analytics è stato buono con noi quest’anno?

[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 ]