Google Analytics in 30 secondi

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!

Qualche mese fa scrissi un post (aggirare il limite dei 50.000 URL giornalieri) con una tecnica per venire a capo di situazioni in cui si vuole analizzare il report delle pagine ma si ha a che fare con siti che inviano più di 50 mila diverse pagine al giorno.
Il problema in realtà si presenta per qualsiasi dimensione: 50 mila è un limite invalicabile del processo di precalcolo dei report di Google Analytics. Nessun dato viene perso, sia chiaro, semplicemente i dati relativi alle eccedenze vengono memorizzati ma mostrati aggregati sotto la riga (other). Ce lo spiega Nick Mihailovski su Google+.

Però… c’è un però. Il limite interviene nel precalcolo dei report, cioè nei report che GA calcola normalmente e che ci mostra quando apriamo il prodotto. Esistono situazioni in cui il motore di Analytics calcola i dati al volo, ad esempio quando creiamo e/o applichiamo un segmento avanzato, che di norma non può essere precalcolato perché dipendente da infinite combinazioni.
Per questo motivo Nick semplifica l’intuizione dei ragazzi di Tatvic di cui vi parlai a Ottobre, e la rende il classico uovo di Colombo: se creiamo un segmento avanzato che intercetti TUTTE le visite, il motore è costretto a interrogare il database e a mostrarci anche quel che c’è dentro ad (other). Ad esempio un segmento così

(INCLUDI – Tipo di visitatore – con espr. reg – .*)

è nominalmente la stessa cosa che applicare il segmento TUTTE LE VISITE, ma essendo un segmento avanzato costringe GA a interrogare il database e a fornirci quel che cerchiamo.

Il limite superiore di questa tecnica è il limite del campionamento: se in dato periodo abbiamo più di 50.000 record per la dimensione, possiamo applicare questo trucco purché l’interrogazione non coinvolga più di 500.000 visite, poiché altrimenti interverrebbe il campionamento.
Spero che vi possa essere utile nelle vostre analisi. E grazie Nick! 🙂

Su Twitter scherzando ho detto che non riesco a star dietro a tutti gli aggiornamenti che il team fa al prodotto, ma pensandoci meglio in effetti tanto scherzo non è… 🙂
Fatto sta che ieri hanno annunciato alcune migliorie ai report sui flussi di visitatori.
La prima novità sono i flussi di eventi, e rappresentano sequenze di eventi che i visitatori eseguono, al pari delle sequenze di pagine che vedono. Se ad esempio avete tracciato il vostro video player con gli eventi, potrete vedere le sequenze di play, pause, stop, eccetera che vengono fatte su di esso.
Seconda novità: la comparazione temporale tra flussi di visite: questa me l’aspettavo, perché se i flussi aiutano ad ottimizzare l’esperienza dell’utente, la comparazione temporale è il miglior modo per analizzare se le modifiche hanno avuto successo o meno. Sostanzialmente aggiunge le percentuali di variazione nei nodi dei vari flussi, evidenziando ovviamente in verde quelle positive e in rosso quelle negative. Non solo, la comparazione viene effettuata anche sulle singole interconnessioni tra i nodi, e anche sugli abbandoni!

Infine, come se non bastasse, i goal flow adesso supportano anche gli obiettivi di engagement come tempo sul sito o profondità della visita.

Negli ultimi giorni c’è stata una grande accelerata nel rilascio di quelle migliorie che preludono il passaggio definitivo alla versione v5 di Google Analytics: il grande mantra di questi mesi è sempre stato “non faremo sparire la v4 fino a che tutte le sue funzionalità non siano passate alla v5”. E quindi abbiamo assistito prima a un piccolo redesign dell’interfaccia, con contestuale re-introduzione della condivisione di segmenti, custom report e dashboard, poi alla comparsa in alcuni account dei pulsanti “esporta in PDF” e “invia per email” (ad esempio Sebastiano Montino ce li ha, io ancora no 🙂 ).

La novità di oggi è che nella panoramica degli account sono tornate le stelline per selezionare solo i profili preferiti, e soprattutto una feature chiesta a gran voce da moltissimi utenti: la presenza dell’andamento dei profili direttamente nella panoramica. guardate questo screenshot (clic per ingrandire)

[edit: dopo poche ore quella visualizzazione è scomparsa. forse un test, forse è stata ritirata prima di andare live per tutti. vedremo nei prossimi giorni]

Non si può cambiare il periodo selezionato come nella vecchia versione (è bloccato sugli ultimi 30 giorni comparati ai precedenti 30), ma è comunque utile. E ora che lo rivedo, capisco quanto ne sentissi anche io la mancanza 🙂

Direi che non manca più molto al “pareggio” delle funzionalità e quindi all’abbandono della vecchia interfaccia. Decisamente in ritardo – fu annunciato il 2 novembre – ma comunque meglio tardi che mai. Vi ricordo anche la mia pagina radar, per essere sempre aggiornati sullo stato degli upgrade

Il problema delle keyword (not provided), non fornite da Google per gli utenti che fanno ricerche mentre sono loggati, è destinato ad aggravarsi nei prossimi giorni, con la progressiva adozione della “censura” anche nelle declinazioni nazionali del famoso motore di ricerca.
Per fortuna non ho ancor avuto modo di scontrarmi con profili con alti numeri di keyword nascoste, ma siccome nella vita non si può mai sapere, vi segnalo questo post di Ani Lòpez che descrive un metodo per “spalmarle” proporzionalmente sulle chiavi branded e su quelle non-branded. Rispetto all’approccio “non tocco niente e considero le (not provided) come una terza categoria di chiavi”, il metodo di Ani ha il vantaggio della semplicità – ci sono due formule sempre uguali da applicare – e lo svantaggio che al crescere della percentuale di (not provided) sul totale diminuisce l’affidabilità del sistema.

Se volete cimentarvi, le formule sono quelle illustrate in figura

mentre in calce al suo post trovate anche un link ad un foglio Excel già pronto dove dovrete soltanto immettere i dati.

Questo post vale un po’ come aggiornamento del vecchio post “comprendere in pieno il tempo sul sito“, ed è in realtà una traduzione pressoché totale di un post di Justin Cutroni: lo faccio perché è spiegato bene ed è esaustivo sulla vicenda:

Capire le “engagement hits”

La chiave per comprendere come GA calcoli gli intervalli di tempo è capire i dati che vengono inviati a Google. Ci riferiamo a loro affettuosamente come “HITS”. Lo so, è un termine terribile da usare quando si parla di web analytics, ma sono proprio hits.
Le hits in Google Analytics sono le richieste alla __utm.gif. Ce ne sono sei diversi tipi possibili:

• Pagine viste
• Eventi
• Transazioni Ecommerce
• Singoli prodotti Ecommerce
• Dati definiti dall’utente (gli antesignani delle variabili personalizzate)
• Richieste generate dai social plugin

Sebbene queste siano tutte le possibili richieste, non tutte sono “engagement hits”. Con questo termine ci si riferisce a richieste non contrassegnate come “non interattive” e non contenenti esclusivamente dati definiti dall’utente. Filtrando la lista di prima con questa nuova informazione, ci ritroviamo con cinque tipi di engagement hits:

• Pagine viste
• Eventi che non siano non interattivi
• Transazioni Ecommerce
• Singoli prodotti Ecommerce
• Richieste generate dai social plugin

Ti starai domandando “e questo che c’entra con i calcoli sul tempo?” Molti sistemi di web analytics usano il tempo trascorso tra le pageviews per tracciare il tempo. Google Analytics usa gli engagement hits per avere un quadro più dettagliato e preciso del tempo sulle pagine e sul sito.

come è calcolato il tempo sulla pagina
Il tempo sulla pagina è calcolato in due differenti modi, e il calcolo dipende dal fatto che la visita abbia una sola o più pagine viste

Quando ci sono più pagine viste
è piuttosto facile da capire, il calcolo è basato sulla differenza di timestamp tra la richiesta alla pagina successiva e quella corrente. Ad esempio

facile no? Molti sistemi di web analytics lavorano in questo modo, ma questo porta a qualche problema: non possiamo calcolare il tempo sull’ultima pagina, perché non ce n’è una successiva da cui sottrarre il timestamp. Ma di questo ne parliamo dopo.

Quando c’è una sola pagina
Molte persone credono che Google Analytics non possa calcolare, e non calcoli, il tempo trascorso sulla pagina quando essa è l’unica della visita; questo è solo parzialmente corretto. Se non c’è un’altra pagina vista nella sessione, Analytics usa il tempo trascorso tra l’apertura della pagina e l’ultimo engagement hits che segue quella pagina vista.

Tempo sulla pagina = timestamp dell'ultimo engagement hit sulla pagina - timestamp della pagina

Chiariamo, se una visita è di una sola pagina, Google Analytics può calcolare il tempo su quella pagina usando (se ci sono, ndMC) altri engagement hits. Se aggiungete molteplici engagement hits alla pagina, avrete una misurazione più accurata del tempo sulla pagina e sul sito, come mostrato ad esempio nella seguente figura:

Come è calcolata la lunghezza della visita
Anche la lunghezza totale della visita usa gli engagement hits per avere numeri più accurati. Invece di usare il solo tempo tra i timestamp delle pagine, la misurazione del tempo totale di una sessione include il tempo trascorso tra il timestamp della prima pagina vista (la landing page) e il timestamp dell’ultimo engagement hit disponibile nella sessione.

Tempo sul sito = timestamp dell'ultimo engagement hit della visita - timestamp della prima pagina vista

Vediamo un esempio reale: qui sotto abbiamo 3 pagine in una visita. Normalmente, se contassimo la lunghezza della visita basandoci solo sulle pagine viste ci perderemmo il tempo trascorso sull’ultima pagina. Ma siccome c’è un evento su di essa (e un evento E’ un engagement hit, ndMC) possiamo avere una fotografia più completa.

E’ importante sottolineare che in questo esempio Google Analytics userà l’engagement hit anche per calcolare il tempo trascorso sulla pagina di uscita. Nell’immagine #1 non era invece possibile perché non c’era nessun engagement hit dopo l’apertura di pagina 3. Nell’immagine #3 invece c’è un engagement hit sulla pagina di uscita, quindi GA è in grado di usare quel pezzo di informazione per calcolare il tempo.

E ricordate, ci sono anche altri engagement hits, come ad esempio le transazioni ecommerce, che possono essere ugualmente usate per calcolare più precisamente la lunghezza di una visita.

Una delle cose che più spesso mi sento chiedere quando parlo dei custom report è “perché non ci forniscono delle basi su cui lavorare? perché bisogna partire da zero?”. Partire da zero può essere una buona idea quando si sta disegnando un report completamente nuovo, molto molto personalizzato e con incroci di metriche e dimensioni inusuali. Alcune altre volte il custom report è solo un modo per dare una sistemata ad un report standard dal quale sentiamo la mancanza di una certa metrica, o dal quale invece vorremmo togliere una metrica.

Ad esempio dico sempre che la metrica bounce rate nel report delle Pagine non ha senso (si veda il perché in questo vecchio post) e che l’unica soluzione è ricostruire il report utilizzando i report personalizzati. Da qualche ora su alcuni rapporti di Google Analytics è presente un nuovo pulsante, PERSONALIZZA, che non fa altro che attivare l’interfaccia di creazione dei custom report riportando esattamente le metriche e le dimensioni del report corrente, facendoci risparmiare molto tempo se l’operazione da effettuare è proprio quella di sistemare un pochino un report che al 90% va bene così com’è.

I report su cui ho verificato che al momento funziona sono:

• dati demografici -> lingua
• dati demografici -> variabili personalizzate
• dati demografici -> definito dall’utente
• comportamento -> nuovi e di ritorno
• tecnologia -> browser e sistema operativo
• tecnologia -> report
• sociale -> interazione sociale
• sociale -> azione
• sociale -> pagine
• mobile -> panoramica
• tutti i report del gruppo AdWords
• tutti i report del gruppo ottimizzazione per i motori di ricerca
• pagine -> dettaglio contenuti
• pagine -> pagine di uscita
• ricerca su sito -> utilizzo
• ricerca su sito -> termini di ricerca
• ricerca su sito -> pagine
• eventi -> principali eventi
• eventi -> pagine
• adsense -> pagine adsense
• adsense -> referrer adsense
• obiettivi -> url dell’obiettivo
• obiettivi -> percorso inverso per l’obiettivo
• e-commerce -> rendimento prodotti
• e-commerce -> rendimento delle vendite
• e-commerce -> transazioni

Mi sono imbattuto in una estensione per Chrome, Table Booster, e non ho resistito alla tentazione di provarla. E’ prodotta da e-dialog, un Google Analytics Certified Partner austriaco, e quindi ha subito avuto la mia fiducia. L’estensione aggiunge un pulsantone azzurro in alto a sinistra, subito sotto all’elenco dei profili, che una volta cliccato fa apparire in cima alle intestazioni di ogni tabella sulla pagina tre ulteriori pulsanti: il primo provvede a far comparire degli istogrammi, fatto 100 il valore massimo visibile nella colonna le altre celle avranno un istogramma proporzionale. Il secondo colora le cella di rosso o di verde, e fatto rosso il valore massimo e verde il minimo (o viceversa) si preoccupa poi di fare le gradazioni di colore. L’ultimo pulsante provvede a far comparire delle barrette riferite alla media della metrica rappresentata nella colonna: se il valore è superiore alla media barretta verde e positiva, rossa e negativa se al contrario il valore è inferiore alla media. Al secondo click del pulsante compaiono anche le percentuali di scostamento dal valore medio.

Il punto negativo è che l’app non accede alle API di Google Analytics, quindi può solo lavorare sui dati presenti sulla pagina; con questo intendo dire che se avete 10 righe nel report e passate a 25, dovrete riattivare l’estensione, perché tra le altre cose dovrà ricalcolare tutti i valori. Stessa cosa se cambiate report. Piuttosto frustrante alla lunga, mentre per analisi spot su una singola metrica può essere utile. Sono sempre bene accetti gli strumenti che ci consentono di variare la monotonia dei dati tabellari, giusto?

Questa mattina ho notato che il report “dettaglio contenuti”, nella sezione CONTENUTI -> CONTENUTI DEL SITO era leggermente differente dal solito. Sono state infatti aggiunte due icone per differenziare le cartelle dalle pagine, e c’è anche l’indicazione del livello di profondità raggiunto.

In alto si legge “livello 1 percorso pagina”, e ovviamente se si clicca su una cartella la scritta cambia in “livello 2 percorso pagina”, dandoci sempre modo di capire (il famoso contesto che dobbiamo sempre dare alle analisi) a che livello di nidificazione sono i contenuti che stiamo analizzando.
Inoltre l’icona a fianco di ogni riga del report ci dà una indicazione immediata del fatto che la riga analizzata abbia al proprio interno altre pagine o sia una foglia terminale dell’alberatura del nostro sito.

Sempre nell’ottica di rendere più agevoli le nostre analisi…

Periodo di fervore anche per tutto ciò che sta “intorno” a Google Analytics: prima di tutto Google ha annunciato che dal primo marzo farà un upgrade della sua privacy policy, che diventerà comune a tutti i servizi. Il nodo principale delle nuove regole è che se si è loggati in un servizio Google, loro potranno combinare i dati ricavati da quel servizio con altri ricavati da altri servizi, sempre mentre eravamo loggati (quindi ad esempio se facciamo una ricerca per “hosting ad alte prestazioni”, potremmo poi trovarci annunci di hosting su Gmail anche se stiamo leggendo una mail che parla di tutt’altro).

Questo ovviamente non ha nessuna implicazione sui dati memorizzati da Analytics, che riguardano i nostri visitatori (in forma anonima e aggregata), e che rimangono nostri.

Quel che invece potrà cambiare, dice il post ufficiale, è che potranno usare i dati di navigazione all’interno dell’interfaccia di GA; perché molti non lo sanno, ma sull’interfaccia di Analytics… c’è Google Analytics, anche se in un forma meno canonica. Ecco qua:

<script type="text/javascript" async="" src="https://ssl.google-analytics.com/u/ga_beta.js"></script>

e poi questa chiamata

<script type="text/javascript">ga.webanalytics.header.setHeaderInfo({"email":"LAMIAEMAILINCHIARO","gUrl":"https:\/\/www.google.com\/accounts\/","tabs":{"H":1,"D":1,"CR":1,"IN":1,"A":1,"R":1,"BF":1,"GO":1,"EC":1},"style":"ANALYITCS","tab":null});ga.webanalytics.header.setLoadBaseData(true);</script>

dal che si evince anche che loro, invece, tracciano eccome i dati personali che a noi sono proibiti.

La seconda novità è che il team di Google Webmaster Tools cambierà la metrica “posizione del sito nelle SERP” che viene riportata da GWT, e di conseguenza importata da Google Analytics. Prima la metrica era la media delle posizioni rilevate, e infatti aveva anche i decimali. Se per una data keyword il sito compariva in 2° e in 5° posizione, la posizione riportata era 3.5; che aveva poco senso in sè, ma ce l’aveva eccome se si teneva presente che era appunto una media. In base alle ricerche del team, secondo loro i webmaster vogliono invece sentirsi dire la “migliore posizione tra quelle riscontrate” e quindi nell’esempio precedente la posizione riportata sarà 2.

Tenendo presente che i dati già registrati non cambieranno, per un certo periodo avremo tutti dati magnifici 🙂 dopo bisognerà tenere conto di questa modifica.