Quando uscì il Google Tag Manager, uno dei punti più interessanti – benché non fosse una novità propria dello strumento Google – fu la possibilità di utilizzare un metalivello informativo di dati (il dataLayer) per fare parte della configurazione. Questo ha portato ad avere molta flessibilità nella conffigurazione, e anche a ridurre le ore dedicate allo sviluppo, suddividendo il lavoro tra chi può produrre l’informazione (lo sviluppatore) e chi deve renderla disponibile nel posto giusto al momento giusto (chi supporta il marketing nella configurazione).
Un dataLayer in realtà è un altro concetto che è trasversale al Tag Management; fatto così al momento funziona solo sul GTM, ma io penso che Google abbia la forza e il dovere di provare a creare uno standard per il datalayer, in modo che possa essere più facile in futuro cambiare soluzione di Tag Management senza dover rifare questa parte di implementazione.
Ecco, la settimana scorsa il blog ufficiale ha annunciato che Google sta unendo le forze a IBM, Accenture, il W3C e altre compagnie per provare a rendere davvero uno standard trasversale ai vendo questa tecnologia.
La cosa ovviamente è molto importante perché, se correttamente adottata da tutti i fornitori di soluzioni di Tag Management, consentirebbe di cambiare velocemente soluzione modificando solo la porzione di codice del contenitore e impostando le regole corrette sulla nuova soluzione. Quindi oltre che rendere il tracking “cross versione del sito” come mi piace dire (cambi sito o template, ma se il dataLayer è sempre al suo posto il tracking non viene intaccato) sarebbe anche “cross soluzione di Tag Management”.
Avevo detto qualche giorno fa che ero curioso di capire come avrebbe funzionato il Google Tag Manager per applicazioni mobili: tecnologia tutto sommato nuova (Ensighten già lo fa, per la cronaca) ma molto promettente.
Il problema di business che questa soluzione risolve non è affatto banale: chiunque si sia cimentato con il processo di approvazione di una applicazione mobile sa quanto possa essere lungo e soggetto a rinvii, soprattutto sull’AppStore di Apple. Anche dopo la prima approvazione, il ciclo di rilascio di una nuova versione non è immediato, e comunque sia ogni minimo cambiamento della app, fosse anche il colore di un pulsante, richiede una nuova versione.
Il Tag Manager per app invece va configurato una volta in fase di creazione del tracking o dell’app, ed esattamente come nei siti web la configurazione dei tag può essere fatta da pannello. Con dei plus molto interessanti, però. Il primo è che la configurazione viene scaricata ogni tot ore, se possibile. E questo risolve il caso in cui una app venga utilizzata in assenza di connessione internet. Il secondo è che il tag manager per app mobile può essere usato per modificare qualsiasi aspetto dell’app, non solo il tracciamento analytics.
Come si vede chiaramente dal video qui sotto, anche la fisica di un gioco o il metodo di rilascio di badge, così come la posizione e la forma di un banner, possono essere variati a piacimento. Non solo: poiché il sistema è basato su regole, come il Tag Manager classico, si possono anche identificare specifici segmenti di utenti e modificare soltanto la loro app. Ad esempio, tutti i dispositivi in lingua inglese. O tutti gli android con versione inferiore alla 4.0. O altri a piacimento.
E tutto questo, ripeto, senza bisogno di pubblicare una nuova versione dell’app, ma comodamente tramite pannello.
Risparmiare tempo, risparmiare soldi! Vi consiglio di prendervi una mezz’oretta e dare un’occhiata al video del Google I/O con la demo, è veramente notevole!
Stavo guardando la sessione di Analytics al Google I/O quando mi son detto “vediamo un po’ se c’è qualche novità nel blog ufficiale!”. Ed eccomi accontentato
Sorgenti Google Play: non è chiaro se si riferiscano alle sole campagne (si poteva già fare da almeno un anno) o – molto più interessante – a TUTTO il traffico che arriva al Google Play e che conduce al download dell’applicazione. Tutto questo esposto sui profili Google Analytics dedicati alle app
View Google Play: per ogni campagna o sorgente, quante view della pagina dell’applicazione sono generate
Installazioni: una metrica che ogni sviluppatore conosce, ma probabilmente segmentabile per sorgente
Nuovi utenti: il numero di primi lanci dell’applicazione, che è diverso dal numero di download.
Il tutto visualizzato tramite flow report.
Altra grandissima novità è il Tag Manager per applicazioni: attualmente il tracking delle app richiede l’aggiunta e la configurazione, più o meno laboriosa a seconda degli intenti di tracciamento, di un SDK apposito. Se lo sviluppatore dimentica di inserire il tracking di un evento (esempio, un certo pulsante che fa un’azione chiave per i nostri KPI), deve aggiungerlo al progetto, ricompilare l’applicazione, inviarla allo store, aspettare che gli utenti la scarichino e inizino ad usarla e inviare dati.
Con il Google Tag Manager per App questo sarà solo un ricordo, perché sugli stessi presupposti del Tag Manager per i siti, la configurazione del tracking verrà fatta soltanto una volta e variata “live” attraverso un comodo pannello. Purtroppo non ci sono molti altri dettagli, ma sono proprio curioso di conoscere la tecnologia sottostante che renderà possibile tutto questo: quella del tag manager “dekstop” in fondo è piuttosto banale, questa per me rappresenta una novità, e una sfida interessante.
Se volete partecipare alla whitelist, dovete compilare l’apposita form, previa creazione di un account Tag Manager se già non lo avete…
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).
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:
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 🙂
Quando vi ho parlato del Google Tag Manager ho volontariamente omesso un particolare sul suo funzionamento: l’ho fatto per non appesantire troppo il post, che conteneva già abbastanza concetti nuovi e che non volevo risultasse troppo ostico da digerire 🙂
Il concetto che ho omesso è quello del datalayer, cioè di un livello di astrazione dei dati passabili al GTM: pensiamo al datalayer come a un baule che contiene tutti – o quasi tutti – i dati possibili e immaginabili che ci potrebbero servire: li contiene sempre, anche quando in realtà non ci servono, ed è presente in ogni pagina; naturalmente i dati sono generati dinamicamente, non è importante come anche perché dipende da molti fattori, l’importante è sapere che esso ci potrebbe essere.
Un semplice datalayer di esempio per il Google Tag Manager potrebbe essere fatto così:
questo baule contiene la categoria della pagina e il tipo del visitatore, e abbiamo detto che è sempre presente in tutte le pagine, anche se con valori differenti. Lo stesso datalayer per un’altra pagina potrebbe avere pageCategory: news, lo stesso datalayer per un altro utente potrebbe avere visitorType: non-customer.
Il Tag Manager attraverso una macro può facilmente estrarre uno di questi valori, è una funzione già presente nell’interfaccia:
e una volta estratta la può utilizzare all’interno dei tag presenti nel container.
Non solo, attraverso una apposita funzione, dataLayer.push({‘Data Layer Variable Name’: ‘value’}) si possono aggiungere al volo variabili che non erano previste in partenza, o sovrascriverne altre che invece c’erano.
A questo punto dovrebbe essere chiaro perché un dataLayer può fare la differenza in un progetto di analisi web: vi è mai capitato di dover implementare qualcosa su Google Analytics che richiedesse una modifica del codice? se si, forse avete dovuto passare per la fase “devo spiegare a chi gestisce il sito cosa fare, dove farlo, come farlo”, che poi è il motivo per cui esiste il GTM. Ecco, tanto quanto l’implementazione dei codici è facilitata dall’inserimento di un solo container del Tag Manager, una buona pianificazione del dataLayer e delle chiamate permette allo sviluppatore di lavorare una volta sola, e a noi di avere sempre a disposizione tutte le informazioni utili al nostro piano di tracciamento del progetto.
Tanto per farvi un’idea, vi mostro un esempio un po’ più complesso (ma secondo me ancora incompleto di come vedrei io un dataLayer) fatto da Justin Cutroni qualche mese fa:
La sintassi non è quella del Google Tag Manager, il post è di Maggio, ma siccome Justin lavorava già per Google, col senno di poi quel post che allora mi sembrava solo una buona idea lungimirante si rivela per quel che è: una comunicazione di intenti per un prodotto in fase di sviluppo 🙂
[edit: L’editor s’è mangiato un pezzo del post. Un dataLayer in realtà è un altro concetto che è trasversale al Tag Management; fatto così al momento funziona solo sul GTM, ma io penso che Google abbia la forza e il dovere di provare a creare uno standard per il datalayer, in modo che possa essere più facile in futuro cambiare soluzione di Tag Management senza dover rifare questa parte di implementazione.]
Sono anni che parliamo della Business Platform, e Google ultimamente ci ha dimostrato chiaramente che anche se non la chiama così, sta puntando a quello. E che Business Platform sarebbe, se non avesse come complemento un tag manager?
Ecco, durante l’Emetrics di Boston Google ha appena annunciato il rilascio del suo tag manager, chiamato con molta fantasia “Google Tag Manager“, un prodotto dedicato a tutti coloro che hanno necessità di implementare sui propri progetti tag di marketing e misurazione. Insieme allo strumento viene anche lanciata una rete di partner qualificati, e sono piuttosto orgoglioso di poter affermare che Intarget fa parte di quella rete. Sul blog aziendale trovate anche alcune considerazioni in ottica business su quanto questa novità del tag manager sia importante in un moderno progetto digital.
Un tag manager, per chi non lo sapesse, è uno strumento che consente di astrarre di un livello la messa in produzione e la modifica dei tag sul proprio sito. Invece di operare direttamente sulle pagine o sui template che le generano, si applica un unico tag a inizio progetto e il resto delle modifiche viene completamente gestito attraverso un’interfaccia web. Non è una idea nuova, di tag manager in giro ce ne sono parecchi da anni, ma l’approccio Google a qualsiasi cosa riserva sempre qualche sorpresa…
Il primo concetto con cui familiarizzare è l’account, che ricalca esattamente quello che noi conosciamo per Google Analytics: un account può contenere diversi progetti, per cui è assolutamente necessario che sia l’account del proprietario del sito a generare il tag contenitore necessario; esattamente come in Google Analytics poi sarà possibile aggiungere utenti, con due livelli di accesso all’account, e quattro livelli al singolo contenitore.
Il secondo concetto è quello di contenitore, cioè del tag fisico che andrà poi inserito sulle pagine del progetto: un contenitore si presenta come un blocco di codice – iframe e javascript sostanzialmente – con un identificativo univoco. Una volta inserito quello nel sito, si potranno effettuare le necessarie modifiche agendo sull’interfaccia web del tag manager.
All’interno di un contenitore si possono poi definire i tag: i tag sono quei pezzetti di codice che fino ad ora siamo stati abituati ad incollare nei template delle pagine dei siti, sotto forma di javascript, html o di pixel tracking. Il Google Tag Manager ha già alcuni template predefiniti – ed altri immagino verranno aggiunti prossimamente, che facilitano molto l’inserimento. Per aggiungere un tag di base di Google Analytics, senza alcuna personalizzazione, basterà selezionare il modello appropriato e incollare il numero UA-xxxxxx-y. Altri modelli predefiniti sono il codice delle conversioni di AdWords, il remarketing o il DoubleClick Floodlight. In ogni caso è sempre possibile definire un tag incollando il codice necessario nell’interfaccia invece che sul sorgente delle pagine.
I tag vengono eseguiti basandosi su delle regole: esse servono a dire al Tag Manager quando eseguire un tag piuttosto che un altro, e sono del tipo “tutte le pagine”, “tutte le pagine tranne…”, “l’url della pagina contiene xyz”, “viene scatenato un certo evento”, “il referrer è…”, ed altre ancora… Esiste in realtà una regola più generale che si può usare per generare qualsiasi regola, ed è: “macro soddisfa condizione”. A questo punto la domanda che sorge spontanea è cosa sia una macro 🙂
Una macro, nel tag manager, è un identificatore di un qualcosa, che servirà poi per definire una regola. Questo qualcosa può essere una variabile javascript, una stringa, un oggetto del DOM, un evento, un referrer, un url e una serie di altre cose.
Combinando insieme macro e regole si sarà in grado di identificare puntualmente le condizioni sulla base delle quali scatenare un tag piuttosto che un altro, anche in modo molto complesso: arrivo sulla pagina x dal referrer y, e se una certa variabile javascript ha un determinato valore, estraggo dal DOM una stringa e la passo al tag manager che la scrive nel tag di remarketing di AdWords.
Tutto questo lavoro non è semplice, ovviamente, e poiché il grado di complicazione è elevato, il Google Tag Manager ha al suo interno una funzione bellissima: il versioning dei tag. Questo è utilissimo perché in caso di problemi con un solo click si può tornare indietro di una o più versioni, ripristinando tutti i tag all’ultima situazione sicuramente funzionante, ma non solo… il versioning funziona anche per le versioni non ancora messe in produzione: se si fanno delle modifiche si può creare una nuova versione del contenitore e pubblicarla in una “sandbox”, cioè funzionante soltanto sui browser abilitati da chi ha creato la versione. Questo permette di conoscere in modo visuale, attraverso una consolle nel browser, se la nuova configurazione funziona man mano che si visita il sito live. Se tutto è corretto, si potrà procedere alla pubblicazione vera e propria.
I vantaggi del Google Tag Manager sono piuttosto evidenti, una volta compreso cosa è e come funziona, ma ve li elenco ugualmente:
– velocità di implementazione, modifica e rimozione
– gestione centralizzata
– minori o assenti richieste al reparto IT
– possibilità di avere preview sul funzionamento di tag non ancora in produzione
– rollback immediati
Questo è un altro grande passo nella direzione della piattaforma di marketing a 360° che desideriamo da tanto: qui non si tratta di nuove funzionalità di un prodotto o di un altro, di evoluzioni o di unificazioni di prodotti già esistenti. Qui si sta parlando di un nuovo prodotto che racchiude tutti gli altri, che facilita molto le operazioni alle agenzie, scarica i clienti da alcune attività e quasi azzera il lavoro di reparti IT e web developer. Come si può dire di no a tutto questo? 🙂
Voi cosa ne pensate?
SemaforoQuesto semaforo indica il livello difficoltà del post
