Oct 20 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Esporta e importa configurazioni dal TagManager (e nuova interfaccia)

autore: Marco Cilia categoria: tagmanager tag: ,

Qualche giorno fa è stata svelata al pubblico la nuova versione dell’interfaccia del Google Tag Manager, uno strumento sempre più popolare ed interessante per velocizzare il digital marketing moderno. Le novità sono tante, ma una in particolare è passata completamente inosservata nei post che ho visto in giro: da adesso è possibile esportare e importare intere configurazioni. Tutti voi dovreste vedere una nuova voce nel menu attuale del GTM:

GTM-export

L’export avviene in formato JSON, mentre l’import può comportare due opzioni:

  • L’import sostituisce completamente il contenitore corrente
  • L’import unisce il contenitore importate con quello corrente

Oltre che essere utile per la migrazione all’interfaccia nuova, che vedremo tra poco, questo consente anche di avere un contenitore “repository” con tutto lo scibile che si può mettere a disposizione, e di usarlo velocemente per creare configurazioni alle quali basta poi togliere le feature inutili. Attualmente infatti ogni nuova configurazione riparte da zero.

Per quanto riguarda le altre novità, una strettamente collegata è l’introduzione delle API del TagManager. Ad esempio l’ottimo Simo Ahava ha già prodotto un primo “clonatore” di configurazioni, oltre a dun visualizzatore delle dipendenze di tag e regole. Come sempre, Google ha capito che fare un’API darà ampio respiro al prodotto e permetterà a molte persone di guadagnare dei soldi, man mano che le esigenze e le soluzioni aumenteranno.

E veniamo all’interfaccia, completamente rinnovata: la cosa più semplice è provarla andando su tagmanager.google.com, avendo bene in testa però che non esiste un processo di migrazione dei contenitori. Attualmente quindi avete due possibilità:

  • Continuate ad usare la vecchia interfaccia per i vecchi contenitore e la nuova per i futuri
  • Usate l’export e l’import per migrare alla nuova versione

In futuro, ha già chiarito Brian Kuhn su Google+, ci sarà la possibilità di fare opt-in per un processo di migrazione automatica, quindi niente paura!
Le novità principali sono:

  • gestione di account e contenitori in stile “Google Analytics”, nella sezione Admin: le colonne e le icone vi risulteranno molto familiari. Anche la possibilità di filtrare per nome “al volo” sarà molto utile a che gestisce decine o centinaia di account (uno a caso, ad esempio :) )
  • overview migliorata, con il differenziale delle modifiche non ancora andate online. Questo può salvare ore di lavoro, perché ogni tanto ho visto fare modifiche nella bozza del contenitore, provarle in preview e dimenticarsi di pubblicare per il resto del mondo!
  • le regole ora si chiamano TRIGGERS, e funzionano leggermente in modo diverso da prima. Ovvero i triggers hanno sempre almeno due condizioni per essere definiti: CHE EVENTO si sta aspettando e DOVE lo si sta aspettando (definito tramite un filtro)
  • i tag di listener non esistono più: sono stati resi impliciti nel fatto che se ho un trigger di tipo EVENTO CLICK sulla pagina X, allora dovrà per forza esserci anche un listener di click. Keep it simple! :)
  • le macro ora si chiamano VARIABILI. Ha molto più senso così, non s’era mai capito perché la scelta di quel nome niente affatto parlante per i profani. In aggiunta, le variabili create automaticamente dal GTM quando si crea un contenitore possono essere nascoste, se non servono.

All’inizio ho trovato un po’ spiazzante la nuova interfaccia, ma sto iniziando ad abituarmici. Vi consiglio di fare delle prove perché non si tratta di un passaggio completamente “liscio”, secondo me. E’ in ogni caso un deciso passo nella direzione giusta. Prossimamente mi aspetto l’introduzione delle “cartelle” di tag, per mettere ordine negli account più grossi, una migliore gestione del multi-utente, con permessi differenziati per team distribuiti e magari anche un processo di approvazione multi-livello.

Sempre in tema di novità segnalo anche il rifacimento dell’estensione di Chrome “Tag Assistant“. Qui al momento continuo a preferire la versione vecchia, ma chissà…


Oct 15 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Il bounce rate accomodato nell’era di Universal e TagManager

autore: Marco Cilia categoria: tagmanager tag: ,

Vi ricordate del post in cui parlavo del bounce rate “accomodato”, cioè dell’ipotesi di non considerare bounce le visite che restano sul sito oltre un tot di tempo? Sebbene io sia contrario a questo genere di modifiche, resta un fatto che invece molte persone lo usano, per cui ho pensato di aggiornare la sintassi ai tempi di Universal Analytics. In sostanza la sintassi da usare sarebbe questa:


<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-XXXXXX-1', 'auto');
  ga('send', 'pageview');
  setTimeout("ga('send', 'event', '15_seconds', 'read')",15000);

</script>

Se invece usate il TagManager la cosa si risolve in un altro modo:

1) Create un nuovo tag di tipo “listener timer” fatto così:

Schermata 2014-10-12 alle 18.05.55

2) Create una regola come questa:

Schermata 2014-10-12 alle 18.07.24

3) create un tag di tipo evento, con Category ’15_seconds’ e Action ‘read’ e fatelo partire sulla base della regola creata al punto 2

4) create e pubblicate una nuova versione del contenitore.

Facile, no? :)


Oct 12 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Il nuovo-nuovo GAIQ test

autore: Marco Cilia categoria: generale tag:

[Prima di iniziare una premessa: nelle settimane scorse ho avuto qualche problema con il blog. La homepage mi ha dato grandi grattacapi, mentre il resto del sito funzionava. Ora mi hanno spostato su un nuovo server e tutto sembra risolto. Grazie per la pazienza!]

Perché il “nuovo-nuovo” GAIQ? Perché il test era stato già rinnovato a gennaio, si veda questo post.
Il test storicamente era attestato su una piattaforma esterna (google.starttest.com, tutt’ora esistente), mentre adesso è stato inglobato all’interno del portale www.google.com/partners, come già è successo per AdWords.
La buona notizia è che è possibile importare le certificazioni in corso sulla piattaforma vecchia, con un semplice click. E’ inoltre possibile “affiliare” o meglio collegare il proprio profilo a quello dell’eventuale agenzia dove si lavora, in modo che anche i profili personali concorrano ad aumentare gli skill dell’agenzia, senza dover sostenere due volte l’esame con email personali e lavorative.

Completano il quadro la possibilità di certificarsi anche su AdWords, e immagino altri prodotti Google nel futuro. Ma la notizia più succulenta è che l’esame non è più a pagamento, ovvero non dovete più spendere 50 dollari per sostenerlo. Nel corso di questi anni questo è sempre stato un deterrente più forte di quanto immaginassi, perché “da fuori” probabilmente il test sembra più complesso di quanto in realtà poi non sia. In ogni caso, ora potete provarci senza remore :)


Sep 21 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

ROI R.I.P. welcome ROAS

autore: Marco Cilia categoria: report tag: , ,

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 :)

nuovo report target rete display


Sep 12 2014

A volte ritornano: riecco il benchmarking

autore: Marco Cilia categoria: report tag: ,

Non tutte le ciambelle riescono col buco, e alcune volte i report di Analytics vengono ritirati. Se non bastano le lamentele sparse su forum e gruppi di discussione, una rapida occhiata alle statistiche di Google Analytics SU Google Analytics (ebbene sì, è una specie di Matrix :) ) è in grado di dire agli ingegneri “questo report non se lo fila nessuno”.

Questa sorte è probabilmente accaduta al vecchio report del benchmark, che però rivive oggi in una forma tutta nuova e, permettetemi di dire, bella sgargiante! Il blog ufficiale infatti ci informa che nelle prossime settimane tutti avrete accesso alla nuova funzionalità, che sarà attivata se e solo se avete preventivamente deciso di condividere anonimamente i vostri dati con Google (Amministrazione -> impostazioni dell’account -> “anonimamente con Google e altri”).

benchmarking-v2

Quando tutti saranno abilitati nella sezione di report PUBBLICO comparirà una nuova sottocategoria, tradotta in italiano con “Analisi comparativa“. Al suo interno, tre report:

  1. Canali: è il report che vedete nello screenshot sul post ufficiale. La dimensione impostata è Channel, le metriche sono le classiche ABC (Acquistion, Behavior, Conversion) e ogni cella è colorata con tonalità dal verde al rosso, a seconda che il risultato ottenuto dal nostro sito sia migliore o peggiore del campione di paragone. Il colore si può eliminare, così come la numerica di comparazione. In questo senso trovo il report molto bello e agevole da leggere, e spero che questa visualizzazione venga estesa anche in altre parti dello strumento.
  2. Località: qui la dimensione principale è il paese/zona di provenienza degli utenti
  3. Dispositivi: dimensione principale è categoria del dispositivo (desktop, tablet, mobile)

Interessanti le metriche che è possibile posizionare sul grafico: oltre alle metriche secche ci sono anche metriche “dedicate”, tipo “differenza % nuove sessioni rispetto al benchmark”. Infine, la domanda principale: contro chi o che cosa sto confrontando i miei dati? in testa ad ogni report sono presenti 3 grandi selettori, uno dedicato all’industry (o vertical, come amano dire gli inglesi) – e ne potete scegliere una tra circa 1600 – uno dedicato al Paese/Regione (no, in Italia niente province, mentre in Francia ad esempio si) per filtrare i dati e uno dedicato alla dimensione dei siti in base al traffico giornaliero (da siti piccoli 0-100 visite al giorno a siti enormi da oltre centomila visite al giorno). Nessuno mi vieta di confrontare il mio piccolo ecommerce di ferramenta con un colosso giapponese di articoli da giardino, ma avrebbe poco senso. I valori stimati da GA all’inizio dovrebbero essere più che sufficienti…
In ogni caso dopo aver modificato i valori di riferimento, Analytics mostra un avviso che indica quante properties fanno parte del benchmarking per quella particolare selezione. Sempre utile per tenere a mente il contesto.


Sep 03 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Il posizionamento di GA secondo gli utenti

autore: Marco Cilia categoria: generale tag:

Qualche tempo fa abbiamo detto del report Forrester Wave 2014, e delle polemiche che ne sono scaturite (che tra l’altro non si sono sopite, dato che Brian Clifton recentemente ci è tornato sopra).

TrustRadius invece adotta un approccio opposto, e attraverso un panel di utenti ha ricostruito – incrociando diffusione e punteggi – una situazione leggermente diversa: prima di tutto le domande sono poste ad aziende di qualsiasi dimensione, in secondo luogo i tool non sono scremati all’inizio (motivo per cui compare anche Piwik, ad esempio). Ebbene, in questa situazione il leader nel settore small business è Google Analytics free, insieme a StatCounter e Piwik.

Per le medie imprese (“medie” nel metro americano, ovvero fino a 500 dipendenti) invece il leader è Google Analytics free, mentre Adobe si posiziona secondo, esattamente sulla linea mediana dei punteggi (4,3 su 5). Nel segmento enterprise il leader è sempre e comunque Google Analytics Free, Adobe è di nuovo sulla linea mediana (4,1 su 5) e Google Analytics Premium è sulla stessa mediana di punteggio, solo meno diffuso. Gli altri big del settore secondo il report di Forrester? IBM e Webtrends più diffusi di GAP ma con punteggi molto inferiori, AT internet è strong performers per punteggio, ma è comunque inferiore a GA free, mentre SAS non è nemmeno menzionato.

Ovviamente l’ottimo sarebbe un’analisi che prendesse dati da entrambi i report, perché ad ognuno manca un pezzo e quindi arrivano a conclusioni differenti.

Forrester, I’m sure, would beg to differ, identifying “the six most significant software providers in the category” as Adobe, AT Internet, Google, IBM, SAS Institute, and Webtrends.

The TrustRadius report profiles all of those providers, minus SAS Institute, and adds comScore, GoSquared, KISSmetrics, Mixpanel, Piwik, StatCounter, and Woopra.

Però è sempre bene avere altri punti di vista, no? :)


Aug 05 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Ora si possono filtrare i bot. Nel senso, meglio di prima!

autore: Marco Cilia categoria: generale tag: ,

Con un annuncio sul G+ ufficiale, Google Analytics annuncia la nuova possibilità di filtrare bot e spider direttamente con un’opzione nella vista. La cosa ha generato un po’ di confusione, per cui mettetevi comodi e leggete.

Google Analytics, da sempre, è un sistema di web analytics basato su una libreria javascript e sui cookies. Javascript è una tecnologia che funziona sui browser degli utenti, per cui il sistema raccoglie informazioni e poi le invia ai server di Google, che le analizzano. La prima conseguenza di questa affermazione – che resta vera – è che chi non esegue javascript non esegue nemmeno il codice di Google Analytics.
Quindi se io disattivo javascript, GA non mi vede. I bot, da che mondo e mondo, non sono progettati per eseguire javascript e accettare i cookie. Questo però non vieta a nessuno di progettarne uno che invece lo faccia, è già capitato in passato e ancora può capitare. Quindi l’affermazione corretta è “Google Analytics non traccia la maggior parte dei bot”.

Recentemente è stato introdotto anche il Measurement Protocol, ovvero la possibilità di inviare dati ai server Google senza l’uso di javascript. In questo caso ovviamente i bot sono SEMPRE inclusi nel traffico. Ho testato in prima persona una soluzione che addirittura include solo il traffico dei bot in una property Google Analytics. Se invece abbiamo una property “normale” che invia parte o tutti i dati tramite Measurement Protocol, la possibilità di filtrare i bot e gli spider con una spunta è molto comoda.

La cosa era diventata praticamente necessaria anche in virtù delle complessità sempre maggiori in gioco: più i siti diventano interattivi e più gli spider devono diventare “umani” per capire cosa contengono. Questo include anche la possibilità di eseguire javascript per attivare funzioni e contenuti altrimenti inaccessibili. Ultimamente aveva fatto molto scalpore il caso AdRoll, di cui potete leggere in questo post su seroundtable. Un altro caso simile e recente è quello di semalt.

Ovviamente la nuova opzione non è risolutiva nel 100% dei casi: affinché un bot sia escluso deve fare parte della lista ufficiale IAB di bot e spider riconosciuti. La lista non è pubblica perché IAB la fa pagare agli iscritti, quindi presumo non la vedremo mai. La feature non è retroattiva, per cui dovrete tenerne conto in fase di analisi, ma avevo letto un post – che non ritrovo – che diceva che nei primi giorni l’impatto era di circa il 3% di un sito piccolo e ancora meno in un sito grande. Chiaramente dipende dal business, dal settore e da molti altri fattori. Se ritrovo il link aggiornerò il post.


Jul 28 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

4 metriche che si confondono facilmente

autore: Marco Cilia categoria: generale tag: ,

M’è passato sotto agli occhi questo post di edynamic: The Four Most Confusing Metrics in Google Analytics e ho pensato che valesse la pena di riprenderlo, anche se parla di cose che negli anni ho già affrontato su questo blog.

Le prime due metriche interessate sono il bounce rate e l’exit rate (tasso di rimbalzo e tasso di uscita, in italiano): le definizioni per queste due metriche sono:

  • Bounce rate: una visita che non fa registrare una seconda pagina, o un evento (che non sia classificato come “non interattivo” tramite apposito settaggio).
  • Exit rate: l’ultima pagina vista di ogni sessione.

Le differenze principali sono che per esserci un bounce la visita deve iniziare e concludersi nella stessa pagina, quindi è una condizione che può verificarsi oppure no, mentre una sessione deve necessariamente terminare da qualche parte, quindi una exit page c’è sempre.

Vi pregherei di non considerare i calcoli successivi nel post originale, perché sono effettuati su un assunto sbagliato :)
Nel caso descritto nel loro esempio, che riporto qui

Session 1: Page A > Page B > Page C > Exit

Session 2: Page B > Page C > Page A > Exit

Session 3: Page C > Page B> Page A > Exit

Session 4: Page A > Exit

i calcoli corretti sono:
– Il bounce rate della pagina A è 50% (1 bounce – la quarta sessione – su 2 sessioni in cui era landing page)
– Il bounce rate della pagina B è 0% (0 bounce su 1 sessione in cui era landing page)
– Il bounce rate della pagina C è 0% (0 bounce su 1 sessione in cui era landing page)

– L’exit rate della pagina A è 75% (è stata l’ultima pagina in 3 sessioni su 4)
– L’exit rate della pagina B è 0% (non è mai stata l’ultima)
– L’exit rate della pagina C è 33% (è stata l’ultima in una sessione su 3 in cui è stata vista)

In ogni caso ne avevo parlato circa cinque anni fa

Le altre due metriche che generano confusione sono il tempo sulla pagina e il tempo sul sito: il tempo sulla pagina è il tempo trascorso su ogni pagina, calcolato come la differenza tra il momento in cui il sistema sa che stiamo facendo “cose” su una pagina (apertura di pagina, eventi sulla pagina) e il momento in cui è stata aperta la pagina precedente. Inoltre, quando si calcola il tempo sulla pagina, Google Analytics non include le visite che hanno fatto dei rimbalzi, che abbasserebbero drasticamente la media.

Con esempi pratici, sempre presi dal post e corretti per non generare confusione (ipotizziamo non ci siano eventi in questo tracciamento):

Session 1: Page A (30 seconds) > Page B (60 seconds) > Page C > Exit

Session 2: Page A > Exit

Session 3: Page A (20 seconds) > Page B > Exit

– Il tempo medio sulla pagina A è 25 secondi (30+20 diviso 2, perché i bounce non contano).
– Il tempo medio sulla pagina B è 60 secondi (60 diviso 1, perché quando una pagina è l’ultima non si può calcolare il tempo sulla pagina. Diverso sarebbe se ci fossero eventi sulla pagina)
– Il tempo medio sulla pagina C è di 0 secondi.

Il tempo medio sul sito usa lo stesso principio, ma sottrae il momento dell’ultima hit arrivata dal momento della prima hit della sessione. Esso include i bounce, ma tanto quanto prima non può includere il tempo sull’ultima pagina (sempre escludendo gli eventi).
Se prendiamo l’esempio di prima, il tempo medio sul sito è 37 secondi (30+60+20 diviso 3).

Di questo ne abbiamo parlato addirittura nel 2008, accidenti se è anziano questo blog ;)


Jul 17 2014

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

client-ID o CRM-ID?

autore: Marco Cilia categoria: codice di monitoraggio tag: ,

Qualche giorno fa Justin Cutroni ha scritto un bel post sull’integrazione dei dati offline con quelli di traffico online: ve ne consiglio la lettura perché è piuttosto interessante.

Quel che mi ha colpito è stato l’approccio, con cui per una volta non sono d’accordo, e in particolare mi riferisco alla frase “What we need to do is extract the client ID value from the Google Analytics cookies and pass it to your CRM system” (trad: quel che dobbiamo fare è estrarre il client ID da Google Analytics e passarlo al nostro CRM).

Il client ID è l’identificativo univoco che Google Analytics crea di sua spontanea volontà: su GA classico si trova dentro al cookie __utma, su Universal si trova dentro all’unico cookie che viene creato, __ga
Il problema dell’approccio di Justin, è che non risolve affatto il problema del cross-device. Se infatti estraggo il mio clientID da qusto browser, ottengo un valore. Se cambio browser e visito lo stesso sito, ottengo un altro valore. Seguendo il suggerimento del post di Justin, anche se mi identifico (ad esempio loggandomi), il CRM ottiene due valori diversi. Deve salvarli entrambi? deve salvare solo l’ultimo? non si sa.

Se Google Analytics e il CRM si “parlano”, allora ritengo più intelligente fare esattamente l’opposto: usare il CRM-ID per sovrascrivere il clientID di GA. In effetti non lo si sovrascrive, ma ci si “appiccica” sopra. Per farlo si usa una sintassi di questo tipo


ga('create', 'UA-XXXX-Y');
ga('set', '&uid', 'CRM-ID');   
ga('send', 'pageview');

In questo modo il CRM non deve preoccuparsi di registrare un campo nuovo, possiamo usare lo stesso i report cross device, abbiamo direttamente in piattaforma un ID facilmente riconducibile (per il possessore del dato) all’identità dell’utente, che possiamo usare per segmentare, fare remarketing o estrazione di dati.


Jul 03 2014

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

Nuovo debugger interno al TagManager

autore: Marco Cilia categoria: tagmanager tag:

Se usate il Google Tag Manager ad un livello medio/avanzato, immagino che sappiate di cosa parlo quando dico WASP, Observepoint, dataLayer inspector, dataSlayer… sono estensioni di Chrome il cui scopo è (anche) quello di mostrare i valori del dataLayer. questo perché il dataLayer non è statico e immutabile, una volta creato su una pagina, ma può subire modifiche grazie ai push e inoltre contiene anche dei valori che non sono inseriti da noi ma sono propri della sua esistenza, e che a volte tornano utili.

Da ieri gli ingegneri di Google hanno rinnovato – pesantemente rinnovato – la finestra di anteprima delle versioni del contenitore, passando da un anonimo frame con l’elenco dei tag e delle condizioni per cui partivano o meno ad una finestra piena zeppa di informazioni utili a spremere al massimo il dataLayer, sempre con l’intento di lavorare meno far risparmiare tempo e denaro ai clienti ( :P ).
Ecco come si presenta adesso la finestra

GTM-debug-UI

Gli elementi principali del cambiamento sono:

  • nel riquadro verde ci sono i tag che sono partiti. Ogni tag è cliccabile e riporta informazioni sulla sua confogurazione (valori, regole di invio, ecc). Stessa cosa avviene per i tag NON inviati, sotto.
  • nel riquadro blu ci sono gli eventi, in ordine di esecuzione, che vengono sentiti dal TagManager. Oltre che dare un’idea di cosa accade quando, quel riquadro funziona anche da filtro per i tag. Questo significa che se premo “pageview” ottengo la situazione dei tag al momento in cui il TagManager capisce su che pagina si trova, mentre se premo “page load” ottengo la situazione al momento della fine del caricamento della pagina (evento gtm.load), perché potrebbero anche essere cose diverse. Se c’è un push successivo, o un click, il riquadro impila ulteriori “momenti”, anch’essi ispezionabili.
  • il riquadro rosso invece di permette di ispezionare i tag, come abbiamo detto finora, oppure i valori delle macro (molto comodo sapere il valore di ogni macro in qualunque momento, permette di testare velocemente i falsi positivi senza ricorrere ad alert o console.log) oppure il valore complessivo del dataLayer. Il tutto sempre potendo filtrare per momento tramite il riquadro blu. Quindi ad esempio il dataLayer finale al caricamento di una pagina sarà diverso da quello visibile dopo un messaggio conseguente ad un dataLayer push

Trovo che questa visualizzazione sia un balzo gigantesco in avanti nella comprensione, e quindi nel miglior utilizzo, dello strumento da parte degli utenti. Il tipo di controllo che si può attuare è molto accurato e specifico, e in ogni caso si risparmierà tempo durante i setup, con beneficio di tutti. Credo che disinstallerò subito l’estensione dataSlayer :)