Google Analytics in 30 secondi

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

2) Create una regola come questa:

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? 🙂

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 ( 😛 ).
Ecco come si presenta adesso la finestra

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 🙂

Manco da un po’ di tempo, ma ci tengo lo stesso a darvi un po’ di notizie su cosa è accaduto nel mondo Google Analytics e dintorni nel frattempo 🙂

Partendo dal blog ufficiale, Premium ottiene le API non campionate; attraverso di esse si possono ottenere informazioni sui report non campionati esistenti, si può creare al volo una richiesta di report non campionato, si può controllare lo stato di avanzamento del calcolo di un report non campionato e infine si può avere il link dal quale scaricare un report non campionato.
La feature è utile perché, come al solito, permette di integrare al di fuori del pannello operazioni che tipicamente possono essere svolte solo da dentro all’interfaccia: nel caso di Premium la cosa è ancora più utile perché non tutte le funzioni aziendali hanno accesso a tutti i report e tutti i dati, e molti si basano sull’uso di API per interrogare solo i KPI di interesse. Se però i KPI di interesse sono fortemente campionati, fino ad ora non c’era altra possibilità che andare sul prodotto e richiedere il report unsampled, mentre adesso anche questa operazione può essere svolta tramite API.

Altra novità recente è la suddivisione semi-automatica tra le keyword di brand e quelle non di brand; il sistema provvede ad estrarre quelle che secondo lui sono le chiavi di brand, ma è ovviamente possibile modificare a piacimento la configurazione. Una volta terminata questa oeprazione Analytics chiederà di poter creare due nuovi canali nel raggruppamento predefinito dei canali: uno per le chiavi di brand e uno per quelle unbranded, che si andranno a sostituire progressivamente al canale di default “Paid Search”. Questa classificazione esiste soltanto per le chiavi a pagamento (non solo per AdWords), mentre per via del fenomeno delle (not provided) non si può applicare (e non avrebbe senso farlo) al traffico organico.

Per quanto riguarda le novità di prodotto vere e proprie, segnalo che per l’ennesima volta è stata rifatta l’interfaccia dei segmenti avanzati, sia nella parte di visualizzazione sia nella parte di creazione.
La nuova visualizzazione dei canali ora si presenta così

se non volete a tutti i costi usare la freccia verso il basso per rimuovere un segmento, vi svelo un trucco: basta trascinarlo ‘via’ 🙂

L’interfaccia di selezione ora si apre per impostazione predefinita in modalità “verticale”, garantendo finalmente la leggibilità dei segmenti con i nomi più lunghi:

E’ stato introdotto anche un comodo selettore “selezionati”, che provvede a scremare soltanto i segmenti attivi: quante volte volevate togliere un segmento e siete stati costretti a scorrere più volte su e giù il menu perché non li trovavate? 🙂

Ho notato da qualche giorno che nelle dimensioni secondarie è comparso un raggruppamento “ora”. Sebbene data, ora e ora del giorno siano sempre stati selezionabili, adesso il numero di dimensioni è molto più cospicuo e comprende cose interessanti come ad esempio:

• giorno del mese
• giorno della settimana
• mese dell’anno (03) e mese dell’anno (201403); pessima traduzione di due concetti diversi :-/
• minuto (001036, inteso come minuto del giorno) e minuto (05, inteso come minuto dell’ora)
• nome del giorno della settimana
• settimana ISO dell’anno ISO

e altri ancora. Quando si fanno analisi granulari sono dimensioni che possono tornare MOLTO utili…

infine giovedì e venerdì scorso si è tenuta la prima edizione italiana dell’ Emetrics summit, evento di caratura mondiale dedicato esclusivamente al mondo della misurazione. Oltre ad aver incontrato Jim Sterne, padre fondatore della web analytics e della Digital Analytics Association, e ad aver rivisto molti amici e colleghi, Tommaso Galli ha tenuto uno speech dove tra l’altro ha ribadito con questo video l’importanza di usare un TagManager per la gestione dei tag di marketing. Un po’ quello che cercavo di spiegarvi qualche tempo fa, sotto un’altra ottica… 🙂

Lukas Bergstrom ha comunicato su Google+ che da adesso le funzionalità avanzate di remarketing (e quindi i report demografici e le liste di remarketing) sono nativamente disponibili anche nei template Universal Analytics su TagManager. Cade anche l’ultima scusa per non migrare definitivamente a Universal Analytics 🙂

Già che ci sono volevo fare una precisazione su come funziona questa integrazione: in passato era richiesta la modifica del codice di monitoraggio per includere un file (dc.js) che era ospitato sul dominio doubleclick. Questo forzava i browser ad inviare insieme ai dati di Analytics anche i cookie del dominio Doubleclick, che poi provvedevano a inserire l’utente in una lista di remarketing o a fare altre operazioni associate a quei cookie. Con Universal invece questa modifica non è richiesta: è sufficiente aggiungere la funzione

ga('require', 'displayfeatures');

al tag di Universal (o cliccare la nuova opzione su GTM, appunto), che continuerà ad inviare dati al dominio google-analytics.com. Insieme alla prima hit ne verrà inviata ANCHE una ai server Doubleclick, e poi un’altra ogni 10 minuti circa. Questo ha l’indubbio vantaggio di evitare che certe hit vadano perse nel caso in cui, ad esempio, un Adblock particolarmente stretto non permetta l’invio di hits al dominio doubleclick.net.

Già che parliamo di Universal, vi sarete accorti anche del messaggio che compare all’apertura dell’interfaccia di Google Analytics: “Universal properties created prior to December 2013 may temporarily report doubled Visits counts between the hours of 0500-0800 in the View timezone. This issue corrects itself automatically. We are working on a fix to address this issue as soon as possible.”

Si tratta di un problema noto da mesi, che speravo si sarebbe sistemato prima del rilascio ufficiale di Universal al pubblico ma che invece è ancora presente, al punto da costringere gli ingegneri a notificarlo in questa maniera. Il problema è fastidioso solo se si ha l’esigenza di analizzare i dati odierni, perché si auto-corregge da solo successivamente, ma si tratta indubbiamente di una situazione affrontata poche volte in passato

Dopo aver scritto il post sulle novità del Google Tag Manager ho riflettuto su un po’ di cose che ho fatto ultimamente tramite quello strumento, realizzando che effettivamente non erano ne poche ne banali. L’intero impianto del TagManager, per come è costruito, aggiunge un ulteriore livello di possibilità che a volte integrano e a volte si sovrappongono a funzionalità core di Google Analytics. Faccio degli esempi:

• Voglio escludere le visite aziendali interne: lascio il codice ovunque e filtro gli indirizzi IP da Google Analytics. Oppure, più elegante, creo tre viste per la stessa property: una totale, una con solo le visite esterne e una con solo le visite interne, sempre con i filtri di GA. Oppure condiziono l’UA cui inviare i dati (produzione o staging/sviluppo) in base all’host. Senza scrivere una riga di codice. Plus aggiuntivo, in questo modo le hit “inutili” non intaccano il limite mensile e non incidono sul campionamento, che avviene sempre sul totale inviato pre-filtri.
• Voglio riscrivere alcuni indirizzi delle pagine: il filtro “cerca e sostituisci” di GA ha alcune limitazioni, ad esempio non permette di togliere parti (cioè di sostituire con “vuoto”), i filtri avanzati richiedono spesso regular espression e in ogni caso devo farne uno per ogni caso. Nel GTM con una macro di tipo Javascript personalizzato invece posso far scrivere a un programmatore tutta la logica necessaria a gestire molti casi, anche complessi, ed inviare ad Analytics solo quel che mi serve, nella forma che mi serve
• Voglio condizionare un certo tag sulla base di una informazione che è esistita solo in un dato momento passato: posso scriverla in un cookie e leggerla in un secondo momento, sempre senza mettere mano al sito e scrivendo poche righe di codice nel GTM

E così via… quindi alla fine ho pensato di scrivere questo post come puro esercizio, per capire fino a dove si può arrivare. Voi scrivete nei commenti cosa vorreste poter fare, o cosa avreste voluto fare su Analytics che non vi è riuscito – tipicamente con i filtri, ma non solo – e tutti insieme vediamo se il Tag Manager può risolvere. Pronti? via! 🙂

Se dovessi descrivere il Google TagManager e i suoi vantaggi non mi basterebbe una giornata. Hai voglia a dire che le cose diventano semplici e veloci, spesso appare talmente bello da non sembrare vero. Se un video vale più di mille parole, per me questo pezzetto di “tre uomini e una gamba” rappresenta la summa perfetta di cosa è il TagManager (ho numerosi testimoni che possono confermare 🙂 )

Una delle note negative però, se vogliamo, è che questo prodotto evolve alla velocità della luce; tanto per capirci, molto più veloce di come evolve Google Analytics, che già non è facile… per questo motivo eccovi un piccolo riassunto delle novità introdotte ultimamente nel GTM, o almeno di quelle che ho potuto vedere (senza nemmeno poterle testare tutte…)

1. Macro Lookup Table (tabella di ricerca in italiano): si tratta di una tabella che restituisce un valore sulla base di un altro valore. Dannatamente comoda in moltissimi casi, il più semplice tra tutti è quello di condizionare l’UA a cui inviare i dati in base al dominio in cui avviene la visita, in questo modo:

   

2. Macro fragment e cronologia: il fragment, unito ad una regola apposita intercetta le variazioni di url con il cancelletto, quindi un indirizzo di pagina che passa da /pagina.html e pagina.html#anchor1 si può intercettare. Il secondo tipo serve a intercettare la history delle location del browser, ma non l’ho ancora testato e presumo si riferisca solo ai cambiamenti forzati tramite javascript. A questo proposito i più tecnici possono leggere questo post su G+ di Simo Ahava, di cui riporto solo il pezzo saliente
   

   1) You have a single-page site with dynamic content
   2) You create a fabricated browser history entry to save current state
   3) The visitor leaves your site and comes back via browser back button
   4) You can use the History Listener to check if there was some state saved in (2)
   5) You can provide the same state that was saved in (2)

3. Tag Evento “rilevatore errori javascript”: si tratta di un nuovo tipo di listener, dopo quelli per i click e le form, che intercetta gli errori javascript sulla pagina. Può essere utile in fase di debug, oppure come suggerisce nuovamente Simo Ahava su Google+, creando un UA tutto nuovo solo per collezionare gli errori javascript e avere un grande repository a disposizione degli sviluppatori per migliorare il sito basandosi su erorri reali e non teorici.
4. Macro “testo elemento”: incredibile a dirsi, mancava! permette di intercettare (ad esempio per creare condizioni) il CONTENUTO di un elemento cliccato

Inoltre sono stati introdotti una macro per indicare se si sta guardando una bozza del contenitore o una versione live, e la possibilità di forzare il codice ad usare la versione debug, che stampa nella consolle del browser moltissime informazioni utili.

All’alba del 2014 mi capita ancora troppe volte di vedere account strutturati in maniera tutt’altro che ottimale. E se da un lato posso essere d’accordo che spesso non è facile ricominciare da zero con un account pulito e ristrutturato, dall’altro ci sono tante ottime ragioni per farlo, e tante tecnologie e soluzioni per facilitarlo. In questo post vedremo cosa è e perché accade il fenomeno del campionamento dei dati, perché le soluzioni adottate in passato non sono più ottimali e come si ovvia al giorno d’oggi.

Campionamento 101: di cosa si parla

Il fenomeno del campionamento (box giallo in alto a destra) avviene ogni volta che si chiede a Google Analytics di produrre dati che non sono precalcolati nei report standard. Ho descritto in passato cosa accade e perché nei due post “come funziona il campionamento” e “come funziona il campionamento (ufficiale)“, che ti invito a ripassare prima di proseguire nella lettura.

Per quanto concerne questo post, la parte fondamentale di quei due articoli è quella che dice “E’ importante notare che il campionamento avviene a livello di web property e non di profilo” (oggi i profili si chiamano “viste”). Avere delle viste-copia non risolve il problema del campionamento, se la vista principale conta tantissime visite.

Il fittizio caso esempio

Il famoso brand ACME è una multinazionale globale, con sedi in tutto il mondo e 30 siti in lingua attestati su 30 diversi top level domain. Per le sue esigenze di marketing interne ha bisogno di KPI a livello globale (rollup) e insight a livello di singola country/lingua.

Fino a qualche tempo fa l’approccio standard era: traccio tutto con una unica web property su GA, quindi con un solo UA, poi creo 30 viste-copia e su ognuna metto un filtro sul nome host.

Questa soluzione si portava appresso alcuni assunti e alcuni accorgimenti da prendere: se il visitatore può passare da un dominio all’altro (ad esempio perché cambia lingua, o perché il sito worldwide ha una spashpage con selezione lingua, o perché il gateway di pagamento ecommerce è uno solo in tutto il mondo ed è attestato in un sottodominio del sito .com, o per qualsiasi altro motivo…) è necessario impostare correttamente il cross domain tracking, altrimenti i conteggi di visite e visitatori unici nel profilo di rollup saranno gonfiati. Inoltre se non si gestisce il passaggio dei cookies, il profilo di rollup vedrà moltissime visite con referral interni (quando un utente passa dal .it al .de diventa un nuovo utente unico, si crea una nuova visita e la sorgente di traffico è un sito ACME). Idem i profili clone, che in assenza del cross domain tracking non conservano la sorgente di traffico originale, ma sono funestati dal fenomeno self referral.

Anche ammesso che questa parte sia stata gestita a puntino, il tutto subirà i nefasti effetti del campionamento se il profilo di rollup salirà molto con le visite. Nel caso in cui il rollup registri 5 milioni di visite, anche una vista copia per un paese nel medesimo periodo segna solo 60 mila visite subirà un campionamento al 5%, perché quando Analytics campiona ritorna sempre ai dati della property per estrarre il campione, e poi rifiltra il risultato secondo le regole impostate nella vista.

Come si riduce, oggi, questo fenomeno?

Oggi non mi sogno più di consigliare le viste clone in casi come questo, gli svantaggi sono evidenti sia in termini di manutenzione (decine o centinaia di filtri da tenere d’occhio) sia soprattutto in termini di performance.
Oggi, grazie soprattutto all’avvento delle tecnologie di Tag Management (ma non è obbligatorio) e di Universal Analytics (soprattutto per quanto riguarda la parte di cross domain tracking) l’approccio che consiglio è quello di “una web property per ogni cosa”:

• Profilo di rollup? una web property! UA-xxxxxx-1
• AMCE.it? una web property! UA-xxxxxx-2
• ACME.de? una web property! UA-xxxxxx-3
• ecommerce globale? una web property! UA-xxxxxx-4
• e così via…

Ovviamente su ogni pagina del sito ci saranno almeno due codici di monitoraggio (il rollup e il singolo dominio, ma potrebbero esserci anche codici per singoli sottoprogetti, non c’è limite alla fantasia…), il cross domain tracking deve essere impeccabile, e per fare queste due cose con semplicità io consiglio l’uso del Google Tag Manager; ma una volta messo in piedi il sistema, i risultati sono garantiti: il numero di visite è sempre congruente tra le property, sebbene non si possa sommare per ovvi motivi. Se passo dal it. al .de sono 1 visita su ognuna delle viste, ma sono 1 sola nel rollup. La sorgente di traffico è sempre quella originale che ha portato l’utente sui siti, e raramente è un referral interno. Ma soprattutto il campionamento viene eseguito sulla base dei reali dati di traffico: con gli stessi numeri dell’esempio precedente il profilo di rollup subisce un campionamento al 5%, ma il profilo con 600 mila visite lo subisce solo al 41%.

Inoltre ogni web property può essere usata singolarmente per produrre viste clone filtrate, su base dominio e non su base rollup. Il che a me sembra un ulteriore vantaggio!

Da qualche giorno l’interfaccia del Google Tag Manager ha subito un lift, ma questa volta il risultato non è del tutto soddisfacente dal mio punto di vista.

Innanzitutto la creazione di un nuovo tag, regola o macro è stata raggruppata sotto un unico pulsante rosso con etichetta “NUOVO”, che se cliccato produce un piccolo menu colorato con le icone che c’erano prima

Questa modifica è tutto sommato positiva.
In secondo luogo le regole di attivazione e blocco dei tag sono state spostate sulla destra, mentre prima erano sotto. Questo da un lato è positivo, perché all’apertura di un tag si ha subito idea di quali siano le condizioni che lo attivano o bloccano. Ma dall’altro lato produce due effetti collaterali piuttosto negativi:

1) lo spazio a disposizione della configurazione del tag è ridotto orizzontalmente, procudendo su schermi piccoli effetti abbastanza orrendi (clic per ingrandire)

2) lo spazio a disposizione delle regole di attivazione e blocco è, di conseguenza, minore, e questo crea problemi con tag con nomi lunghi

Indubbiamente l’intenzione dei designer è quella di ottimizzare lo spazio, ma in questa interazione non ci sono riusciti pienamente e in alcuni casi (schermi di portatili, soprattutto) lavorare sul TagManager è diventato più complicato invece di più facile.

Speriamo che alla prossima interazione non manchi molto.

Sin da quando il Google Tag Manager ha fatto la sua comparsa nel panorama web, una delle critiche maggiori che gli è stata mossa era “eh, ma non ci posso mettere il tag xyz”. Non perché il GTM sia uno strumento su misura solo per i tag di Google – anche se ovviamente questi hanno dei template già pronti – quanto perché una delle restrizioni maggiori era data dal fatto che il codice del tag manager agisce in modo asincrono: ovvero viene eseguito “quando si può”, indipendentemente dallo stato di caricamento della pagina.

Questo determinava l’impossibilità di usare, all’interno dei custom HTML tag, codici che contenessero la direttiva “document.write”, che invece agisce in modo sincrono modificando l’output generato dal browser per inserire “pezzi” a partire da istruzioni javascript. Quasi tutti i pixel di tracciamento usano document.write per fare i tracciamenti, e fino a ieri non si potevano inserire nel GTM.

Da qualche giorno invece quando si crea un custom HTML tag esiste una checkbox – opzionale – che permette proprio di inserire codici con document.write nel tag manager. Quale tipo di “magia” tecnica ci sia dietro non me lo chiedete, non arrivo così in là con la comprensione di queste cose, ma da qualche test veloce sembra funzionare come ci si aspetta: in ogni caso tenete presente che si tratta di una funzione NUOVA, e che la dovrete usare a vostro rischio e pericolo.

Un’altra novità riguardante il tag manager è l’introduzione delle custom javascript macro, ovvero macro che non dipendono più dalla presenza o meno di un valore all’interno di URL, dataLayer, variabili o testo della pagina, ma che consentono di scrivere funzioni che dato un valore in ingresso lo elaborano e restituiscono un valore in uscita: questo consente tra le altre cose di aggiungere della “logica” (se… allora…) a uno strumento che fino ad ora ne era sprovvisto, e di fare tante altre cose carine che sto sperimentando in questo periodo 🙂

Infine una nota di colore: la settimana scorsa sono incappato in un errore strano facendo delle prove con Tag Manager, e non trovavo bibliografia in merito. Prova e riprova non ne venivo a capo, e quindi ho fatto una segnalazione: si trattava in effetti di un baco (o meglio di un caso particolare che generava un problema). La cosa è stata risolta in pochi giorni, e devo dire che mi ha fatto piacere sentirmi parte del continuo miglioramento di uno strumento che sta aiutando moltissime aziende e persone a velocizzare tantissimo i processi interni di gestione e delivery dei tag, e quindi ad avere risposte dagli strumenti in tempi incredibilmente ridotti!

EDIT, pochi minuti dopo: siccome le novità non sono mai troppe, apprendo or ora che esiste anche una V2 del dataLayer, impostabile quando si crea una macro, che consente di accedere ai valori nidificati tramite notazione javascript standard. La frase di help esatta è:
“Versione 2: i punti accedono a valori nidificati. I valori inviati al livello dati contenente punti nel nome verranno considerati valori nidificati in base alle regole JavaScript standard.”
Su questo però devo fare prima dei test, perché l’ho appena vista anche io 🙂

Come dicevo nel post precedente, anche durante la settimana di Ferragosto il team di Google Analytics non riposa, ed in effetti ci sono state un po’ di novità sugli strumenti che usiamo tutti i giorni. Iniziamo dai post apparsi sul blog ufficiale:

• Tag Manager Mobile e GA Services SDK: vi avevo già parlato del Tag Manager per applicazioni mobile in occasione della sua presentazione al Google I/O 2013. E’ venuto il momento di farlo conoscere al grande pubblico e il blog ufficiale ce ne da riscontro. Degli indubbi vantaggi che esso apporta ad una applicazione mobile vi ho già detto (vi ricordo solo la killer feature di bypassare le richieste di ripubbliccazione agli store), mentre una novità è che da adesso gli SDK di Analytics e del Tag Manager sono racchiusi in un unico set di files, chiamato Google Analytics Services SDK. Questo significa che importare il file nel progetto consente di utilizzare sia GA sia il Tag Manager Mobile.
• Data Driven Attribution Tool (Premium only): si tratta di un sistema automatizzato di analisi del miglior modello di attribuzione disponibile in base ai dati presenti nel proprio account. Fino ad ora il Multi Channel Funnel e i modelli di attribuzione ci hanno aiutato a capire meglio il cosiddetto customer journey, ma si trattava pur sempre di rendicontazione di qualcosa che accade. Questo nuovo set di tool si spinge oltre, e permette di esplorare le variazioni basando le sue decisioni su algoritmi e probabilità di conversione. Una volta definito il proprio goal, il modello analizza i path di conversione e crea il “modello ideale” di attribuzione, e lo aggiorna con regolarità, permettendo anche di confrontare i risultati del modello automatizzato con uno dei modelli predefiniti disponibili nel sistema. E’ disponibile soltanto ai clienti GA Premium
• Metadata API: si tratta di un nuovo set di API, in grado di semplificare la vita a chi usa le API 🙂 sembra un gioco di scatole cinesi, ma in effetti non lo è. Al momento, se Google rende disponibile una nuova metrica o dimensione attraverso le API lo sviluppatore di un tool deve prima sapere che questo è accaduto e poi modificare la sua applicazione di conseguenza. Se è un servizio web gli utenti sono facilitati, se si tratta di un software si rende necessario far scaricare una nuova versione. Usando le Metadata API questo fatto verrebbe automaticamente esposto all’applicazione, che potrebbe semplicemente leggere il nuovo valore, il suo nome e i suoi attributi ed essere programmata per esporre sempre tutti gli attributi presenti. Faccio un esempio pratico: per una certa dimensione GA mi permette di fare query su 3 diverse metriche. L’applicazione visualmente me le propone. Google espone nelle API una nuova metrica per quella dimensione. Dopo aver fatto “un giro” con le metadata API l’applicazione mi presenta automaticamente anche la quarta metrica come disponibile per quella dimensione. Si tratta di un’automazione molto importante affinché le applicazioni che si basano sulle API siano sempre aggiornate. E’ una innovazione talmente importante che Google ha deciso di applicare una nuova policy di deprecation ovvero di cessazione del supporto a cose obsolete riguardante le API: se qualcosa viene deprecato le metadata API restituiranno DEPRECATED per almeno 6 mesi, e poi BAD REQUEST, consentendo anche in quel caso di aggiornare le applicazioni in modo automatico
• Supporto document.write nel Tag Manager: da qualche giorno utilizzando un tag HTML custom nel Tag Manager appare la scritta “Supporto document.write. Google Tag Manager offre un nuovo motore sperimentale per il rendering dei tag HTML personalizzati. Include un supporto per le chiamate a document.write()”. Questa cosa era impossibile sino a qualche tempo fa, ma è molto importante perché di fatto consente di infilare dentro al Tag Manager qualsiasi tag, anche quelli che fino ad ora si era detto che non si potevano inserire perché – appunto – ristretti dal fatto che contenessero una direttiva document.wirte. Va notata la parola “sperimentale”, quindi usate questo tipo di tag ancora con cautela; come tutte le novità è bene fare delle prove prima di mandare cose in produzione 🙂