Google Analytics in 30 secondi

Questo caso non è molto comune perché si verifica solo in determinate circostanze, ma siccome a qualcuno capita e la soluzione non è banale, ve ne parlo qui.

Il problema è che in alcune situazioni l’interfaccia di Google Analytics impedisce di aggiungere un segmento avanzato, mostrando non selezionabili le caselle di spunta; esattamente la stessa situazione che si verifica quando abbiamo già selezionato quattro segmenti (che vi ricordo essere il numero massimo di segmenti impostabili su un report), solo che noi abbiamo al momento soltanto il segmento “Tutte le visite”.
Secondariamente, il problema non si verifica mai all’inizio delle nostre analisi, ma genericamente dopo qualche tempo.
Terzo, il problema tende a presentarsi tanto più spesso quanti più profili possiamo vedere nel nostro account.

Prima di addentrarci nella soluzione voglio ricordarvi un fattore che molti spesso dimenticano, e che come vedremo è alla base del verificarsi del problema. Quando si crea un segmento personalizzato, per impostazione predefinita esso è disponibile in tutti gli account e i profili a cui ha accesso la mail che sta operando su Analytics in quel momento.

Tuttavia un segmento avanzato può anche essere “limitato” ad essere visibile soltanto su alcuni profili, tipicamente questa impostazione serve quando un segmento è troppo specifico per essere utile ovunque (per esempio tutti i segmenti che includono un certo brand, che sono utili solo e soltanto nei profili attinenti quei brand).

Supponiamo di avere quindi:

profilo A – segmento per il brand A (visibile solo nel profilo A)
profilo B – segmento per il brand B (visibile solo nel profilo B)
profilo C eccetera…

E’ mattina, apro Google Analytics e inizio la mia analisi dal profilo A, e oggi è giornata di analisi sul brand. Analytics mi preimposta il segmento “Tutte le visite”, io uso il menu a tendina dei segmenti e faccio una comparazione tra “Tutte le visite” e “segmento brand A”. mi rigiro un po’ i dati, guardo un grafico a torta, traggo le mie conclusioni.
Passo al proilo B, Analytics mi lascia nel report in cui sono ma switcha di profilo: ritorno a vedere soltanto “Tutte le visite” e quindi seleziono anche “segmento brand B”. Finisco le mie analisi, passo al profilo C con il segmento C, finisco anche quelle e quando arrivo al profilo D, ecco che non posso più aggiungere nessun segmento.

Esatto, il problema è che Analytics ricorda i segmenti che abbiamo selezionato, anche se non ce li mostra perché indisponibili negli altri profili; se vogliamo pensarla in un altro modo, il “contatore” dei segmenti avanzati selezionati non si azzera quando passiamo di profilo in profilo, ma resta sempre uguale, mentre la visibilità dei segmenti invece varia in conseguenza delle impostazioni dei segmenti stessi.

Il problema non si presenta quando usiamo un segmento che è disponibile su tutti i profili: cambiando profilo l’impostazione viene mantenuta e noi ci ritroviamo le due, tre o quattro linee colorate nei grafici, e i segmenti attivi. La soluzione al problema quindi, è disattivare i segmenti che non ci serviranno nel profilo che andremo a selezionare prima di cambiare, perché altrimenti bisognerà tornare indietro su ogni profilo e deselezionare uno ad uno i segmenti, oppure ripartire da zero “pulendo” il contatore dei segmenti avanzati.

Un po’ noioso, lo so, ma quel che in certi casi è un vantaggio (lo strumento tiene memoria delle cose selezionate al momento quando cambio profilo) in altri casi si tramuta in uno svantaggio.

L’altro giorno ho trovato la segnalazione di questa discussione nel forum di Giorgio Taverniti: “a che ora i miei fan interagiscono di più?“. Niente da eccepire sul contenuto del post, se non che come dico nel primo commento la mancanza di un filtro nel custom report mi costringe a fare dei clic in più. Siccome noi siamo analisti precisini, noiosi e ripetitivi, ogni clic risparmiato è un clic guadagnato 🙂

Quindi, siccome l’obiettivo del post è l’analisi delle interazioni orarie per le provenienze da Facebook, ne approfitto per ribadire un concetto che molto spesso non vedo applicato come si dovrebbe: il custom report filtrato all’origine. Un custom report è un rapporto che in Google Analytics non esiste, e che viene calcolato “al volo” sulla base delle nostre indicazioni. Ad esempio proprio quello discusso sul forum GT, cioè le ore di arrivo delle visite per ciascuna sorgente.
Però il custom report così come viene proposto risponde (con DUE clic) alla domanda: “a che ora interagiscono tutti i miei utenti, divisi per sorgente?”. Per rispondere alla domanda originale propongo due variazioni:

La prima è appunto l’inserimento di un filtro direttamente nel custom report: si elimina la prima dimensione (la sorgente) e si usa il filtro per mostrare SOLO facebook. Il filtro si trova subito dopo la sezione delle dimensioni nel custom report, come in figura (clicca per ingrandire):

In questo modo aprendo il custom report si hanno SOLO le visite provenienti da Facebook, esplose per ora e senza necessità di clic aggiuntivi.

La seconda modifica è l’aggiunta di una seconda tab, che se trovate migliore potete anche spostare come prima (o usare solo questa), e cioè una tabella piatta con sorgente / ora e metrica visite. Questo report permette di distinguere le varie tipologia di sorgente Facebook (sito, app, sito mobile, campagna se avete usato facebook come source…) ma di avere lo stesso a portata di mano già all’apertura le ore in cui sono divise le visite. Vedasi screenshot (clicca per ingrandire):

.

Se volete, potete scaricare il tutto e salvarlo direttamente nel vostro Google Analytics: basta cliccare questo link mentre si è loggati nel proprio account Google.
Ripeto, nulla di eccezionale, ma solo un modo più veloce per arrivare al dato. Alternativamente potete usare il custom report proposto nel forum di Giorgio e usare le scorciatoie per arrivare direttamente alle sorgenti desiderate, se ne avete più d’una.

Una delle cose più belle (e incredibili, se ci pensiamo un attimo) di Universal Analytics è la possibilità di tracciare qualsiasi cosa, in qualsiasi modo, attraverso il Protocollo di Misurazione ideato dagli ingegneri di Google.
In buona sostanza fintanto che si inviano richieste nella forma corretta, Analytics le riceverà e le elaborerà proprio come ha sempre fatto. Il nuovo SDK per Android – se non ho capito male – si basa su questo tipo di interazione, valorizzando opportunamente i campi app name e il tipo di hit inviata.

Poiché non mi piace parlare di cose che non conosco, prima di scrivere qualcosa in proposito mi sono dotato di un accesso alla beta pubblica e ho “giocato” un pochino con la nuova funzione. Allo stato attuale dello sviluppo tracciare con analytics.js invece di ga.ja comporta poco più di un cambio di sintassi, e parecchie funzioni in meno da ricordare poiché molte cose possono essere configurate lato server. Ma non è questo il punto importante, perché subito dopo aver inviato una hit valida attraverso il javascript mi sono concentrato sul measurement protocol: volevo mandare una hit senza usare il file di Google.

E trattandosi di una API ufficiale, ovviamente funziona: ho inviato delle pagine viste e delle visite attraverso PHP, ancora prima che la pagina venisse mostrata al mio browser. Naturalmente l’ho fatto male, usando degli assunti che mi facevano comodo (ad esempio, un cookie col nuovo formato deve già essere presente nel browser) e con del codice che mi vergogno a mostrare, ma funziona, è fattibile.

Subito dopo mi sono interrogato sul come e sul quando questa cosa poteva dimostrarsi utile, dandomi alcune prime risposte, ma soprattutto pensando a una certa categoria di utenti che non accettano mai javascript e cookie: gli spider. Se è possibile inviare hit ad Analytics senza usare javascript (non è una novità, ma questo è il metodo ufficiale, che si presume molto più robusto e a lungo termine), allora un SEO potrebbe usare Universal Analytics per tracciare anche – o solo – gli spider, mimando esattamente le stesse informazioni contenute nei logfiles che è costretto ad utilizzare adesso. Potrebbe avere qualche vantaggio a farlo perché così potrebbe usare l’interfaccia di Analytics per le sue analisi, quindi segmentazione avanzata, dimensioni secondarie, report personalizzati… pensiamo un secondo soltanto al real-time, quali spider sono sul sito in quale momento (magari sapendo anche in base a quale avvenimento questo accade). Carino no?

Addirittura creando un hash che comprenda indirizzo ip, user agent e qualche altro parametro si potrebbe pensare di assegnare un ID differente per ogni spider, aumentando le possibilità di personalizzazione e i casi d’uso possibili. Insomma le possibilità sono tante, e la tecnica – ufficiale – adesso c’è: basta risolvere un paio di problemini e adattare il tutto alle proprie esigenze, ma non ci vedo particolari impedimenti. Credete che diventerà una pratica normale?

[a proposito di web analytics senza javascript, c’è chi lo dice da anni: “il futuro della wa è senza javascript?“]

Come ogni prodotto nuovo che si rispetti, dopo una breve fase di rodaggio arriva il tempo delle migliorie, che nel caso del Google Tag Manager possono essere molte e sotto molti aspetti.
La prima infornata riguarda – come è lecito aspettarsi – una migliore integrazione con Google Analytics, per cui da qualche giorno:

• il tracking ecommerce è abilitabile con una regola specifica: purché il dataLayer sia popolato seguendo il naming delle variabili illustrato in questa pagina di help, è sufficiente creare un tag di tipo Google Analytics – transaction
• E’ possibile abilitare il codice di remarketing con una sola spunta in fase di creazione del tag di base, selezionando la spunta su “Aggiungi assistenza per gli inserzionisti display”
• sono disponibili setting aggiuntivi per il codice di Google Analytics sotto la voce “altre opzioni”: essi sono pagine virtuali, frequenza di campionamento, timeout dei cookie di sessione, uso di _setAllowAnchor, timeout dei cookie di campagna, custom var, _setAllowLinker, _setCookiePath, _setDomainName e _setAllowHash

Ecco lo screenshot di tutte le nuove funzionalità insieme:

E’ stato anche risolto un bug relativo agli eventi, segnalato tra gli altri da Andrea Scarpetta. Adesso si possono riportare i parametri degli eventi a “nulli” senza doverlo ricreare da capo 🙂

Il report In-Page Analytics è sempre stato un po’ bistrattato dagli utenti con cui ne ho parlato: tutto è migliorabile, per carita, e lui non ha mai brillato per utilità, ma è vero che in alcune cose aveva la sua parte di cose da dire, specialmente da quando hanno aggiunto i report sul viewport effettivo dei visitatori. Una delle cose per cui il report era meno utile, invece, era cercare di capire quale link fosse stato cliccato di più per muoversi da una pagina all’altra: questo perché il report era fatto “all’indietro”, cioè Google Analytics sapeva quante persone hanno visto una certa pagina e quante quelle dopo (e i loro url) e quindi ricalcolava la percentuale di visite che passavano da un link. Ma se c’erano più link alla stessa pagina – ad esempio un link identico nell’header e nel footer – GA assegnava ad entrambi la stessa percentuale, non aveva modo di distinguere i link. E’ sempre esistito un workaround, ma tra poco non sarà più necessario: il report In-Page guadagna da solo la possibilità di distinguere i link!

Per usufruirne è necessario modificare il codice di tracciamento in questo modo:

var _gaq = _gaq || [];
var pluginUrl = '//www.google-analytics.com/plugins/ga/inpage_linkid.js';
_gaq.push(['_require', 'inpage_linkid', pluginUrl]);
_gaq.push(['_setAccount', 'UA-XXXXXX-Y']);
_gaq.push(['_trackPageview']);

e bisogna anche abilitare il tracciamento tramite le opzioni della proprietà web. Finché non vedete quella opzione, significa che non siete stati raggiunti dal rilascio di questa funzionalità.

Il tutto non si basa più sul derivare i dati, ma piuttosto sul calcolo “al volo” dei passaggi: per ogni clic viene settato un cookie temporaneo che registra l’ID dell’elemento cliccato, e nella pagina successiva questa informazione viene inviata ai server di Analytics. La descrizione completa del processo è disponibile nella pagina di help della funzione

Mi è capitato recentemente un caso che non vedevo da tempo, e anche se ne ho già parlato in passato è utile una ripassata, perché è una di quelle cose piccole che può far perdere tanto tempo.

Il caso, nella sua forma più estrema, è questo: un profilo non traccia niente, nonostante il codice sia installato correttamente.
Innanzitutto mi accerto che il codice sia davvero installato correttamente: a questo proposito l’estensione GA debug di Google è senza dubbio quella che dà più informazioni in assoluto. Siccome il codice c’è, e le chiamate partono, il problema deve essere per forza nel profilo: di solito è un problema con i filtri, e infatti il profilo dovrebbe raccogliere dati da tre diversi sottodomini. Sono stati quindi approntati tre distinti filtri sul nome host:

• includi solo l’host a.sito.it
• includi solo l’host b.sito.it
• includi solo l’host c.sito.it

Nella testa delle persone, che ragionano come persone, questo si tramute in italiano in “includi solo il traffico da a, oppure da b, oppure da c”. In realtà l’analisi delle hit nei filtri di Google Analytics è sequenziale, e le hit per essere accettate devono passare sempre da tutti i filtri di inclusione.

Quel che accade nel server di Google, che ragiona come un computer, è quindi questo:

ARRIVA UNA HIT DA QUALSIASI ALTRO HOST: il server la passa al primo filtro, e siccome non soddisfa la condizione viene scartata.
ARRIVA UNA HIT DA A: il server la passa attraverso il primo filtro, e soddisfa la condizione, la passa al secondo filtro, ma non soddisfa la condizione: viene scartata.
ARRIVA UNA HIT DA B: al primo filtro viene già scartata.
ARRIVA UNA HIT DA C: al primo filtro viene già scartata.

Anche cambiando l’ordine dei filtri – adesso capite perché è possibile impostare un ordine? – il risultato non cambia; nessuna hit arriverà mai al profilo.

La soluzione è fare un unico filtro di inclusione con espressione regolare (a|b|c)\.sito\.it, in modo che ogni hit debba rispondere ad una sola domanda del server: “questa hit arriva da a OPPURE b OPPURE c?”. tutte le volte che la risposta è “si”, il profilo riceverà quella hit e le informazioni relative.

Il problema potrebbe essere esteso a tutti i casi in cui si debba utilizzare più filtri di inclusione sullo stesso campo, quindi ad esempio “includi solo questi indirizzi IP”, “includi solo queste pagine” e così via. Il consiglio è sempre “un solo filtro di inclusione per campo“.

Uno non fa in tempo ad abituarsi all’idea che in Google hanno finalmente creato una cosa che immaginavamo da tempo, e dopo due ore salgono due tizi su un palco e la migliorano ancora!

Vado stringato, che per alcune cose nemmeno io ci ho capito troppo (un tweet è poco per capire una feature, a volte…):

• i modelli di attribuzione, attualmente solo per GA Premium, saranno estesi anche alla versione free
• si potranno importare dati di costo da qualsiasi fonte: ShufflePoint ha già un prodotto funzionante in tal senso, si chiama In2GA
• dovrebbe arrivare una nuova sezione chiamata Acquisition, con report ad hoc per mostrare chiaramente i tre step della vita di un visitatore: acquisizione, comportamento sul sito e guadagni derivanti (outcoming)
• i raggruppamenti di canali dei multi channel funnel saranno – finalmente – condivisibili
• Google Analytics avrà un campaign manager integrato: niente più utm_source, utm_medium e altri parametri: si potrà creare una campagna dall’interfaccia e avere link con un unico identificativo
• prima o poi (ho visto passare un tweet velocissimo, prendiamolo con le molle!) potrebbe essere introdotto una specie di intelligence per il budget: tipo “dove mi conviene spendere i miei soldi”, basato sui dati presenti in piattaforma
• le nuove custom dimensions/metrics avranno 20 slot nella versione free, e 200 nella Premium
• nel post precedente ho menzionato l’import di dati per le custom dimensions: il limite sarà di 50 milioni di righe 🙂
• Segmentazione a livello visitor, praticamente come fa Webtrends attraverso Segments: significa poter creare un segmento basato su un visitatore, indipendentemente da quando s’è collegato, quante volte, con quale dispositivo e da quale fonte
• Report per l’analisi del valore progressivo del cliente (CLV = Customer Lifetime Value)
• Report per l’analisi della frequenza, fidelizzazione e introiti (RFM = Recency, Frequency, Monetary). Se dividiamo gli utenti in quattro quadranti (visite vecchie/recenti, pochi/tanti acquisti,) vorremo sempre avere che fare con il quadrato “nuovi, tanti acquisti). Questi report dovrebbero permetterci di analizzare questo tipo di dato.
• Remarketing real-time basato su Visitor Segments

E siamo a metà pomeriggio, ora Californiana 😀

[edit: e mi stavo dimenticando del primo annuncio, che da solo sarebbe valso un post ma che evidentemente passa talmente in secondo piano da farmelo tralasciare durante la scrittura: real time avrà presto la visualizzazione dei GOAL 😀 ]

Oramai ci siamo, siamo nella famosa “Business Platform“, possiamo dirlo senza mezzi termini: durante i primissimi minuti del Google Analytics Partner Summit 2012 è stato annunciato l’arrivo di Universal Analytics, ovvero la prossima versione di quel che fino ad oggi abbiamo chiamato Google Analytics. Magari il nome non cambierà, ma il concetto stesso di misurazione cambierà.

Praticamente GA non sarà più uno strumento basato sulle sessioni, come lo abbiamo conosciuto fino ad ora, ma sarà user-centrico, cioè basato sull’utente (sempre senza registrare dati personali): questo significa che potenzialmente sarà in grado di risolvere una volta per tutte il dilemma del cross-device tracking, ovvero lo stesso utente che si collega da più dispositivi diversi: dettagli ancora non ce ne sono, e probabilmente il tutto sarà fattibile per chi in qualche modo si logga al sito, ma il balzo in avanti è che non si dovranno più legare le sessioni, come si potrebbe già fare oggi con le variabili personalizzate, ma si legheranno gli utenti, e le loro sessioni saranno solo una conseguenza.

Il tutto si baserà sulla definizione di “user-ID“, che potranno essere poi passati a GA attraverso una API documentata, e con delle librerie sviluppate da Google o da terzi. Addio alla presenza di cookies multipli, addio al cross domain tracking. Come ci spiega egregiamente il solito Justin Cutroni, l’identificazione delle sessioni avverrà lato server, e nei browser dei visitatori resterà soltanto l’identificativo univoco. Questo vuol dire che l’aggiunta di motori di ricerca, il cambio della durata del cookie o altre operazioni che adesso siamo abituati a fare aggiungendo funzioni al codice di GA, potranno essere fatte dall’interfaccia, lato server.

Poiché si sta parlando a tutti gli effetti di usare una API per tracciare le visite, vorrei per prima cosa soffermarmi su questa vecchissima previsione di Ian Thomas che risale addirittura a Maggio 2008: 2 delle tre si sono già avverate, mancava la terza, e cioè l’esistenza di una “standard API” bidirezionale che permettesse a chiunque di tracciare pressoché tutto dentro a Google Analytics.

Quando dico “tutto”, intendo anche ad esempio le conversioni offline: ad esempio stampando il visitor-ID su un coupon che viene riscosso offline: si può creare una interfaccia che invierà a GA il “segno” che è stata fatta una conversione da un utente che aveva visto il sito 4 volte da desktop, da certe campagne, e poi due volte da cellulare cliccando quali annunci. Non è affatto male, no? oppure, più in generale, un CRM che dialoga con GA e lo aggiorna su quando un prospect diventa customer, anche attraverso altri mezzi (pensiamo al call center…).

Come se non bastasse, hanno annunciato anche le Dimensioni e le Metriche personalizzate, cioè una delle ultime feature che separavano GA dai grandi nomi della web analytics Webtrends e Adobe; sono un’evoluzione delle Variabili personalizzate. Non basta? ok, si potranno anche IMPORTARE dei csv per ampliare le dimensioni, in un processo che in inglese suona “dimension widening” e che voglio vedere come avranno il coraggio di tradurre. L’esempio nel post di Justin è esemplare:

state tracciando la vendita di libri, voi passate a GA il codice ISBN, e poi con comodo attraverso un csv importare nome autore, data pubblicazione e altri dati. Potrete legare le metriche di Analytics a tutti questi dati, senza bisogno di farlo al momento della collezione dei dati, quindi via codice.

Tutto questo nella prima ora e mezza di summit, che dura due giorni. Sopravviveremo? 😀

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!

A nessuno piace avere torto, questo è innegabile. A me nemmeno. Esiste però un’eccezione: quando io dico “no, questo è impossibile, Google Analytics non lo farà mai” e poi invece lo fa. Lo abbiamo visto quando ha introdotto gli unici per pagina, poi con il real time. A quel punto io ho sempre detto “non supporta i filtri perché la mole di calcoli, già adesso spaventosa, sarebbe ancora più alta”.
Ormai dovremmo avere imparato che se è solo una quesitone di calcoli e tecnologia, Google non ha problemi, e infatti ieri sul blog ufficiale è comparsa la notizia che da adesso il real time supporta i filtri di profilo.

Questo significa praticamente due cose: la prima è che vedrete meno dati, se guardate un profilo filtrato: fino ad ora avete sempre visto passare sul real time anche i dati che sarebbero stati successivamente filtrati in fase di analisi. La seconda è che adesso real time è disponibile anche agli utenti dei profili, e non sono agli amministratori.

Inoltre viene precisato che real time funziona anche con il monitoraggio delle applicazioni mobili, e per debug questa è un’ottima cosa, anche se le richieste spesso vengono accorpate in pacchetti e inviate tutte insieme, per cui potrebbe esserci un ritardo maggiore nell’aggiornamento del real time per una app.

L’altra piccola novità che ho notato è che la creazione guidata di un nuovo profilo presenta adesso un’opzione in più:

“dati di doubleclick” e che selezionandola il codice provvede automaticamente a inserire la chiamata a stats.g.doubleclick.net/dc.js invece di quella a google-analytics.com/ga.js: si tratta del codice necessario quando si fa remarketing attraverso Google Analytics.