Google Analytics in 30 secondi

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.

Ieri Google ha aperto a tutti la possibilità di provare analytics.js, il file che abilita le nuove funzioni di Universal Analytics annunciato durante lo scorso Summit. In realtà non basta cambiare il file che si richiama sulle pagine, c’è anche bisogno di creare un nuovo profilo. Nelle prossime settimane verranno fornite, probabilmente, delle guide per il passaggio.

Universal Analytics, ve lo ricordo, permetterà di incentrare le analisi sul visitatore, nella sua forma più “pura”, riuscendo a tracciarlo durante tutti i suoi movimenti – a determinate condizioni – e riuscendo quindi a fare segmentazioni per visitatore e non più per visita. Un vantaggio sarà ad esempio poter riconoscere una stessa persona quando usa device multipli.
Altra novità è la possibilità di usare un tracking server-side, usando un protocollo di invio dei dati ideato da Google.

Le possibilità che Universal Analytics apre sono moltisisme, molte più di quelle che riusciamo a immaginare fino ad ora, e sicuramente l’apertura a beta pubblica denota un grado di maturazione sufficiente e fa ben sperare sulla data di rilascio finale (che comunque non reputo vicina). In questo periodo le persone potranno provarlo e capire se e come potrà essere utile, studiarlo, creare framework di tracciatura e insomma arrivare preparati quando Universal farà il suo debutto ufficiale.

La grande novità di oggi sono i nuovi permessi utente, attesi da praticamente sempre e invocati a gran voce da tutti gli utenti con almeno due account a cui io abbia mai rivolto la parola.
Tradizionalmente sono sempre esistiti due ruoli, in Google Analytics:

• Utente: può vedere i report di un singolo profilo
• Amministratore: può vedere i report di tutti i profili di un Google Analytics Account, e modificare la configurazione

Il problema è che non c’è la via di mezzo: vedi poco di un solo profilo o vedi tutto di tutti.

Tra qualche settimana invece i permessi saranno portati a tre, e la granularità sarà aumentata grazie a un sistema di ereditarietà e sommatoria dei ruoli. I nuovi ruoli saranno (in inglese che chissà poi come li traducono):

• Manage Users: può aggiungere e rimuovere utenti e cambiare i permessi. Niente altro.
• Edit: può compiere task amministrativi, come aggiungere property e account, filtri, obiettivi, ma non può modificare gli utenti. Include anche il ruolo View
• View: può vedere i report

I permessi sono ereditari, nel senso che se aggiungo un utente con ruolo View a un Google Analytics account, esso avrà accesso come View anche a tutte le web property e tutti i profili. Mentre se aggiungo un utente come Edit a un singolo profilo, esso vedrà e potrà modificare solo il singolo profilo.
Naturalmente i permessi, scendendo nella gerarchia, si possono aggiungere ma non togliere: quindi un permesso Edit sulla web property non si può limitare a View su un profilo ivi contenuto, mentre è vero il contrario (View sulla property e Edit su soltanto un profilo).

Nelle prossime settimane Google migrerà automaticamente tutti gli utenti esistenti secondo queste regole:

• Gli Amministratori diventano “full access” (quindi tutti e tre i permessi di cui sopra) a livello di GA account
• Gli utenti diventano “view” per i profili cui hanno correntemente accesso

La domanda che ho visto girare su Google Plus è questa: questo risolve l’annoso problema degli account in mano a persone “sbagliate”? (si veda questa discussione in proposito)
La risposta sembra essere si, perché adesso puoi rendere una persona “amministratore” di un singolo profilo, dandogli tutti e tre i permessi limitatamente al singolo profilo. Non risolve del tutto, perché qualcuno con un privilegio più alto può sempre rimuoverti (e perché ad esempio alcune cose si possono fare solo a livello GA account, come il collegamento AdWords), ma dovrebbe risolvere al 90%.

L’altra domanda che mi pongo, e per la quale incrocio le dita, è: ci sarà finalmente la possibilità di auto-rimuoversi dai profili? almeno riuscirò a fare pulizia di tutti quei profili dai quali non riesco a liberarmi (e che non posso nemmeno punire con un filtro azzera-visite perché adesso c’è la cronologia delle modifiche )

La cronologia modifiche dovrebbe ormai essere attiva per tutti: la trovate cliccando AMMINISTRAZIONE e selezionando un Google Analytics Account, sta tra “sorgenti di dati” e “impostazioni account”. Se non siete soliti apportare molte modifiche ad account e profili sarà probabilmente una schermata vuota, io in un paio di casi ho già le prime notifiche. D’ora in avanti sarà più facile tenere traccia dei cambiamenti nella configurazione.

Altra modifica recente su GA si trova nei report Social, con la promozione a voce di menu dei report “attività hub dati” e “trackback”.
Molte novità invece nel Google Tag Manager, che ultimamente mi trovo ad aprire più volte al giorno e dove praticamente sempre si notano modifiche e introduzione di funzionalità; le ultime che ho notato sono:

• rifatta la grafica del selettore del tipo di tag, e riorganizzato logicamente il contenuto. Il problema è che probabilmente stanno usando un traduttore automatico, e quindi il “trasforma monitoraggio delle conversioni” altro non è che “Turn conversion tracker”, dove Turn è uno strumento di web analytics :-/
• Aggiunti al template Google Analytics anche i tipi di monitoraggio “social” e “tempi utente”
• Aggiunti al template Google Analytics per le pagine – configurazione avanzata – le opzioni “titolo della pagina”, “chiave della sorgente/mezzo/termine/contenuti/nome”, “chiave del valore che impedisce la sostituzione” ( non chiedetemi cosa sia ), “sostituzione sorgente/mezzo/termine/contenuti/nome”, “sostituzione gclid”, “sostituzione sorgente clic di Google (gclsrc)”, “sostituzione ID clic di Doubleclic (dlid)”.
• Aggiunta la possibilità di aggiungere motori di ricerca dall’interfaccia del GTM (funzione _addOrganic)
• Aggiunta la possibilità di dare un nome al tracker

Quest’ultima possibilità, anche se ai più sembra poca cosa, è invece fondamentale per fare una migrazione completa.
L’oggetto che viene istanziato dal Tag Manager quando si usa il template predefinito di Google Analytics, infatti, è privato e inaccessibile dall’esterno: ovvero se uso il template predefinito, poi non posso mettere (o lasciare se già ce l’ho) un onclick di tipo _gaq.push(['_trackEvent', eccetera]). Non funzionerebbe e dovrei alternativamente passare all’uso di dataLayer.push come suggerito dalle best practices del GTM, ma dovendo potenzialmente cambiare molto codice nelle pagine, oppure rinunciare al template e usare un tag HTML custom in cui re-incollo il codice di base presente sulle pagine.

Con la nuova opzione in teoria mi basta nominare il tracker _gaq e dovrei essere in grado di salvare capra e cavoli (questa è una castroneria, naturalmente, che mi vale tutta la brutta figura. Così imparo a scrivere di notte dicendo “domattina lo testo” ) mi basta selezionare l’opzione e lasciare vuoto il nome, giacché il tracker predefinito in GA – versione asincrona – non ha nome (nella versione sincrona si chiamava pageTracker).