Innanzitutto la grafica: molto più “morbida”, tutta in toni di grigio, molto elegante. Da qualsiasi punto si clicchi il pulsante di amministrazione, si arriva alla medesima interfaccia che mostra – esplosa – la visione sui tre livelli differenti di oggetti su cui si può operare: account, proprietà e profilo (e se avete dubbi, avevo scritto un articolo a proposito qualche tempo fa).

Il nome di ogni oggetto è contenuto in un menu a tendina, dal quale si può passare a un altro oggetto di pari livello: dal primo menu si cambia ACCOUNT, dal secondo menu si cambia PROPRIETA’ (all’interno dello stesso account), dal terzo si cambia PROFILO (all’interno della stessa proprietà).
Sotto ad ogni oggetto vi è poi l’elenco completo delle azioni che è possibile operare su di esso; quante volte vi siete chiesti se la gestione degli account AdWords fosse all’interno della proprietà o dell’account? e AdSense si linka da profilo o da account? e il remarketing? tutto questo sarà un ricordo, perché in una unica schermata ci sono tutti i link possibili.

Inoltre c’è un effetto molto bello di transizione che porta dalla schermata a tre colonne a una schermata con una colonna sola, corrispondente alle voci di menu parallele alla selezione fatta, e che nella parte destra reca lo spazio per operare fisicamente le modifiche. Per intenderci, se clicco “Filtri” su un profilo, mi trovo una schermata come questa (clic per ingrandire)

tramite la freccia in alto posso tornare al menu precedente, con la tendina cambio profilo, agendo sul menu laterale faccio comparire le schermate con le configurazioni di PROFILO. La schermata di una proprietà è uguale, salvo avere le voci di menu relative alle proprietà, e così via.

All’inizio dovrete farci un pochino l’abitudine, come tutti i cambiamenti radicali di interfaccia, ma sono sicuro che dopo qualche giorno la troverete molto utile e funzionale anche voi!

Questo credo sia solo una delle motivazioni che ha spinto il team di Google Analytics a creare la nuova API per i Content Experiment, annunciata ieri.
I vantaggi principali dell’uso dell’API al posto del normale snippet di codice sono riassunti così:

• esperimenti senza redirect: lo snippet attuale fa un redirect usando javascript. L’uso di API consentirà di evitare questo passaggio, e di informare il sistema che è stata servita una versione A o B sul medesimo URL
• testing di “cose” lato server: si potranno testare anche “cose” che l’utente non vede, perché avvengono lato server. L’esempio che fanno sul post ufficiale è un algoritmo o un reccomendation engine. Ad esempio si possono usare due diversi set di post consigliati, basati su query diverse, e capire quale dei due funziona meglio nel servire post che poi vengono cliccati.
• logica personalizzata negli split: per chi non volesse usare l’algoritmo denominato “multi armed bandit” potrà implementare una propria logica per servire le variazioni, magari tornando al classico 50/50
• testing con il protocollo di misurazione: Universal Analytics permette di comunicare con Google Analytics attraverso un protocollo di misurazione, e quindi permette di tracciare anche cose diverse da siti web. Usando l’API dei Content Experiment e il protocollo di misurazione sar possibile fare A/B test anche su questi oggetti che non rappresentano siti internet.

Insomma, come tutte le nuove API che vengono introdotte, bastano poche righe per annunciarle, ma aprono moltissime possibilità per tutti, developer, persone con le idee e utilizzatori finali

In questo modo se faccio una modifica, essa sarà riflettuta e disponibile a tutti coloro che usano quella dashboard nel profilo in cui si trova e in cui l’ho creata la prima volta. Da quanto capisco, inoltre, anche le modifiche fatte da altri saranno salvate, rendendo di fatto molto più facile creare dashboard in team molto grandi: qualcuno si occupa dei widget per la SEO, altri dei widget per la SEM, qualcuno aggiunge le parti social and so on…

Il problema di business che questa soluzione risolve non è affatto banale: chiunque si sia cimentato con il processo di approvazione di una applicazione mobile sa quanto possa essere lungo e soggetto a rinvii, soprattutto sull’AppStore di Apple. Anche dopo la prima approvazione, il ciclo di rilascio di una nuova versione non è immediato, e comunque sia ogni minimo cambiamento della app, fosse anche il colore di un pulsante, richiede una nuova versione.

Il Tag Manager per app invece va configurato una volta in fase di creazione del tracking o dell’app, ed esattamente come nei siti web la configurazione dei tag può essere fatta da pannello. Con dei plus molto interessanti, però. Il primo è che la configurazione viene scaricata ogni tot ore, se possibile. E questo risolve il caso in cui una app venga utilizzata in assenza di connessione internet. Il secondo è che il tag manager per app mobile può essere usato per modificare qualsiasi aspetto dell’app, non solo il tracciamento analytics.

Come si vede chiaramente dal video qui sotto, anche la fisica di un gioco o il metodo di rilascio di badge, così come la posizione e la forma di un banner, possono essere variati a piacimento. Non solo: poiché il sistema è basato su regole, come il Tag Manager classico, si possono anche identificare specifici segmenti di utenti e modificare soltanto la loro app. Ad esempio, tutti i dispositivi in lingua inglese. O tutti gli android con versione inferiore alla 4.0. O altri a piacimento.

E tutto questo, ripeto, senza bisogno di pubblicare una nuova versione dell’app, ma comodamente tramite pannello.
Risparmiare tempo, risparmiare soldi! Vi consiglio di prendervi una mezz’oretta e dare un’occhiata al video del Google I/O con la demo, è veramente notevole!

Non mi sembra che abbiano una utilità così elevata, almeno a una prima occhiata, ma non si può mai dire. Quel che noto rispetto al post sul blog ufficiale è che nello screenshot

Nella casella di input loro visualizzano “Goal ID 1 / Goal set 1“, mentre io nei miei account non lo vedo. Perché questo ha una qualche rilevanza? perché al contrario della vecchia interfaccia ora non sembra più possibile decidere a priori la posizione di un goal: mentre prima c’erano 4 set di 5 obiettivi ciascuno, ed era comunque possibile creare un goal in un set a piacere, al momento questa possibilità non esiste, e i goal vengono creati in maniera sequenziale, e poi mostrati nell’interfaccia in ordine alfabetico. A livello di funzionalità finale non cambia molto, ma bisognerà farci un po’ l’abitudine, e vedere che impatto avrà la cosa sugli account già esistenti con una certo tipo di categorizzazione dei goal.

A voi come sembra la nuova interfaccia?

In questo caso la soluzione Premium, lo sappiamo, permette il download dei dati non campionati sotto forma di file gestibile con Excel. Però poi i dati su Excel ci devono ENTRARE. Cosa accade se debbo elaborare 4 file da 3 milioni di record l’uno senza che mi esploda il PC?

La nuova soluzione che Google propone ai suoi utenti Premium è l’integrazione con BigQuery (che a dire il vero si era sentita brevemente al momento del lancio di Premium, salvo poi sparire nel nulla), un servizio poco noto che consente di manipolare con facilità grandi quantità di dati, sfruttando le capienti infrastrutture di calcolo di BigG.

Durante il Google I/O è stata fatta una dimostrazione live, usando un dataset di 42 milioni di record e creando una interrogazione complessa (join nidificate con regular expression, per i curiosi) ottenendo il risultato in meno di 10 secondi.
Un tempo ridicolo considerando il valore potenziale di analisi di questo tipo, visto che tra l’altro BigQuery consente di caricare propri dataset e quindi integrare i dati che provengono da GA Premium!

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…

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.

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

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 )