Sep 07 2017
Cosa è il nuovo gtag.js e cosa cambia all’utente medio?
Senza nemmeno troppa pubblicità, il team di Google Analytics ha introdotto un nuovo snippet di codice da utilizzare “per il page tagging”: cosa si intende esattamente? sicuramente si può utilizzare per inviare dati a Google Analytics, come vedremo tra poco. E-nor riporta anche che presto la libreria includerà conversion.js di AdWords. Questo rende il discorso interessante sotto alcuni punti di vista. Ma andiamo con ordine.
Lo snippet da installare appena dopo l’apertura di HEAD è più corto del classico di Universal, vediamo come è fatto
<!-- Global Site Tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=GA_TRACKING_ID"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments)};
gtag('js', new Date());
gtag('config', 'UA-XXXXXXX-Y');
</script>
La prima cosa che si nota è che non c’è il comando per l’invio del pageview, e la cosa è voluta. Questo codice, da solo, fa quel che faceva il vecchio codice di base. Se anzi volessi disabilitare l’invio del pageview per qualche motivo, dovrei forzarlo con un parametro aggiuntivo
gtag('config', 'GA_TRACKING_ID', { 'send_page_view': false });
La seconda novità è che si possono gestire i multicodici con più facilità. Ipotizziamo, nemmeno con troppa fantasia, che debba mandare i dati a 4 properties. Oggi dovrei istanziare 4 tracker e fare 4 send pageview, come minimo. Domani, in presenza di un codice così
gtag('config', 'UA-111111-11', {'groups': 'default'});
gtag('config', 'UA-222222-22', {'groups': 'access'});
gtag('config', 'UA-333333-33', {'groups': 'access'});
gtag('config', 'UA-444444-44', {'groups': 'access'});
Verranno inviate 4 pageview, ma potrei anche decidere che un evento lo mando solo alle tre property del gruppo access, tramite l’uso di send_to (che in ogni caso supporta anche la specifica degli ID delle property). Su installazioni complesse e ridondanti può essere un toccasana.
Oltre ai pageview, sappiamo che si possono inviare eventi. gtag.js ovviamente li supporta, in un modo un po’ inusuale però. Sebbene sia possibile sempre fare un “classico” evento con category, action e label, la sintassi della documentazione ufficiale parla genericamente di parametri
gtag('event', 'event_name', {
// Event parameters
'parameter_1': 'value_1',
'parameter_2': 'value_2',
// ...
});
che a me ricorda MOOOOOLTO DA VICINO un dataLayer.push 🙂
Eventi normali quindi sempre possibili, ma c’è un ma… la guida parla di RECCOMENDED EVENTS e RECCOMENDED PARAMETERS, e qui avviene la magia. Per esempio questo
gtag('event', 'login');
invierà un evento con categoria engagement, action login e nessuna label. Se volessi mandarlo alle 4 property raggruppate come sopra, mi basterebbe fare
gtag('event', 'login', {'send_to': ['default', 'access']});
Simpatico, no? 🙂
Dove troviamo l’elenco degli eventi raccomandati? nella documentazione ovviamente. Se faccio un evento add_to_whishlist, GA registra categoria ecommerce, action add_to_whishlist e label vuota. Se faccio un evento begin_checkout, lui si aspetta i parametri value, curency, items, coupon.
Ora, perché sono importanti questi eventi raccomandati? per due motivi:
- standardizzazione: sebbene sia lasciata facoltà di personalizzare tutto, gli eventi più comuni possono essere tracciati con nomi automatici, favorendo aggregazioni e confronti e facilitando la lettura dei dati
- se scorriamo la lista degli eventi, troviamo anche cose interessanti, ad esempio che che gli item parameter hanno origin e destination, e si specifica anche (travel). Non ricorda i parametri del remarketing dinamico per il vertical dei viaggi? e se si, non fa il paio con quanto dice E-nor sul fatto che domani gtag potrebbe incorporare anche lo script di AdWords? in questo modo una sola riga di codice farebbe entrambe le cose…
Infine, le mappe per le custom metric e dimension: supponiamo che dobbiate si mandare i dati a due o tre property, ma che gli indici delle custom metric e dimension non coincidano affatto. Un grande classico, peraltro. Ecco che ci viene in aiuto la mappatura preventiva, così:
gtag('config', 'UA-111111-11', {'groups': 'default',
'custom_map': {
'dimension2': 'age',
'metric5': 'avg_page_load_time'
}});
gtag('config', 'UA-222222-22', {'groups': 'access',
'custom_map': {
'dimension33': 'age',
'metric66': 'avg_page_load_time'
}});
Questo codice in pratica dice: “sulla property -11 l’età (age) la si manda sulla dimensione 2, e il tempo medio di caricamento della pagina sulla metrica 5. Sulla property -22 invece età va nella custom dimension 33 e load time sulla custom metric 66.”
A questo punto facendo ad esempio un semplice
gtag('event', 'add_to_whishlist', {'age': 'eta', 'avg_page_load_time': 14.5, 'send_to': ['access', 'default']});
avremo gli stessi valori inviati a due property e per giunta negli slot corretti! Interessante, no?
Ora, venendo all’utente medio, la domanda è naturalmente “dovrei migrare o no? questa cosa sostituisce Tag Manager?”
Questo tag NON SOSTITUISCE Tag Manager, che resta per ora il metodo di implementazione consigliato. La sua versatilità è enorme, e va ben oltre l’installazione di Google Analytics. Quindi restano in ballo solo i nuovi e vecchi progetti che vogliono migrare che per un motivo o per l’altro non vogliono o possono usare GTM sulle loro pagine. Per tutti coloro gtag.js è indubbiamente il futuro, sebbene al momento esso ancora non supporti i content experiment (ma che, ancora non sei passato a Google Optimize free? che aspetti? 🙂 ), i custom task e i custom plugin.
Se queste limitazioni non vi dicono nulla, e non avete GTM, allora vi consiglierei di provare a fare una migrazione. Se poi come dice Enor anche altri prodotti tipo AdWords saranno inglobati nel Global Tag, potrebbe essere vantaggioso avere già una installazione pronta.