Google Analytics in 30 secondi

Questa notte sono iniziate ad arrivare mail di avviso da Google Analytics riguardo a “Cambiamenti importanti alle proprietà di Google Analytics per app per dispositivi mobili”.

Il punto saliente è che tra un anno inizieranno a sparire i report delle property di tipo MOBILE. Se non sapete di che tipo sono le vostre property (perché magari avete un’app ibrida o una web app e non ricordate cosa è stato scelto per tracciarla), dovrete andare nella homepage di Analytics, dove c’è l’elenco delle property/viste cui avete accesso, e controllare le icone a fianco ai nomi delle property.

Se l’icona è a forma di telefonino (frecce rosse nello screenshot qui sopra), allora siete soggetti alle conseguenze indicate nella mail.
Se l’icona è a forma di mondo, o vi è indicato “Firebase”, allora siete a posto.

La parte saliente della mail è questa:

Nel 2019, inizieremo a ritirare le proprietà che ricevono dati esclusivamente da Google Analytics Services SDK.

• La raccolta e l’elaborazione dei dati relativi a tali proprietà verrà interrotta il 31 ottobre 2019.
• Fino al 31 gennaio 2020, sarà possibile accedere ai dati storici di queste proprietà attraverso l’interfaccia utente e l’API.
• Dopo la disattivazione del servizio, non sarà più possibile accedere a queste proprietà tramite l’interfaccia utente o l’API di Google Analytics e i relativi dati saranno rimossi dai server di Google Analytics. In futuro riceverai altre notifiche.

In pratica è meglio se da adesso in poi ogni nuovo progetto, o aggiornamento di progetto, utilizzi Firebase Analytics e non i vecchi SDK; un processo già in atto da tempo, anche se ancora qualcuno che fa la scelta “conservativa” si trova. Ma Google l’ha appena spazzato via con questa mail 🙂

Oggi durante il Google Marketing Live 2018 Google ha annunciato che Analytics presto sarà fornito di report cross-device.
Sento già levarsi le voci e vedo i nasi storti in chi sta per dirmi “hai preso una botta in testa? Google Analytics HA GIA’ i report cross-device, basta passare uno USERID uguale tra desktop e mobile, ed è fatta”.

Si, lo so, ma quella è una funzione “volontaria”, sta al webmaster o a chi implementa i tracker far si che la magia accada. Google oggi ha annunciato una cosa che mi sono sentito chiedere in almeno la metà dei corsi che ho tenuto negli ultimi dieci anni, ovvero il fatto che il ricongiungimento dei dati verrà fatto direttamente dalla piattaforma sulla base dei segnali che normalmente usa per identificare gli utenti su più dispositivi, il più semplice da immaginare e capire è l’essere loggati ad un google account (gmail, youtube, eccetera…)

Ho visto questi report quasi un anno fa a San Francisco, spero che abbiano fatto che passi in avanti perché seppur stupendevoli e sicuramente utilissimi, gli ingegneri non erano ancora riusciti a fugare un paio di dubbi che i clienti più avanzati ed esigenti vorrebbero risolti da una funzionalità come questa, guarda caso sempre legata a iOS e Safari 😀

In ogni caso preparatevi, perché se funzionerà a dovere e con una significatività statistica decente, questo cambierà completamente le vostre attuali valutazioni dei ritorni di marketing!

Che ne pensate?

Come ogni 14 novembre che si rispetti, celebriamo oggi il compleanno di questa creatura, che ormai ha 9 anni.
L’anno prossimo affronterà l’esame di fine elementari e diventerà un adolescente, sebbene in realtà molti lo considerino già maturo 🙂

La prossima frase dovrebbe iniziare con “per festeggiare, oggi gli ingegneri hanno rilasciato…” ma in realtà ormai abbiamo capito tutti due cose:

1. Gli ingegneri non festeggiano 🙂
2. I rilasci sono ormai talmente tanti e ravvicinati, che si tratta di una mera casualità 😀

Quindi, dicevamo, oggi il blog ufficiale di Analytics ci dice che entro qualche settimana entrerà in fase di beta pubblica, dopo mesi e mesi di testing privato, una funzionalità molto attesa dagli sviluppatori di App mobile: il tracking delle installazioni di app iOS attraverso i parametri di campagna (o AdWords), operazione invece già possibile da anni su Android, naturalmente.

Significa che il report acquisizione di una property dedicata ad una App iOS verrà popolata con i dati delle campagne di marketing che vengono messe in piedi per promuovere l’install. Questo in futuro (attraverso l’upload dei dati di costo della campagna) potrà consentire di calcolare il CPI (cost per install) tanto caro al marketing orientato alle app mobili.

Senza entrare troppo nei tecnicismi, il meccanismo sfrutta l’IDFA di iOS. L’IDFA è un identificatore univoco (anonimo) del dispositivo, una sorta di tracker dell’utente unico.
In questa pagina del supporto è presente anche lo strumento di creazione degli URL per la campagna, che genera dei link del tipo

https://click.google-analytics.com/redirect?tid=UA-12345-1&url=https%3A%2F%2Fitunes.apple.com%2Fus%2Fapp%2Fmy-app&aid=123456789&idfa=[DEVICE_AD_ID]&cs=asd&cm=asd&cn=asd

https://click.google-analytics.com/redirect?tid=UA-12345-1&url=https%3A%2F%2Fitunes.apple.com%2Fus%2Fapp%2Fasd&aid=123456789&idfa=[:_jv_uaid:]&cs=asd&cm=asd&cn=asd

Si tratta quindi di redirect che Google effettua dopo aver registrato il click, puntando poi su iTunes. il formato del parametro IDFA cambia a seconda dell’Ad Network selezionato (AdMob, Applovin, InMobi, LeadBolt, Millenial, Mdot, MobFox e Custom); all’interno di custom è anche selezionabile il ping, invece del redirect, ma non compare nessun campo aggiuntivo. Va un po’ studiato, come tutte le novità.

Lo aspettavate?

[edit 22/7: il report ha poi cambiato nome e ora si chiama proprio “Aggiustamenti delle offerte” 🙂 ]

Con l’arrivo delle campagne AdWords potenziate, era anche scontato l’arrivo di un report o dimensioni in grado di farci comprendere meglio come queste campagne performassero sui vari device in cui erano visualizzate. Detto fatto, da stamattina nella sezione dei report AdWords, subito sotto al classico “campagne” ecco comparire “campagne potenziate”.

(clic per ingrandire)

Si tratta sostanzialmente di un report con la dimensione secondaria già presente, e “chiusa” appena si apre il report, pronta per essere espansa. In questo caso il click sul nome della campagna comporta la comparsa di due ulteriori righe che separano i valori della campagna TUTTO in COMPUTERS e TABLET CON FULL BROWSER. Per tutte e tre le righe sono naturalmente presenti tutte le metriche classiche cui siamo abituati, con il vantaggio di avere già nel report di riepilogo anche alcune metriche di preclick che erano tipiche – e limitate – del report “clic”.

Se ve lo state chiedendo, non ho ancora capito a cosa si riferisca la colonna “Agg. offerta” 🙂 [edit: come mi fanno giustamente notare nei commenti, si tratta degli aggiustamenti delle offerte, caratteristica propria delle campagne potenziate]

Sempre in tema di novità, segnalo anche che il report del traffico mobile è stato modificato. La panoramica ora non mostra più una semplice dimensione “si/no” a seconda che il device fosse o meno un dispositivo mobile, ma differenzia le metriche in tre categorie: desktop, mobile (cellulare) e tablet. La stessa cosa accade nel dettaglio dispositivo

Avevo detto qualche giorno fa che ero curioso di capire come avrebbe funzionato il Google Tag Manager per applicazioni mobili: tecnologia tutto sommato nuova (Ensighten già lo fa, per la cronaca) ma molto promettente.

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!

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…

L’altro giorno guardavo un collega creare un nuovo account, e mi sono imbattuto in questa schermata

Non avendo mai visto i pulsantoni grigi pensavo che avessero cambiato la schermata, ma sui profili che guardavo io non risultava. Ci siamo ricollegati allo stesso profilo, ma nessuno dei due è più riuscito a vederla. La cosa si è poi ripetuta ancora una volta, e soltanto ieri Google ha annunciato che insieme all’entrata in beta dell’app analytics era stato ridisegnato il processo di creazione dei account.

Per chi non se lo ricordasse, il tracciamento delle app in versione due era stato annunciato a fine giugno, in fase limitata e sperimentale. Il nuovo set di report vuole dare a chi analizza un’applicazione la stessa efficacia ed esperienza d’uso di chi ha usato GA per i siti fino ad ora, con report completi ed esaustivi pensati apposta per chi deve analizzare i comportamenti di una app mobile invece di un sito; e quindi report sulle versioni dei sistemi operativi su cui è installata, interazioni sociali, report sugli errori generati, campagne che hanno portato all’installazione (solo su play store) e così via…

Un altro miglioramento interessante è l’uso di “custom dimensions”, cioè di una versione potenziata delle custom var; per adesso, da quanto si capisce, limitata alle app, ma ovviamente speriamo che in futuro questo sia possibile anche nei profili classici!

Durante questa settimana sono accadute tre cose piuttosto importanti nel mondo di Google Analytics, due delle quali nella sola giornata di Venerdì.

Per prima cosa è tornato l’index$, anche se adesso si chiama Valore Pagina. Me ne ero accorto un paio di settimane fa, ma non avevo fatto in tempo a dire “rieccolo”, che già era scomparso… probabilmente erano prove tecniche. Dell’importanza dell’index$ abbiamo già parlato in passato, ed esso effettivamente è una metrica che aiuta molto quei webmaster che non monetizzano direttamente i loro siti web, ad esempio i publisher; non averla era una mancanza che loro soffrivano.

La seconda cosa è che finalmente il team di Google Analytics ha rilasciato un’applicazione ufficiale per Android, la trovate nel Play Store: invece di replicare quel che le altre app già presenti fanno più o meno bene (si veda questo mio vecchissimo post, e questa recensione), cannibalizzando il mercato degli sviluppatori, il team ha rilasciato una app che fa solo 4 cose: mostra i dati Real-time, mostra una dashboard personalizzabile, e mostra gli avvisi automatici e personalizzati. In questo modo avere l’app ufficiale non rende superflua la presenza di un’altra app, ma piuttosto la integra. Justin Cutroni la descrive in un post piuttosto lungo.

La terza, che è anche la più grossa, è il rilascio di un nuovo SDK per tracciare le applicazioni mobile. Si tratta ovviamente di qualcosa di molto superiore a quanto è già possibile fare: al momento le applicazioni vengono tracciate su Google Analytics come se fossero siti, con pagine ed eventi. In futuro, al momento della creazione di un profilo, ci verrà chiesto se vorremo tracciare un sito o una app. Nel secondo caso i rapporti standard di GA appariranno così:

I report ci daranno informazioni sugli utenti, quanti scaricano e quanti davvero usano l’applicazione, da quali paesi, che versione dell’app stanno usando e da quali device. Questo ovviamente legato alla sorgente di traffico che ha portato l’utente a scaricare l’app dal Play store, come già si può fare adesso.
Dopodiché si potranno avere informazioni sulle sessioni (che si chiamano schermate), sui crash dell’applicazione e sulle sequenze di azioni fatte dagli utenti sull’applicazione: è un flow visualization che incrocia le schermate viste con le azioni intraprese (ad esempio quale pulsante viene premuto). Non mancano infine report sui goal, definibili come nel “normale” GA, o sugli acquisti effettuati all’interno dell’applicazione.

Se siete sviluppatori di applicazioni Android e siete interessati, c’è da compilare una form per avere il nuovo SDK in prova: i nuovi report saranno disponibili a partire dalla fine dell’estate.

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!

Google Analytics sta iniziando ad introdurre due nuovi pulsanti nei report di AdWords, pulsanti che servono a separare il traffico complessivo da quello generato da cellulari di fascia alta e da tablet. Niente che non si potesse già fare con dei segmenti avanzati, per carità, ma ritrovarseli già pronti fa sempre piacere. Inoltre possiamo anche azzardare che la separazione avvenga usando lo stesso database che dentro ad AdWords ci permette di selezionare i dispositivi sui quali visualizzare i nostri annunci.

facilitandoci quindi l’analisi dei risultati segmentati per dispositivo e dandoci la possibilità di ottimizzare ancora di più le campagne sui dispositivi mobili.