Sep 30 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

I dati come i LEGO

autore: Marco Cilia categoria: tagmanager tag: ,

Ultimamente, sempre più spesso, mi è capitato di parlare con persone e intuire come nella loro testa fosse difficile capire le relazioni che ci sono tra gli strumenti che utilizziamo, il modo di trasportare i dati e la loro rappresentazione nel sistema. Grossomodo è la stessa relazione esistente tra chi dice genericamente “il posizionamento” sui motori di ricerca, e un SEO attento che invece conosce la differenza tra fasi distinte di crawling, indicizzazione e ranking (lo so, anche questa è una semplificazione).

La cosa è evidente soprattutto quando si parla di Enhanced Ecommerce e quando di mezzo c’è il/un TagManager. Vediamo di provare a fare chiarezza.

I bei tempi andati

Nei tempi che furono esisteva una relazione stretta, quasi 1:1, tra quel che si faceva in pagina con Google Analytics e la rappresentazione che ne usciva fuori nello strumento: metto il codice di base? ho le pageview. Metto un trackEvent su un pulsante? ogni volta che lo premo avrò un evento su Analytics. Facile, preciso, indolore. Il controllo era assoluto, e ogni azione provocava una reazione. Ho un Ecommerce? metto un ALTRO tag particolare sulla thankyou page per dire ad Analytics che l’utente ha comprato, e cosa, e quanto ha speso eccetera…

l’avvento del TagManager

Il primo “scollamento” tra la relazione stretta è stato l’inserimento del TagManager. Non esiste più una relazione 1:1 tra quel che faccio in pagina e quel che ritrovo sullo strumento (o almeno, non necessariamente anche se si può fare in modo che accada), semplicemente perché in mezzo c’è un altro sistema che possiede una logica propria ed è in grado di “fare cose”. Metto il contenitore del TagManager e dentro c’è il codice di base di GA? ho le pageview. Dentro ci metto un evento GA con la stessa regola? allora avrò per OGNI pagina ANCHE un evento su Google Analytics (non fatelo, non ha senso 🙂 ). Creo un evento GA che parte solo sul click di un bottone, che intercetto con GTM? allora avrò un evento esattamente quando mi serve. Il problema, se così vogliamo chiamarlo, deriva da una scelta infelice degli ingegneri del TagManager, che hanno creato un metodo per pompare informazioni dentro al dataLayer (la struttura di dati che viene letta automaticamente dal GTM) dandogli un naming particolare: event. Ora, quando si usa la sintassi

dataLayer.push({'event': 'video', 'titolo': 'video corso di GA'});

NON si sta creando un evento Google Analytics con category “video” e action o label “video corso di GA” (infatti il TagMAnager non serve solo per GA, questo in teoria dovrebbe essere sufficiente a chiarire la cosa, ma così non è). Si sta semplicemente dicendo al TagManager che c’è una situazione (purtroppo si chiama evento, ma possiamo chiamarlo message, o push) e che la parte di dataLayer che si chiama titolo va aggiornata con l’informazione “video corso di GA”. Se vogliamo farne un evento GA dovremo configurare un tag GA di tipo evento, con category fissa e action o label presi da una variabile dataLayer che legge “titolo”.
Se questa parte di dataLayer esisteva già, l’event fa l’update, se invece non esisteva la crea. E qui inizia il gioco delle costruzioni con i mattoncini. Per ulteriori dettagli tecnici vi invito a leggere il GTMtips #26 di Simo Ahava

l’Enhanced Ecommerce sul TagManager

Il secondo scollamento totale tra quel che si fa in pagina, come viaggiano i dati e che risultato otteniamo in interfaccia è stato l’Enhanced Ecommerce. Per far si che l’Enhanced Ecommerce funzioni a dovere, è necessario fornire i dati in un certo modo. Se si usa il Google TagManager alla pagina linkata ci sono le istruzioni e le configurazioni necessarie affinché questo accada. Ma sono un po’ fuorvianti 🙂
Bisogna capire per bene i tre momenti distinti che servono per arrivare al risultato finale:

  1. devo mettere nel GTM le informazioni necessarie, facciamo l’esempio di 4 impressions. La parte rilevante è QUANDO riesco ad avere queste informazioni. Il programmatore potrebbe averle già quando si crea la pagina, e metterle nel dataLayer che c’è in HEAD. Oppure potrebbe avercele solo ad un certo punto del sorgente della pagina, e quindi fare un dataLayer.push nel body, dopo il contenitore.
  2. devo inviare le informazioni a GA: se le informazioni sono nel dataLayer in HEAD, mi basta il tag di base di GA opportunamente provvisto della spunta “usa Ecommerce avanzato” e “usa struttura livello dati”. Il sistema accoda le informazioni sulle impression a quelle della pageview, per risparmiare hit. Finito. Se invece il programmatore ha dovuto fare un push dopo il contenitore (quindi al 99% DOPO CHE LA PAGEVIEW è già partita verso i server di Google), allora le mie impressions stanno si nel dataLayer, ma ci restano finché non si comunica di nuovo con i server PRIMA di cambiare pagina: ricordate che il dataLayer riparte da zero ad ogni cambio pagina. Allora mi servirà un evento Google Analytics, anche un evento fake inutile per le analisi, che provvisto delle stesse spunte di cui sopra mi fungerà da trasporto per i dati delle impressions

La cosa è spiegata bene solo nell’esempio della thankyou page

EE-purchase

“pusha i dettagli della transazione nel dataLayer usando l’action purchase, insieme ad un evento che azionerà un tag evento con le opzioni ecommerce. In questo esempio, i dettagli della transazione sono conosciuti nel momento in cui la pagina carica, e saranno inviati con una pageview quando si aziona gtm.js (cioè quando si apre la pagina, ndMC)”

conclusioni

Con gli strumenti a disposizione oggi è necessario comprendere bene quale sia il flusso dei dati in fase di collezionamento e di invio. Dimentichiamoci delle relazioni dirette: la pagina parla col dataLayer, che parla col TagManager, che parla con Google Analytics (che parla con noi 🙂 ). Ognuno di questi passaggi ha delle peculiarità e dei punti di attenzione, ma presenta anche grandi opportunità di modifica, razionalizzazione e pulizia dei dati.


Sep 02 2015

Come funziona Tag Assistant Recording

autore: Marco Cilia categoria: codice di monitoraggio

La novità dell’estate del mondo Google Analytics, anche se arriva a fine agosto, è la disponibilità di Tag Assistant Recording, una sorta di v3 del plugin di controllo/debug dei tag Google, di cui vi avevo già accennato in questo post.

Se non sapete di cosa si tratta, partite dallo scaricare l’estensione di Chrome da questo link. In breve l’estensione controlla su ogni pagina la presenza di tag di marketing by Google, quindi Google Analytics, AdWords, Doubleclick, Google Tag Manager. Per ognuno di questi sono disponibili molte informazioni, e si può cambiare il livello di dettaglio di esse utilizzando le opzioni dell’estensione; ad esempio l’estensione potrebbe dire che su una pagina ci sono due Floodlight, due Analytics versione classica e uno Universal dentro a un container TagManager. Che uno dei tag è nella posizione sbagliata, che altri tag non funzionano come previsto, insomma una marea di informazioni utili.

La funzionalità nuova e più interessante però è quella di recording, ovvero l’estensione registra una navigazione e poi vi consente di riguardarla step-by-step con vari livelli di informazioni. Per utilizzarla è necessario premere il pulsante “RECORD“, nella parte bassa dell’interfaccia dell’estensione: da quel momento un classico pallino rosso ci avvisa che l’estensione sta registrando. Dopo aver navigato le pagine che ci interessano ed aver fatto tutte le azioni che desideriamo controllare si può stoppare la registrazione ed avere un rapido sommario che somiglia a questo:

TA-recording-sommario

Il click su “show full report” ci porta ad una interfaccia divisa in due macrosezioni: la prima riguarda un report sui TAG che vengono inviati, quindi tutti quelli supportati da Tag Assistant. Le seconda invece è prettamente dedicata a Google Analytics. Ma andiamo con ordine: il report dei Tag su un sito complesso può assomigliare a qualcosa del genere

TA-vg

e subito notiamo la possibilità di filtrare solo i tag che ci interessano. Di base, il sistema permette di vedere le pagine registrate e per ogni pagina mostra: URL, timestamp della richiesta, tempo di caricamento, numero di tag totali, numero di errori, warning e suggerimenti. Per ogni tag di ogni pagina mostra i metadati, ovvero un riassunto di cosa fa un tag (advertiserID per Floodlight, o UA di Analytics, per esempio), le ottimizzazioni possibili se ce ne sono e le richieste (un tag potrebbe infatti generare più richieste). Per ogni richiesta generata, infine, mostra i metadati, ovvero l’elenco dei parametri, alcuni dei quali sono tradotti in un linguaggio comprensibile mentre altri restano da decifrare.

Spostandosi nella sezione “Google Analytics report” invece l’interfaccia cambia, e a seconda che la mail con la quale siete loggati in Chrome/Analytics abbia o no accesso alla property GA che state analizzando, le possibilità variano. Innanzitutto il menu laterale, che è fatto così:

TA-GA-section

  1. Update report permette di ricaricare il report dopo aver fatto modifiche nella configurazione.
  2. Select Views permette di switchare tra i vari recording di GA, se le pagine inviavano dati a più properties. Nel caso in cui non abbiate accesso ai dati, esce il messaggio “The recording contains hits sent to this property, but you (email@email.ext) don’t have permissions in Google Analytics for its views. You won’t be able to see view-specific information.
  3. Change Location permette di simulare la visita come proveniente da una differente località o da un diverso indirizzo IP
  4. Open permette di caricare un file con una sequenza di hit e Save di salvare la sequenza corrente, per riusi futuri

Nella parte destra invece troviamo un recording summary, con informazioni generali come l’ora della registrazione, il totale delle pagine e dei tag, la property selezionata, ecc, seguita da una sezione di alert, in cui il sistema da una valutazione di quel che ha visto, una sezione di “views summary” che esiste solo se state guardando i dati che andrebbero ad una property cui avete accesso, e che riassume così la visita (clicca per ingrandire)

TA-behavior

Ricordate che siamo FUORI da GA, quindi se avere informazioni su Browser e OS è banale, vi invito a guardare la sezione “conversions” 😉
Il caso d’uso praticamente è questo: voi su un Analytics settate una conversione, poi andate sul sito e registrate la sessione mentre convertite, poi chiedete a Tag Assistant se quella sarebbe stata una conversione; se vi dice no, modificate il setting del Goal, tornate su Tag Assistante e fate Update Report e controllare in tempo reale se la modifica ha senso. Notevole no?
Altra cosa che potete fare, questa però non l’ho provata, è vedere se una richiesta passa indenne o viene modificata da un filtro, nella sezione FLOW -> Hit -> Mutuations

Per finire, se salvate una sessione la potete riusare in futuro; i file hanno estensione .harz
Già questo può essere interessante perché potete scambiarvi o farvi inviare da un cliente la sua navigazione, e controllare come la vede GA senza essere fisicamente da lui o nelle sue “condizioni di rete” (proxy, location, rete, eccetera). Più interessante ancora è che i file HAR sono uno standard per gli archivi di richieste HTTP, e quindi ci sono moltissimi software che possono generarli (un semplice Chrome dal pannello NET, Fiddler, Firefox dalla versione 41 in su, secondo questa lista).
Altro caso d’uso quindi: per strettissime policy aziendali e insormontabili problemi tecnici, è impossibile vedere gli ambienti di staging del nuovo sito del cliente, quindi si dovrebbe configurare alla cieca o quasi. Si va dal cliente, si fa esattamente il percorso di conversione e si registra con Tag Assistant. Dopo si torna in ufficio e lo si testa infinite volte man mano che la configurazione dell’account procede.

Non c’è praticamente limite alle possibilità di debuggare ogni più piccola virgola, in tempi sempre più ristretti e con risultati sicuramente più veloci.