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).
Da qualche giorno la panoramica di profilo, cioè la schermata che si apre in modo predefinito quando accediamo ad ogni profilo, si presenta rinnovata, e risulta ottimizzata per gli schermi più larghi. Questo perché l’elenco delle metriche principali e le relative sparkline sono ora disposte in modo fluido e affiancato, ed occupano spazio in larghezza invece che in verticale.
Altro cambiamento interessante è il modo elegante con cui i designer hanno risolto un problema che affliggeva il report “principali percorsi di conversione” nelle canalizzazioni multicanale. Fino a qualche giorno fa i percorsi con canali ripetuti venivano esplicitati interamente, e questo significava che – ad esempio – i percorsi che avevano richiesto 13 visite dirette vedevano il quadratino “diretto” ripetuto 13 volte, occupando molto spazio sia in orizzontale sia in verticale senza aggiungere nessuna informazione al dato (anzi, costringendo a contare i quadratini per conoscere il dato quantitativo).
Il report è stato ridisegnato per comprimere il numero di quadratini ed esplicitare il numero di ripetizioni dei canali, in questo modo:
Oltre che maggiore leggibilità, è adesso chiaro a colpo d’occhio quante volte ogni percorso viene ripetuto, alleggerendo il lavoro dell’analista.
“un altro passo verso” è in realtà un eufemismo, perché Google Analytics un prodotto enterprise lo è già da tempo. Però a volte gli mancano alcune piccole feature che sono banali da costruire e che invece tutti gli altri hanno da tempo. Una di queste feature è lo storico dei cambiamenti apportati, funzionalità che GA si appresta a colmare tra qualche settimana.
Prima è comparso un avviso dopo aver fatto la login (a proposito, ottimo modo per diffondere notizie sul prodotto, senza costringere gli utilizzatori a tenere d’occhio blog, twitter e altro…), ora è il turno del blog ufficiale.
Sostanzialmente per gli ultimi 180 giorni è presente un log completo di “chi ha fatto cosa”, relativamente a cambi su utenti, account, profili, obiettivi e filtri. La change history sarà visibile solo agli account con livello admin, poiché esiste a livello di account e non di singolo profilo. In questo modo sarà più semplice risalire a chi ha fatto una modifica, e chiedere conto del perché. Sarà anche meno facile che qualche malintenzionato (non avete idea di quante richieste di aiuto per danni fatti da ex-dipendenti e collaboratori ci siano sul forum ufficiale) possa fare danni senza essere scoperto.
In progetti con molti attori e ampia base di utenti è un cambiamento molto importante e utile. La funzionalità è in fase di rilascio, anche se è possibile che debba trascorrere qualche settimana prima che la vediate nei vostri account.
Una delle cose che a mio avviso è sempre mancata in Google Analytics era un modo semplice per inviare transazioni multivaluta, un problema molto sentito dagli e-commerce internazionali. Poiché nel codice di tracciamento e-commerce non è mai specificata la valuta, essa veniva impostata a livello di di profilo tramite l’apposita opzione nell’amministrazione.
Se il tuo e-commerce vende in molti paesi con valute diverse, la soluzione è sempre stata “converti tutto in una unica valuta PRIMA di inviare la transazione”.
Oggi non è più così perché il team di Google Analytics ci informa tramite un post sul blog che è arrivata la multivaluta: GA provvederà ad effettuare la conversione nella valuta principale che è stata specificata nel profilo.
Prima domanda: quale tasso usano i server di Google? usano il tasso medio di conversione del giorno precedente all’analisi, ricavato dallo stesso server di Google Billing (che se non ho capito male dovrebbe essere lo strumento ufficiale di fatturazione di Google, giacché non esiste un servizio che si chiama così).
Seconda domanda: come faccio ad usare il multivaluta? basta aggiungere una sola funzione e conoscere il codice ISO 4217 corrispondente alla valuta. Attualmente sono supportate 31 diverse valute in Google Analytics.
Ad esempio una transazione in euro avrà questa funzione prima di _trackTrans
_gaq.push(['_set', 'currencyCode', 'EUR']);
mentre una transazione in peso messicani avrà questa funzione
_gaq.push(['_set', 'currencyCode', 'MXN']);
A livello di report saranno poi disponibili specifiche metriche relative alle transazioni nella loro valuta originale. Se ne possono vedere alcune nello screenshot postato sul blog di Analytics
Terza domanda: ho un ecommerce in una sola valuta. devo cambiare i miei tracciamenti? no, questa operazione è necessaria SOLO se si vogliono registrare transazioni in più valute e si vuole che Google si occupi della conversione automaticamente.
La novità di cui parlavamo nello scorso post non si è fatta attendere tanto: da qualche giorno sono presenti due nuovi tipi di monitoraggio, quando si seleziona il tipo di tag “Google Analytics”:
il primo è “monitoraggio interdominio per link” (orribile l’espressione “interdominio”) e serve a creare sul tag manager l’equivalente della funzione _link. Il secondo è “monitoraggio interdominio per post di modulo” e serve a ricreare l’equivalente della funzione _linkByPost.
Non ho ancora avuto tempo di provarle, ma il fatto che si possano definire delle macro e il fatto che il tag non sia legato a un ID – almeno nella versione _link – mi fa sperare che basti mettere quel tag su una pagina, e che esso si preoccupi automaticamente di immettere la funzione _link su tutti i collegamenti che puntano all’url specificato.
Leggermente più complesso il discorso su _linkByPost, che voglio testare per bene prima di scriverne.
Sempre a proposito di macro, è stata introdotta anche la possibilità di usare una macro per definire il numero UA-XXXXXXX-Y. Questo è veramente interessante e permette di snellire molto il numero di tag necessari, specialmente nei profili multidominio/multilingua.
La settimana scorsa il team di Google ha tenuto un webinar tecnico sul Tag Manager, argomento che riscuote un discreto successo ma ha bisogno di approfondimenti, a giudicare dalle domande che leggo in giro.
Tra le tante risorse utili mostrate, un comodo cheat Sheet con una procedura sensata e ragionata sulla migrazione dei codici al Tag Manager, sempre utile da tenere sott’occhio, e il link al forum ufficiale di supporto, oltre ad una serie di domande e risposte che meritano attenzioni particolari, e che riassumo qui:
– posso mettere il codice del tag manager nell’HEAD?
Viene consigliato di metterlo subito dopo l’apertura di body perché il codice contiene un iframe (per chi non ha javascript abilitato), e gli iframe nell’head non ci possono stare. E’ vero che i moderni browser sono abbastanza tolleranti nei confronti di errori di questo tipo, tuttavia si ricade in un caso non standard e non vi è garanzia che tutto possa sempre funzionare al meglio.
– come faccio a usare macro ed eventi se non ho accesso al codice delle pagine?
impostare un dataLayer è una best-practice, ma non è l’unico modo possibile di operare. Si possono creare macro anche a partire da variabili javascript o elementi del DOM (Document Object Model), ad esempio se il valore è dentro a un certo div con un certo ID. Poiché il tag manager è asincrono, un evento di questo tipo potrebbe essere sparato prima che il documento sia stato caricato completamente, risultando in una macro vuota. Per ovviare a questo problema esiste una regola particolare – evento uguale a gtm.dom – che si preoccupa di aspettare che l’elemento indicato sia stato effettivamente caricato prima di eseguire la regola e il tag.
Un’altra via è quella di iniettare dei dataLayer.push() attraverso tag HTML personalizzati, ad esempio sfruttando jQuery. Google non garantisce questa soluzione, ma dice di aver sentito di gente che c’è riuscita. Io non l’ho mai detto a Google, ma una soluzione così l’ho fatta funzionare già a inizio Dicembre, quindi posso garantire che almeno in questa fare funziona eccome 🙂
– come faccio il cross domain tracking?
da qualche tempo è disponibile l’apposita opzione (ve l’ho mostrata nel post “guida pratica alle opzioni del tag manager“), oppure potete sempre usare un tag HTML personalizzato. La grande notizia è che nel post si annunciano prossime novità per rendere ancora più semplice il tracking multidominio. Che abbia a che fare con la scomparsa della documentazione riguardante _setDomainName(none) (almeno dalla pagina discorsiva, perché nella reference c’è ancora), scoperta da Enrico Pavan?
– perché non posso usare tag con document.write?
il Tag Manager è asincrono, e document.write scrive fisicamente qualcosa all’interno della pagina. Questo significa anche che l’esecuzione del contenuto del Tag Manager può avvenire mentre la pagina si sta caricando (escluse le regole gtm.dom come abbiamo visto sopra) o quando ha finito di caricare. Scrivere un pezzo di pagina allora potrebbe portare a risultati inattesi. Poiché la maggior parte dei tag document.write servono a scrivere dei pixel di tracciamento, è presente un template apposito per ricostruire l’url dei pixel attraverso le macro, e poter così migrare anche quei tag.
Non conoscere tutte le funzioni possibili da utilizzare nello script di Google Analytics porta molte persone a domandarsi cosa siano tutte le opzioni disponibili quando si configura un tag di Google Analytics usando il Google Tag Manager. Ho pensato di farvi cosa utile riportando uno screenshot con le varie opzioni e il loro equivalente nella notazione “classica”, cioè quella che si deve fare quando non si usa il GTM.
Un paio di annotazioni:
– le funzioni che hanno solo la spunta sono, ovviamente, accese o spente, vere o false.
– le funzioni che si occupano dei timeout vogliono il tempo espresso in millisecondi, mentre l’interfaccia del tag manager ci facilita chiedendo i SECONDI (in verde nello screenshot); tenetelo presente se le usate o se dovete tradurre funzioni già in essere.
– se la funzione di cui avete bisogno non è tra quelle indicate, non c’è altra soluzione che usare un tag HTML personalizzato, dentro al quale dovrete riscrivere TUTTO il codice di Google Analytics che normalmente avete sulla pagina. Tanto per essere chiari, se dovete usare la funzione _setSiteSpeedSampleRate, che non è prevista dal GTM, vi tocca per adesso fare un tag HTML custom con dentro
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-Y']);
_gaq.push(['_setSiteSpeedSampleRate', 5]);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
Detto questo, ecco la legenda. Clic per ingrandirla:
Da qualche ora quando si apre Google Analytics si viene accolti da una nuova schermata di benvenuto: secondo me graficamente un po’ peggiore della precedente, ma indubbiamente più utile perché contiene più informazioni:
Vengono mostrati i Google Analytics account, con la possibilità di espanderli tutti o comprimerli tutti. Al clic su uno di essi compaiono le web properties e i profili, e a patto che sia selezionato il pulsante “mostra metriche”, per ogni profilo ci vengono mostrate le visite, il tempo medio delle sessioni, la frequenza di rimbalzo e il tasso totale di conversione all’obiettivo. Questi dati si basano sul periodo temporale selezionato, e cambiano variandolo.
Esiste anche una modalità diversa, in cui i profili vengono elencati di seguito e senza essere suddivisi in account e proprietà web: questa modalità è molto utile per avere il colpo d’occhio sulla situazione di tutto quel che monitoriamo con la nostra login, sarà sufficiente scorrere l’elenco verso il basso.
Meglio ancora, attivando il confronto temporale e usando la nuova modalità, guardate che estrema utilità si raggiunge!
Ottimo lavoro, ecco la nostra nuova schermata da controllare ogni mattina 🙂
SemaforoQuesto semaforo indica il livello difficoltà del post
