Google Analytics in 30 secondi

Joe di Morevisibility.com inizia il classico giochino di fine anno con le previsioni per i dodici mesi che stanno per arrivare, ovviamente riguardanti il sistema di web analytics made in Google. Ecco cosa prevede:

• urchin.js sarà eliminato e tutti saranno costretti a migrare a ga.js. Questa è facile: tralasciando il fatto che i vantaggi di ga.js stanno diventando schiaccianti (monitoraggio eventi, tanto per dirne una), quando ci fu la riscrittura a oggetti del sorgente di Analytics tutti i Google Analytics Authorized Consultant precisarono che il supporto al vecchio codice sarebbe andato avanti ancora per 12-18 mesi. Essendo stato introdotto il 13 dicembre 2007, in entrambi i casi si finirebbe nel 2009.
• Google Website Optimizer sarà integrato dentro a GA. E’ una delle tante cose ce prima o poi Google farà per arrivare a quello che abbiamo deciso di chiamare Google Business Platform. Ritengo che una prima integrazione sia fattibile durante il 2009, almeno a livello di interfaccia di accesso, come adesso si può accedere ad Analytics da dentro al pannello AdWords
• Saranno aggiunte nuove sezioni di report, come “blog”, “social media” o “mobile”. A causa di questo fatto Google dovrebbe raggruppare alcuni siti che adesso appaiono come referrer e creare un nuovo mezzo al pari di referrer, motori di ricerca e campagne. Aggiungo che se succederà, dovranno essere assolutamente introdotte funzioni per il controllo di questo nuovo mezzo, al pari di _addOrganic e _clearOrganic, perché il valore dei social media varia molto da paese a paese.
• Sarà aggiunta una sezione di path analysis. Oppure saranno pesantemente ristrutturati i report esistenti, che al momento sono utili ma non consentono analisi troppo approfondite, e che sono sostanzialmente identici a quando GA fu presentato per la prima volta.
• La sezione di report subirà una pesante ristrutturazione. Ad esempio si possono solo schedulare gli invii degli export su base giornaliera, settimanale, mensile o trimestrale e non si può fare molto più che modificare oggetto e corpo dell’email.

Aggiungo che secondo me il 2009 è l’anno buono per l’integrazione di Feedburner dentro a Google Analytics, ipotesi che non solo si rafforza in virtù del punto tre predetto da Joe (i feed sono molto diffusi nei blog e nei social network), ma che trova un indizio nel fatto che da pochi giorni Google ha iniziato a migrare forzatamente i vecchi feed sul dominio feedburner.com sul nuovo dominio di proprietà feedproxy.google.com. I feed su questo nuovo dominio possono poi, tra l’altro, usufruire di Adsense per i feed, e i rapporti Adsense si stanno piano piano attivando anche su GA. E il cerchio si chiude.

Quali sono invece le vostre previsioni per il 2009 di Google Analytics?

Una form è pur sempre una form, e molti utenti non amano questa forma di interazione che invece spesso è fondamentale per entrare in possesso di informazioni più o meno vitali per la vita del proprio sito web. Ci sono centinaia di pagine e scritti sull’usabilità delle form e sulle best-practice per invogliare l’utente a compilarle, o per non distruggere la sua esperienza sul nostro sito.

Uno dei passi principali del processo di ottimizzazione dei moduli è quello che porta all’eliminazione dei campi “inutili”, dove per inutili si includono anche i campi non obbligatori che gli utenti non compilano. Se l’informazione richiesta ci serve, converrà rendere la compilazione del campo obbligatoria, altrimenti dovremo arrenderci all’evidenza che la form non funziona. Ma come possiamo rendercene conto? con uno strumento di web analytics, ad esempio. In questo caso un post su e-nor.com ci illustra come piegare Google Analytics a questa esigenza, come asservirlo alle esigenze di progettisti e di coloro che hanno a cuore la user experience degli utenti.

il primo passo è quello di aggiungere una un evento onClick ogni volta che la form viene inviata
<input type="submit" name="Submit" value="Submit" onClick="return validate(this.form);"/>

il contenuto della funzione validate() è invece il seguente

function validate() 
{ 
isEntered(document.getElementById('name'),'name');
isEntered(document.getElementById('email'),'email');
isEntered(document.getElementById('phone'),'phone');
isEntered(document.getElementById('company'),'company');
isEntered(document.getElementById('comments'),'comments');

frm.action='/thankyou.aspx?src=contact_us.htm'; 
} 

function isEntered(el, field_name)
{ 
     if((el.value=="") || (el.value==null))
     {
     pageTracker._trackPageview('/contact_us.htm/empty/'+field_name); 
     }

     else
     {
     return false;
     }
}

ovviamente serve una riga per ogni campo della vostra form, e gli id devono corrispondere. Non è molto differente dalle molte funzioni di validazione delle form che si trovano in giro per il web, ma questa ha la particolarità di aggiungere una chiamata a _trackPageview() ogni volta che uno dei campi risulta vuoto al momento dell’invio. La scelta in questo caso è di creare una pagina /contact_us.htm/empy/nome-del-campo.

Per leggere i dati l’articolo consiglia anche di creare un profilo-copia e di mettere un filtro di inclusione solo per i dati provenienti dalle form inviate, in modo da non perdere troppo tempo a cercare i risultati nei report. Il filtro sarebbe fatto così:

Nome: URL Filter – Contact Us Form
Tipo: filtro personalizzato, di inclusione
Campo filtro: URI della richiesta
Pattern filtro: contact_us\.htm
Maiuscole Minuscole: No

il report CONTENUTI PRINCIPALI di un profilo con questo filtro applicato conterrebbe solo URL riferiti alla pagina di contatto, con le evidenze del numero di volte in cui ogni campo è stato inviato vuoto, permettendoci di trarre le dovute conseguenze sul proseguo della vita della nostra form.

Come nota personale aggiungo che la soluzione mi piace, ma non mi fa impazzire. Ne ho in testa una versione evoluta, che permetterebbe anche di conoscere quante volte le persone cliccano su ogni campo per compilarlo o quanto tempo viene impiegato per la compilazione della form e del singolo campo. E’ uno dei tanti progetti che prima o poi riuscirò a realizzare.

Si è sempre detto che non è possibile modificare l’intervallo predefinito di date visualizzate quando si accede ai report, ed in effetti è sempre stato così. Nemmeno ora, a dire il vero, si può cambiare questa impostazione e far sì di visualizzare sempre gli ultimi diciotto giorni, ad esempio, tuttavia il nuovo pannello di accoglienza introdotto da qualche giorno porta in dote un piccola novità.

Nel momento in cui ci viene proposto il riepilogo degli account, o dei profili se abbiamo già selezionato un account, abbiamo la possibilità di scegliere quattro periodi temporali predefiniti con cui raffrontare i dati: giorno, settimana, mese e anno. Selezionarne uno farà si che i dati visualizzati nel riepilogo cambino, ovviamente, ma farà anche si che una volta aperto un report il periodo temporale sarà già impostato sul corrispettivo selezionato; quindi se stavamo controllando i riepiloghi settimanali (e li stavamo quindi confrontando implicitamente con la settimana precedente), i report saranno impostati per default sugli ultimi sette giorni escluso il giorno corrente.

È anche un modo che Google Analytics usa per non creare confusione nell’utente passando da un periodo ad un altro in modo poco chiaro. Uscendo dall’interfaccia di GA e rientrando in un momento successivo, tuttavia, il periodo temporale predefinito sarà nuovamente impostato ai precedenti trenta giorni (“mese” nel riepilogo), non vi è modo di rendere permanenti le modifiche. Al limite penso si potrebbe fare uno script per GreaseMonkey…

Immagino che molti di voi, ormai, abbiamo avuto modo di osservare come l’iPhone sia “entrato di prepotenza” nelle statistiche e nella dashboard del vostro account di Google Analytics; con questo post vediamo come capovolgere la questione: far entrare Google Analytics nell’iPhone.

Oggi il mercato mette a disposizione di chi vuole fruire delle statistiche di Google Analytics attraverso l’iPhone solo due possibili soluzioni: myAnalytics e Google Analytics for iPhone.
Il semplice tentativo di accedere alle statistiche navigando su google.com/analytics/it-IT/ non è percorribile in quanto Safari per iPhone non è compatibile con le tecnologie utilizzate nei report di Google Analytics (Flash ed Ajax).(*)

Vediamo di seguito in dettaglio le caratteristiche delle due soluzioni. Continua a leggere “Usare Google Analytics sull’Iphone”

Quando illustro come Google Analytics tiene traccia delle campagne, con l’uso di parametri proprietari negli URL delle pagine sul sito, spesso vengono fuori le domande “ma quegli URL sono indicizzati?” e “ma quello non è contenuto duplicato?” (mi ricordo che ne parlammo anche al primo corso gratuito di GA a Verona, con YoYo – formazione rotolante e Stefano Gorgoni). La risposta a tutti gli effetti è si, gli url delle campagne vengono indicizzati a meno che non siano esplicitamente bloccati tramite META TAG o file robots.txt (e non sempre è possibile), e se vengono indicizzati rappresentano un URL che presenta gli stessi contenuti di un altro.

Premetto che non sono un SEO e mi occupo di posizionamento solo per i siti che creo, ma che sono dentro al settore, mi documento e mi confronto con amici e colleghi perché spesso le considerazioni che si traggono dalle analisi si possono tramutare in consigli per il posizionamento o devono tenere conto delle azioni per il posizionamento fatte autonomamente dal cliente o da altri consulenti. Detto ciò, se questa situazione vi spaventa e non volete rinunciare all’uso delle campagne, un suggerimento viene da Benjamin Mangold: sostanzialmente il suggerimento è di usare la funzione _setAllowAnchor(true) (di cui vi avevo già parlato) e di cambiare il punto interrogativo ( ? ) negli URL da diffondere per la campagna con il cancelletto ( # ). Si tratta effettivamente di un uso “creativo” della funzione, che probabilmente non è stata creata per questo motivo.

Per definizione Google non indicizza nulla di quanto vi sia in un indirizzo web dopo al carattere cancelletto, poiché il cancelletto viene usato in HTML per indicare delle ancore interne alla pagina web, quindi per definire link a punti differenti della stessa pagina. Combinando queste due informazioni si ha la soluzione al problema degli eventuali contenuti duplicati.

[photo credit LollyKnit su Flickr]

Non conosco Brandt Dainow e non leggo il suo blog, però trovo parecchio interessante e condivisibile il post di “risposta” di Ian Thomas su “Lies, damned lies…”. Brandt asserisce che Google Analytics sbaglia le misurazioni (anzi, lo farebbe apposta) al punto che molte persone percepirebbero una situazione fortemente distorta rispetto alla realtà. Si concentra in particolar modo sul fatto che GA considera le visite di una sola pagina (i bounce, tanto per chiarire) come visite valide e le usa anche per calcolare la durata media delle visite.

Mi permetto di riportare i tre punti che Ian usa per smontare questa tesi:

• Esistono innumerevoli situazioni in cui è perfettamente legittimo che i visitatori guardino una sola pagina: il lettore tipico di blog, che consulta la homepage e va via se non ci sono aggiornamenti, o chi clicca su un articolo da un feed rss e lo legge. Tagliare via tutte queste visite sarebbe da pazzi
• Sebbene l’inclusione di queste visite nel calcolo del tempo medio sia un problema conosciuto, escluderle non lo risolverebbe ma semplicemente lo sposterebbe altrove: non si avrebbe un numero “più accurato” ma un numero “inaccurato in altra maniera”. Non si avrebbe comunque modo di conoscere il tempo di permanenza sull’ultima pagina, e questo si rifletterebbe in una scarsa accuratezza del dato in presenza di una visita di due pagine
• Il tipo di metrica che produce GA è il risultato di lunghi studi e discussioni (e peraltro è aderente agli standard della Web Analytics Association); c’è bisogno di una forte motivazione per cambiare una metrica semplice e facile da capire con una più complicata che non apporta sostanziali miglioramenti

Sono personalmente d’accordo al cento per cento con Ian, e non solo perché questo blog tratta di Google Analytics. Non difendo nessuno a priori e quando ne ho occasione mostro anche i limiti di GA, ma non mi sembra questo il caso: particolarmente significativa la frase “Quando, come industria, non siamo d’accordo su cosa costituisca esattamente una visita, è facile accusare questo o quel sistema di non essere accurati semplicemente perché non si ha fiducia nell’approccio che essi hanno nei confronti dei dati“. Che non esista un tool perfetto e universale lo sappiamo tutti (e se non lo sapete lo ripeterò ancora una volta), il problema è che bisogna trovare un tool di cui fidarsi. Bisogna studiare, conoscere, chiedere e provare, e poi scegliere di conseguenza. Possibilmente verificando l’aderenza del prodotto con i famosi standard della WAA.

Volevo approfittare di questo post per fare un’altra considerazione: Ian Thomas lavora in Microsoft, e faceva parte del team di adCenter Analytics (il sistema di analisi che prima si chiamava Gatineau), ma nonostante questo difende GA, che è comunque un suo competitor. E’ un comportamento molto onesto che ritrovo spesso nel web, in maggior parte negli Stati Uniti dove c’è una cultura migliore del mercato e della concorrenza, ma che mi sembra ancora più accentuato quando si guarda al settore della Web Analytics. Io penso che la ragione sia da ricercare nel grande fermento che lo sta attraversando e dal relativo nuovo interesse che vedo nascere intorno alla web analisi (di pochi giorni fa la discussione “la web analytics è a prova di crisi?” di Eric Peterson su Web Analytics Demystified). Non sono abbastanza dentro al settore per definirla una “seconda giovinezza”, ma credo che le aziende si stiano rendendo conto che c’è bisogno di analisi, e che le analisi sono un investimento e non un costo, spesso un investimento che permette di tagliare con senso altri costi. Voi cosa ne pensate?

[image credit Morning Glory on Flickr]

Nonostante la versione del GATC non sia cambiata, il codice di monitoraggio da inserire nelle pagine web su alcuni profili è leggermente variato. Questo il codice che potreste trovare:

<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-XX");
pageTracker._trackPageview();
} catch(err) {}</script>

Come potete notare l’oggetto pageTracker e la relativa chiamata al metodo _trackPageview si trovano dentro ad un blocco try, in un’istruzione try… catch.

In programmazione il costrutto try… catch permette di gestire le “eccezioni” che più semplicemente potremmo definire “errori”. Per farla breve la variante del codice di Google Analytics sopra riportata cerca di eseguire le sue normali funzioni e in caso di errore… non fa niente, ma evita che appaiano errori nella console Javascript del browser:

Inoltre, un errore Javascript nel codice di Google Analytics, in certe condizioni, potrebbe bloccare l’esecuzione di altri script presenti nella pagina, riducendo le funzionalità di un sito web.

Con questo try… catch si riduce quindi il rischio che il codice di Google Analytics generi un errore, che potrebbe ad esempio essere causato dalla mancata inclusione del file ga.js. A sua volta, la mancata inclusione del file ga.js, potrebbe essere causata da un programma o estensione per bloccare annunci pubblicitari, da impostazioni di rete in server aziendali o da servizi estremi di protezione della privacy, come ad esempio FoolDNS.

Per concludere, se non volete rischiare di avere un sito che “non funziona” per colpa di Google Analytics, potete fare tre cose:

1. Non usate Google Analytics!
2. Lasciate il codice di Google Analytics al suo posto, tra i propri tag SCRIPT e /SCRIPT. Se lo prendete e lo mettete in un file esterno o in mezzo ad altro codice Javascript, rischiate che in caso di errore non funzioni neanche tutto il resto. In alternativa inserite il codice di Google Analytics in un costrutto try… catch, come nella variante proposta da Google.
3. Includete il codice di tracciamento appena prima della chiusura del tag /BODY e non tra i tag HEAD e /HEAD delle pagine HTML. Questo vale per Google Analytics come per tutti i file Javascript che risiedono su server esterni. Infatti i browser leggono i documenti in modo sequenziale, dall’inizio alla fine, e quando trovano l’inclusione di un file Javascript non proseguono fino a che il file non è stato incluso. Se i server di Google Analytics non fossero raggiungibili per qualsiasi motivo, la porzione di pagina non caricata non includerebbe il contenuto principale.

[questo è un guest post di Francesco Terenzani. Francesco è il classico “amico di chat che non si è ancora conosciuto di persona” ma è una persona in gamba ed è molto preparato. Quando ho un dubbio su javascript mi permetto di disturbarlo, e lui trova sempre qualche minuto da dedicarmi. D’altronde senza il suo lavoro non avremmo mai prodotto lo script per auto-tracciare link esterni e download anche in presenza di multipli GATC.]

[to Joe Texeira: yes, I noticed the change in the script on 13th November, but I was waiting for my friend Francesco to confirm me some ideas 🙂 ]

Google Analytics è un sistema di tracciamento delle visite tramite javascript, come abbiamo visto più volte; significa che ogni volta che un browser con javascript abilitato visita una pagina contenente il GATC, esso invia immediatamente una serie di informazioni ai server di Google. Siti con traffico molto alto, nell’ordine delle milioni di pagine viste al mese, generano una mole di richieste molto alta, ma naturalmente il problema non è certo la banda che l’infrastruttura di Google può dedicare ad Analytics, bensì il problema potrebbero essere i report.

I dati accumulati dai server vengono processati e messi “ordinati” nel database di GA, ma non viene fatto quasi nessun precalcolo. I dati sono sostanzialmente grezzi, altrimenti non si potrebbero creare i nuovi rapporti personalizzati. Questo però comporta lo svantaggio di dover effettuare i calcoli “al volo” ogni volta che apriamo un report, infatti più dati ci sono più il sistema può risultare lento (e con i segmenti avanzati la cosa è accentuata parecchio). Per questo motivo i profili con molte pageviews potrebbero presentare la dicitura “questo rapporto si basa su dati di esempio. Ulteriori informazioni” e i dati avere una percentuale di scostamento a fianco: significa che il numero visualizzato non è preciso ma è appunto in un intorno percentuale di quanto indicato.

La funzione _setSampleRate(stringa) serve a dire a Google Analytics di non conteggiare tutti i visitatori, ma solo la percentuale passata come parametro alla funzione. Ad esempio impostando la funzione così:
pageTracker._setSampleRate("70");
verranno tracciati solo sette visitatori ogni 10. Su siti di grandi dimensioni è un’operazione statisticamente possibile, e non inficia i rapporti generati anche perché Google Analytics si comporta in maniera coerente rispetto ai visitatori che ritornano. Ogni visitatore viene “marchiato” dalla funzione: se GA decide di tracciarlo, lo traccia sempre. Se decide di non tracciarlo, non lo traccia mai. In questo modo il suo comportamento è sempre registrato e l’esperienza utente sul sito non viene stravolta nei report.

Se il dubbio che vi ha assalito durante la lettura di questo articolo è “non sono sicuro di voler tralasciare parte delle visite”, la creazione di due oggetti di tracciamento distinti che puntano a due profili differenti è la soluzione che fa per voi: un profilo conterrà tutti i dati, un altro solo un sample. Potrete fare le analisi sul profilo agile e approfondire le questioni dubbie su quello completo, diminuendo il tempo di attesa del caricamento dei dati. Ecco un esempio di codice

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write("\<script src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'>\<\/script>" );
</script>

<script type="text/javascript">
var firstTracker = _gat._getTracker("UA-12345-1");
firstTracker._setSampleRate("70"); // traccia il 70% delle visite
firstTracker._trackPageview();

var secondTracker = _gat.getTracker("UA-67890-1");
secondTracker._trackPageview(); //traccia tutte le visite
</script>

Ieri durante l’evento Adobe Max di San Francisco Google e la stessa Adobe hanno annunciato il rilascio di alcuni metodi e librerie per facilitare il tracciamento di siti o oggetti realizzati tramite Adobe Flash o Adobe Flex.
La cosa era tecnicamente fattibile anche prima, tramite l’Event Tracking, ma avere una serie di metodi appositi può facilitare molto il lavoro di sviluppatori e utenti finali. Ad esempio il sistema Sprout Mixer di Sprout Inc. (tramite il quale sono realizzati ad esempio alcune parti del fansite di Pink [edit: ora offline]) è già pronto per inviare i dati ai report di Analytics. Per l’utente la configurazione dovrebbe essere minima e potrebbe limitarsi solo all’inserimento del numero del proprio account GA.

La documentazione per il tracciamento di Flash si può ovviamente trovare sulle pagine ufficiali del Google Code. Dal canto mio, avevo iniziato ieri a studiare la documentazione per un certo progetto che intendo rilasciare qui, ma questa novità rimescola un pochino le carte. Poiché non sono così tanto ferrato in javascript e ActionScript (il linguaggio usato da Flash), ho bisogno della collaborazione di due persone, e soltanto dopo potrò sottoporvi la cosa. Sono abbastanza sicuro che verrà apprezzata, dovrete solo avere un po’ di pazienza…

Una delle domande che mi viene rivolta più spesso è come si faccia a immettere due o più parole nella casellina di ricerca a fianco del menu a tendina “contenente / tranne”. L’inserimento di spazi, virgole e segni più infatti non sortisce gli effetti desiderati, e spesso non sortisce proprio nessun effetto se non quello di azzerare i dati mostrati. Se stiamo guardando l’elenco delle pagine e vogliamo dire a Google Analytics di mostrare le pagine che nell’url contengono la parola “cane” OPPURE la parola “gatto” l’unico modo possibile è inserire una espressione regolare.

La notizia buona è che l’espressione equivalente a un semplice “questo oppure questo” è molto facile, quella cattiva è che per esigenze leggermente più avanzate è necessario addentrarsi nelle espressioni regolari. Ma affrontiamo una questione alla volta, cercando di non complicare troppo la questione.
L’operatore booleano OR viene reso con il segno pipe ( il segno | che si trova facendo SHIFT + \ nella tastiera italiana), per cui per ottenere il risultato menzionato precedentemente si inserirà l’espressione
cane|gatto

Questo tipo di espressione funziona ovviamente sia nel caso si stia usando il menu a tendina impostato su “contenente” sia su “tranne”. Quello che invece non esiste è l’operatore booleano AND. O meglio, non esiste nella sintassi delle espressioni regolari e non si tratta di un limite di GA. Le espressioni regolari infatti nascono per intercettare porzioni di dati, tipicamente testuali; non si può fare una regular expression che cerca “cane E gatto” in un testo, bisogna scrivere una espressione regolare più complicata. Devo essere sincero, nonostante regolarmente io stesso mi ponga questa domanda, almeno finché non avrà iniziato e finito la lettura di Mastering Regular Expression della O’Really l’unica sensata (benché non elegantissima) che ho trovato è questa:
cane(.*)gatto|gatto(.*)cane

che in italiano significa “trova qualsiasi riga in cui ci sia la parola cane e gatto inframmezzate da qualsiasi cosa, oppure gatto e cane inframmezzate da qualsiasi cosa”.