Google Analytics in 30 secondi

Qualche settimana fa Google ha presentato l’ultima versione del sistema operativo Android, Ice Cream Sandwich, insieme alla terza incarnazione dei telefonini serie Nexus, il Galaxy Nexus. Curiosando nel relativo sito, il buon Tommaso Galli mi fa notare una chiamata piuttosto strana a qualcosa che somiglia ad Analytics:

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>
    <script>
      new gweb.analytics.AutoTrack({
            profile: 'UA-19761916-1'
          });
    </script>

basta, questo è tutto. il file autotrack.js è ovviamente minificato come da tradizione Google, ma alcune parti sono ancora leggibili: ci si ritrova dentro la classica coda _gaq.push che tutti conosciamo, con i classici comandi di setAccount e trackPageview, e altre funzioni tipiche. Il nome però è parlante, e così facciamo un test: ricopio tutto il sito in un mio dominio, cambio l’UA con uno dei miei di test e insieme facciamo qualche visita. Effettivamente quelle due sole righe di codice sono equivalenti al normale codice javascript che Google Analytics ci fa copiare su tutte le pagine del sito, con una sola, notevole eccezione: traccia automaticamente – tramite eventi – anche tutti i click fatti su elementi href, distinguendoli in interni ed esterni; quelli interni finiscono in una categoria NAVIGATION (se sono link a pagine) o LINK CLICK (se sono files), quelli esterni in una categoria OUTBOUND CLICK.

Facendo qualche ricerca sul web scopro che non siamo i primi ad accorgerci di questa cosa, che è precedente al sito del Galaxy Nexus: Mohit Jain l’aveva già notato su Google Plus, ed aveva fatto lui stesso dei test, scoprendo tra l’altro anche la funzione heatMapper, che se impostata a true provvede a registrare automaticamente la posizione del mouse per TUTTI i click fatti sulla pagina, anche quando non sono fatti su elementi cliccabili. Cioè la base per creare una heatmap, appunto.

Ora, io non so esattamente se questo sarà lo script di un Google Analytics di domani, ma ogni volta che c’è una semplificazione per l’utente io sono contento. Portare a 2 le righe di codice necessarie al monitoraggio base è sicuramente un miglioramento, e le funzioni aggiuntive si possono sempre aggiungere come adesso, se servono. Quanto al fatto che parte del lavoro che adesso siamo costretti a delegare a soluzioni esterne (jQuery, cose scritte in casa, o il plugin sviluppato da me e Francesco Terenzani) verrebbe svolto automaticamente e autonomamente, beh direi che si commenta positivamente da solo.

[traduzione del post di André Scholten Simulate Google trackPageLoadTime without sampling]

Poco dopo aver descritto un metodo per tracciare i tempi di caricamento delle pagine in Google Analytics, Google ha tirato fuori la propria tecnica per fare la stessa cosa, ma entrambi i metodi hanno alcuni svantaggi. Per chiarirvi le idee vi mostro questa immagine:

Questa immagine mostra tutti i passaggi dall’inizio della richiesta di una pagina fino alla fine. I tempi di queste operazioni sono memorizzati in un oggetto javascript chiamato “performance”. E con un semplice script potete leggere questi valori e calcolare i tempi di caricamento. Tutto questo deriva direttamente dalle specifiche “Navigation Timing” del W3C.

La linea verde sono i tempi che misuro con il metodo descritto in precedenza, il che significa: solo i tempi da quando l’HTML inizia a caricarsi fino a che non accade l’evento onload.
La linea rossa sono i tempi che Google usa per misurare il load time in GA. Un numero molto più verosimile perché include anche i tempi di risposta del server. Ma Google usa solo un campione di dati per calcolare i tempi di caricamento.

Il metodo migliore è una via di mezzo: il metodo più affidabile usato da Google ma senza il campionamento. Tutto questo può essere ottenuto con una semplice aggiunta al codice di monitoraggio di Analytics:

if (typeof performance == "object")
{
  var loadtiming = parseInt(performance.timing.loadEventStart - performance.timing.fetchStart);
  if ((loadtiming > 0) && (loadtiming < 40))
  {
    _gaq.push(['timer._setAccount', 'UA-XXXXXX-X'], ['timer._trackPageview'], ['timer._trackEvent','w3c-navigationtiming',location.pathname,,loadtiming]);
  }
}

potete eseguire questo codice dopo l’onload, così i visitatori non saranno rallentati, e mi raccomando di usare un nuovo profilo, e non il vostro profilo normale, perché questa funzione rovinerà il vostro bounce rate. Le funzioni LoadEventStart e fetchStart sono le stesse che Google usa nella sua trackPageLoadTime.
C’è solo un piccolo problema con questo script: non tutti i browser supportano l’oggetto “performance” (che è piuttosto nuovo ndr), al momento solo Chrome lo fa. Ma poiché la velocità del sito sta diventando sempre più importante, probabilmente in futuro anche gli altri browser aggiungeranno il supporto.

Questa è una delle domande che mi vengono rivolte più spesso: molte persone, per motivi disparati che vanno dal non pervenuto a problemi di performance, vorrebbero salvarsi sul server una copia dello script sorgente di Google Analytics – cioè quel che trovate su www.google-analytics.com/ga.js e che viene richiamato dal codice di GA in modo automatico – ed evitare di fare la chiamata remota ai server di Google.

E’ sicuramente possibile, così come potete decidere se mettere ad esempio JQuery sul vostro server o usare una libreria online che fornisce sempre l’ultima versione, ma il problema è per l’appunto il medesimo: il codice di GA cambia, a volte rapidamente a volte meno, però cambia. Stanotte, ieri notte e la notte prima è stato modificato, dopo settimane di stasi. Se usate il codice fornito da Google siete certi di richiamare l’ultima versione, di avere tutte le funzionalità e gli ultimi bugfix; se decidete di fare le cose localmente dovrete controllare gli aggiornamenti e ogni volta che viene fatta una modifica aggiornare anche il vostro codice (compresi i casi in cui vengano fatte più modifiche al giorno, quando si presentano).

Non è impossibile, è solo un po’ più laborioso del normale. Comunque sia, se volete essere informati quasi in tempo reale delle modifiche al file sorgente, potete usare un servizio di alert via feed rss o email. Io ad esempio uso Page2RSS

Se anche voi come me siete vittime del debug “fai da te” e non passate un giorno senza dare un occhio agli header HTTP che Google Analytics invia ai server collettori, forse avrete notato che c’è un nuovo parametro nelle richieste, il parametro utms. Le nuove richieste della .gif si presentano così

/__utm.gif?utmwv=4.9.2&utms=1&utmn=761092721&...eccetera...

quel parametro utms fino a qualche tempo fa non c’era, e infatti non è documentato da nessuna parte. Ho già lasciato un quesito sul forum ufficiale, ma finora nessuno ha risposto. Il numero in effetti cambia ad ogni richiesta (pagina, evento, eccetera), ed ho notato che si comporta così:

• All’interno della stessa sessione di visita, ogni nuova richiesta della .gif lo incrementa di uno. quindi se avete due codici di monitoraggio farete due richieste della gif, una con utms=1 e una con utms=2, se dopo inviate 5 eventi avrete utms=3, poi 4 e così via
• Se nel frattempo aprite un’altra scheda e navigate un altro sito – che abbia il codice di monitoraggio di GA, ovviamente – per le richieste fatte da quel sito utms riparte da 1

Mi sembra sia una specie di contatore delle richieste inviate per sessione, infatti chiudendo il browser e navigando un sito già visto utms riparte da 1. Perché? come forse saprete, esiste un limite di richieste per sessione oltre le quali i dati sono ignorati da Google Analytics e attualmente questo limite è di 500 richieste per sessione; ovviamente l’onere di verificare quante richieste sono state fatte per sessione spetta al server che analizza i dati, mentre inserendo un contatore lato client semplicemente si eviterebbero di inviare le richieste in eccesso, scaricando il server da questo lavoro. E’ solo una mia supposizione, ma al momento non vedo altri indizi che mi facciano puntare verso altre teorie.

[edit: in realtà non ci voleva poi molto a verificarlo ho impostato un javascript affinché registrasse un evento ogni secondo, e arrivati a utms=500 non è partita più nessuna richiesta della GIF. Il codice di Google Analytics ha smesso di inviare richieste ai server]

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

Era solo questione di tempo, ed era anche già stato annunciato, il passaggio alla versione asincrona del tag anche per Google Website Optimizer, lo strumento di split test e test A/B di Google.

Direttamente dal post sul blog ufficiale, ecco cinque cose da sapere sul nuovo codice:

1. Lo script tradizionale ovviamente continuerà a funzionare, come per Analytics. Il nuovo codice viene proposto automaticamente alla creazione di nuovi esperimenti
2. Il nuovo codice usa un unico snippet di codice sia per la parte di controllo sia per quella di tracciamento; ora c’è un unico script da incollare sulle pagine invece di due.
3. Esattamente come per Google Analytics, il nuovo codice non va più prima della chiusura /BODY, ma va posizionato appena dopo l’apertura di HEAD; quindi addirittura prima dello script di GA
4. Nel caso in cui lo script necessiti di personalizzazioni (come per esempio nel caso di test tra più domini), allora c’è ancora bisogno della sintassi tradizionale.
5. Gli articoli delle pagine di help sono stati aggiornati di conseguenza

E’ una modifica che è stata richiesta a gran voce dalla comunity degli utenti di Google Analytics, e non sarà nemmeno l’ultima: presto o tardi anche Adsense e tutti gli altri script usati da Google passeranno ad una versione asincrona, in accordo al nuovo dettame “web più veloce” che l’azienda americana sta portando avanti da un po’ di tempo a questa parte.

[GAADDONS NON E' PIU' SUPPORTATO DALL'AUTORE]

Qualche tempo fa vi ho parlato di GAaddons, un piccolo javscript scritto da Stéphan Hamel per automatizzare ed estendere alcune funzionalità di Google Analytics. Una novità di questi giorni è l’introduzione, in versione beta, della funzione _setXDomain, che serve a semplificare – e di molto aggiungerei – la normale gestione del cosiddetto crossdomain tracking, ovvero la gestione di Google Analytics quando si ha a che fare con stoddomini e domini multipli.

Nella pagina di documentazione della funzione Stéphane ha ripreso i casi dell’help ufficiale di Analytics e li ha tradotti nella sintassi per il suo addon, e così le due chiamate necessarie a tracciare un dominio e un sottodominio nello stesso profilo passerebbero da

 _gaq.push(['_setDomainName', '.example-petstore.com']);
  _gaq.push(['_setAllowHash', false]);

a un più semplice

_gaq.push(['_setXDomain', {
      domainName: '.example-petstore.com'
      }]);

Fino qua niente di che. Vediamo adesso il codice per domini multipli e sottodomini. Normalmente ci sarebbe un setdomainname, un setallowlinker e un setallowhash sul dominio principale e sul sottodominio, e un setdomainname differente con setallowlinker e setallowhash nell’altro dominio principale. Inoltre tutti i passaggi da un dominio all’altro andrebbero gestiti con le funzioni link() e linkByPost(), e bisognerebbe fare molta attenzione a non dimenticarsi qualcuno di questi link.
Con la funzione di GAaddons il tutto si riduce a

_gaq.push(['_setXDomain', {
      domainName: '.example-petstore.com',
      include: /(my-example-blogsite.com|otherdomain.com)/
      }]);

e questo farà anche si che tutti i link “incrociati” abbiano le giuste funzioni per passare i cookie. Esistono poi i casi con domini e sottodirectory, ma poiché sono minoritari non ve li riporto e vi rimando ancora alla pagina di documentazione [che non è più online].

Una cosa da tenere presente è che esistono ancora due casi reali possibili per il crossdomain tracking, e cioè il tracciamento di due sole sottodirectory nello stesso dominio e gli iframe con contenuto su dominio esterno, ma che questi non sono (ancora, si spera) contemplati da GAaddons. Per il resto, questa mi sembra veramente una buona novità ed una semplificazione molto grossa: nella mia esperienza di consulente il tracciamento su più domini è sempre un momento di grande tensione e spesso rappresenta un momento in cui il tracciamento fa perdere consistenza ai dati. Avere una semplificazione in tal senso è estremamente positivo, e speriamo che anche Google se ne renda conto e magari copi l’idea

[In chiusura, vi ricordo che la funzione è in beta: se decidete di provarla scaricate la versione del file GAaddons appropriata, e fatelo avendo ben chiari i rischi cui andate incontro usando una versione sperimentale di qualcosa]

Oggi vorrei parlarvi di uno script aggiuntivo per Google Analytics, e vorrei farlo iniziando dal fatto che ancora non l’ho testato. Se ve ne parlo è perché l’autore, Stéphane Hamel, mi è noto ed è conosciuto e stimato in tutto il mondo della web analytics: oltre ad essere nel board della Web Analytics Association (tesoriere), alcuni di voi forse lo ricorderanno come l’autore dell’estensione di Firefox WASP, che serve a controllare la presenza sulle pagine di vari sistemi di web analytics.

Lo script aggiuntivo di chiama GA addons, ed è reperibile nell’apposito mini-sito gaaddons.com: serve ad aggiungere in modo abbastanza semplice alcune funzioni di cui ogni tanto parliamo su queste pagine, ed altre che invece non abbiamo trattato. Dipende da JQuery per il funzionamento, quindi dovrete assicurarvi di avere la necessaria chiamata prima del codice di tracciamento dopodiché dovreste scaricare il file di GAaddons, metterlo nel vostro sito e referenziarlo con una chiamata nelle vostre pagine, ovviamente sempre prima del vostro codice di Analytics.

Che funzioni offre?

• form analysis: traccia l’ultimo campo di una form dove è stato posizionato il cursore, in modo da capire dove gli utenti abbandonano la compilazione. Al momento supporta una sola form per pagina.
• giorno della settimana: crea una variabile personalizzata (di sessione) contenente il giorno della settimana. Utile per le segmentazioni
• dual mode: salva una copia dei dati anche nei logfiles del vostro webserver (nè più né meno che una combinazione di _setLocalRemoteServerMode e _setLocalGifPath)
• track downloads: serve ad automatizzare il tracking dei file scaricabili, specificandone i formati
• track errors: traccia le pagine di errore (per default 404 e 500, ma è configurabile)
• track load time: tiene traccia del tempo di caricamento delle pagine, in millisecondi. Utile per fare debug delle prestazioni in casi di picchi di traffico.
• track mailto: traccia gli invii delle email sui link mailto:
• track outbound: traccia i link esterni (al momento inutilizzabile se usate il cross domain tracking)
• traccia il “vero” bounce rate: se la visualizzazione della prima pagina si protrae oltre un tot di secondi, spara un evento in modo da azzerare il tasso di bounce per quella visita.
• 4Q: se lo usate, si integra con 4Q di iPerceptions, un sistema di sondaggi online per la customer satisfaction

Fattore positivo, ognuna di queste funzionalità ha un settaggio che permette di essere disabilitata se la pagina visitata è la prima della visita. Diversamente, poiché ognuna di esse lancia una chiamata ai server di GA, il bounce rate sarebbe falsato. Altra cosa positiva è che l’intero sistema GAaddons può funzionare con pagine virtuali o eventi, a scelta dell’utente e secondo le esigenze.

In definitiva si tratta di un modo di automatizzare e rendere standard alcune funzioni che sono applicabili a Google Analytics anche senza GAaddons (ad esempio il tracciamento di mailto, donwload e link esterni si può fare con la libreria mia di di Francesco Terenzani), il track load time l’ho presentato qualche giorno fa al corso avanzato, eccetera.

Il sistema è gratuito per uso personale, mentre costa 149 dollari per piccoli siti aziendali. Per professionisti e agenzie che devono implementarlo su siti di clienti, il costo è rispettivamente di 149 e 699 dollari.

In attesa del cambio bagagli mare-montagna, ecco un riassunto di due novità introdotte dal team di Google Analytics mentre ero via:

1. Ordinamento ponderato: è una nuova modalità di ordinamento delle righe dei report non più basata solo sull’ordine ascendente o discendente (o dal maggiore al minore) ma che tiene conto anche del numero delle visite di ogni riga. Basta quindi con i report che mostrano tutte le righe con 1 sola visita come fossero uguali, e che costringono a scorrere tutta la lista alla ricerca di fenomeni interessanti. Un esempio può essere il report dei rimbalzi: non tutti i 100% sono uguali: alcuni sono generati con una sola visita, altri con duecentotrenta. I secondi sono più interessanti da analizzare, e l’ordinamento ponderato ve li farà scoprire prima. Post ufficiale. Articolo dell’help in lingua inglese
2. Strumento di debug: è un nuovo file di tracciamento (ga_debug.js) in grado di inviare informazioni anche all’oggetto window.console dei browser, per cui si potranno vedere in modo chiaro le singole richieste della GIF dentro a Firebug per Fireofx o alle apposite finestre di Chrome e Safari. Per facilitare ulteriormente il lavoro Google ha predisposto un’apposita estensione di Chrome per attivare e disattivare “al volo” la versione di test su qualsiasi sito. Per me è una manna dal cielo! Post ufficiale. Articolo dell’help in inglese

La prossima settimana non avrò completamente internet, ci risentiamo martedì 7 settembre.

Come abbiamo già  avuto modo di notare in passato, Google Analytics non ha mai costretto nessuno a effettuare migrazioni del codice di monitoraggio; esse sono semplicemente consigliate. Se anche non usate il nuovo codice asincrono non cambia nulla. Se addirittura avete ancora il vecchio urchin.js, i vostri dati vengono raccolti ugualmente. In questo ultimo caso non potete avvantaggiarvi di alcune delle ultime funzionalità , tipo il tracciamento degli eventi o molte funzioni che esistono solo per ga.js, ma i vostri dati di base ci sono, vengono analizzati.

Mi è venuta in mente questa cosa perché ho letto che da fine luglio la versione v.4 del codice di tracciamento di Yahoo Web Analytics smetterà di funzionare, in favore della v.5. Da un alto trovo giusto che ogni sistema agisca come vuole – ed in Yahoo avranno sicuramente le loro ragioni ed esigenze – dall’altro mi stavo domandando quale dei due metodi sia preferibile. In Google effettivamente fanno fatica a star dietro ai tre metodi con la documentazione, ed ogni situazione andrebbe descritta tre volte, ma così facendo nessuno ha mai perso un dato. Esisteranno clienti di YWA che non hanno letto, in questi anni, o che non si ricordano della deadline? qualcuno perderà dei dati?

quale pensate che sia la soluzione migliore?

[a margine, già che ci siamo: le richieste HTTP alla gif fatte da codice asincrono (leggi questo post se non sai di cosa sto parlando) contengono un parametro aggiuntivo &gaq=1, che non produce nessun dato in Google Analytics, ma che immagino consenta a Google di conoscere puntualmente il numero di installazioni che usano l'ultimissima versione del GATC]