Google Analytics in 30 secondi

Qualche giorno fa Sean Carlos ha postato, prima su Google+ e poi sul suo blog, un messaggio di errore che compariva sul debugger di Google Analytics relativo alla funzione _trackPageLoadtime, usata per misurare la velocità del sito. A quanto si poteva allora capire, la funzione _trackPageLoadTime veniva dichiarata deprecata e si faceva riferimento a una certa _setSiteSpeedSampleRate, di cui però non c’era traccia sul web. Anche io ho fatto alcune prove, impostando il campionamento al 100% o all’80%, ma senza ottenere risultati.

Il bandolo della matassa è arrivato Venerdì scorso, quando il blog ufficiale ha introdotto la nuova funzione, ed è stato aggiornato anche il changelog.

La nuova funzione _setSiteSpeedSampleRate prende come argomento un numero intero che rappresenta il campione di pagine che vogliamo Google Analytics utilizzi per popolare i report sulla velocità del sito. Si usa in questo modo, e va chiamata prima di _trackPageview

_gaq.push(['_setSiteSpeedSampleRate', 5]);
_gaq.push(['_trackPageview']);

Con questo esempio impostiamo GA per usare il 5% delle pagine inviate per calcolare la velocità del sito e delle stesse pagine.
Contemporaneamente la vecchia funzione _trackPageLoadTime è considerata deprecata, ma per compatibilità con il passato potete lasciarla: sarà come se chiamaste la nuova funzione con un sample del 10% (che tra l’altro è il massimo ad oggi consentito, nonostante la funzioni accetti numeri da 1 a 100). quindi ricapitolando:

– se non avete mai usato _trackPageLoadTime avrete i report della velocità del sito popolati come se chiamaste _setSiteSpeedSampleRate con valore 1
– se non avete mai usato _trackPageLoadTime ma volete cambiare la percentuale di campionamento dovrete aggiungere la funzione come indicato sopra
– se avete attualmente _trackPageLoadtime sul sito potete lasciarla, ed è come se chiamaste _setSiteSpeedSampleRate con valore 10
– se avete attualmente _trackPageLoadtime sul sito ma volete cambiare il campionamento, dovrete rimuoverla e passare alla nuova come indicato sopra

Secondo la documentazione della funzione in condizioni normali viene usato l’1% delle pagine viste inviate fino a un massimo di 10.000 pageviews al giorno. Se il vostro sito invia più di un milione di hits al giorno tuttavia, i vostri tentativi di aggiustare il sample rate saranno infruttuosi e Analytics userà sempre e comunque l’1%.

In aggiunta a tutto questo ci sono altre due novità: la prima è che adesso anche le pagine virtuali generate con _trackPageview saranno conteggiate nel report della velocità del sito, la seconda è che il tempo impiegato da eventuali redirect verrà conteggiato nel tempo di caricamento, per fare in modo che esso concida sempre più con la reale percezione dell’utente.

La mossa mi sembra assolutamente sensata: a Google non costa nulla invocare quella funzione in modo automatico, ed essa genera un report piuttosto interessante. Nell’ottica di semplificare il più possibile lo strumento è una buona mossa, e infatti quando uscii il report sulla velocità del sito più volte mi chiesi: “ma perché addirittura una funzione nuova da inserire a mano?”

L’avevo sentito dire e letto in giro, ma non avevo mai pensato di verificare direttamente nella fonte suprema, la “costituzione” di Google Analytics, i Termini del Servizio. E invece, al punto 2:

2. CANONE E SERVIZI. Fermo restando quanto previsto nella successiva Clausola 15, il Servizio è fornito gratuitamente per Lei sino ad un limite massimo di Page View non superiore a 10 milioni di visualizzazioni al mese per ciascun Account.

Quel limite è sempre stato di 5 milioni, sin dalla nascita del sistema, ma è stato recentemente raddoppiato, caso vuole proprio in concomitanza con l’uscita di Analytics Premium.
I Termini del Servizio non sono scritti benissimo, in effetti, perché se uno leggesse solo quella parte sarebbe tratto in inganno: nelle definizioni poco sopra una “Page View” è definita come una richiesta alla gif UTM, quindi anche gli eventi, le transazioni e le richieste fatte dalla funzione _trackPageLoadTime concorrono alla formazione del limite, che è per Account.

Spero che abbiate un tale traffico sul sito da accogliere questa notizia con sollievo; io devo lavorarci ancora un pochino… 🙂

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

Morto un papa se ne fa un altro, recita il detto; ed ecco che tolto il report velocità di connessione, arriva “velocità del sito”, come annunciato dal blog ufficiale.

Il nuovo report è disponibile soltanto nella versione v5, che è accessibile a tutti tramite il link rosso in alto nell’interfaccia, ed è utile per capire quali sono i tempi di caricamento delle nostre pagine. Poiché in Google spingono pesantemente su questo aspetto (il codice di Adsense è passato ad asincrono, quello di GA lo era già, Chrome dispone di uno strumento nativo bellissimo per comprendere i tempi di caricamento, da poco hanno rilasciato Page Speed Online…), molti di voi avevano correttamente pronosticato che il sostituto del vecchio report sulla velocità di connessione sarebbe stato qualcosa di simile.

Tecnicamente si tratta di aggiungere una funzione al codice di tracciamento, la funzione _trackLoadPageTime, chiamandola senza passargli valori dopo aver chiamato _trackPageview, in questo modo:

<script type="text/javascript">
 var _gaq = _gaq || [];
 _gaq.push(['_setAccount', 'UA-XXXXX-X']);
 _gaq.push(['_trackPageview']);
 _gaq.push(['_trackPageLoadTime']);

 (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>

Dopo aver fatto questa modifica il report “velocità del sito”, che si trova sotto il gruppo CONTENUTI, inizierà a popolarsi con i dati, mentre prima mostrerà soltanto dei laconici zeri. Poiché la nuova funzione effettua un’ulteriore chiamata alla gif __utm.gif, anche se essa è presente in tutte le pagine non invierà dati per ogni pagina vista, ma effettuerà un invio a campione (e adesso è anche chiaro a cosa servisse il contatore interno alle chiamate UTMS: non puoi randomizzare le chiamate se non c’è un contatore 🙂 ), per cui analizzando le richieste che partono dal codice di monitoraggio sarà perfettamente normale non vedere sempre due richieste.

Nel blog ufficiale c’è anche un link ad un custom report già pronto che potrebbe risultare utile: Site Speed Custom Report (il link porta direttamente al custom report pronto da salvare, dovete essere loggati a Google Analytics per vederlo); si tratta di un report che usa come metriche Visite, Rimbalzi, Tempo di caricamento medio e Campione per il caricamento, e come dimensioni Browser e Pagina.

Tempo di caricamento medio è il tempo, espresso in secondi, che una pagina impiega per caricarsi, dalla prima chiamata a quando il browser considera completato il caricamento.
Campione per il caricamento indica il numero di pagine viste utilizzate per calcolare il dato precedente, in modo che sia chiaro l’indice di confidenza espresso.

Poiché ovviamente tutto è segmentabile, le possibilità sono infinite: ad esempio si potrà finalmente capire se l’alto tasso di uscita da una certa pagina è dovuto o no all’alto tempo di caricamento della stessa. O se il tasso di rimbalzo di una certa campagna AdWords è dovuto alla lentezza della relativa landing page.