Google Analytics in 30 secondi

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

Oltre a questo c’era una frase che voglio riportarvi dal mio 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.

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”.

Il che mi sembra una buona notizia 🙂

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

<script>
  dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];
</script>

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:

var dataLayer = {
"pageTitle" : "Receipt Page",
"pageURL" : "/pages/checkout/receipt",
"pageCat" : "Checkout Pages",
"PageCat2" : "",
"tranID" : "17658726382",
"tranTotal" : "34.95",
"tranTax" : "0.00",
"tranShipping" : "0.00",
"tranShippingMethod" : "USPS",
"tranCurrency" : "USD",
"tranProds" : "249|398",
"tranSKUs" : "249-32|398-12",
"tranProdNames" : "Kids Onsie|Kids Lava Lamp",
"tranCategories" : "Kids|Kids",
"tranPayMethod" : "VISA",
"visitorType" : "RETURN",
"visitorState" : "Logged In",
"visitorFirstPurchDate" : "20111205",
"visitorFirstProds" : "822"
}

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.]