Google Analytics in 30 secondi

In questo back-to-basic voglio affrontare un classico errore da principiante che su Google Tag Manager è potenzialmente molto dannoso: si tratta dell’editing delle regole di attivazione direttamente da dentro alla configurazione di un tag.

Come saprete, l’interfaccia v2 di GTM consente ampia libertà nel configurare Variabili, Attivatori e Tag: oltre che nelle sezioni apposite e con l’uso del pulsante “NUOVO”, si può creare una attivatore o una variabile anche mentre si configura un tag, con schermate successive che si sovrappongono all’attuale. Ecco, secondo me l’aggiunta di regole (la modifica più che altro) direttamente dall’interfaccia dei tag dovrebbe essere limitata. Facciamo il caso pratico:

Il cliente chiama e dice “mi serve questo tag solo sul sottodominio italiano”. Tu prendi, configuri il tag e crei una regola di attivazione tipo – ipotizziamo – “page Host uguale a it.sitodelcliente.com”. Pubblichi, funziona e te ne dimentichi.
Dopo tre mesi il cliente richiama e dice “sai quel tag? dobbiamo estenderlo anche ai sottodomini francese e tedesco”.

Qualcuno potrebbe avere la bella idea di andare nel tag, aprire l’attivatore, cambiargli nome e cambiare la regola in “page Host corrisponde alla regex (it|fr|de)\.sitodelcliente\.com”. D’altronde in italiano è esattamente quel che ci ha chiesto il cliente, estendere un tag ad altri sottodomini.

ERRORE!

L’errore è quello di pensare all’attivatore come parte di un tag, cosa che l’interfaccia un po’ ti spinge a fare. Ipotizziamo che un’altra agenzia nel frattempo abbia messo un suo tag solo sul dominio italiano. Se cambiamo l’attivatore, lo cambiamo PER TUTTO IL TAGMANAGER, non solo per quel tag. Ovvero, estendiamo il campo di azione di TUTTI i tag associati a quell’attivatore.

Se invece di aprire il tag andassimo nella sezione degli attivatori, la cosa sarebbe più chiara perché ogni attivatore riporta vicino il numero di tag associati ad esso. E in ogni caso noi staremmo solo cambiando un attivatore, senza riferimento a nessun tag, e la cosa potrebbe farci nascere sospetti se ripensassimo alle parole esatte del cliente.

In buona sostanza il mio consiglio è quello di evitare per quanto possibile di modificare variabili e attivatori da dentro a un tag, in modo da rimuovere il legame mentale tra il tag e gli altri elementi, e lasciare che il concetto più corretto del GTM pervada la nostra mente: MODULARITA’ 🙂

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

Dopo qualche segnalazione di malfunzionamento il team di Google Analytics è riuscito a riprodurre l’anomalia e ad individuare le cause di un baco che mostrava zero visite in alcuni custom report, segmenti avanzati e dimensioni secondarie, quando si guardava ai dati di Aprile.
Non ci è dato sapere perché, ma il post ufficiale ci informa che stanno lavorando alacremente per risolvere il problema; quindi non possiamo fare che attendere speranzosi…

[edit 12/5: tanto piccoli i problemi non devono essere, tanto è vero che la risoluzione prevista, ad oggi, è per il 23 maggio.

We expect to resolve the problem affecting a majority of users of Web Report at May 23, 2011 11:00:00 PM PDT. Please note that this time frame is an estimate and may change.
We are now able to provide a tentative date for resolution of the issue with April data in Advanced Segments, Custom Reports and secondary dimensions of May 23rd. We will continue to update the status dashboard as more information becomes available.

Sarei tanto curioso di capire esattamente cosa è successo, per “incasinare” così a fondo le cose… ]

Se siete preoccupati perché non vedete i dati di ieri 2 novembre, beh sappiate che non siete i soli. Ci sono decine di post nel forum ufficiale, e Google è al corrente della cosa e ci sta lavorando, come potete leggere dalla Google Analytics Status Dashboard.

Ho fatto un controllo a campione sui miei profili, e anche io ne sono affetto. Non ci sono più i privilegiati di una volta! 🙂

[edit: Matteo Carli mi segnala su Twitter che i dati sono disponibili attraverso le API, e che il problema è solo dell’interfaccia, come tra l’altro si nota guardando la dashboard. il problema è nella riga “rapporto web” e non in quella “raccolta dati” ]

[edit 2: ecco anche il post ufficiale]