Google Analytics in 30 secondi

Uno non fa in tempo a cambiare lavoro ( 😛 ) che il team di Google Analytics prova a prenderlo in castagna: vediamo se ti fai scappare questo annuncio, sembrano aver detto, e io rispondo: no! eccomi qui! 🙂
Oggi il blog ufficiale ci introduce la nuova versione di un tool già esitente: il vecchio http://browsersize.googlelabs.com sarà disponibile – “nelle prossime settimane” come al solito – direttamente dentro a Google Analytics. Con il non indifferente vantaggio di essere totalmente basato sui dati dei vostri veri visitatori. Se vi ricordate infatti tempo fa vi parlai di un nuovo parametro nelle richieste alla gif di tracciamento, che ci anticipava l’introduzione di questa nuova feature.

All’interno della sezione “in-page analytics” sarà disponibile un nuovo strato di informazioni, che appunto mira a farvi comprendere in modo visuale quanta percentuale dei vostri visitatori vede quanta parte dei vostri contenuti: un conto è infatti dire che i visitatori hanno al 70% una certa risoluzione dello schermo, un altro invece è sapere quanto viewport (il nome tecnico della porzione di browser effettivamente adibita ai contenuti) essi hanno a disposizione. La visualizzazione sarà disponibile anche in forma di percentile, e sarà possibile fare comparazioni tra pagine, ad esempio tra la prima e l’ultima di un funnel, per capire se un certo step viene abbandonato a causa di pulsanti fuori dalla visuale, ad esempio.

Sicuramente un altro strumento utile alla piena comprensione dei visitatori ai nostri siti. Dati reali, aggregati e mostrati in forma semplice e utile a capire come migliorare le pagine web.

Come vado ogni tanto ripetendo, la web analytics non è mai stata il mio lavoro principale. Occupa da molto tempo una posizione di spicco nel mio cuore, ma il mio lavoro principale era il programmatore web nel settore dei siti per la pubblica amministrazione. La mia attività professionale, sviluppata anche grazie a questo sito, era un “di cui”, portato avanti con impegno e molta passione, ma era pur sempre una cosa secondaria.

Dico “era”, perché da oggi inizio un nuovo lavoro: ho infatti accettato un posto in Intarget Group, nella sua divisione Intelligence, che finalmente mi porterà a lavorare tutti i giorni tutto il giorno con i numeri, i grafici, le dimensioni e le metriche che mi sono tanto care, e che spero siano tanto care anche a voi che mi leggete… 🙂

Cosa cambia quindi per questo sito, questa modifica ha un qualche impatto? in realtà si: Intarget ha da poco acquisito la qualifica di Google Analytics Certified Partner, il titolo attribuito alle aziende certificate ufficialmente da Google e consigliate quando qualcuno cerca supporto a pagamento per Analytics. Per questo motivo esse godono di canali privilegiati di comunicazione, e hanno in qualche modo accesso agli ingegneri. Se siete soliti seguire gli annunci di nuove funzionalità vi sarete accorti che quando viene lanciata una nuova funzione (l’ultima giusto venerdì con i Content Experiment), alcuni blog presentano all’istante post chilometrici e sono pieni di screenshot anche se le funzioni non sono disponibili ai comuni mortali.

Quindi direi che i cambiamenti per questo blog sono principalmente due:

1. A causa delle pesanti NDA (Non Disclosure Agreement) in gioco tra tutte le parti, mi asterrò da ora in poi da qualsiasi commento sul futuro di GA e dal mettere bocca nel classico giochino delle previsioni di inizio anno. Un conto è usare la fantasia e indovinare un certo sviluppo, come abbiamo fatto finora, un altro è scrivere una boutade e poi magari vedersela realizzata per davvero sotto al naso. Da parte vostra mi aspetto però che teniate a mente questa nuova condizione ed evitiate di mettermi in difficoltà 🙂
2. Per le parti di cui invece si può parlare liberamente, però, varrà la regola “meno ipotesi e (ancora) più concretezza”. Molte volte in passato ho detto “secondo me”, spero di poterlo spesso sostituire con forme più certe. Il che è un vantaggio 🙂

Per tutto il resto credo che non cambierà niente: se ci sarà da fare una critica al prodotto o a Google non mi tirerò di certo indietro: l’obiettivo è sempre e comunque quello di migliorare lo strumento, lo era “da fuori” e se possibile lo sarà ancor di più da “dentro”.
Avrò a che fare molto spesso anche con altri prodotti ma non credo che la cosa avrà riflessi, perché questo è e resta un blog monotematico. A seconda di quanto sarò distrutto a fine giornata però la frequenza di post potrebbe risentirne, almeno inizialmente 🙂

Se in questi anni vi ho in qualche modo aiutato, specialmente se non vi siete mai palesati in un commento, e se ne avete voglia, mi farebbe piacere leggere un vostro in bocca al lupo!

Oggi è uno di quei giorni destinati a segnare il corso della storia del nostro strumento preferito di web analytics: il team ha appena annunciato sul blog ufficiale il prossimo rilascio dei Content Experiment, e la contestuale sparizione di Google Website Optimizer.
Con il passare degli anni le richieste più pressanti al team di Google Analytics sono state quelle relative all’integrazione con gli altri prodotti Google destinati agli advertiser, ai webmaster o agli editori: prima fu AdWords, ovviamente, poi Adsense, poi Feedburner (anche se il risultato ancora oggi lascia un po’ a desiderare…), poi Webmaster Tools (e anche lì c’è molto spazio per migliorare!). Il grande escluso di questa lista, benché fosse il più naturale candidato al matrimonio (ne parlavo qui e qui), è stato fino ad oggi Google Website Optimizer, lo strumento dedicato ai test A/B e ai multivariati; uno strumento cioè in grado di prendere due versioni della stessa pagina, o due o più elementi della stessa pagina, e aiutare a decidere quale delle due fosse più funzionale al raggiungimento di un determinato obiettivo.

Benché non fossi affatto un esperto di GWO, ho assistito negli anni al susseguirsi di una serie di istruzioni dedicate a chi volesse integrare i due strumenti: codici aggiuntivi, funzioni apparentemente slegate dal contesto da aggiungere al tracciamento, uso di variabili personalizzate. Quando la nuova funzione Content Experiment sarà disponibile tutto questo sarà un ricordo! i vantaggi principali dei content experiments infatti sono:

• strumento guidato di setup, che aiuta passo-passo nella creazione del test
• uso del codice di Analytics già presente sulla pagina, meno javascript da caricare, meno modifiche al codice
• determinazione automatica del vincitore, quando viene raggiunto un adeguato intervallo di confidenza
• un test richiederà almeno 2 settimane, e non oltre 3 mesi
• le variazioni con performance scarsissime saranno automaticamente scartate dall’esperimento in corso d’opera, in modo da rendere più significativi i risultati per le restanti varianti

Il vantaggio di fare tutto questo direttamente dentro a GA è ovviamente quello di poter legare i dati degli esperimenti a tutti gli altri presenti nei nostri report, poter usare la segmentazione, e avere le altre metriche a disposizione, e sono poi i motivi per cui sono anni che si chiede a gran voce l’integrazione. A partire dal 1 agosto inoltre, Google Website Optimizer in versione stand-alone smetterà di essere accessibile. L’altro svantaggio è che al momento i content experiment supportano solo gli split test A/B con 5 varianti oltre alla pagina di controllo originale: niente test multivariati
Quando tutto questo sarà visibile? “nelle prossime settimane”, ovviamente 🙂

(altri post che ne parlano: Daniel Waiseberg, Roi Revolution)

Sono incappato in un interessante post su customreportsharing.com: quali sono i limiti assoluti, intesi come imposti dalla piattaforma o dagli ingegneri di Google, di Analytics? Ecco le risposte che sono uscite fuori:

100 account (200 per gli account certificati, qualsiasi cosa voglia dire)
50 profili per account

500 richieste alla gif per sessione
10 richieste massime in 5 secondi
5 variabili custom per ogni richiesta (ma sono 50 per GA Premium)

256 caratteri nei filtri di visualizzazione
4 segmenti avanzati massimi contemporaneamente (sono 8 solo col confronto temporale)
5 tab per ogni custom report
5 gruppi di metriche per custom report
5 dimensioni annidate per custom report
5 filtri per ogni custom report
10 metriche per ogni gruppo di metriche nei custom report
50 caratteri massimi per il nome di un custom report, per il nome di un gruppo di metriche, per il nome di una tab
500 il numero massimo di righe esportabili per ogni report (ma esiste un trucco e lo sappiamo…)

80 è invece il massimo numero di caratteri nel nome di un alert personalizzato

256 caratteri massimo per il nome di un GOAL
20 goal per profilo
5 gruppi di goal per profilo
5 goal per gruppo
10 passaggi al massimo per ogni funnel che precede un GOAL
99999999999999999999999999999999 è invece il valore massimo che si può attribuire a un GOAL 🙂

sembrerebbe non esistere, o non è stato trovato, un limite alle condizioni che si possono impostare nella definizione di un segmento avanzato

12 widget per ogni dashboard
(20 dashboard per profilo, ne sono quasi certo anche se non è elencato nel post)
65536 caratteri massimi nel nome di una dashboard

50000 visite al giorno (in realtà non è un limite, ovviamente: l’help dice che se si inviano più di 50000 visite al giorno si perde l’elaborazione delle informazioni continua ed essa viene fatta una volta al giorno, alle 12:00 UTC (le 2 del mattino pomeriggio in Italia), e il processo dura circa 10 ore)
10 milioni di hits alla gif al mese – PER ACCOUNT

50000 richieste al giorno per ogni progetto che usa le API
10 query al secondo per IP
4 richieste contemporanee dallo stesso IP
non più di 10 richieste al secondo per IP per TUTTE le Google API insieme
10000 richieste al giorno per profilo
10 richieste contemporanee per profilo

Mancano ancora informazioni circa il numero massimo di custom report, di categorie di custom report, di alert per profilo e di utenti cui può essere dato accesso a un profilo. Per cui se siete incorsi in qualcuno di questi limiti, segnalatelo!

Quanti di voi, guardando il report in tempo reale, si sono domandati da quale isola o barca provengono quelle visite che si vedono al largo delle coste tra la Nigeria e il Gabon? In effetti è vicino all’isola di Sant’Elena, e ad Ascensione, ma non corrisponde a nessuna delle due. Non è nemmeno Sao Tomé. Non si tratta di una piattaforma petrolifera, dalla quale tramite una connessione satellitare stanno visitando il vostro sito, e non si tratta nemmeno di una nave.

Siccome è un fenomeno che ho rilevato su moltissimi profili, ho sempre saputo che si trattasse di un errore di Google Analytics, ma non ho mai riflettuto abbastanza sul perché si presentasse. La risposta me l’ha data qualche tempo fa Alessandro Sinigaglia, con il quale si stavano guardando i report in tempo reale. “E’ la coordinata 0,0” mi fa, come se fosse la cosa più naturale del mondo. E ovviamente ha ragione. Il perché questo accada, con precisione non lo so tutt’ora: ma so che quando arriva una visita per capire da dove essa provenga Analytics guarda l’indirizzo IP e consulta il suo enorme geodatabase.
Per fare questa operazione nei “normali” tempi di elaborazione dei report impiega il tempo che ci vuole, per farla nei report real-time ha ovviamente molto meno tempo a disposizione, perché la visita deve essere mostrata subito all’utente: se per qualche motivo l’operazione non riesce, mi sono fatto l’idea che piuttosto che ritentare GA preferisca andare avanti, e gli assegni le coordinate di default 0,0, che poi la mappa mostra e visualizza correttamente.

Infatti per gli stessi report in cui si verifica il fenomeno non rilevo poi visite da Nigeria e paesi limitrofi, segno che si tratta solo di un problema col geocoder del real-time 🙂

Dato un ecommerce o un sito che utilizza il codice di tracciamento ecommerce che abbia anche impostato un GOAL alla thankyou page dell’ordine, il numero di acquisti effettuati sarà disponibile sia nel report delle transazioni sia nel report degli obiettivi. A questo punto, che differenza c’è tra il report Tempo all’acquisto (scheda visite) e il report Lunghezza percorso nei Multichannel Funnel?

Guardare al report Tempo all’acquisto, scheda Visite alla transazione nella sezione Ecommerce significa avere uno spaccato su quante visite sono occorse prima di una transazione a partire dall’ultima campagna registrata. E come ormai dovremmo sapere, questo equivale a dire “dall’ultima volta che il cookie __utmz è stato cambiato”

Il report Lunghezza percorso nelle Canalizzazioni multicanale invece ci indica quante visite sono state necessarie, negli ultimi 30 giorni, affinché la transazione abbia avuto luogo.
Vediamo un esempio pratico:

Nel periodo in oggetto registro 18 transazioni, e il report “Visite alla transazione” mi dice che 11 avvengono con 1 visita, 4 con 2 e 3 con 3. O meglio, quel che realmente mi sta dicendo è che 11 transazioni avvengono durante una visita in cui __utmz era stato cambiato, 4 avvengono alla seconda visita dopo l’ultimo cambio di __utmz e 3 alla terza.
come si presenta il report Lunghezza percorso nei Multi Channel Funnel per lo stesso periodo, e per lo stesso obiettivo? così:

Numeri completamente diversi, che mi indicano quante VISITE sono state necessarie per la conversione, a prescindere dai cambi di cookie, negli ultimi 30 giorni. L’ultima transazione ha richiesto ben 11 visite prima di convincersi a mettere mano al portafogli. Per comprendere ancora meglio la cosa, torniamo un attimo al report precedente. Quando è che il cookie __utmz non viene cambiato, e quindi non attiva il conteggio nel report Visite alla transazione? quando la visita è diretta (Google Analytics usa l’attribuzione last cookie non direct, ricordate vero?). Allora prendiamo il report dei percorsi di conversione nei funnel multicanale e…

… il numero di conversioni che avvengono durante una sessione “direct” è proprio 7, cioè le 4+3 del primo screenshot.

Escludendo i social-plugin, che richiedono un settaggio apposito sul sito, il bello dei nuovi report sociali è che si attivano da soli, senza bisogno di fare nulla. Nessuna azione è richiesta all’utente, e la magia si compie da sé. E allora che cosa è e a cosa serve quella tab che si vede accedendo all’Amministrazione di un profilo, quella tab chiamata IMPOSTAZIONI SOCIALI e che riporto nell’immagine in apertura?

Si tratta di una serie di campi (se ne possono aggiungere tramite il pulsante + posto alla destra del form) che permettono di AGGIUNGERE altre fonti da considerare nei social report. Cioè di URL che contengono contenuti sociali relativi al nostro sito. L’esempio che fa Google Analytics calza a pennello: il nostro canale youtube contiene sicuramente delle attività sociali, quindi è giusto farlo confluire nei report sociali. Ci sono però due cose da tenere a mente:

1. molto importante: come sottolineato anche dalla schermata di configurazione, se si inserisce uno o più URL in quel campo è necessario anche riportare l’indirizzo del sito tracciato. Questo perché per impostazione predefinita i report sociali tracciano il sito impostato nel profilo di GA, ma se andiamo a toccare questo settaggio allora lui vuole la lista completa degli URL; mi sembra abbastanza assurdo, ma al momento è così.
2. secondariamente: non immaginatevi di trasformare quei report in uno strumento di analisi della concorrenza. Non è che inserendo qualsiasi url i report sociali si popoleranno con i dati delle condivisioni e delle citazioni di quell’URL! ci ho sperato per un secondo anche io (ho provato a vedere cosa si diceva del sito nasa.gov 🙂 ), ma evidentemente non è così. L’help ufficiale ci viene in aiuto e recita “Activities data is only shown for properties from which your domain has received hits. (I dati delle attività vengono mostrati solo per le proprietà web dalle quali il vostro dominio ha ricevuto visite).

Vi eravate accorti di questa possibilità?

Ho promesso all’organizzazione di questo corso un aiuto per la diffusione: sebbene la maggior parte di voi siano uomini e donne “di marketing”, so per certo che c’è anche una fetta di utenti più tecnici che mi legge. A loro è rivolto questo corso, il prossimo 26 Maggio, un corso avanzato su Google Web Toolkit. Un’intera giornata formativa dedicata allo sviluppo di un’applicazione con GWT. Un corso pensato per chi ha già un minimo di conoscenze su Google Web Toolkit e vuole provare a sviluppare un’applicazione web partendo da zero.

Relatori saranno Alberto Mancini e Francesca Tosi fondatori del progetto Jooink finanziato da Telecom Italia e creatori del Google Technology User Group di Firenze (GTUG).

L’evento si terrà nella sede del Centro Adriatico Eventi ad Ascoli Piceno (mappa) e la partecipazione al corso ha un costo di 149€. Al termine del corso verrà rilasciato un attestato di partecipazione.

Per maggiori informazioni potete pure contattare me, che poi vi instrado verso gli organizzatori 🙂

Due giorni fa il team di Google Analytics ha pubblicato una nuova libreria, di cui Nick ci aveva dato un assaggio la settimana scorsa su Google+: questa libreria dovrebbe teoricamente rendere molto facile creare grafici con i dati di base, dovrebbe in qualche modo permettere alle persone di crearsi delle dashboard personalizzate da pubblicare, o da consultare senza dover accedere all’interfaccia di Analytics.

Dico dovrebbe perché ci ho giocherellato un po’, e nonostante abbia seguito le istruzioni (e provato anche a fare di testa mia), non sono riuscito a venirne a capo. Non mi reputo certamente un genio di javascript, ma non mi sento nemmeno un principiante: diciamo che se mi dicono che c’è una nuova “easy library” e c’è un esempio funzionante e del codice sorgente, mi figuro di poterci riuscire.

Comunque sia, la libreria è questa (si trova nella prima riga), l’esempio è nella stessa pagina. La demo funzionante di Nick si trova invece qui (avrete bisogno del numero di Table_ID).

Se qualcuno vuole cimentarsi e mi fa vedere una pagina funzionante, gliene sarò grato 🙂

I report in tempo reale, disponibili da qualche mese, sono un ottimo strumento a patto di sapere esattamente cosa farci. Per molti al momento sono ancora un passatempo ipnotico e divertente, in grado di dare uno spaccato istantaneo sul traffico sul sito e poco più, qualcuno invece li usa attivamente perché ha delle leve e delle possibilità di intervento immediate sul sito.
Quando ne parlo e mi vengono mosse delle critiche al sistema, non posso fare a meno di opporre l’argomentazione che lo sforzo da parte di Google è titanico: la potenza di calcolo per dare a tutti (dal blog con 5 visite al sito con un milione di pageview al giorno) le statistiche in tempo reale è impressionante! questo però non significa che anche io non speri che in futuro questi report non vengano migliorati, ad esempio inserendo informazioni sui goal o le transazioni, che sarebbe già un ottimo passo avanti.

Comunque sia, una cosa che i report in real-time possono già fare, ancorché in modo limitato, è la segmentazione: non la segmentazione avanzata cui siamo abituati, ma una blanda segmentazione in grado di farci percepire meglio un determinato gruppo di visite. Per accedere ai report segmentati è sufficiente cliccare uno dei link presenti nei report, è molto semplice. Ad esempio partendo dal report real-time “sorgenti di traffico”, e cliccando “organico” e poi “ask” (se ce l’avete), otterrete lo stesso report solo per coloro che in questo istante sono giunti sul sito tramite parole chiave sul motore di ricerca ASK. La cosa è mostrata graficamente tramite due rettangoli presenti sopra al report, così:

Una volta selezionato un segmento, esso sarà mantenuto anche cambiando report, ad esempio passando alle località o alla panoramica, e per modificarlo sarà sufficiente rimuovere una o più condizioni tramite le X poste sulle dimensioni – che però curiosamente sono indicate in blu invece che in verde, al contrario dello standard di Google Analytics – oppure agire sul link “azzera”.

Ripeto, non è la stessa cosa che crearsi un segmento avanzato, ma è sempre meglio di niente! 🙂