Google Analytics in 30 secondi

Il titolo un po’ criptico fa seguito ad un post sulla pagina Google+ di GA, in cui si annuncia la sostituzione della metrica del ROI (Ritorno sull’Investimento) con quella del ROAS (Ritorno sulla spesa per annunci) all’interno dei report AdWords. La modifica dovrebbe già essere visibile a tutti.

La formula con la quale è calcolato il ROAS è (entrate ecommerce + valore obiettivo) / spesa. Nei report AdWords il numeratore è segmentato per i valori derivanti da visite con conversioni “ultimo clic non diretto” da AdWords. Questo è il motivo per cui la quasi totalità dei profili che vedo ha un ROAS con una certa percentuale che è comunque inferiore alla media del sito: la media è calcolata come totale entrate ecommerce / spesa AdWords, mentre il ROAS AdWords è entrate ecommerce da ADW / spesa ADW. Sarebbe 100% solo se TUTTE le entrate fossero attribuite ad AdWords.

Mi aspetto che il passo successivo sia introdurre la stessa metrica anche nei report “analisi dei costi”, in modo da poter calcolare il ROAS di qualsiasi attività di spending in advertising.

Altre novità interessanti sul fronte advertising sono elencate in questo post sul blog ufficiale, vediamole una per una:

1. E ora possibile attivare i report demografici anche per le applicazioni mobili, e questo permetterà anche di fare migliori campagne di remarketing in-app, potendo segmentare anche per profili demografici.
2. La creazione delle liste di remarketing dall’interfaccia di Analytics è ora stata semplificata; inoltre ora si possono importare template già fatti di liste di remarketing con lo stesso meccanismo di custom report, dashboard e segmenti, quindi usando la Solution Gallery
3. C’è un nuovo report nella sezione AdWords, che misura l’efficacia dei target nella rete Display: a mia memoria è la prima volta che GA mostra un report con TRE dimensioni primarie. Si tratta più precisamente di Parola chiave per la rete display, campagna e gruppo di annunci. In verità la prima posso anche modificarla con Posizionamenti, Argomenti, Interessi e remarleting, età o sesso. L’applicazione di una dimensione secondaria porta a quattro il numero di colonne che elencano dimensioni nel report (e inizia anche a essere stretto da vedere su un monitor da 17 pollici :-/ )

clicca l’immagine per ingrandirla e renderti conto di quanto sia lungo il nuovo report 🙂

Durante l’ultimo summit dei partner a San Francisco Google ha annunciato che la funzionalità che prima si chiamava Dimension Widening sarebbe stata rinominata semplicemente Custom Data Import: attraverso di essa si potranno caricare dati di costo o ampliare informazioni presenti in piattaforma. Per i dati di costo è solo un rebranding della funzionalità, mentre per l’ampliamento delle dimensioni c’è una novità importante, ovvero la possibilità di non usare le API e di caricare semplicemente dei file CSV.

Ovviamente le cose non sono così semplici come sembrano a prima vista, come spesso accade per le grosse novità nel prodotto la funzionalità viene prima lanciata e dopo semplificata: se siete interessati vi invito a leggere la documentazione a riguardo, mentre per partecipare alla beta è necessario compilare la domanda usando questo form

Per gli utenti Premium invece c’è un’altra succosissima novità: il cosiddetto Query Time Mode, cioè la possibilità di modificare i dati pregressi. Beh, in verità non è esattamente così, anche se il risultato è praticamente lo stesso: quel che accade è che la funzionalità di data import non modifica perennemente i dati durante il calcolo, ma applica uno “strato” sopra ai dati che vengono visualizzati nel prodotto. Facciamo un esempio pratico, taggo un certo annuncio di campagna usando un solo parametro ?campaignID=12345. Attraverso il Query Time mode carico un file che dice a Google Analytics che campaignID 12345 corrisponde a sorgente A, mezzo B, campagna C e content XYZ. Dentro al sistema vedo questi dati.
A fine campagna mi viene notificato che in realtà la creatività usata era diversa, alla fine l’agenzia ha usato un formato ZZZ. Modifico il file, lo carico nuovamente e voilà: anche i dati pregressi cambiano. Il Query Time mode rappresenta un grosso passo avanti nella “parificazione” dei dati in possesso dell’azienda con i dati di Google Analytics: gli usi sono moltelpici e le possibilità di analisi che apre sono tante.
Purtroppo come detto, per ora la funzionalità è disponibile soltanto agli utenti Premium. chissà che prima o poi non discenda anche sulla free, come già successe per i modelli di attribuzione…

Manco da un po’ di tempo, ma ci tengo lo stesso a darvi un po’ di notizie su cosa è accaduto nel mondo Google Analytics e dintorni nel frattempo 🙂

Partendo dal blog ufficiale, Premium ottiene le API non campionate; attraverso di esse si possono ottenere informazioni sui report non campionati esistenti, si può creare al volo una richiesta di report non campionato, si può controllare lo stato di avanzamento del calcolo di un report non campionato e infine si può avere il link dal quale scaricare un report non campionato.
La feature è utile perché, come al solito, permette di integrare al di fuori del pannello operazioni che tipicamente possono essere svolte solo da dentro all’interfaccia: nel caso di Premium la cosa è ancora più utile perché non tutte le funzioni aziendali hanno accesso a tutti i report e tutti i dati, e molti si basano sull’uso di API per interrogare solo i KPI di interesse. Se però i KPI di interesse sono fortemente campionati, fino ad ora non c’era altra possibilità che andare sul prodotto e richiedere il report unsampled, mentre adesso anche questa operazione può essere svolta tramite API.

Altra novità recente è la suddivisione semi-automatica tra le keyword di brand e quelle non di brand; il sistema provvede ad estrarre quelle che secondo lui sono le chiavi di brand, ma è ovviamente possibile modificare a piacimento la configurazione. Una volta terminata questa oeprazione Analytics chiederà di poter creare due nuovi canali nel raggruppamento predefinito dei canali: uno per le chiavi di brand e uno per quelle unbranded, che si andranno a sostituire progressivamente al canale di default “Paid Search”. Questa classificazione esiste soltanto per le chiavi a pagamento (non solo per AdWords), mentre per via del fenomeno delle (not provided) non si può applicare (e non avrebbe senso farlo) al traffico organico.

Per quanto riguarda le novità di prodotto vere e proprie, segnalo che per l’ennesima volta è stata rifatta l’interfaccia dei segmenti avanzati, sia nella parte di visualizzazione sia nella parte di creazione.
La nuova visualizzazione dei canali ora si presenta così

se non volete a tutti i costi usare la freccia verso il basso per rimuovere un segmento, vi svelo un trucco: basta trascinarlo ‘via’ 🙂

L’interfaccia di selezione ora si apre per impostazione predefinita in modalità “verticale”, garantendo finalmente la leggibilità dei segmenti con i nomi più lunghi:

E’ stato introdotto anche un comodo selettore “selezionati”, che provvede a scremare soltanto i segmenti attivi: quante volte volevate togliere un segmento e siete stati costretti a scorrere più volte su e giù il menu perché non li trovavate? 🙂

Ho notato da qualche giorno che nelle dimensioni secondarie è comparso un raggruppamento “ora”. Sebbene data, ora e ora del giorno siano sempre stati selezionabili, adesso il numero di dimensioni è molto più cospicuo e comprende cose interessanti come ad esempio:

• giorno del mese
• giorno della settimana
• mese dell’anno (03) e mese dell’anno (201403); pessima traduzione di due concetti diversi :-/
• minuto (001036, inteso come minuto del giorno) e minuto (05, inteso come minuto dell’ora)
• nome del giorno della settimana
• settimana ISO dell’anno ISO

e altri ancora. Quando si fanno analisi granulari sono dimensioni che possono tornare MOLTO utili…

infine giovedì e venerdì scorso si è tenuta la prima edizione italiana dell’ Emetrics summit, evento di caratura mondiale dedicato esclusivamente al mondo della misurazione. Oltre ad aver incontrato Jim Sterne, padre fondatore della web analytics e della Digital Analytics Association, e ad aver rivisto molti amici e colleghi, Tommaso Galli ha tenuto uno speech dove tra l’altro ha ribadito con questo video l’importanza di usare un TagManager per la gestione dei tag di marketing. Un po’ quello che cercavo di spiegarvi qualche tempo fa, sotto un’altra ottica… 🙂

Ecco una novità attesa da tanto tempo, praticamente da quando esiste Universal Analytics: la possibilità di avere direttamente nei report le dimensioni personalizzate.

Fino ad oggi infatti per utilizzare le Custom Dimension, oltre a impostarle e registrarle, era infatti necessario creare dei custom report. Da oggi invece esse sono disponibili anche tra le dimensioni secondarie, velocizzando molto il lavoro di analisi, soprattutto per le configurazioni Premium dove le custom dimension possono essere anche 200. Immaginate infatti di dover creare a priori tutti i custom report necessari ad analizzare 200 dimensioni personalizzate!

Come sempre il lavoro del team è prima quello di abilitare le features e poi di renderle più facilmente fruibili: in questo caso c’è voluto un po’ di tempo, ma finalmente abbiamo questa possibilità!

Non ancora comparsa sul blog ufficiale, ma ampiamente pubblicizzata da Justin Cutroni e dal Google Plus del team di GA, ecco fare capolino all’orizzonte la prossima dirompente rivoluzione di questo prodotto: il Dimension Widening, che ancora non ha un nome nell’interfaccia italiana si trova nella voce “importazione dati” a livello di property.

Si tratta in buona sostanza di un sistema per aggiungere informazioni ai dati che verranno presentati nei report. Una cosa che è già possibile fare a due livelli, ma questo ne aggiunge un terzo, e molto più interessante:

1. il primo livello è l’aggiunta di informazioni a hit, sessioni o utenti tramite le custom dimension e metrics, per chi è già passato a Universal Analytics; è il modo con cui in passato si aggiungevano sino a 5 variabili personalizzate, ora divenute 20 dimensioni e 20 metriche; lo svantaggio è che questo deve essere fatto contestualmente alla hit e alla sessione di visita, e richiede modifiche allo script (o alla configurazione dei tag sul TagManager)
2. il secondo livello è l’import dei dati di costo, che consente di importare e associare dati di costo e preclick anche per periodi PASSATI. Sebbene esistano alcuni tool, anche online, per semplificare il processo, si tratta di una operazione non proprio alla portata di tutti, e comunque limitata ai suddetti dati.
3. il terzo – nuovo – livello è appunto il dimension widening, di cui ironia della sorte si accennava già nel post di annuncio di Universal Analytics linkato sopra. I vantaggi di questo livello sono due: si opera con un file CSV e permette di aggiungere informazioni a pressoché qualsiasi dimensione o metrica presente sullo strumento

Avete letto bene, ho scritto “aggiungere informazioni a pressoché qualsiasi dimensione o metrica”. Partiamo dall’esempio più semplice: un e-commerce di libri salva il numero ISBN di ogni libro che mettiamo nel carrello in una dimensione personalizzata. Se volesse riflettere in piattaforma tutti i dati che conosce su ogni ISBN, dovrebbe far parlare il database dei libri con il CMS del sito, e popolare al volo tante custom dimensions quante informazioni conosce su ogni libro. In questo modo potrebbe avere report sul genere o l’autore più inserito nei carrelli, che non necessariamente si riflettono poi nei generi e autori più acquistati.

Con le custom dimensions invece dovrebbe salvare su Google Analytics un grande file CSV con tante righe quanti sono i libri, e in cui ogni riga ha come chiave l’ISBN e come colonne aggiuntive le informazioni. Istruendo GA a considerare la custom dimension che contiene l’ISBN come chiave del dimension widening, lo strumento popola i report di conseguenza durante l’analisi, senza bisogno di mettere in piedi tracking “al volo”.

Se questo è chiaro possiamo passare allo step successivo: ripetete l’esercizio mentale con metriche o dimensioni (ad eccezione di variabili personalizzate, dimensioni e metriche relativi ai prodotti e-commerce, dimensioni relative alle campagne, dimensioni relative al tempo o alla geografia) che sono già presenti normalmente sullo strumento! 🙂
Un esempio pratico? metadati relativi a tutti gli URL del vostro sito: autore, categoria, data di pubblicazione, tags…

Il processo è descritto nel blog di Justin, e non è proprio “1 click”, ma non è nemmeno impossibile da seguire. Per siti con grandi volumi di informazioni da mantenere aggiornate è disponibile una API per uploadare file CSV aggiornati, in modo che le informazioni in piattaforma non siano obsolete. Questo anche perché è bene ricordare che le modifiche apportate attraverso il dimension widening non sono applicate retroattivamente ai dati già registrati, ma vengono applicate in fase di analisi ai dati futuri. Tanto quanto i filtri, sbagliare qualcosa può avere effetti indesiderati, quindi consiglio di fare prima delle prove su profili e account di test, giusto per essere sicuri…

Ho notato un post curioso su Google+ che parlava della dimensione “visitor bucket”, che non avevo mai visto ne sentito. In italiano si chiama “segmento visitatori” ed è disponibile sia nei custom report sia nei segmenti avanzati.

In pratica serve a dividere qualsiasi dato in 10 diversi bucket, o segmenti. Anzi, oserei quasi affermare che funziona al contrario: ad ogni visita viene assegnato un bucket a caso, ed esso viene registrato nell’apposita dimensione. A che pro? ad esempio per segmentare a caso quantità di dati molto grandi. Diciamo che sei arrivato ad esaurire le dimensioni di un custom report ma hai ancora un campione troppo ampio? segmenti per visitor bucket. Oppure che vuoi analizzare il comportamento di un sottosegmento casuale di un segmento avanzato (magari in ottica split test)? aggiungi una condizione sul visitor bucket.

La dimensione è rappresentata da un numero compreso tra 1 e 100 e come detto compare solo in segmenti avanzati e custom report, il che significa che non è disponibile come dimensione secondaria, e che nella mente degli ingegneri di Google probabilmente è una specie di “ultima spiaggia” in termini di segmentazione

Se leggeste tutti i messaggi, mail, forum e gruppi che leggo io su Analytics (o quantomeno se leggeste gli stessi che leggo io) sapreste benissimo che il mondo delle API che ad alcuni sembra una cosa oscura e “di nicchia” è vivo e vegeto e migliaia di persone creano applicazioni utili attraverso di esse. Non solo, esse vorrebbero di più, e continuamente si lamentano che nelle API non c’è questa metrica, vorrebbero questa dimensione, non si può incrociare quei dati.

Con l’aggiornamento di ieri molti di loro saranno stati soddisfatti, giacché il blog ci informa che sono ora disponibili oltre 40 nuove metriche e dimensioni: la lista completa è in questa pagina.

All’interno dell’ultimo update troveremo quindi metriche relative al social (bottoni sociali e interazioni offsite), ai dispositivi mobili, al dettaglio dei contenuti e ai tempi utente.

Insomma, un sacco di roba, potete provare da voi le novità attraverso il data query explorer 🙂

Mi scrive Imma con questa domanda:

non riesco a capire perché i dati che ottengo dalle API non corrispondono a quelli che vedo in analytics. Come metrica sto utilizzando ga:organicSearches, come intervallo di tempo tutto dicembre, e ottengo come risultato 1421, mentre dalla piattaforma di analytics mi risulta che le visite organiche siano 1520.

La prima risposta porta la soluzione del problema, cioè usare la metrica giusta: ga:visits, dimensione ga:medium e filtro ga:medium==organic
cioè con questa richiesta (cambiando opportunamente le date, ovvio):

https://www.google.com/analytics/feeds/data?ids=ga%3A284804&dimensions=ga%3Amedium&metrics=ga%3Avisits&filters=ga%3Amedium%3D%3Dorganic&start-date=2011-12-09&end-date=2011-12-09&max-results=1000

poi la risposta alla domanda “ma allora ga:organicsearches cosa è?”: secondo la definizione ufficiale rappresenta il numero di ricerche organiche che si verificano durante una sessione. Secondo questa risposta di Nick Mihailovski è un conteggio delle sorgenti organiche per una stessa sessione, quindi nel suo esempio di sessione organic > organic > ppc ga:organicsearches avrebbe valore 2. Ma la sua risposta è precedente al cambio del conteggio delle sessioni in GA, quindi oggi la spiegazione non è più del tutto aderente alla realtà. Poiché ogni volta che cambia il cookie __utmz viene creata una nuova sessione ga:organicsearches dovrebbe combaciare con la visite organiche, tranne per il fatto che quando si fa una visita da organico e poi si ritorna da traffico diretto, Google conteggia la visita come proveniente dal motore di ricerca. ga:visits per quella keyword si incrementa di uno, ma ga:organicsearches no.

E questo dovrebbe spiegare la differenza nei due valori.

[edit: il valore esiste anche nell’interfaccia: basta creare un Custom Report e aggiungere la metrica “Ricerche Organiche”]