Google Analytics in 30 secondi

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:

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…

“Per un punto Martin perse la cappa” è un vecchio detto popolare che mette in guardia da un errore apparentemente di scarsa entità ma che invece comporta conseguenze spesso disastrose. E’ il detto che mi è venuto in mente rileggendo un vecchio articolo di AnalyticsPros riguardante gli errori dei codici di tracciamento e-commerce. Probabilmente un problema che noi italiani sentiamo meno, ma che vale la pena comunque di sottolineare.

Le funzioni javascript del codice asincrono (ma anche quelle del vecchio codice asincrono per la verità) vanno incapsulate tra apici singoli (carattere sotto al punto interrogativo nella tastiera italiana). Questo è un requisito fondamentale affinché il codice funzioni. Ma cosa succede se un prodotto ha un apostrofo nel suo nome? vi ricordo che il nome del prodotto non è un parametro strettamente necessario al funzionamento del sistema, ma non ho mai visto un e-commerce che omette i nomi dei prodotti e valuta le prestazioni del suo sito con Google Analytics usando solo gli SKU code.

Quindi, se nella nostra thank-you page abbiamo un codice così:

  _gaq.push(['_addItem',
      '1234',         // order ID
      'DD44',         // SKUcode
      'Nettare d'ambrosia',      // nome del prodotto
      'bevande', // categoria
      '11.99',        // prezzo unitario
      '1'             // quantità
   ]);

il sistema va a scatafascio perché nella riga del prodotto ci sono tre apostrofi. Il prodotto diventa nettare d, ambrosia sarebbe la categoria, bevande il prezzo, 11.99 la quantità, 1 sarebbe ignorato. E peraltro mancando una virgola dopo il nome del prodotto Google Analytics non ci capirebbe nulla.

La checklist proposta nel post è piuttosto semplice: se sapete di avere prodotti che contengono l’apostrofo nel nome andate in Analytics, report dei prodotti, e cercate \’ (backslash e apostrofo, senza spazi); se non vedete nessun risultato significa che quei prodotti non vengono mai registrati da GA, e che siete affetti dal problema.
Le soluzioni possibili sono:

1. Modificare i nomi dei prodotti
2. Operare una sostituzione lato server PRIMA di eseguire il comporre il codice di Google Analytics
3. inserire un backslash prima dell’apostrofo in modo che la riga diventi ‘Nettare d\’ambrosia’, // nome del prodotto

Tutto questo lavoro per un semplice apostrofo? pensate a Martin!

Di recente mi è capitato di dover dare un’occhiata all’Analytics di due grandi siti italiani, di cui ovviamente non posso/voglio fare i nomi (anche perché irrilevante), e di riscontrare errori. Banali errori o semplici sviste che però sono in grado di inficiare i dati.

Il primo concetto da tenere sempre a mente è che javascript è case sensitive, cioè è sensibile al fatto che il codice sia scritto con le maiuscole e le minuscole corrette. Se avete mai personalizzato almeno una riga di codice dello script di Google Analytics, avrete forse notato che le funzioni sono scritte con la notazione che i programmatori chiamano “CamelCase“: per cui _trackPageview (con la P maiuscola), _setDomainName (con la D e N maiuscole), _addTrans (T maiuscola) e così via. Scrivere la funzione _trackpageview invece di _trackPageview porta al risultato di non vedersi tracciate le pagine, perché il codice cerca una funzione che non esiste.

Il secondo fatto sconcertante è che ad alcune persone non è ancora chiaro che il codice deve stare su tutte le pagine, e non solo sulla home page. Analytics non è un polipo vorace in grado di insinuarsi nel vostro sito, non germoglia tra i rami del vostro albero di navigazione, è semplicemente un codice javascript che viene eseguito insieme alla pagina. Ho usato il singolare appositamente, viene eseguito insieme alla pagina. Ad ogni pagina. Il flusso concettuale è facile:

1. vedo una pagina
2. viene eseguito il codice
3. l’informazione sulla pagina (e quindi visita e tutti i correlati) viene inviata subito a Google

Se manca il passaggio due, niente passaggio tre. Lineare

Bonus: il dominio che indicate in fase di apertura di un account GA non è rilevante o vincolante ai fini della raccolta dei dati. Analytics raccoglie i dati da qualsiasi pagina su qualsiasi dominio nella quale ci sia il vostro codice di monitoraggio (a meno che non abbiate dei filtri sul nome host, chiaro). Per questo motivo alla domanda: “devo fare qualcosa al codice se sposto il sito da un dominio a un altro”? la risposta è sempre “se non hai filtri sull’host, no!”.

Breve e conciso: il tracciamento dei link in uscita.

La prima volta che ho sentito dire “sarebbe bello che tracciasse automaticamente i link in uscita” deve essere stato il mese dopo il lancio del prodotto, quindi sei anni fa. La prima volta che ho sentito dire a un ingegnere di Google “vi daremo il tracciamento automatico dei link” non la ricordo con esattezza, ma si parla comunque di oltre tre anni fa. Poi qualcuno scoprì che il report era bello e pronto, e che le funzioni necessarie erano già presenti nel javascript, ma niente. Anche nella nuova versione v5 di prossimo rilascio, di quella funzionalità non c’è traccia.

D’accordo che le alternative sono tante, ma perché esattamente ci vuole così tanto ad attivare una funzione usata da tantissimi utenti?

Come spiego sempre durante i miei corsi, ogni singola azione che l’utente compie nel nostro sito e che deve essere trasmessa a Google Analytics, sia essa una pagina vista, una transazione ecommerce o un evento, necessita di una chiamata a una immagine .gif trasparente 1×1 pixel, a cui sono “appesi” una serie di parametri che poi il sistema trasforma nei dati che vediamo nei report.

Questa richiesta è sempre stata trasmessa con il metodo HTTP GET, che ha una limitazione tecnica di 2048 byte; le richieste che eccedevano questo limite venivano troncate, e i dati persi. Ad esempio se nella stessa richiesta state impostando 5 variabili personalizzate con nome+valore abbastanza lungo, potreste incorrere in quel limite.
Il blog ufficiale di GA ieri ci ha informato che da adesso lo script è in grado autonomamente di capire se la richiesta che stiamo per fare eccede quel limite, ed eventualmente se lo fa trasmetterla ai server di Analytics usando il metodo HTTP POST, che ha una limitazione quattro volte più alta: 8192 bytes.

Ovviamente la nostra speranza è anche un’altra: se c’è più spazio per inviare informazioni, Analytics potrebbe darci più spazio per memorizzare “cose”: ad esempio potrebbero aumentare il numero di variabili personalizzate possibili

Sempre il buon Andrea mi pone una domanda, e ne approfitto di nuovo per un post: mi fa sempre piacere scoprire cosa non è chiaro alle persone, dato che io con Google Analytics ci faccio anche colazione e quindi tendo a dare per scontate troppe cose

Il suo quesito è all’incirca “Non sono d’accordo con una persona che sostiene che trackpageview può essere utilizzato anche per rimappare l’url corrente della pagina e fare in modo che sia possibile poi utilizzare il nuovo indirizzo all’interno dei goals per verificare chi converte e chi no. Io ritengo che la funzione del trackpageview è quella si di assegnare una pagina virtuale, ma nel caso in cui si scateni un evento a cui questo è stato associato”

L’errore nasce dal fatto che _trackPageview noi lo vediamo solo in due forme. La prima è all’interno del codice di monitoraggio classico, dove viene sempre richiamata senza parametri, la seconda è quando creiamo pagine virtuali e quindi le passiamo come parametro un indirizzo fittizio. La funzione in realtà è sempre la stessa, e il suo scopo è quello di “fare il punto della situazione” nel codice di monitoraggio, scrivere i cookie nel computer del visitatore e sparare i dati verso i server di Google. Se non gli si passa un parametro, essa invia per impostazione predefinita l’url corrente della pagina così com’è.
Ma nessuno ci vieta, ad esempio, di usare una funzione lato server per inserire dinamicamente all’interno di un codice di monitoraggio degli indirizzi più leggibili ai fini delle nostre analisi.

Ipotizziamo di non avere modo di riscrivere le URL attraverso i metodi “normali” – quali .htaccess o filtri ISAPI per webserver Microsoft – e di aver scritto una funzione in PHP (abbellisciURL() ) che ci restituisce un simil-URL nella forma /categoria/marca/nomeprodotto.html

Se modificassimo il GATC così

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try{
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview(<?php abbellisciURL(); ?>);
} catch(err) {}</script>

dentro a Google Analytics avremmo SOLO ED ESCLUSIVAMENTE i nostri url abbelliti.

Potrete poi usare questi url per definire gli obiettivi? ASSOLUTAMENTE SI, dato che non sappiamo esattamente QUANDO GA elaborerà i dati, e dato che gli url modificati sono I SOLI ad essere stati inviati ai server di Google, è assolutamente lecito e possibile definire dei goal usando gli url fittizzi. Anzi, non potreste fare altrimenti!

_trackPageview() quindi si rivela anche un potente strumento per rendere i vostri report più semplici e chiari, più leggibili, ed eventualmente anche per facilitarvi la vita nell’impostazione degli obiettivi.

Qualche giorno fa mi ero messo a scrivere un post in cui sostanzialmente mi chiedevo quanto potesse essere vera l’affermazione che feci qualche tempo fa in occasione della presentazione del tracciamento dei siti mobile tramite script lato server; mi chiedevo se Google Analytics avrebbe abbandonato del tutto l’uso di javascript. Il post non mi soddisfaceva, e l’ho cestinato, ma oggi mentre riordinavo le bozze ho trovato questo articolo di Paul Legutko, datato settembre 2009: Web analytics without javascript? in cui si dice che la previsione secca “javascript sparirà entro cinque anni” è addirittura di Yahoo.

Ad alcune considerazioni ammetto di non aver pensato, sono interessanti. Vediamole:
- mobile. Ho appena detto che la soluzione di Google per il mobile non usa javascript, ma un pezzo di codice lato server (asp, php, eccetera). E’ vero che il supporto a javascript da parte degli smartphone è in costante ascesa, ma perché un colosso come big G – che pure ha fatto del tracking code javascript di Analytics una colonna portante – non crede in questa tecnologia portata sui cellulari?
- integrazione dei dati. Praticamente tutti i sistemi di tagging “sparano” i dati in un datacenter remoto; che sia Google, Webtrends o Omniture importa poco, perché l’esigenza sempre più sentita oggi è quella di integrare i dati della web analytics con tutti gli altri messi a disposizione dalla Business Intelligence. Allora perché inviare i dati per poi cavarli di nuovo fuori? è un processo poco razionale, se ci pensiamo…
- cookie. L’attenzione sempre maggiore verso la privacy e la sicurezza degli utenti online porta quasi sempre a puntare anche il dito contro i cookie. Secondo l’autore dell’articolo la percentuale di rifiuto dei cookie è tra il 3 e il 7%, a seconda della tipologia di sito preso in considerazione. Addirittura, alcuni software antivirus tracciano come “non pericolosi” i cookie traccianti dei sistemi di web analytics, ma ne consigliano comunque la cancellazione.

In passato si è parlato ogni tanto di Flash come sostituto di javascript, poiché Flash è leggero e presente su quasi tutti i computer che navigano in rete, ma è anche vero che ultimamente si sente dire che Flash morirà a causa di HTML5 (ok, in rete si sente dire di tutto, ma stiamo ragionando abbastanza in astratto…). In uno dei commenti al post viene invece suggerito il packet sniffing lato server, ovvero l’apertura di tutti i pacchetti a livello TCP che vengono inviati dal server ai visitatori del sito, in modo da carpire tutte le informazioni che normalmente vengono affidate allo script di tracciamento. Questa però è una soluzione che non è affatto alla portata di tutti, certamente non semplice quanto copiare e incollare un pezzo di codice in tutte le pagine di un sito.
Sia come sia, ritengo difficile pensare di tornare ai file di log, almeno non nella forma in cui li abbiamo conosciuti (e in qualche caso ancora conosciamo). Cinque anni sono un tempo enorme in informatica, e può darsi che la prossima generazione di sistemi di web analytics utilizzerà una tecnologia che non è stata ancora inventata; il dibattito però è affascinante, ed ancora una volta potenzialmente in grado di ribaltare completamente il settore.

[questo post tecnico è stato scritto da Paolo Ciarrocchi; dopo avermi chiesto una mano per risolvere un problema, ha iniziato a voler capire più a fondo il principio di funzionamento di Google Analytics. Ne è scaturito questo post, perché comunque è un argomento che non avevo ancora affrontato ]

Installazione del codice di monitoraggio.

Utilizzare Google Analytics per tracciare gli accessi ad un sito e’ molto semplice, e’ sufficiente inserire il codice di monitoraggio in tutte le pagine del sito che vogliamo tracciare.
Esempio di codice di monitoraggio:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._trackPageview();
} catch(err) {}</script>

xxxxxxx indica l’account number e y indica il property number. Questa coppia identifica in modo univoco il profilo utilizzato per collezionare e analizzare le statistiche.
E’ consigliabile inserire il codice di monitoraggio appena prima del tag di chiusura del body della pagina:

</body>

Ora che avete inserito il codice non resta che aspettare fino a 24 ore per iniziare a collezionare ed analizzare i primi dati.

Ma come fa Google Analytics a monitorare il vostro sito?

Ogni volta che una pagina monitorata viene caricata il codice javascript che avete inserito effettua una richiesta GET verso la URL http://www.google-analytics.com/__utm.gif inserendo al suo interno una serie di parametri.

Ecco un esempio:

http://www.google-analytics.com/__utm.gif?utmwv=4.3.1&utmn=2028990980&utmhn=xxxxxx&utmcs=UTF-8&utmsr=1280x1024&utmsc=32-bit&utmul=it&utmje=1&utmfl=10.0%20r32&utmdt=xxxxx&utmhid=941747535&utmr=-&utmp=/xxxxx&utmac=xxxxxx&utmcc=__utma%3D1.3953800709497065000.1248852507.1251792483.1251811994.60%3B%2B__utmz%3D1.1248852507.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B

Una chiara spiegazione di tutti i parametri che possono essere inviati verso google-analytics e’ presente al seguente URL:

code.google.com/intl/it-IT/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html

Troubleshooting del codice di monitoraggio.

Avete di dubbi sul corretto funzionamento del vostro codice di monitoraggio?
Volete capire meglio quali informazioni vengono inviate ai server di Google?

Vi consiglio di utilizzare i seguenti plugin per Firefox per tracciare le chiamate verso http://www.google-analytics.com/__utm.gif

• Live HTTP Headers
• Firebug

Live HTTP Headers

Il plug-in e’ disponibile al seguente URL:
https://addons.mozilla.org/en-US/firefox/addon/3829

Questo add-on vi permetterà di visualizzare tutti gli header HTTP inviati e ricevuti durante la navigazione di un sito web.
Terminata l’installazione del plugin andate in strumenti e selezionate Live HTTP Headers, attendete che il plugin si avvii e selezionate il tab Generator. Selezionate quindi le opzioni indicate nel seguente screenshot:

Firebug

Il plug-in e’ disponibile al seguente URL:
http://getfirebug.com/

Questo plugin vi permetterà di fare editing, debugging e monitoring delle componenti HTML, Javascript e CSS delle pagine caricate dal vostro browser.
Per monitorare le interazioni con Google Analytics andremo quindi ad utilizzare un piccolo sottoinsieme delle sue funzionalità.

Terminata l’installazione del plugin dovrete attivarlo premendo l’icona

Attivate ora il pannello Net e selezionate la tipologia Immagini:

Potete ora provare questi due ottimi strumenti per fare troubleshooting del codice di monitoraggio di Google Analytics. Utilizzateli per intercettare tutte le chiamate verso la URL http://www.google-analytics.com/__utm.gif e analizzate, con molta attenzione, i parametri che vengono passati all’interno della GET.

Non vedo GET verso http://www.google-analytics.com/__utm.gif !!

Probabilmente non state utilizzando correttamente gli strumenti, verificate le configurazioni e ricordatevi che:

• Ogni volta che caricate una pagina contenente lo snippet di codice di Google Analytics viene inviata una GET verso __utm.gif. Quando fate troubleshooting potete fare un semplice refresh della pagina per cercare nuovamente di intercettare la GET.
• Ogni volta che cliccate su di un link marcato come “virtual page view” viene inviata una GET verso __utm.gif. Questo scenario e’ particolarmente interessante dal punto di vista del troubleshooting in quanto richiede una conoscenza della configurazione di Google Analytics superiore al semplice “copia e incolla” del suo codice di tracking
• Potreste essere di fronte ad un BUG di Google Analytics (o delle relative API usate da altri prodotti Google), questa possibilita’ e’ indubbiamente remota ma non e’ da escludere a priori (Io stesso ho iniziato a fare troubleshooting del codice di monitoraggio di Google Analytics in quanto mi sono trovato di fronte ad un BUG di un prodotto di Google).

Cosa cercare all’interno della GET?

Ottima domanda!
Ci sono indubbiamente alcune variabile che devono essere sempre analizzate con attenzione:

• utmac – Indica il vostro account di GA. Controllate che sia valorizzato correttamente.
• utmdt – Indica il titolo della pagina che include il tracking code di GA
• utmp – Indica la page request della pagina in questione
• utmr – Indica il referral

Ci sono poi variabili che forniscono informazioni relativamente sia al browser che al “computer” che state utilizzando:

• utmcs – Indica il language encoding del browser
• utmje – Indica se Java e’ abilitato nel browser (in quel caso la variabile e’ valorizzata a 1)
• utmul – Indica la “lingua” del browser
• utmfl – Indica la versione di Flash
• utmhn – Indica il nome dell’host
• utmsc – Indica la profondidita’ di colore del vostro monitor
• utmsr – Indica la risoluzione del vostro monitor

Ci sono poi variabili strettamente legate alle campagne e all’e-commerce, come gia’ indicato in precedenza vi invito a leggere la guida al troubleshooting di Google (in inglese) per maggiori informazioni:

code.google.com/intl/it-IT/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html

[Molti dei problemi che risolvo per me, amici o clienti, li risolvo proprio guardando gli header HTTP verso i server di Google Analytics. In quell'unica stringa di testo ci sono tutte, TUTTE, le informazioni che il vostro browser invia ad Analytics. Se c'è un problema lì non c'è filtro che tenga: GA registrerà un dato erroneo, o peggio non registrerà nulla. Se visitando la pagina non vedete nemmeno partire la richiesta per la gif, siete già a metà dell'opera e potete concentrarvi solo sul vostro codice, lasciando del tutto perdere I pannelli di GA ]

Tracciare cosa cercano gli utenti tramite il motore interno è molto importante quando si fa web analytics, perché è fonte di informazioni dirette sui contenuti più interessanti che spesso non sono abbastanza valorizzati. I dati che si possono estrarre guardando alla ricerca interna sono però molti di più, e combinarli con il resto delle informazioni che il software di web analytics ci fornisce accresce di molto le nostre possibilità di comprendere meglio cosa accade sui siti.

In effetti la ricerca interna è fonte anche di un’altra importantissima informazione, se riusciamo a catturarla: cosa l’utente cerca ma non trova sul nostro sito, cioè contenuti che ci vengono richiesti ma che non forniamo. Questo è il motivo per cui Justin Cutroni ha scritto un interessante post su come tracciare le ricerche con zero risultati (link non più disponibile). Purtroppo è un post molto tecnico e non credo riuscirei e renderlo meno “spesso” di così traducendolo. Se volete tracciare le ricerche con zero risultati, quella è la via.

C’è però una buona notizia: se usate WordPress, monitorate la ricerca interna e avete il plugin per Google Analytics di Yoast (tra l’altro tre condizioni che avevo già raccomandato in passato ) vi basta aggiornarlo all’ultima versione – cioè la 3.2.3 – e seguire le semplici istruzioni contenute in questo video:

Configuring Site Search Tracking in Google Analytics from Joost de Valk on Vimeo.

Ovvero andare in modifica del profilo, poi dire “Sì” alla domanda “Utilizzi categorie per la ricerca su sito?”, digitare cat come “Parametro di categoria” e infine dire a GA “Sì, rimuovi i parametri di categoria dall’URL” tramite l’ultima opzione. Facile, no?

Ulteriore segno del grado di interesse che desta la ricerca interna è questo post di Tom Pitts, che consente di tracciare anche il numero di risultati per ogni ricerca. Per utilizzare questo metodo è necessario modificare l’header globale del template, la pagina che mostra i risultati delle ricerche e il codice di monitoraggio di GA.