Google Analytics in 30 secondi

Stavo guardando la sessione di Analytics al Google I/O quando mi son detto “vediamo un po’ se c’è qualche novità nel blog ufficiale!”. Ed eccomi accontentato

Sorgenti Google Play: non è chiaro se si riferiscano alle sole campagne (si poteva già fare da almeno un anno) o – molto più interessante – a TUTTO il traffico che arriva al Google Play e che conduce al download dell’applicazione. Tutto questo esposto sui profili Google Analytics dedicati alle app

View Google Play: per ogni campagna o sorgente, quante view della pagina dell’applicazione sono generate

Installazioni: una metrica che ogni sviluppatore conosce, ma probabilmente segmentabile per sorgente

Nuovi utenti: il numero di primi lanci dell’applicazione, che è diverso dal numero di download.

Il tutto visualizzato tramite flow report.

Altra grandissima novità è il Tag Manager per applicazioni: attualmente il tracking delle app richiede l’aggiunta e la configurazione, più o meno laboriosa a seconda degli intenti di tracciamento, di un SDK apposito. Se lo sviluppatore dimentica di inserire il tracking di un evento (esempio, un certo pulsante che fa un’azione chiave per i nostri KPI), deve aggiungerlo al progetto, ricompilare l’applicazione, inviarla allo store, aspettare che gli utenti la scarichino e inizino ad usarla e inviare dati.

Con il Google Tag Manager per App questo sarà solo un ricordo, perché sugli stessi presupposti del Tag Manager per i siti, la configurazione del tracking verrà fatta soltanto una volta e variata “live” attraverso un comodo pannello. Purtroppo non ci sono molti altri dettagli, ma sono proprio curioso di conoscere la tecnologia sottostante che renderà possibile tutto questo: quella del tag manager “dekstop” in fondo è piuttosto banale, questa per me rappresenta una novità, e una sfida interessante.

Se volete partecipare alla whitelist, dovete compilare l’apposita form, previa creazione di un account Tag Manager se già non lo avete…

Come vi avevo anticipato ieri, l’interfaccia di creazione dei goal è stata rifatta con una grafica più moderna, che assomiglia molto all’interfaccia di creazione dei content experiment. Anche l’usabilità mi sembra migliorata.
Ora il passaggio 2 si presenta così (clic per ingrandire):

Vi faccio notare il riquadro rosso, che rappresenta una quantificazione di quanto un goal configurato così avrebbe convertito negli ultimi 7 giorni (e questo l’abbiamo già visto nella creazione delle liste di remarketing). Può essere molto utile per capire se stiamo sbagliando qualcosa, perché se ci desse un tasso di conversione dello 0% potrebbe voler dire che la pagina è nuova ma anche che lo abbiamo configurato male e non traccerebbe niente, dandoci quindi la possibilità di correggere ancora prima di mandarlo in produzione.

Tra le ormai pressoché quotidiane novità che abbracciano lo strumento (tipo oggi ho visto i nuovi goal in un tweet di Jehoshua Coren), i filtri non vengono toccati da un po’ di tempo. E’ vero che sono un punto nevralgico del sistema, perché le modifiche ai dati sono permanenti, ma di norma aggiungere qualcosa non è mai foriero di problemi.

Infatti oggi il team di Analytics ci informa sul blog ufficiale che sono disponibili 10 nuovi campi relativi al mobile, 3 relativi ai social, 3 relativi a contenuti e traffico e 1 per l’ecommerce. La lista è sul post del blog ufficiale, e alcuni di essi sono piuttosto interessanti: mi riferisco in particolare a “hit type”, che consentirebbe, ad esempio, di avere un profilo che registra solo e soltanto le transazioni. Oppure a “internal search term”, che consente di fare una cosa che, incredibile a dirsi, era fino ad ora impossibile: rendere tutte le ricerche interne minuscole, per normalizzare il report.

Altra novità (o almeno presunta tale, io non mi ricordo di aver mai visto quella pagina) è la lista completa di tutti i campi filtro e relativa spiegazione, disponibile in lingua inglese a questo indirizzo https://support.google.com/analytics/answer/1034380 o in italiano a questo altro url: https://support.google.com/analytics/answer/1034380?hl=it&uls=it

Questa sera mentre facevo il solito giro per Analytics sono andato nel tempo reale del profilo di questo blog e ho immediatamente notato una presenza di piccole scritte arancioni sospetta 🙂
Le piccole scritte arancioni di norma recano le lettere “B E T A” e così era anche questa volta: si tratta del monitoraggio delle conversioni in tempo reale, una funzione che molte persone chiedono da tempo.

Non che io sia un grande fan del real time a tutti i costi, ma se avete possibilità di prendere decisioni su quei dati, allora avere ANCHE le conversioni è sicuramente giusto, e ne intravedo tutte le potenzialità.

Se ve lo state chiedendo, la risposta è no: al momento le TRANSAZIONI e-commerce non ci sono, ci sono solo i goal. A meno che non abbiate impostato un goal sulla thankyou page dell’acquisto (e se avete un funnel dovete averlo fatto per forza, per monitorarlo). Ma immagino sia solo questione di tempo…
questo colma parte del gap verso prodotti come Chartbeat, specificamente dedicati al monitoraggio real time dei punti di conversione.

ecco lo screenshot, speriamo non sparisca come han fatto i real time widget…
(clicca per ingrandire, e non stupirti se all’una di notte non ho conversioni 😉 )

Una veloce segnalazione per questa infografica – arrivata anche sul blog ufficiale – realizzata da Allan Johnson per Jeff Sauer. E’ una lista di features, metriche, report e caratteristiche di prodotto in forma di tavola periodica degli elementi. Niente di trascendentale, ma carina e utile per avere sott’occhio tutte le caratteristiche di un prodotto che ormai progredisce talmente alla svelta da avere sempre qualche “angolo buio” da scoprire 🙂

link diretto al pdf con la tavola completa

Nel giro di pochi giorni mi è arrivata tre volte questa domanda, e siccome tre indizi fanno una prova (di scarsa usabilità del sito) credo sia giusto esporre la procedura: tutti sappiamo più o meno come si crea un rapporto schedulato via email: si può usare il pulsante “EMAIL” nella barra superiore e aggiungere un report a una mail esistente o crearne una nuova. Oppure si può creare una dashboard e inviarla periodicamente a se stessi o ad altre email. Quando il sistema crea una email pianificata, ci chiede quando la vogliamo ricevere (una tantum, giornalmente, settimanalmente – scegliendo il giorno della settimana – mensilmente – scegliendo il giorno del mese – o trimestralmente).

A seconda della selezione effettuata, il report conterrà:

• esattamente quel che vediamo (report una tantum)
• dati del giorno precedente (report giornaliero)
• dati della settimana precedente (report settimanale)
• dati del mese precedente (report mensile)
• dati del trimestre precedente (report trimestrale)

Ma se io volessi aggiungere il confronto con l’analogo periodo precedente? questa opzione non c’è quando schedulo la mail. Infatti per ottenere quel risultato devo semplicemente creare la mail mentre ho attivato il confronto temporale, non importa se il periodo che sto guardando sia o meno quello che poi mi aspetto di trovare nella mail pianificata. La casellina “attiva confronto temporale” agisce come un’opzione quando creiamo una mail pianificata. Casellina disattivata, il report contiene i dati di periodo, casellina attivata, il report contiene i dati di periodo raffrontati al periodo precedente.

Semplice, una volta che si sa come fare, no? 🙂

Alla fine, con un po’ di tira e molla, i widget in tempo reale per le dashboard sono arrivati.
I widget possibili sono 4: metrica secca (che viene giustamente chiamata “contatore”), sequenza temporale, mappa geografica e tabella, e non sono molto difformi da quel che già si vede nei report real time.

Altra novità di oggi è un nuovo grafico a torta: molto più curato graficamente, ha un ottimo sistema per lasciare una fetta selezionata ed eventualmente posizionare il mouse su un’altra prima di fare uno screenshot. In certi frangenti può essere utile. La “nuova torta” è disponibile ovunque si possa creare un grafico a torta, con l’unico problema che nell’overview delle sorgenti di traffico, come segnala Alessandra Farabegoli su Twitter, è momentaneamente sparita la fetta gialla della sorgente “campagne”. Secondo me tornerà, non mi preoccupo più di tanto 🙂

Ora che Universal Analytics è disponibile al pubblico in beta gli utenti si stanno interrogando su come dovrebbero utilizzarlo. Ho già ricevuto diverse domande in privato, e ho letto molto sui social network, per cui penso che un po’ di chiarezza non possa che fare bene alla comunità che ruota intorno a Google Analytics.

Innanzitutto una precisazione: Universal Analytics è ancora in beta, quindi alcune feature non sono disponibili. Non è obbligatorio usarlo, anzi al momento non esiste una guida alla migrazione, ed è quindi disponibile solo per i NUOVI profili. Richiede l’utilizzo di un altro codice di tracciamento, con una sintassi diversa da quella a cui siamo abituati (ma non solo, come vedremo). Non è ancora pienamente supportato dal Tag Manager, nel senso che il template Universal manca ancora di alcune opzioni.

Innanzitutto l’elenco delle cose supportate. Come sempre ci viene in aiuto Justin Cutroni:

metriche classiche, ecommerce tracking, tracking degli eventi, link con AdWords, Variabili personalizzate (nella forma di dimensioni personalizzate) e le nuove metriche personalizzate.

Cosa non è al momento supportato:

Esperimenti sui contenuti, Liste di remarketing attraverso Google Analytics, integrazione AdSense, tracking cross device.

Per fare quel che al momento si può fare, come detto, non serve niente di più che abituarsi ad una nuova sintassi del codice di tracking (ma nemmeno, se ci si affida al Tag Manager).

Quali le possibilità nuove, allora?

La presenza di un protocollo di comunicazione: in concreto significa poter inviare i dati senza
l’ausilio del codice javascript a cui siamo abituati; purché i dati siano “fomattati” secondo le specifiche, Google Analytics li accetterà e processerà. (su questo blog trovate 4 post molto strani di cose che si possono fare con Universal: tracking dei pdf acceduti direttamente, tracking del cane col gps, tracking di gmail…) Vedremo quindi fiorire framework di tracciamento più o meno integrati con i CMS. Avete mai avuto discrepanze tra il transato da CMS e le transazioni su Google Analytics? È normale, diciamo, se ad esempio un utente ha javascript disabilitato. Con il measurement protocol questo non avverrà più, perché ad ogni transazione ci sarà una comunicazione server-server, e i sistemi combaceranno alla perfezione.

Questo peraltro si potrà fare da qualsiasi “terminale” collegato alla rete, indipendentemente
dal fatto che sia un browser che visita un sito. Unendo questo alla possibilità di controllare l’ID
del visitatore, si arriva facilmente a capire che sarà possibile tracciare le interazioni offline.

Diciamo che MediaWorld è in grado di riconoscermi, perché ho una carta fedeltà a mio nome e sono anche iscritto al sito. Arrivo sul sito con una certa chiave mentre sono loggato, poi clicco un annuncio cpc, poi vedo una newsletter. In nessun caso compro sul sito, magari aggiungo solo item al carrello senza comprare (e magari stanno tracciando anche quello). Poi vado in negozio, e compro d’impulso un Samsung Galaxy S4 (a proposito, terminale da sbavo, sono curioso di provarlo. Ma anche il rumoreggiato nuovo telefono di Google che dovrebbe essere presentato al Google I/O mi stuzzica, soprattutto se dovesse già essere equipaggiato con Android Key Lime Pie. Sono un fissato dei cellulari della serie Nexus, se non lo sapeste! 🙂 ). Nel momento in cui passo la carta fedeltà parte una transazione verso Google Analytics, e quella vendita viene attribuita ANCHE alla ricerca organica, al cpc e alla newsletter.

Il measurement protocol è analogo a quanto già fanno gli SDK per Android e iOS, e infatti nella documentazione ufficiale vengono fatti degli esempi anche per mobile e/o applicazioni web, e anche in questo caso le potenzialità sono grandi: sempre avendo il controllo sugli ID dei visitatori, potrò segmentare a livello di visitatore e ottenere quindi una lista dei devices e dei mezzi utilizzati nel processo decisionale di formazione dell’idea di conversione. Una specie di multichannel funnel cross device.

A tutto questo si aggiungano le dimensioni e le metriche personalizzate, in grado di ampliare molto le informazioni presenti in piattaforma. Per le dimensioni si pensi alle variabili personalizzate di livello visitor, per facilità, per le metriche invece ci vuole uno sforzo maggiore di fantasia: diciamo che state tracciando una app mobile di messaggistica istantanea, potrete creare una metrica “numero di msg inviati per sessione” e caricarla su Analytics, ottenendo report di conseguenza.

Mettendo insieme tutti i pezzi risulta abbastanza chiaro perché Google definisca questa una “rivoluzione” del mondo dell’analytics. E’ un modo completamente nuovo di pensare alle statistiche (che ormai perdono definitivamente il suffisso “web”): più complete, più aderenti ai bisogni di business, personalizzabili e in grado di seguire il visitatore lungo tutta la filiera del processo decisionale, riportando e “normalizzando” le informazioni che derivano dagli investimenti digital anche quando producono effetti nel mondo reale. Notevole, no?

Ecco un caso infido, una delle sfide che mi piace affrontare nel quotidiano per capire sempre di più come ragionano gli ingegneri che stanno dietro al sistema e provare quindi a capire un po’ meglio lo strumento.
Che il totale delle transazioni registrate da Google Analytics possa non coincidere con quanto registrato dal sistema e-commerce è normale, oserei dire quasi fisiologico; in tanti anni ho visto uno ed un solo e-commerce con aderenza 100% tra registrato e GA. Le cause possono essere molteplici, si va dagli utenti che comprano senza avere javascript abilitato (quindi invisibili a GA), a errori bloccanti nell’esecuzione dello script, lentezza della pagina e posizione sbagliata del codice, redirect fantasiosi, insomma avete capito.

Il caso di cui parliamo oggi invece è diverso, perché rappresenta una discrepanza interna dello strumento: in un dato giorno l’overview ecommerce dice che ci sono 102 transazioni e 13.084 euro di entrate, e il report delle transazioni elenca solo 47 record, per lo stesso ammontare di entrate (clic sulla seconda immagine per ingrandire).

Il problema non sarebbe nemmeno tanto grave una volta appurato quale dei due è quello corretto (quello del report, vi rovino la sorpresa 😀 ), se non fosse che nell’overview è presente il dato del valore medio, che è un KPI importante in un e-commerce, e che in quel caso viene calcolato usando il numero di transazioni dell’overview.

Un po’ di background tecnico, per cominciare

Tutti ormai dovremmo sapere almeno a grandi linee come funziona Google Analytics, anzi come fa ad inviare le informazioni ai server di Google: richiama una gif trasparente 1×1 pixel e ci attacca una lunga serie di parametri, con i dati che servono. Tra le tante informazioni che invia, ne esiste una particolare che dice allo strumento che tipo di hit sta arrivando: se si tratta di una pagina vista (il default), di un evento, di un prodotto o di una transazione.
Esatto, ogni prodotto e ogni transazione generano una nuova chiamata alla gif, per cui la thankyoupage di un ecommerce in cui ho fatto un acquisto con 4 prodotti avrà almeno 6 chiamate alla gif: la pageview, la transazione e una chiamata per ogni prodotto.

Quindi?

Quindi la discrepanza è semplicemente dovuta a gif di tipo transazione che vengono conteggiate in un caso e nell’altro no. Come me ne sono accorto? facendo un semplice custom report con metrica “transazioni” e dimensione “transazione” (clic per ingrandire)

ci sono si 102 transazioni, ma ce n’è una di nome “undefined” con 55 transazioni. 47 transazioni “vere” + le 55 undefined fa proprio 102.
Al sistema quindi arrivano, per motivi da debuggare in seguito, delle hit di tipo transazione con transaction ID (il primo parametro obbligatorio della funzione _addTrans) vuoto (o undefined). L’overview e-commerce mostra semplicemente il numero di hit di tipo transazione, il report delle transazioni invece è filtrato a monte per mostrare solo ID di transazioni “reali”, o meglio per nascondere i valori undefined. Da cui la discrepanza.

E abbiamo portato a casa un altro pezzo di conoscenza del sistema 🙂

[edit 27/3: i real time widget sono spariti, oggi. Pazienza, probabilmente è solo questione di tempo 🙂 ]

[edit 28/3: arriva anche il post ufficiale, senza i widget, ma con altre novità: ora il realtime fa lo spaccato del traffico desktop/cellulari/tablet, andando nel report dei contenuti. Inoltre si possono creare scorciatoie che memorizzino anche i “segmenti” applicati. Infine quando si applica un segmento è possibile comparare il dato real time con quello globale, secondo per secondo. Provate ad esempio a cliccare sul traffico diretto e poi mettere la spunta su “mostra tutto il traffico”. Il traffico diretto resta azzurro scuro, il traffico totale azzurro chiaro. Pura potenza di calcolo!]

Stavo sistemando una dashboard quando ho notato due righe di pulsanti per aggiungere un widget: sulle prime ho pensato a un errore del browser o del css, poi ho guardato meglio:

Preso dal sacro fuoco della curiosità ci ho subito cliccato ed effettivamente mi ha dato la possibilità di selezionare una sola metrica, cioè visitatori, ma di avere i widget aggiornati in tempo reale, esattamente come avviene nei report. Veramente interessante e di grande aiuto quando si vuole dare ancora maggiore contesto alla dashboard, per la serie “in un dato arco temporale hai questo, ma di norma in ogni istante hai quest’altro”.

L’altra novità che ho visto è la comparsa di un report “Eventi” all’interno del tempo reale.

Verificato sperimentalmente anche quello, funziona e fa quel che promette, cioè visualizza in tempo reale la categoria e l’azione degli eventi nel momento in cui accadono sul sito (beh, con qualche secondo di ritardo 🙂 ). Cliccando sulla categoria si ha il dettaglio delle etichette dei singoli eventi.

Ultima novità viene dal blog ufficiale, che ci informa che i report “attività hub dati” e “trackback” sono stati promossi al primo livello della sezione di report Sociali, e non sono più incorporati all’interno di altri report. In effetti risultavano un pochino nascosti.