Google Analytics in 30 secondi

Il sempre ottimo Brian Clifton mette in piazza la sua personale visione sulle modalità di scelta tra segmenti avanzati e profili-clone con filtri, visto che le due cose sono molto simili e ultimamente tendono a sfumare l’una nell’altra: Brian considera i profili-clone come una segmentazione “di lunga durata”, destinata a durare nel tempo e destinata a una categoria di visitatori piuttosto importanti, dato che quelli esclusi dal filtro sono persi per sempre (nel solo profilo-clone, ovviamente).

Ecco una comparazione puntuale:

Brian quindi dice di usare i filtri sui profili per filtrare il “rumore” permanente (visite interne), quando il segmento definito è destinato ad essere usato per lungo tempo o quando c’è bisogno di controllare l’accesso ai soli dati segmentati.
Di contro, usate i segmenti avanzati quando state cercando di capire i differenti comportamenti di alcune fasce di utenti, visite da social network, visite da mobile, o se i clienti acquisiti navigano diversamente dai potenziali clienti, oppure quando c’è bisogno di condizioni basate su valori numerici (visite di persone che hanno speso più di 100 dollari per transazione e che restano sul sito almeno 30 secondi).

Direi che mi trovo sostanzialmente d’accordo con Clifton, e che già ora è questo l’uso che faccio dei segmenti avanzati e dei filtri applicati a profili-clone, anche se ultimamente mi è capitato molto meno di creare filtri al profilo. Potrebbe dipendere dalla tipologia di siti che analizzo, indubbiamente, ma non è detto. Capita anche a voi?

…anzi, siccome noi siamo attenti alla statistica useremo la frase corretta, cioè “il 28% dei quattro milioni di domini campionati ha lo script di Google Analytics”.
E’ questo il risultato di una interessante indagine di CommonCrawl.org messa a disposizione da Factual.com tramite un interessante meccanismo di consultazione che comprende filtri, colonne e la possibilità di aggiungere altre tabelle a quella visualizzata.

La tabella è qui, a disposizione di chiunque voglia giocarci un pochino 🙂

Direi che per GA è un risultato notevole, anche se è vero che è l’unico strumento di web analytics considerato e non ci sono quindi paragoni; però il numero mi sembra interessante lo stesso, non trovate?

Da quando faccio il consulente Google Analytics devo ammettere che la domanda “perché un consulente?” mi si è presentata più volte, sotto varie forme. E’ vero, ho detto che Google Analytics non è gratis e costa soltanto meno degli altri prodotti, ho detto che l’aiuto – sebbene sparpagliato in vari luoghi online – è comunque una ottima fonte di aiuti preziosi, e ho messo in piedi questo blog anche per aiutare le persone con questo strumento.

Ma vediamo perché a volte c’è bisogno di una consulenza più specifica e puntuale:

• vuoi una persona con un “titolo”: come ho detto più volte, essere certificato Google Analytics Invidual Qualification non significa sapere tutto di GA ed essere in grado di rispondere a qualsiasi richiesta. Però è un esame, presuppone un po’ di studio e un investimento in denaro, per quanto piccolo esso sia. Sicuramente una persona certificata crede fortemente nello strumento e può fornirti una consulenza di un certo tipo.
• alcune cose sono troppo difficili per te: Google Analytics è uno strumento magnifico, con pochi click e un copia-incolla si è in grado di avere già molti report. Ma quando le cose si complicano – specialmente con l’introduzione di alcune recenti novità come lo script asincrono o il tracciamento dei siti mobile – potresti avere bisogno di qualcuno che vada oltre la semplice ricerca di una soluzione online.
• non hai il tempo di seguire tutte le novità: anche io ultimamente fatico a stare dietro a tutti gli annunci che il team di Google Analytics fa o ai cambiamenti dell’interfaccia dei report. Mi immagino che per le persone che GA lo usano e basta sia ancora più complesso stare aggiornati. Un consulente può sempre darti una visione sulle ultime novità e magari mostrarti una strada più semplice o più vantaggiosa che tu non avevi considerato semplicemente perché non sapevi esistesse. Io non sto otto ore al giorno con la faccia su GA (anche se mi piacerebbe), ma ti assicuro che ogni giorno leggo decine e decine di cose sullo strumento, trucchi, soluzioni, post, forum… Ho le mie fonti e ne vado abbastanza fiero: se qualcuno nel mondo scrive qualcosa di interessante su Analytics, stai certo che al 90% lo leggerò.
• ti serve un lavoro costante nel tempo: potresti aver bisogno di un tipo di lavoro che porta via troppo tempo a un tuo dipendente, o che nessuno è in grado di fare, o che richiede una conoscenza specifica di GA. Potrebbero essere delle analisi dettagliate, oppure conferme a sospetti e intuizioni, potrebbero essere report specifici costanti nel tempo o analisi costanti sulla situazione e le modifiche apportate al sito.
• hai fretta: è leggittimo; alcune volte implementare una soluzione nuova richiede test, controllare i risultati, capire se qualcosa non va e perché, fare correzioni. Sebbene non possa darti garanzia totale che questo con un consulente non accada, è più facile che qualcuno che maneggia Google Analytics intensivamente abbia già affrontato un problema simile e possa quindi darti una soluzione “cucinata”.

Quando hai bisogno di un consulente? molti lettori di questo blog possono testimoniare che rispondo sempre alle mail e ai commenti al meglio delle mie possibilità, senza chiedere un centesimo. Diciamo che, di solito, se per spiegare la soluzione ci vogliono più di tre mail o una telefonata di un’ora, o si parla di un problema molto grosso o totalmente nuovo, quello è il momento di ragionare su una possibile collaborazione.

Partendo dal presupposto che un funnel è un insieme predefinito di pagine che vanno viste prima di arrivare a un obiettivo, e tenendo bene a mente che il metodo descritto non tiene conto dell’ordine di visualizzazione, mentre il funnel definito in Google Analytics si, i ragazzi di ROIrevolution se ne sono usciti con un metodo per creare dei funnel “al volo”; metodo che avevo già sperimentato (per fortuna ho i testimoni, vero @marcoziero? 🙂 ) ma non avevo mai descritto.

Dopo aver definito il percorso verso l’obiettivo (il funnel, appunto) è necessario creare un segmento avanzato che isoli le visualizzazioni di ogni pagina, la cui combinazione produce il numero di visite che hanno visto TUTTE le pagine. Si inizierà quindi con la pagina 1 del percorso, avendo cura di usare la dimensione “pagina” invece di “pagina di destinazione” e di inserire la condizione “contiene” invece di “corrisponde esattamente a”. dopo aver dato il nome al segmento è necessario premere “segmento di prova” e annotarsi il numero risultante nella riga “…questo segmento corrisponde a XXX visite”. Poi si inseriranno le altre pagine del funnel e si ripeterà la prova per ogni inserimento, annotandosi i risultati. Il numero di utenti che hanno visto entrambe le pagine dovrebbe essere inferiore al precedente, e così via. Alla fine si avranno i numeri di visitatori di tutti gli step, e si sarà creato un rudimentale funnel. Non è da prendere come oro colato, ma rappresenta una buona approssimazione, sicuramente più utile rispetto a non avere nessun dato 🙂

photo credit: AndyRob on Flickr

[questo è un post per tecnici incalliti 🙂 ]

Il changelog lo conferma ufficialmente: le API di Google Analytics sono passate alla versione 2 a partire da ieri, 14 dicembre. Alcune delle nuove funzioni annunciate infatti sono espressamente dedicate alle richieste che includono negli header la richiesta GData-Version: 2.

Le novità sono le seguenti:

• supporto dei segmenti avanzati, anche per la creazione “al volo” di segmenti che non sono stati definiti prima nell’interfaccia. Molto interessante!
• nuovi goal. tutti i tipi di goal sono recuperabili tramite API, con descrizione, numero di completamenti, goal start e valore.
• variabili personalizzate, che adesso sono disponibili come un intero elemento XML, insieme a 10 nuove dimensioni incrociabili con esse.
• cambio di nome per due dimensioni (ga:countOfVisits ora si chiama ga:visitCount e ga:countOfVisitsToATransaction è diventata ga:visitsToTransaction) e quattro metriche e dimensioni deprecate (ga:countOfVisits, ga:countOfVisitsToATransaction, ga:sourceMedium, ga:percentNewVisits)

Insomma, a poca distanza dall’introduzione di nuove funzioni, esse sono subito disponibili tramite le API. Programmatori di tutto il mondo, andate e create! 🙂

[beh, come nota a margine devo dire che oggi ho installato Trakkboard per provarlo, ed è basato proprio sulle API. Questi strumenti stanno diventando sempre più notevoli, e secondo me non abbiamo ancora visto niente! ]

Non faccio nessuna fatica a immaginare perché Google abbia lanciato oggi un servizio di URL shortening (goo.gl), cioè un servizio che tramuta indirizzi di pagine molto lunghi in piccoli e snelli link da incollare dentro a email, twit, social network e affini…

Lo ha fatto perché alcuni dei servizi più popolari, ad esempio bit.ly, forniscono statistiche sulla provenienza geografica dei click, sull’andamento temporale degli stessi, sul referrer che li ha generati (nel caso in cui qualcun altro incolli il “vostro” url accorciato in altri posti).
E dove ci sono statistiche, presto o tardi arriva Google Analytics. Al momento il servizio è disponibile per la toolbar di Google, ma a mio avviso è molto probabile che in futuro esso sarà disponibile anche attraverso un’interfaccia web, e che si preoccuperà di incapsulare anche i parametri necessari a tracciare automaticamente quei link come campagne di GA, esattamente come fa adesso Feedburner.

Un altro tassello prende la direzione del tracciamento con Google Anlaytics…

A partire dal primo dicembre 2009, la funzione _setVar() è deprecata, il che significa che non va più usata nel proprio codice di tracciamento. Nel contempo sotto al report “definito dall’utente” è stato aggiunto “Variabili personalizzate”, che consente di monitorare quel che viene definito con la nuova funzione. Il vecchio report è adesso popolabile soltanto tramite filtro.

_setVar() è stata invece sostituita dalla nuova _setCustomVar(indice, nome, valore, scopo), che ha le stesse possibilità della precedente, ma aggiunge ulteriori livelli di utilizzo e possibilità di tracciamento. Vediamo come:

• indice è un numero intero, da 1 a 5, e rappresenta lo “slot” nel quale il valore viene inserito.
• nome è una stringa, e rappresenta il nome che diamo alla variabile impostato.
• valore è una stringa e rappresenta il contenuto della variabile personalizzata
• scopo è una numero intero – opzionale – che possiamo usare per tenere traccia del perché quella variabile viene impostata. Valori tipici sono 1, 2 e 3 che nell’idea di Google Analytics rappresentano nell’ordine variabili impostate a livello di visitatore, di sessione o di pagina.

Dal punto di vista del programmatore la funzione ritorna un valore booleano: true se la variabile personalizzata è stata impostata correttamente, false se qualcosa è andato storto. Tenete a mente che la somma dei caratteri di nome e valore non può sorpassare i 64 caratteri.

Perché è utile dichiarare uno scopo? perché la nuova funzione _setCustomVar() può essere usata in contesti differenti rispetto alla vecchia _setVar(), ad esempio per raggruppare i contenuti senza trucchi. Il codice necessario per raggruppare le pagine della categoria “sport” potrebbe ad esempio essere:
pageTracker._setCustomVar(1,"sezione","sport",3);

Se per adesso non avete voglia di fare troppe modifiche ma vi interessa solo continuare a far fare ad Analytics quello che facevate con _setVar(), la traduzione della vecchia riga

trackPageview._setVar('miovalore');

si fa – ad esempio – con

trackPageview._setCustomVar(1,'valore_pers','miovalore',1);

Si è inserito il valore di 1 nello scopo perché la vecchia funzione impostava SOLO valori a livello utente, che sono appunto quelli con scopo 1.

Ricordatevi sempre che _setCustomVar() va chiamata PRIMA di un trackPageview() o di un _trackEvent(), poiché la funzione imposta il valore ma non comunica niente ai server, mentre le altre due poi inviano tutte le informazioni, quindi anche il valore appena impostato, a Google Analytics

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? 😉

Social Search è uno degli esperimenti di Google Search che è possibile sottoscrivere in test (gli altri due al momento sono keyboard shortcut e accessible view). In sostanza è una speciale categoria di ricerche che si preoccupa di cercare contenuti rilevanti per la query da noi inserita nel motore, all’interno della nostra rete di amici e conoscenti online. Il cosiddetto “circolo sociale”.

La settimana scorsa Giorgio Taverniti mi ha chiesto come si potessero tracciare queste ricerche in Analytics, poiché stava preparando il suo intervento al ConvegnoGT 2009. Poiché un giorno Social Search potrebbe essere promosso a funzione ufficiale, eccovi il metodo che ho impiegato, che poi è sostanzialmente una modifica di quello che abbiamo usato per tracciare separatamente i risultati illustrati mantenendo la keyword:

Anche in questo caso servono tre filtri per fare tutta l’operazione. Possiamo pensare a Social Search come a una “branca” di Universal search. Il referrer di una ricerca Social avrà al suo interno il parametro oi=social_search oppure il parametro tbs=frim:1. Poiché ho avuto qualche problema con il filtro in presenza dei due punti, ho inserito soltanto tbs=frim. Ecco i tre filtri:

primo filtro, di tipo personalizzato – avanzato:
nome: SocialSearch – cambia sorgente
Campo A -> Estrai A -> Referral -> (\?|&)q=([^&]*)
Campo B -> Estrai B -> Referral -> (tbs=frim)|(oi=social_search)
Output in -> Constructor -> Sorgente campagna -> Google Social Search
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

secondo filtro, di tipo personalizzato – avanzato
nome: SocialSearch – estrai keyword
Campo A -> Estrai A -> Referral -> (\?|&)q=([^&]*)
Campo B -> Estrai B -> Referral -> (tbs=frim)|(oi=social_search)
Output in -> Constructor -> Termine della campagna -> $A2
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

terzo filtro, di tipo personalizzato – avanzato
nome: SocialSearch – cambia mezzo
Campo A -> Estrai A -> Referral -> (\?|&)q=([^&]*)
Campo B -> Estrai B -> Referral -> (tbs=frim)|(oi=social_search)
Output in -> Constructor -> Mezzo della campagna -> SocialSearch
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

Il risultato dell’operazione sarà poi visibile nel report “tutte le sorgenti di traffico” e sarà segmentabile per parola chiave.
Se vi siete iscritti all’esperimento (che lo ricordo funziona solo su google.com e solo in lingua inglese) avrete notato che Social è solo l’ultima delle scelte nelle opzioni della barra laterale. Ognuna di esse ha un parametro che la distingue, e che potrebbe essere usato modo simile a quanto ho fatto io. Ve li elenco:

Images ha il parametro tbs=isch:1
Videos ha il parametro tbs=vid:1
News ha il parametro tbs=nws:1
Blogs ha il parametro tbs=blg:1
Books ha il parametro tbs=bks:1
Forums ha il parametro tbs=frm:1
Social ha il parametro tbs=frim:1
Edit 9/12: Real-time ha il parametro rltm:1 [Google ha lanciato la ricerca real-time, è anch’essa è disponibile su google.com nella medesima barra delle opzioni]

[Questo è un guest-post di Alessandro Martin. Mi fa piacere perché me l’ha proposto lui in un momento in cui per via di un corso di formazione non avevo tempo di scriverlo da me]

Da pochissimo il team di Google Analytics ha rilasciato una nuova versione dello script di tracciamento. Vediamo insieme quali sono le novità.

Piccola premessa

Quando il browser visualizza una pagina web deve scaricarne tutti i componenti: immagini, file CSS, script Javascript, ecc… Il browser è in grado di scaricare in parallelo più di un file ma non gli script Javascript che vengono invece sempre scaricati uno alla volta. Ne consegue che tutto quello che si trova dopo uno script in una pagina web non può né essere scaricato né essere visualizzato fino al completo caricamento dello script stesso. Per questo le linee guida per il vecchio codice di Google Analytics suggeriscono di inserire lo script subito prima della chiusura del tag <body>. In questo modo il codice di tracciamento interferisce il meno possibile con il caricamento della pagina che può comunque essere visualizzata fino in fondo. Con questo metodo però tutti quegli utenti che abbandonano la pagina prima che il codice sia completamente caricato non vengono tracciati, portando ad una perdita di dati più o meno importante a seconda dei casi.

Cosa è cambiato?

Con il nuovo codice di Google Analytics cambia il meccanismo con il quale il codice di tracciamento viene richiamato nella pagina. Al costo di una leggera complicazione dello script si ottengono tre benefici principali.

• Aumenta la velocità di caricamento delle pagine. La tecnica di inclusione utilizzata, descritta qui per i temerari non blocca il download parallelo.
• Migliore esperienza utente. Nel caso in cui i server di Google Analytics impiegassero molto tempo a rispondere l'utente non si accorgerebbe di nulla perché il nuovo script viene caricato "in background".
• Più dati. Sarà possibile inserire il nuovo codice nella sezione <head> della pagina HTML evitando la potenziale perdita di dati descritta più sopra.

Feticismo Javascript: il codice visto da vicino

Diamo un’occhiata da vicino al codice per capire dove stanno le novità:

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-X']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script');
ga.src = ('https:' == document.location.protocol ?
    'https://ssl' : 'http://www') +
    '.google-analytics.com/ga.js';
ga.setAttribute('async', 'true');
document.documentElement.firstChild.appendChild(ga);
})();

La prima riga del codice crea una coda, ovvero una struttura dati, un contenitore che permette di conservare al suo interno oggetti o funzioni. Nella seconda e terza riga viene richiamato due volte il metodo _gaq.push() che serve per inserire nel contenitore appena creato le chiamate alle funzionalità di GA che si vogliono utilizzare e che verranno conservate finché il codice ga.js non verrà realmente caricato. Le righe successive, incluse in una funzione anonima per evitare di disturbare il funzionamento di altri script nella pagina, si occupano di:

• costruire nel DOM del documento un elemento <script> con nell’attributo src la URL dello script ga.js.
• inserire nel primo nodo figlio del documento HTML (solitamente il tag <head>) il tag <script> appena creato.

Tempo di migrare?

La migrazione è consigliata ma non obbligatoria. Il vecchio codice “sincrono” continuerà ad essere supportato probabilmente per lungo tempo. Personalmente credo che qualunque cambiamento che migliori la velocità di un sito e quindi la qualità l’esperienza dell’utente sia da abbracciare senza pensarci due volte. Per esperienza però so che anche un cambiamento apparentemente semplice come la sostituzione del codice di tracking è una battaglia che in certi contesti può lasciare sparsi sul terreno morti e feriti in gran quantità ;-). Google fornisce una guida dettagliata per la migrazione con diversi esempi di configurazioni tipiche, quindi mi raccomando: pianificate bene la vostra migrazione e non lasciate in giro (orrore!) pagine con un doppio codice di tracciamento.

[considerazione personale: È un’ottima cosa che Google abbia ascoltato il parere di chi voleva questa funzionalità. Personalmente non ho mai notato rallentamenti di sorta per via del GATC, ma in alcuni casi combinandolo con altri script vi era un “effetto imbuto”. Peraltro questa mossa arriva insieme a molte altre nel settore “velocità”: prima Matt Cutts dichiara che in futuro i siti più veloci a caricare potrebbero avere un livee vantaggio nel posizionamento, poi Google tira fuori un po’ di strumenti per i programmatori,sistemisti e webmaster (page speed, il protocollo SPDY, il compressore javascript Closure, la visualizzazione dei tempi di caricamento su Webmaster tools), poi Analytics introduce lo script asincrono, infine Google annuncia i propri DNS free, ovviamente velocissimi. Stanno provando in tutti i modi a velocizzare il web, e Francesco Piersimoni ha ragione: lo stanno facendo per preparare il campo all’arrivo di ChromeOS, che sul web praticamente vive e prospera. Anche Wave potrebbe avere la sua parte in tutto questo, ma una cosa è certa. Se il web andrà più veloce, ci guadagneremo prima di tutto noi utenti e poi sicuramente anche Google.]

[contenuto bonus: Francesco Terenzani ha subito scritto un post per aggiornare tutti noi sull’utilizzo della sua mitica libreria per tracciare automaticamente link esterni e download. Lo trovate sul suo blog]

[photo credit: mainblanche on Flickr]