Google Analytics in 30 secondi

Più di un anno fa vi feci un resoconto abbastanza dettagliato del panorama delle applicazioni Android per gestire Google Analytics. Da allora ogni tanto ho fatto una ricerca per vedere se ne fossero uscite di nuove, ed effettivamente qualcuna nuova c’è stata, ma nessuna mi soddisfava.

L’altro giorno invece ho testato – e comprato – Analytix for Google di Folkert, perché rappresenta qualcosa di nuovo, per certi versi differente dal resto del panorama della applicazioni Android per Google Analytics. L’applicazione è disponibile in versione trial (versione di prova) menomata di alcune funzioni, e in versione completa al costo di 99 centesimi di euro.
La mia recensione è riferita alla versione completa.

La grafica dell’applicazione è molto pulita ed essenziale, e il fatto che non presenti nemmeno un arancione – colore tipico di GA – la rende diversa dalle altre. All’apertura, dopo aver autorizzato l’applicazione ad accedere al nostro account Analytics, ci sono tre opzioni: my accounts, (my favorites se ne abbiamo selezionati), preferences e info. La prima serve ovviamente per accedere ai dati, e la vedremo tra un attimo, preferences permette di personalizzare l’applicazione; ad esempio si può decidere se avere subito i profili preferiti selezionabili (non si tratta di quelli contrassegnati da una stellina su GA, l’app ha una sua gestione interna dei preferiti), o se iniziare con un profilo specifico invece della lista. Si possono decidere quali tab avere a disposizione nell’applicazione (e sono tante, ve l’assicuro), il numero di risultati da mostrare per default, la data finale e quella iniziale per determinare il periodo di reporting, e se permettere o meno l’uso del giorno corrente.

A margine dirò che è disponibile anche un widget per le schermate home, basato sui profili preferiti, in grado di dare il “polso della situazione” in tempo quasi reale sull’andamento di alcuni parametri del proprio sito: il widget predefinito mostra ad esempio le visite, le pagine viste e i visitatori di oggi e di ieri.

Se dalla home selezioniamo “my account” avremo la lista degli account cui abbiamo accesso, e da lì potremo finalmente arrivare a un profilo. Le tab disponibili sono:

• dashboard: riassume i principali indicatori
• charts: grafici a barre per visite, visitatori, nuovi visitatori, bounce rate, pagine viste, tempo medio sul sito, transazioni, revenues e goal completati
• visits: indica giorno per giorno il numero di visite, visitatori, pagine viste, bounce rate. I dati (in questo report e nei successivi) sono sia testuali sia visuali, in modo da avere una buona comprensione dell’andamento già aprendo il report)
• top referring
• visit by country
• visit by region
• page routes: indica i numeri dei visitatori per ogni combinazione di pagina vista e la sua successiva
• search engines
• visitor engagement: è il numero di visite di ogni visitatore (è il report “fedeltà”)
• most popular: le principali pagine viste
• keywords
• top landing pages
• problematic: sono le landing page con un alto bounce rate
• browser
• system information
• connection speed (che in realtà è deprecato per GA)
• newtork information
• mobile traffic
• conversion rate: conversioni per sorgente
• revenues
• revenues by type: elenco dei prodotti e delle revenue generate
• social revenues: revenue con sorgente uguale a una lista di social network non editabile
• social pageviews: pagine viste da parte di utenti provenienti dai social di cui sopra

Ne esistono anche altre, che però vanno abilitate tramite le opzioni dell’applicazione:

• android pageviews
• android events
• ad click: report sui costi adwords
• matched query: sempre relativo ad Adwords, è la keyword realmente cercata
• total events
• event categories
• event actions
• event labels

Per definizione la schermata si apre con il confronto tra oggi e ieri, ma tramite uno slider possiamo far comparire già dalla dashboard una diversa data per il confronto: 3 giorni fa, una settimana fa, un mese fa, 3 mesi fa, un anno fa. Il giorno corrente viene evidenziato in rosso, mentre il periodo passato è grigio, in questo modo è abbastanza facile capire se la performance è migliore o peggiore (o nel caso si stia analizzando il giorno corrente, se l’outlook a fine giornata è positivo o no). La selezione delle possibili tab si fa scorrendo verso destra la lista: non molto intuitivo, ma ci si prende subito la mano.

Tra tutte le applicazioni per GA che ho provato, devo dire che Analytix si è subito ritagliata un suo importante spazio: per soli 99 centesimi dà accesso a moltissimi report, molti più delle altre applicazioni, e inoltre mi sembra un pezzo di software scritto come si deve (c’è addirittura un’opzione per evitare di inviare al Google Analytics dello sviluppatore informazioni sull’utilizzo ricavate tramite la Android SDK per GA!). Anche la presenza di un sito dedicato gioca a suo favore. Per me è un acquisto decisamente consigliato, nonostante sia necessario prendere un po’ la mano con i controlli dell’interfaccia prima di poterla sfruttare al 100%

[image credit: appbrain.com]

Il titolo è una domanda perché non ho sicurezza che sia una novità. In effetti il report recency non è uno di quelli che guardo più spesso, per cui quando oggi l’ho aperto (e parlo ancora della versione “vecchia” di Google Analytics, non della v5) mi sono stupito di trovarlo così:

Ovvero con l’indicazione separata di quanti fossero alla prima visita (il numero corrisponde ai nuovi visitatori) e di quanti siano tornati lo stesso giorno della prima visita. Due numeri che prima erano affogati all’interno della riga “0 giorni fa“, che infatti adesso è sparita (e se la vedete ancora nei report, come mi accade su alcuni profili, riporta esattamente la somma dei due valori precedenti).

Mi sembra una indicazione utile, ma ripeto non ho coscienza di quando abbiano fatto questa modifica. Lo so che ultimamente perdo colpi, ma so anche che voi siete attenti e mi saprete aiutare 🙂

[in questo periodo sono talmente impegnato che ho dimenticato il terzo compleanno di questo blog! il 22 maggio 2011 🙂 ]

Da qualche tempo a questa parte Facebook ha dato la possibilità di inserire sulle proprie pagine dei frame contenenti sorgenti esterni, ad esempio pagine ospitate sul nostro dominio, o pagine del nostro sito esistente. Questo porta alla non trascurabile possibilità di “iniettare” Google Analytics per tracciare cosa accade lì sopra; in passato avevamo già visto alcune soluzioni per provarci, ma erano tutte poco pratiche e anche piuttosto inefficaci a causa di problemi tecnici in larga parte attribuibili a Facebook stesso.

Inserire un frame con una pagina che possiede il necessario codice di GA invece porta al risultato atteso: si può tracciare l’interazione tra gli utenti e il contenuto del frame (ma non ad esempio con quel che accade in bacheca). Per farlo è necessario usare come sorgente del frame una pagina che contenga il nostro codice di Google Analytics, magari dopo aver creato un profilo-copia che include solo le pagine del frame per poterle analizzare in dettaglio. Se state usando lo stesso codice del sito, ad esempio, i cookies saranno i medesimi quindi GA sarà in grado di riconoscere gli utenti e tracciarli come di ritorno, di conteggiare gli unici, eccetera.

Esiste una modifica interessante, che ci suggerisce Lunametrics, e che riguarda le fonti di traffico; se stiamo usando Facebook come landing page di una campagna (ad esempio una pagina tipo apps.facebook.com/my-app-name), usaremo i soliti tag delle campagne per valorizzare correttamente la sorgente di visita.
Se stiamo mandando gli utenti alla pagina con il frame (un tab di un profilo, ad esempio), Facebook oscura il referrer e non lo rende disponibile al frame, per cui sarà sempre qualcosa del tipo static.ak.facebook.com/platform/page_proxy.php. Il workaround consiste nel creare una pagina sul sito con un redirect al tab di Facebook, e impostarlo come landing page della campagna con gli appositi tag delle campagne. Su questa pagina prima di fare il redirect vero e proprio è necessario eseguire il codice di Analytics. Aggiungere poi la funzione _addIgnoredRef(“static.ak.facebook.com”) al GATC della pagina contenuta nel frame.

In questo modo il cookie __utmz viene impostato quando si è ancora sul nostro sito, e ha i parametri corretti, poi quando si arriva su Facebook esso non viene aggiornato per via della funzione addIgnoredRef.

Un po’ macchinoso, forse, ma ingegnoso! 🙂

Per lavoro mi occupo di siti per la pubblica amministrazione, e per questo motivo mi sono trovato davanti agli occhi la versione 11 maggio 2011 delle linee guida per i siti web della PA. Mentre mi addentravo nella lettura mi è caduto l’occhio su questa pagina del capitolo 4 e in particolare sulla nota a fondo pagina

[21] Si raccomanda di considerare, per le statistiche web, un visitatore unico ogni 30 minuti per IP.

La cosa ovviamente non ha senso: un visitatore unico prescinde da un intervallo di tempo, e di sicuro se io faccio una visita di un’ora e mezza non sono tre visitatori, ma uno solo. Inoltre sono anni che si dice che basarsi sugli IP è arcaico, perché le visite aziendali fatte da dietro a un proxy (ma anche gli accessi dalla rete geografica di Fastweb) vengono “annegati” dietro a un unico indirizzo. Migliaia di persone che risultano come una sola, che però ogni mezz’ora va conteggiata come fosse un’altra :-/

Perché – mi direte voi – una scelta così palesemente sbagliata? non lo so, ma di sicuro fa il paio con quanto scritto nel paragrafo “Policy” a proposito dei cookies, che sarebbero la soluzione al problema di cui sopra:

…né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. [omissis] L’utilizzo di cookies permanenti deve essere strettamente limitato all’acquisizione di dati statistici relativi all’accesso al sito e/o per mantenere le preferenze dell’utente (lingua, layout, etc.)

Due frasi in antitesi tra di loro: da un lato sembrerebbe che non si possano utilizzare cookies per il tracciamento, ma per le statistiche si. Ma allora se posso utilizzare i cookies, perché definire gli unici attraverso gli IP?

Infine, tanto per non farsi mancare nulla, le linee guida impongono che i dati del monitoraggio vengano pubblicati periodicamente. Tralasciamo un attimo il fatto che se ogni PA usa un sistema di web analytics differente, i dati non saranno mai confrontabili, e concentriamoci su un altro aspetto: i tre dati da pubblicare sono (sic!) pagine viste, sessioni utente (visite) e visitatori unici.

Solo che, se non si da un intervallo di tempo, parlare di unici non ha senso, per il noto “problema dell’hotel“. Alla linea guida manca fondamentalmente l’indicazione del periodo di tempo da considerare per l’indicazione degli unici. Ogni mese si deve dare il totale annuale degli unici, oppure ogni mese si deve dare il numero di unici del mese precedente?

Molte persone col tempo dimenticano che le espressioni regolari, comprese quelle che si usano dentro a Google Analytics, funzionano per i caratteri, e non per i numeri. Anzi, per dirla meglio, i numeri vengono trattati come caratteri invece che come cifre.

Per questo quando diciamo che l’espressione regolare [0-9] identifica “tutti i numeri da 0 a 9” diciamo una verità e ne sottindendiamo un’altra: essa identifica SOLO i numeri da 0 a 9. Per cui se voglio fare una espressione regolare che prenda da 0 a 39 non posso scrivere [0-39]. Se scrivessi così intenderei qualcosa che intercetta solo numeri di due cifre, la prima delle quali può essere 0, 1, 2 oppure 3 e la seconda delle quali è sicuramente (e solamente) un 9 un numero di una sola cifra, 0, 1, 2, 3 oppure 9 (tnx to Enrico Altavilla per la correzione).

La regular expression per intercettare tutti i numeri da 0 a 39 è un’altra:

[0-3]?[0-9]
^[0-9]$|^[1-3][0-9]$

(o un numero singolo da 0 a 9 oppure un numero di due cifre la cui prima può essere 1, 2 o 3 e la seconda può andare da 0 a 9).

Le cose si complicano ancora di più quando le cifre non sono “tonde” (chiamo tondo il 39 perché comunque si vuole intercettare tutta la decina dei trenta ed escludere dai quaranta in poi), ad esempio se si vuole fare il match da 0 a 33. La regex diventa

^([0-9]|[1-2][0-9]|3[0-3])$

praticamente la scomposizione dei numeri: “da 0 a 9, oppure da 10 a 29, oppure da 30 a 33”. Un po’ verboso, ma funziona così 🙂

Dopo qualche segnalazione di malfunzionamento il team di Google Analytics è riuscito a riprodurre l’anomalia e ad individuare le cause di un baco che mostrava zero visite in alcuni custom report, segmenti avanzati e dimensioni secondarie, quando si guardava ai dati di Aprile.
Non ci è dato sapere perché, ma il post ufficiale ci informa che stanno lavorando alacremente per risolvere il problema; quindi non possiamo fare che attendere speranzosi…

[edit 12/5: tanto piccoli i problemi non devono essere, tanto è vero che la risoluzione prevista, ad oggi, è per il 23 maggio.

We expect to resolve the problem affecting a majority of users of Web Report at May 23, 2011 11:00:00 PM PDT. Please note that this time frame is an estimate and may change.
We are now able to provide a tentative date for resolution of the issue with April data in Advanced Segments, Custom Reports and secondary dimensions of May 23rd. We will continue to update the status dashboard as more information becomes available.

Sarei tanto curioso di capire esattamente cosa è successo, per “incasinare” così a fondo le cose… ]

Morto un papa se ne fa un altro, recita il detto; ed ecco che tolto il report velocità di connessione, arriva “velocità del sito”, come annunciato dal blog ufficiale.

Il nuovo report è disponibile soltanto nella versione v5, che è accessibile a tutti tramite il link rosso in alto nell’interfaccia, ed è utile per capire quali sono i tempi di caricamento delle nostre pagine. Poiché in Google spingono pesantemente su questo aspetto (il codice di Adsense è passato ad asincrono, quello di GA lo era già, Chrome dispone di uno strumento nativo bellissimo per comprendere i tempi di caricamento, da poco hanno rilasciato Page Speed Online…), molti di voi avevano correttamente pronosticato che il sostituto del vecchio report sulla velocità di connessione sarebbe stato qualcosa di simile.

Tecnicamente si tratta di aggiungere una funzione al codice di tracciamento, la funzione _trackLoadPageTime, chiamandola senza passargli valori dopo aver chiamato _trackPageview, in questo modo:

<script type="text/javascript">
 var _gaq = _gaq || [];
 _gaq.push(['_setAccount', 'UA-XXXXX-X']);
 _gaq.push(['_trackPageview']);
 _gaq.push(['_trackPageLoadTime']);

 (function() {
   var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
   ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
   var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
 })();
</script>

Dopo aver fatto questa modifica il report “velocità del sito”, che si trova sotto il gruppo CONTENUTI, inizierà a popolarsi con i dati, mentre prima mostrerà soltanto dei laconici zeri. Poiché la nuova funzione effettua un’ulteriore chiamata alla gif __utm.gif, anche se essa è presente in tutte le pagine non invierà dati per ogni pagina vista, ma effettuerà un invio a campione (e adesso è anche chiaro a cosa servisse il contatore interno alle chiamate UTMS: non puoi randomizzare le chiamate se non c’è un contatore 🙂 ), per cui analizzando le richieste che partono dal codice di monitoraggio sarà perfettamente normale non vedere sempre due richieste.

Nel blog ufficiale c’è anche un link ad un custom report già pronto che potrebbe risultare utile: Site Speed Custom Report (il link porta direttamente al custom report pronto da salvare, dovete essere loggati a Google Analytics per vederlo); si tratta di un report che usa come metriche Visite, Rimbalzi, Tempo di caricamento medio e Campione per il caricamento, e come dimensioni Browser e Pagina.

Tempo di caricamento medio è il tempo, espresso in secondi, che una pagina impiega per caricarsi, dalla prima chiamata a quando il browser considera completato il caricamento.
Campione per il caricamento indica il numero di pagine viste utilizzate per calcolare il dato precedente, in modo che sia chiaro l’indice di confidenza espresso.

Poiché ovviamente tutto è segmentabile, le possibilità sono infinite: ad esempio si potrà finalmente capire se l’alto tasso di uscita da una certa pagina è dovuto o no all’alto tempo di caricamento della stessa. O se il tasso di rimbalzo di una certa campagna AdWords è dovuto alla lentezza della relativa landing page.

Ora che – finalmente – Google Shopping è sbarcato anche in Italia, molti si stanno ponendo la fatidica domanda: “come traccio il tutto su Google Analytics?”. Domanda legittima, per capire l’impatto sul traffico di un nuovo motore di ricerca verticale – peraltro presente anche tra le opzioni della ricerca “classica”, e per determinare il ROI dell’effort richiesto a far sì che i nostri prodotti siano nelle liste del motore.

Poiché purtroppo non ho siti miei o di clienti listati in Product Search, e che quindi non ho modo attualmente di verificare direttamente la bontà di questo metodo, devo allora affidarmi ad una soluzione già confezionata, che però dovrebbe funzionare: la scrisse qualche mese fa il blog state of search. Sostanzialmente si tratta di aggiungere un filtro personalizzato avanzato:

Campo A -> Estrai A
Referral -> google\.it\/products

Campo B -> Estrai B
Mezzo -> organic

Output in -> Constructor
Sorgente -> Google Shopping
Campo A richiesto: si
Campo B richiesto: si
Sovrascrivi campo output: si
Maiuscole/minuscole: no

Sostanzialmente, poiché non si cambia il mezzo che resta organic, GA capisce da solo che si tratta sempre di un motore di ricerca, e lo processa esattamente come Google classico, estraendo la keyword usata dal parametro “q”, ma noi cambiamo la sorgente e la isoliamo dal resto modificandola in “Google Shopping”. Questo ci permette di avere al volo la possibilità di isolare le visite provenienti dal motore verticare e capire quali keyword sono state usate, per quali prodotti, su quali landing pages, eccetera…

[edit: come mi fa notare @gpelagatti, si possono anche impostare i normali URL con i parametri delle campagne; non l’ho scritto perché avevo idea che essendo una campagna Analytics non estraesse la keyword usata dal visitatore per trovare il prodotto, ma il suo screenshot è eloquente e mi sbagliavo: a questo punto, dato che siamo nella sperimentazione, varrebbe la pena di provare a impostare i parametri taggati mantenendo “organic” come medium e “google.it” come source, e cambiando solo il campaign. Oppure, come discusso con Tommaso Galli, impostare “organic” come medium, “google-shopping” come source e campaign a piacimento, e vedere se GA lo tiene nei motori di ricerca e mantiene la keyword.

In ogni caso, grazie a entrambi per gli punti 🙂 ]

Ho tradotto letteralmente il titolo dell’ultimo post di Eric Peterson sul suo blog personale all’interno di web analytics demystified, in cui sostiene di avere notizia che Google starebbe per rendere a pagamento Google Analytics per la cifra di 100 dollari l’anno. La notizia-bomba sarebbe che il costo sarebbe applicato a tutti, e non solo a chi desiderasse un servizio con migliorie.

Eric si concentra in particolare su due punti: dato l’altissimo numero di installazioni di GA, la revenue per Google sarebbe altissima. Considerando il costo della banda e dello storage necessari ad assicurare a tutti il funzionamento di Analytics, sarebbe una manna dal cielo e consentirebbe a BigG di diversificare le entrate dal solo settore search. Dal canto mio posso immaginare che il numero così alto di installazioni (ricordiamo che si tratta del prodotto di web analytics più usato del pianeta) è dovuto anche – o soprattutto – alla gratuità del prodotto.
Il secondo punto è che questa mossa favorirebbe tutta una serie di altri produttori di sistemi di analisi dei dati, Eric cita Kissmetrics, Woopra, Clickly eccetera; sarebbe una specie di ottimo paretiano: Google guadagna e gli utenti persi da Google Analytics andrebbero a far guadagnare altri produttori di sistemi. Però Eric stesso dice, un paragrafo più avanti, che grazie alle caratteristiche di questi prodotti, che per forza di cose dovendosi distinguere dal principale player spingono su caratteristiche che a lui mancano) stanno già facendo affari d’oro nonostante il fatto che GA sia gratuito.

Come spesso accade la discussione più interessante è però nei commenti. Tale Judah dice che per essere “profittevole” – e immagino non intenda aritmeticamente – GA dovrebbe portare nelle casse di Google 200-300 milioni di dollari l’anno, ma che questo volume può essere fatto semplicemente caricando i 100$ solo sulla clientela enterprise, in cambio di alcune doverose concessioni (meno limiti? un livello di servizio certificato? assistenza?).

Il mio punto di vista è senz’altro concorde con la maggior parte dei commenti, sono cioè per l’adozione di un modello “freemium”: quel che c’è resta così e resta gratis, eventualmente si introdurrà una versione a pagamento con apposite funzioni aggiuntive. Mi sembra la soluzione meno traumatica e quella che consentirebbe di non distruggere il “momento d’oro” che la web analytics sta vivendo anche – o forse soprattutto – grazie alla spinta che Google Analytics dà al settore in quanto strumento gratuito.
Da non sottovalutare tuttavia anche il commento di Tim Wilson, che sottolinea come spesso 10.000 sia meglio di 100. Fin tanto che è gratis e chiunque lo può installare, va bene. Se costasse 100 dollari qualcuno dovrebbe mettere mano ad una carta di credito, scatenare un ufficio acquisti, registrare una transazione. A quel punto qualcuno, specialmente nelle grandi aziende, obietterebbe qualcosa del tipo “possiamo avere dati di livello enterprise per soli 100 dollari l’anno? c’è qualcosa che non torna”, e vi garantisco che questo punto non va affatto sottovalutato.

Ma comunque, tanto per tornare alla domanda iniziale: voi li paghereste 100$ l’anno per Google Analytics?

Se anche voi come me siete vittime del debug “fai da te” e non passate un giorno senza dare un occhio agli header HTTP che Google Analytics invia ai server collettori, forse avrete notato che c’è un nuovo parametro nelle richieste, il parametro utms. Le nuove richieste della .gif si presentano così

/__utm.gif?utmwv=4.9.2&utms=1&utmn=761092721&...eccetera...

quel parametro utms fino a qualche tempo fa non c’era, e infatti non è documentato da nessuna parte. Ho già lasciato un quesito sul forum ufficiale, ma finora nessuno ha risposto. Il numero in effetti cambia ad ogni richiesta (pagina, evento, eccetera), ed ho notato che si comporta così:

• All’interno della stessa sessione di visita, ogni nuova richiesta della .gif lo incrementa di uno. quindi se avete due codici di monitoraggio farete due richieste della gif, una con utms=1 e una con utms=2, se dopo inviate 5 eventi avrete utms=3, poi 4 e così via
• Se nel frattempo aprite un’altra scheda e navigate un altro sito – che abbia il codice di monitoraggio di GA, ovviamente – per le richieste fatte da quel sito utms riparte da 1

Mi sembra sia una specie di contatore delle richieste inviate per sessione, infatti chiudendo il browser e navigando un sito già visto utms riparte da 1. Perché? come forse saprete, esiste un limite di richieste per sessione oltre le quali i dati sono ignorati da Google Analytics e attualmente questo limite è di 500 richieste per sessione; ovviamente l’onere di verificare quante richieste sono state fatte per sessione spetta al server che analizza i dati, mentre inserendo un contatore lato client semplicemente si eviterebbero di inviare le richieste in eccesso, scaricando il server da questo lavoro. E’ solo una mia supposizione, ma al momento non vedo altri indizi che mi facciano puntare verso altre teorie.

[edit: in realtà non ci voleva poi molto a verificarlo 😀 ho impostato un javascript affinché registrasse un evento ogni secondo, e arrivati a utms=500 non è partita più nessuna richiesta della GIF. Il codice di Google Analytics ha smesso di inviare richieste ai server]