Google Analytics in 30 secondi

Google Analytics è un sistema di web analytics lato client basato su un pezzetto di codice javascript: ne consegue che tutto quel che non è taggato, per lui è invisibile. Detto così sembra banale, però non lo è quando si cerca di rispondere alla domanda “che succede quando si passa da una pagina senza tag?”
Di fronte a questa domanda ho sentito le risposte più fantasiose, e anche le più irrazionali. La risposta è: niente! La risposta completa in realtà sarebbe “dipende da QUANTO tempo trascorre sulla pagina non taggata” e il tutto parte dal presupposto che la pagina sia nello stesso dominio che si sta tracciando.

Se infatti la pagina non tracciata fa parte di un ALTRO dominio, o di un sottodominio che genera un altro set di cookie, o di un dominio terzo con lo stesso codice di GA ma non gestito con le apposite funzioni di passaggio dei cookie, allora il ritorno ad una pagina tracciata rientra nel caso di una visita da referrer: se il cookie __utmz contiene qualsiasi altra informazione, viene cambiato, viene generata una nuova visita e si vede un referrer.

Se invece si sta parlando di una normale navigazione A -> B -> C, dove la pagina B NON CONTIENE il codice di GA e le altre due si, quel che arriva ai server di Analytics è semplicemente A -> C; B non esiste, non avrebbe modo di sapere che esiste e non può essere tracciata. All’arrivo sulla pagina C Analytics si chiede “e questo visitatore chi è, da dove arriva?”, controlla se è presente il cookie __utmb (che scade dopo 30 minuti di inattività dell’utente), e se lo è semplicemente accoda la pagina C alla visita, e la piazza dopo la pagina A.

Se invece sulla pagina B l’utente trascorre più mezz’ora, allora si genera un nuovo cookie __utmb, quindi una nuova visita, con referrer il proprio sito. Ma questo accade in ogni caso in cui l’utente lascia scadere la sessione di visita, anche nei siti taggati perfettamente.

C’è però una cosa da tenere presente, che è una conseguenza del cambio di calcolo delle visite operato da Google Analytics nell’Agosto 2011: siccome prima di allora il modo per controllare se iniziare o meno una nuova sessione era il cookie __utmc (che veniva distrutto alla chiusura del browser), una sequenza come A -> browser chiuso -> B (il tutto entro mezz’ora) veniva vista come due distinte visite. Da dopo il cambio si tratta invece di una sola visita.

Come aveva già notato Andrea Pernici, seguito da Sean Carlos, da due settimane è presente su Google Analytics il report “tempi utente”, che però è vuoto. Oggi il blog ufficiale ci svela il perché: per popolarlo è necessario usare la nuova funzione _trackTiming; a cosa serve questa nuova funzione, anzi questa nuova API? serve a misurare i tempi di caricamento di pressoché qualsiasi cosa del nostro sito, che si tratti del caricamento di una libreria piuttosto che il tempo di reazione del server al click su un certo pulsante…

Come avevo più o meno pronosticato, si tratta dell’evoluzione e della codifica di una cosa che si poteva già fare, e si poteva fare con una libreria messa a disposizione da Google su una pagina seminascosta delle pagine dei developer (che però è stata rimossa). Oggi il tutto viene modernizzato con un set di chiamate apposito e ufficializzato. La nuova funzione ha questa sintassi:

_gaq.push(['_trackTiming', 'categoria', 'variabile', 'tempo', 'label_opzionale', 'samplerate_opzionale']);

e come molte delle ultime funzioni introdotte è praticamente una variante della funzione _trackEvent. La categoria ci permette di separare logicamente i vari caricamenti (librerie, immagini, richieste AJAX…), la variabile è il nome dell’oggetto che stiamo tracciando, il tempo sono i millisecondi impiegati per caricare, la label può servire per distinguere ulteriormente differenti tempi di caricamento, e il samplerate ci permette di decidere a quale percentuale di visite applicare il tracciamento.

Si tratta ovviamente di un tracciamento molto avanzato, che richiede un po’ di programmazione, quindi la cosa migliore che posso fare è rimandarvi alla documentazione ufficiale; in fondo alla pagina ci sono altri esempi su cose che si potrebbero tracciare: il tempo speso a guardare un video, il tempo impiegato per finire un livello di un browser-game, il tempo speso per leggere una sezione o una pagina (magari modificando questo metodo di Justin Cutroni).
Mi piacerebbe però anche sapere voi cosa ci fareste o cosa avete intenzione di fare con questa nuova funzione…

Un po’ di segnalazioni minori di cose avvenute in questi giorni e che non meritavano un post dedicato.

• La versione 4 è ancora disponibile: il link è stato spostato nel footer, e si chiama “Versione precedente – Rapporti”. Ho visto passare su Twitter messaggi disperati per questa mossa, ma mi sento in dovere di dirvi una cosa: abbandonate la vecchia versione il prima possibile, tanto non sarà Febbraio come ipotizzato mesi fa, ma è solo questione di tempo prima che scompaia del tutto. Arrivare impreparati all’evento sarebbe drammatico, ipotizzare che in qualche modo la 4 continuerà ad essere disponibile (magari sulla base del fatto che esistono complessi iter per avere la vecchia interfaccia di Gmail) addirittura azzardato!
• Phil Mui lascia Google: per chi non lo sapesse, Phil è stato uno dei product manager per Google Analytics per molti anni. Viene descritto come persona gentilissima ed estremamente disponibile, e come uno dei più grandi contributori alla progressione dello strumento per come oggi lo conosciamo. Noi eravamo abituati a sentire il suo nome come speaker alle conferenze e sognare annunci di nuovi rilasci, un po’ come è successo per i report social all’ultimo LeWeb. Lascia Google per una società di nome Acxiom
• goanalytics.info raggiunge gli 800 fan su Facebook: invero non molto da dire, se non un grosso grazie!

Più il fenomeno delle keyword (not provided) aumenta e più le persone si ingegnano per contrastarlo. Non passa giorno senza che si legga qualcosa in merito, a volte sono cose banali, altre volte cose sensate, altre ancora metodi complicatissimi che tirano in ballo funzioni statistiche magari non alla portata di chiunque. Io ve ne parlo quando trovo qualcosa di interessante, e in questo caso il post di Barry Adams su State of Search lo è; è uno di quei post che mette in fila concetti noti, ed è utile perché è semplice.

La premessa è avere un sistema che tracci su Google Analytics la posizione della keyword: in passato ne abbiamo visti alcuni, altri ne potete trovare con delle ricerche su Google. Se avete dei profili-copia in cui avete keyword (posizione), allora avete già risolto la parte “difficile” del lavoro. Darò per scontato che sia così, diversamente rileggetevi il post che ho linkato poco sopra.

A questo punto il report delle keyword mostrerà un record per ogni posizione in cui si trovava la keyword estirpata da Google al momento di passarvi la visita, quindi avremo dei record con (not provided)(1) distinti dai (not provided)(3). Aggiungendo la dimensione secondaria “pagina di destinazione” e ordinando per quest’ultima ci ritroveremo con la situazione che mostra nello screeshot

Se la keyword (not provided) ha lo stesso ranking di una in chiaro, e anche la medesima landing page, ci sono buone probabilità che si tratti della stessa keyword. La cosa funziona meno per le pagine molto popolari, cioè quelle che attraggono visite con keyword molto variegate, come spiega Barry in fondo al suo post.

Qualunque tecnica si scelga, il primo passo da fare per provare e venire a capo dei (not provided) è quello di diluirli: con dimensioni secondarie, filtri o segmenti, analizzare un unico blocco è diverso da avere tanti piccoli record. Ci sono maggiori possibilità di controllarli e confrontarli.

Ispirato dal post precedente, mi sono messo a realizzare, per renderlo decente e fruibile, un custom report che mi è servito qualche tempo fa: io lo chiamo “full search experience”, e te lo regalo con un link più sotto, nel post.
Niente di trascendentale, sia chiaro, ma in pratica è un report che mette in relazione le ricerche ESTERNE al sito – quelle cioè usate per raggiungere il sito – e le ricerche INTERNE – ammesso che siano tracciate, naturalmente.
La domanda alla quale vuole rispondere è: esiste una qualche relazione tra le due cose? e se c’è, come influenza le mie conversioni? se il mio sito è bene indicizzato e mostra landing page calibrate sulle ricerche effettuate sui motori, probabilmente i visitatori non avranno bisogno di usare il motore interno. Oppure si, perché dopo aver soddisfatto il loro bisogno primario che li ha portati sul sito, vogliono sapere qualcos’altro. Viceversa se il mio sito è difficile da navigare, il motore di ricerca interno sarà sotto stress, e potremo vedere se i termini ricercati hanno attinenza con le keyword in ingresso. E tutte le vie di mezzo, naturalmente.

Le metriche usate seguono il classico schema “acquisition – engagement – conversion”, le dimensioni sono ovviamente “Parola chiave” e per ognuna di esse “Termine di ricerca“, e ho usato due filtri: includo solo le visite che hanno sia fatto una ricerca interna sia una visita da mezzo organic.
Il primo livello di dimensioni presenta le parole chiave usate per raggiungere il sito dai motori per le sole visite che hanno poi fatto una ricerca interna. Al clic verranno presentati i termini di ricerca usati.
Se dopo averlo provato ti stai domandando “cosa sono tutte quelle visite a 0 nei termini di ricerca?” ti dico subito che non lo so: per qualche strano motivo il conteggio totale delle visite è corretto, ma i singoli record no, almeno per quel che concerne le metriche non strettamente legate alla ricerca interna. Vero è che una stessa visita può fare più ricerche interne (e questo lo spiegherebbe), è strano però che io veda keyword con 19 visite nel cui dettaglio i termini di ricerca hanno tutti zero visite. Quel che mi interessava maggiormente, comunque, era avere a portata di mano un report che legasse le keyword esterne a quelle interne, e pazienza se alla seconda dimensione alcune metriche perdono senso.

DOWNLOAD DEL CUSTOM REPORT

Se avete correzioni o suggerimenti, sono come sempre bene accetti!

Il bello di internet è che pochi minuti dopo che succede qualcosa, qualcuno ha già pensato a cosa fare. Esce il nuovo Google+ e c’è troppo spazio bianco? ecco pronta una estensione di Chrome che risolve! la seconda cosa che ho imparato è che o fai parte della cerchia delle persone “veloci” a realizzare qualcosa, o ti accontenterai per sempre di essere uno di quelli che si accodano (o, se vogliamo vederla da un altro punto di vista, inizia a fare le cose anche se non tutti i pezzi del puzzle sono a posto: se ci vanno devi solo dare una sistemata, altrimenti dovrai iniziare il lavoro solo allora, e sarai sempre lento).

Questo preambolo per dire che si, in effetti l’idea di creare un luogo ove la gente potesse scaricare e condividere elementi di Google Analytics mi ha accarezzato per un bel po’; da un lato non ero sicuro dell’idea – d’altronde se una cosa si chiama “report personalizzato” è o dovrebbe essere perché va bene per me, e magari non per te – dall’altro credevo che fosse un’esigenza che potesse colmare un vuoto. Però fino a qualche tempo fa le dashboard non si potevano condividere. Comunque sia non c’è più bisogno di tormentarsi, perché Jill Whalen l’ha creato al posto mio, e si chiama CustomReportSharing.com

Lì potete trovare link diretti a report personalizzati, segmenti avanzati e dashboard, divisi per categorie (SEO, ecommerce, social…) e provvisti di commenti e screenshot in alcuni casi. Si tratta di un forum, e potete registrarvi normalmente oppure usare i metodi di login forniti da Twitter e Facebook. Io mi sono collegato col mio account twitter. Un’idea semplice, che potrebbe esservi utile. Anche se, ve lo ripeto, niente è meglio di qualcosa pensato da voi, per voi. Al massimo potete farvi aiutare a realizzarlo, magari da me

Di metodi per tracciare gli errori dei siti ne abbiamo visti parecchi, in questi anni: 404, 500, con pagine virtuali o con eventi, praticamente tutte le combinazioni possibili sono state sviscerate. Ma c’è un tipo di errore diverso che non avevo mai visto tracciato, ed è l’errore client-side, o l’errore visualizzato dal browser. Se ad esempio il vostro sito è una webapp, o un sito che fa un uso molto spinto di AJAX e javascript, i problemi più comuni non saranno errori di pagine non trovate o di chiamate sbagliate al database, bensì errori di interpretazione ed esecuzione di funzioni lato client.

Per questo motivo in un post del blog di ThetaBoard c’è un elenco di tool dedicati adatti a tracciare queste situazioni, ma allo stesso tempo è anche presente una soluzione semplice e alla portata di tutti: siccome Google Analytics è installato un po’ ovunque, e siccome è gratis, con una semplice modifica del codice si può avere – quasi – lo stesso risultato. La modifica è l’aggiunta, dopo il codice di monitoraggio standard, delle righe

// ADD THIS AT THE BOTTOM OF YOUR GOOGLE ANALYTICS TRACKING CODE //
window.onerror = function(message, file, line) { 
   var sFormattedMessage = '[' + file + ' (' + line + ')] ' + message; 
   _gaq.push(['_trackEvent', 'Exceptions', 'Application', sFormattedMessage, null, true]);
}

Il sistema utilizzato è quello degli eventi, per cui il report relativo da guardare sarà quello delle etichette degli eventi. Ancora meglio però sarà suddividere gli errori per pagina, per cui si aprirà il report CONTENUTI -> EVENTI -> PAGINE e si utilizzerà la dimensione secondaria ETICHETTA EVENTO, ottenendo esattamente quel che si vede nell’immagine del post che vi ho linkato

Come si dice giustamente nel paragrafo finale, il sistema non è perfetto, e non è un sistema dedicato, ma ha dalla sua almeno due buoni vantaggi: non dovrete installare un nuovo sistema e caricare il server anche di quell’incombenza, e soprattutto potrete capire che relazione esiste tra questi errori e le vostre metriche di business, come il conversion rate o le transazioni. Il che non mi sembra affatto poco!

All’interno del post che contiene l’ultimo video della serie Web Analytics TV c’è una spiegazione semplificata di come funziona l’algoritmo che determina il fenomeno del campionamento all’interno dei nostri report, che lo ricordo interviene quando l’interrogazione che facciamo ha una base di oltre 250.000 visite.

Il campione usato nel sampling è random ed uniformemente distribuito nell’arco temporale selezionato. Vediamo nel dettaglio l’esempio del blog: se un sito riceve 500mila visite il giorno 1, 250mila il giorno 2 e 500mila il giorno 3, nell’arco del periodo ha un totale di 1 milione e 250 mila visite. come fa Google Analytics a determinare QUALI di queste sessioni di visita usare per calcolare i valori mostrati nel vostro report campionato?

Per prima cosa calcola un moltiplicatore, dividendo il totale delle visite per il numero di visite scelto dallo slider di controllo. Nel caso dello slider impostato sul valore predefinito, 1.250.000 / 250.000 = 5. A quel punto le visite di ogni giorno vengono divise per il moltiplicatore, e viene preso un numero casuale di visite che combaci con quel numero.
Nel nostro esempio:
- 500mila / 5 = 100mila visite casuali dal giorno 1
- 250mila / 5 = 50mila visite casuali dal giorno 2
- 500mila / 5 = 100mila visite casuali dal giorno 3

A questo punto I VALORI che abbiamo richiesto all’interno di queste visite totali vengono conteggiati tutti, ma vengono mostrati dopo essere stati ri-scalati secondo il moltiplicatore.

Ad esempio: “quanti visitatori nel periodo selezionato usano Opera e sono visite di ritorno?”. Ipotizziamo 1200 dei 100mila del giorno 1, nessuno dei 50mila del giorno 2 e 2700 dei 100mila del giorno 3. Totale 3900 * 5 = 19500. Questo è il valore che verrà mostrato nel report campionato che risponde alla domanda. I singoli valori saranno rispettivamente 6000, 0 e 13500.

Statisticamente ha senso, a meno di improvvisi sbalzi dei valori il numero campionato dovrebbe essere fedele al numero reale. E vien da sè, tanti più giorni ci sono nel periodo temporale, tanto più l’effetto di questi eventuali sbalzi è mitigato.

[image credit: [F]loximoron on Flickr]

Subito la premessa: il metodo descritto non è stato da me testato, questa è una pura segnalazione! tuttavia è stato scritto un mese fa, non dovrebbero esserci stati sconvolgimenti colossali nel frattempo.

Se analizzate spesso i report mobile, vi sarete accorti che alle righe Iphone e Ipad dei report sui sistemi operativi non corrispondono dei drilldown con le versioni dello stesso (iOS 5, iOS 5.1, eccetera…). La cosa è meno vera per i dispositivi Android, e in parte vera per altri sistemi. La cosa potrebbe avere una certa influenza, a seconda del tipo di business in cui operate, per cui Jay Taylor di Fresh Egg se ne è uscito con una soluzione per ovviare al problema:

il primo passo da fare è quello di scaricare la libreria – trovate il link sul suo sito – e referenziarla PRIMA del codice di Google Analytics.
Secondariamente si deve aggiungere la seguente riga al codice di monitoraggio
_gaq.push(function() { checkMobileAgent(); });
Jay dice di metterla prima o dopo _trackPageview, io la metterei prima.
Terzo bisogna mettere in piedi dei filtri personalizzati.

Filtro 1 – Capture Mobile OS Platform from User Defined
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: definito dall’utente
Campo A -> regex: ^([^:]+)::.+$
Output To -> Constructor: piattaforma del sistema operativo visitatore
Output To -> Constructor value: $A1

Filtro 2 – Capture Mobile OS Version from User Defined
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: definito dall’utente
Campo A -> regex: ^[^:]+::(.+)$
Output To -> Constructor: piattaforma del sistema operativo visitatore
Output To -> Constructor value: $A1

Prestate attenzione alle espressioni regolare, differiscono di pochissimo. Altra cosa interessante del metodo è che usa il valore definito dall’utente impostato tramite la deprecata funzione _setVar, ma aggiunge un terzo filtro che svuota il valore definito dall’utente prima che esso arrivi ai report; in questo modo il relativo rapporto sarà vuoto, oppure se avete degli altri filtri che usano quel campo li potrete accordare a questi tre, e continueranno a funzionare.

Filtro 3 – Prevent __utmv Cookie Data writing to User Defined report
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: User-Defined
Campo A -> regex: (.*)
Output To -> Constructor: definito dall’utente
Output To -> Constructor value: (not set)

Il sistema funziona se e solo se lo user agent utilizzato per visitare il vostro sito da mobile corrisponde a uno di questi sistemi: “iPhone”, “iPod”, “iPad”, “Android”, “webOS”, “BlackBerry”, e quindi il nuovo drilldown relativo sarà presente solo per questi sistemi operativi. Ma come vedete dallo screenshot di Jay, direi che funziona!

Ecco, io ora non lo so se è solo un pesce d’Aprile, un pesce elaborato (giacché funziona) che è costato poco sviluppo, o se davvero hanno introdotto stabilmente questa cosa, ma oggi dopo segnalazione di Sean Carlos su Google Plus ho aperto il mio Analytics e ho visto che si può fare davvero: nel grafico della panoramica è presente una icona a forma di nota musicale, che se premuta presenta due opzioni; piano e sitar. Premendo una delle due dalle vostre casse usciranno delle note che corrisponderanno ai punti del vostro grafico. Più il punto è in alto, più alta è la nota, e viceversa.

Anche se alla maggior parte di voi la cosa può sembrare frivola o inutile, il mio primo pensiero è andato a un webmaster non vedente. Tolti i grafici in Flash (e temo anche quelli in SVG della versione v5), ho sempre avuto l’idea che uno screenreader difficilmente avrebbe saputo leggere i dati di Google Analytics. Anche con l’aiuto di qualcuno che “racconti” i dati, deve essere difficile farsi un’idea dell’andamento degli accessi tramite una voce, o leggendo una tabella più o meno lunga. Noi diamo per scontato il grafico per vedere il trend, un non vedente se lo deve costruire memorizzando i dati. Invece le note con un singolo click possono rendere questa operazione facile anche per loro.

Insomma, frivola o inutile per molti, fondamentale per altri. Io spero che non sia uno scherzo del primo di Aprile!