Google Analytics in 30 secondi

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:

1. 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
2. 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.

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 🙂

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:

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

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?

[qui c’è un post di Daniel Waiseberg con alcuni screenshot]

Bounce rate “accomodato” è la mia traduzione per “adjusted bounce rate”, come lo chiamano su questo post del blog ufficiale di Google Analytics. Si tratta di un escamotage per evitare di considerare come rimbalzi visitatori che trascorrono più di tot tempo sulla pagina di atterraggio.

In pratica si aggiunge una funzione javascript che trascorso un intervallo di tempo predefinito spara un evento, che essendo una hit di engagement annulla il bounce rate. Il codice di base delle pagine diventerebbe quindi

var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXXXX-1']);
  _gaq.push(['_trackPageview']);
  setTimeout("_gaq.push(['_trackEvent', '15_seconds', 'read'])",15000);

  (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);
  })();

A seconda di quanti millisecondi utilizzerete nella vostra implementazione, il vostro bounce rate si abbasserà in modo maggiore o minore.

Ma ragioniamo un attimo su quel che succede:
Normalmente un visitatore atterra su una vostra pagina, e se non compie nessuna azione (cioè se non invia nessun’altra engagement hit), viene considerato un bounce; questo naturalmente può accadere sia se il visitatore trascorre sulla pagina 3 secondi, sia se invece ci resta 5 ore. L’esempio della pagina super ottimizzata del ristorante, che trovo al primo colpo su Google e che contiene anche il numero di telefono, quindi soddisfa in pieno il mio desiderio (e magari si mangia pure bene, e anzi come dice sempre Francesco de Francesco – magari poi ci torno per il matrimonio e gli porto un incasso di seimila euro, e lui vede un bounce! 🙂 ), è perfetta. E’ una pagina che è naturale abbia un alto tasso di rimbalzo, almeno per il segmento di visite organico.

Bene, abbiamo detto quindi che non sappiamo quanto tempo sia stato effettivamente sulla pagina, e benché meno sappiamo se la pagina l’ha letta davvero oppure no!

Implementiamo allora il bounce rate accomodato, e consideriamo bounce solo chi va via prima di 15 secondi. Questo cosa mi dice più di prima? quanti stanno più di 15 secondi, ovvio. Ma è in grado di cambiare la vera informazione che mi servirebbe, cioè se la pagina è stata letta o no? assolutamente no! se uno non la legge, può non leggerla in 8 secondi, ne in 32, ne in 4 ore (perché ha lasciato il browser aperto ed è andato in riunione).

Non sto dicendo che il metodo sia da evitare a tutti i costi, sia chiaro: dico solo che va utilizzato per la reale informazione che mi da, cioè una modifica del tempo sulla pagina; ma trascorrere più tempo sulla pagina non significa che è stata compiuta un’azione!
Se proprio volessimo fare degli aggiustamenti, allora punterei di più sul sistema di Justin Cutroni per tracciare lo scroll della pagina (parte 1 – parte 2), magari in una sua forma alleggerita per sparare l’evento antibounce allo scroll della pagina, che mi sembra una azione molto più del trascorrerci più di 15 secondi.

Royal Pingdom è uno dei mie blog preferiti, perché coniuga i numeri con le storie, produce spesso ottime infografiche e spesso ci fa riflettere su quanto siamo piccoli all’interno del mare magnum di internet (e sono svedesi 🙂 ).
Un loro post recente ha nuovamente fatto il punto sulla diffusione del nostro sistema di web analytics preferito: prendendo la top 10.000 di Alexa, Google Analytics è presente su più del 62% dei siti.

Questo numero scende a poco meno del 50 se si restringe alla top 1.000, e al 22,7 se si guardano solo i primi 100: normale se si considera che più si sale, più i siti sono corporate, e-commerce, trafficati e quindi è più facile che abbiano esigenze che possono essere soddisfatte anche da altri sistemi di web analytics. La crescita della diffusione all’interno della top 10.000 parla chiaro: in due anni il numero è cresciuto del 25%!

Interessante anche l’ultimo punto: già che scansionavano i siti, i ragazzi di Pingdom si sono presi l’onere di controllare quante chiamate a ga.js ci fossero e quante invece a urchin.js, la versione obsoleta dello script che nessuno al mondo dovrebbe più usare. Ebbene, a distanza di cinque anni dall’introduzione di ga.js, il 6,5% dei siti usa ancora la vecchia versione dello script di tracciamento. Credo che questo numero sia ancora troppo alto per far propendere Google verso la sua totale cancellazione (e sicuramente loro, che stanno nella “stanza dei bottoni”, sanno quale sia il reale utilizzo del file), però non si può mai dire…

Di metodi per tracciare gli errori dei siti ne abbiamo visti parecchi, in questi anni: 404, 500, con pagine virtuali o con eventi, praticamente tutte le combinazioni possibili sono state sviscerate. Ma c’è un tipo di errore diverso che non avevo mai visto tracciato, ed è l’errore client-side, o l’errore visualizzato dal browser. Se ad esempio il vostro sito è una webapp, o un sito che fa un uso molto spinto di AJAX e javascript, i problemi più comuni non saranno errori di pagine non trovate o di chiamate sbagliate al database, bensì errori di interpretazione ed esecuzione di funzioni lato client.

Per questo motivo in un post del blog di ThetaBoard c’è un elenco di tool dedicati adatti a tracciare queste situazioni, ma allo stesso tempo è anche presente una soluzione semplice e alla portata di tutti: siccome Google Analytics è installato un po’ ovunque, e siccome è gratis, con una semplice modifica del codice si può avere – quasi – lo stesso risultato. La modifica è l’aggiunta, dopo il codice di monitoraggio standard, delle righe

// ADD THIS AT THE BOTTOM OF YOUR GOOGLE ANALYTICS TRACKING CODE //
window.onerror = function(message, file, line) { 
   var sFormattedMessage = '[' + file + ' (' + line + ')] ' + message; 
   _gaq.push(['_trackEvent', 'Exceptions', 'Application', sFormattedMessage, null, true]);
}

Il sistema utilizzato è quello degli eventi, per cui il report relativo da guardare sarà quello delle etichette degli eventi. Ancora meglio però sarà suddividere gli errori per pagina, per cui si aprirà il report CONTENUTI -> EVENTI -> PAGINE e si utilizzerà la dimensione secondaria ETICHETTA EVENTO, ottenendo esattamente quel che si vede nell’immagine del post che vi ho linkato

Come si dice giustamente nel paragrafo finale, il sistema non è perfetto, e non è un sistema dedicato, ma ha dalla sua almeno due buoni vantaggi: non dovrete installare un nuovo sistema e caricare il server anche di quell’incombenza, e soprattutto potrete capire che relazione esiste tra questi errori e le vostre metriche di business, come il conversion rate o le transazioni. Il che non mi sembra affatto poco! 🙂

Subito la premessa: il metodo descritto non è stato da me testato, questa è una pura segnalazione! tuttavia è stato scritto un mese fa, non dovrebbero esserci stati sconvolgimenti colossali nel frattempo.

Se analizzate spesso i report mobile, vi sarete accorti che alle righe Iphone e Ipad dei report sui sistemi operativi non corrispondono dei drilldown con le versioni dello stesso (iOS 5, iOS 5.1, eccetera…). La cosa è meno vera per i dispositivi Android, e in parte vera per altri sistemi. La cosa potrebbe avere una certa influenza, a seconda del tipo di business in cui operate, per cui Jay Taylor di Fresh Egg se ne è uscito con una soluzione per ovviare al problema:

il primo passo da fare è quello di scaricare la libreria – trovate il link sul suo sito – e referenziarla PRIMA del codice di Google Analytics.
Secondariamente si deve aggiungere la seguente riga al codice di monitoraggio
_gaq.push(function() { checkMobileAgent(); });
Jay dice di metterla prima o dopo _trackPageview, io la metterei prima.
Terzo bisogna mettere in piedi dei filtri personalizzati.

Filtro 1 – Capture Mobile OS Platform from User Defined
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: definito dall’utente
Campo A -> regex: ^([^:]+)::.+$
Output To -> Constructor: piattaforma del sistema operativo visitatore
Output To -> Constructor value: $A1

Filtro 2 – Capture Mobile OS Version from User Defined
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: definito dall’utente
Campo A -> regex: ^[^:]+::(.+)$
Output To -> Constructor: piattaforma del sistema operativo visitatore
Output To -> Constructor value: $A1

Prestate attenzione alle espressioni regolare, differiscono di pochissimo. Altra cosa interessante del metodo è che usa il valore definito dall’utente impostato tramite la deprecata funzione _setVar, ma aggiunge un terzo filtro che svuota il valore definito dall’utente prima che esso arrivi ai report; in questo modo il relativo rapporto sarà vuoto, oppure se avete degli altri filtri che usano quel campo li potrete accordare a questi tre, e continueranno a funzionare.

Filtro 3 – Prevent __utmv Cookie Data writing to User Defined report
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: User-Defined
Campo A -> regex: (.*)
Output To -> Constructor: definito dall’utente
Output To -> Constructor value: (not set)

Il sistema funziona se e solo se lo user agent utilizzato per visitare il vostro sito da mobile corrisponde a uno di questi sistemi: “iPhone”, “iPod”, “iPad”, “Android”, “webOS”, “BlackBerry”, e quindi il nuovo drilldown relativo sarà presente solo per questi sistemi operativi. Ma come vedete dallo screenshot di Jay, direi che funziona!

Abbiamo già visto in passato come aggirare il limite di visualizzazione nei report nella versione 5 di Google Analytics, ma quel “trucco” funziona solo mentre si guardano i report; gli export sono sempre limitati a 500 righe.

Il buon vecchio André Scholten non si capacitava di questa situazione e ha scritto una funzione javascript che fa quel che ci aspettiamo: costringe Google Analytics ad inviarci un file contenente fino a un massimo di 10.000 righe. Per farlo potete fare come dice lui (creare un bookmark e usare la funzione come indirizzo) oppure semplicemente posizionarvi nel report che preferite, copiare la funzione e incollarla nella barra degli indirizzi, assicurandovi che sia mantenuto il prefisso javascript:
Una volta premuto il testo ENTER ci verrà richiesto quante righe vogliamo esportare, da un minimo di dieci a un massimo di diecimila, e una volta confermato il download partirà automaticamente.

Al momento il sistema funziona solo per l’export di file TSV (quindi separati da tabulazioni), ed è stato testato da lui solo su Firefox e Chrome, da me solo su Chrome. Però funziona, e in certe occasioni è comodo!