Google Analytics in 30 secondi

In verità una delle tre “cose nuove” è in giro da un po’ di tempo, ma soltanto ora Google mette a disposizione uno strumento nativo.
Autotrack.js è una libreria made in Google per il tracking dei cosiddetti siti monopagina, o applicazioni monopagina: quei siti che si risolvono tipicamente solo con uno scrolling o con ancore che fanno scrollare i contenuti.
Il post ufficiale ci informa che con una semplice modifica del codice di monitoraggio possiamo importare il plugin autotrack e iniziare a modificare il codice della pagina in modo che comunichi da sola le azioni dell’utente a GA. Le azioni che possono essere monitorate in modo semplice sono:

• click su link esterni e compilazione di form
• cambio di url su applicazioni monopagina (tipicamente con l’uso di #ancore alla fine dell’url)
• eventi tracciati con la sola modifica dell’HTML della pagina
• tracking delle media query e dei cambi, ad esempio se cambia l’orientation del device o viene stretta la finestra

Tutte queste operazioni sino ad ora non erano impossibili da tracciare, ma richiedevano comunque un effort discreto a seconda delle possibilità e delle tecnologie utilizzate. Avere una libreria ufficiale indubbiamente sarà di aiuto.

La seconda novità è il lancio ufficiale delle pagine AMP, introdotte in beta in autunno per farle conoscere ai publisher e adesso sdoganate da Google: si tratta di un progetto per rendere il caricamento degli articoli editoriali pressoché istantaneo sui dispositivi mobile, aumentando l’esperienza d’uso. Ora, come si tracciano queste pagine che hanno una struttura particolare e imposta da Google? per prima cosa va dichiarato dentro a un tag CHE COSA andremo a tracciare e DOVE invieremo i dati, attraverso una struttura di dati particolare. Questo funzionerebbe per qualsiasi richiesta di tracking per la quale si sa come costruire l’invio dei dati, ma ovviamente i maggiori vendor hanno collaborato con Google e quindi esistono delle sintassi “facilitate”: ad esempio alcuni nomi che troviamo sono Adobe, Chartbeat, comScore e ovviamente Google Analytics, la cui documentazione specifica è qui. Ad esempio, ecco uno script molto semplice per il track delle sole pageview

<amp-analytics type="googleanalytics" id="analytics1">
<script type="application/json">
{
  "vars": {
    "account": "UA-XXXXX-Y"  // Replace with your property ID.
  },
  "triggers": {
    "trackPageview": {  // Trigger names can be any string. trackPageview is not a required name.
      "on": "visible",
      "request": "pageview"
    }
  }
}
</script>
</amp-analytics>

Aggiungere eventi significa dichiarare a priori che un click su un certo elemento dovrà essere trattato come tale, con quale categoria vada tracciato e con quale action; idem per le interazioni sociali o altri elementi. A seconda quindi del numero di interazioni possibili lo script potrebbe essere anche lunghetto da gestire, ma di contro il numero di diverse azioni possibili su una pagina AMP non è così elevato. Si possono comunque prevedere tracking aggiuntivi lavorando un po’ con i dev, ad esempio vi suggerisco di leggere questo post di E-nor.

Terza novità di questi giorni sono gli instant articles di Facebook, lo stesso concetto delle pagine AMP ma calate nel contesto di Facebook, ovvero leggere il contenuto senza abbandonare l’esperienza utente di FB. Anche in questo caso, il tema di come tracciarli è trattato in un capitolo apposito della documentazione, e non richiede modifiche pesanti alla pagina perché il tutto viene incluso con un iframe. In questo caso quindi si può utilizzare un TagManager senza grossi problemi, almeno sulla carta. L’instant article viene in ogni caso trattato come una pagina del vostro sito aperta tramite il browser interno dell’applicazione di Facebook.

E’ un mondo che cambia in fretta, bisogna sapersi adattare in fretta 🙂

Oggi mi sono imbattuto per caso in questo report, di cui non ho memoria e di cui non vedo alcuna segnalazione in giro: suggerimenti velocità, all’interno di Velocità del sito. Eccovi uno screenshot (clic per ingrandire):

Non si tratta di niente di speciale, è un elenco delle vostre URL in ordine di visualizzazioni, con accanto il tempo medio di caricamento e due colonne nuove: suggerimenti pagespeed e punteggio pagespeed.

Il link con i suggerimenti porta ad una pagina del tipo https://developers.google.com/speed/pagespeed/insights?utm_source=analytics#url=http_3A_2F_2Fwww.goanalytics.info_2F&mobile=false con informazioni su come far performare meglio la pagina, la seconda colonna è un indicatore da 0 a 100 di quanto è possibile migliorare la pagina. 100 rappresenta una pagina perfetta, 0 una pagina disastrosa.

Questo nuovo report non contiene niente di nuovo, PageSpeed Insights è un servizio abbastanza noto di Google, ma vi fa il favore di analizzare al posto vostro – e uno per uno – tutti gli url registrati da Google Analytics. Al momento il report mi sembra un po’ acerbo: niente filtri sulle metriche, si possono solo ordinare i dati e si è limitati a 10 url alla volta, ma se verrà allineato agli altri ha del potenziale interessante!

Mi sono perso una discussione su Twitter in cui cinic afferma che Analytics è inferiore ad altri strumenti di monitoraggio delle prestazioni del sito. Rimedio con un post sul blog, tanto in 140 caratteri non ci starebbe 🙂

Quando parliamo di strumenti per il monitoraggio delle prestazioni del sito, ci riferiamo di solito a siti o software che interrogano le vostre pagine e vi fanno un resoconto di quanto ci mette ogni singolo elemento ad essere caricato: alcuni esempi di queste applicazioni sono Yslow, GTmetrix, Google Pagespeed online, Pingdom. Qualsiasi browser moderno ha integrato uno strumento simile, più o meno evoluto.

Google Analytics, come dovreste sapere, ha da qualche tempo introdotto dei report relativi alla velocità del sito, ne ho parlato qualche tempo addietro.

Ora, la prima domanda da porsi è sicuramente questa: “cosa voglio ottenere?” e la seconda è altrettanto indubbiamente “come faccio a ottenerlo?“. Per quanto riguarda il cosa, la risposta è invariabilmente “voglio ottenere un miglioramento dei tempi di caricamento delle pagine”. Per capire cosa cambiare, tutti gli strumenti che ho elencato prima vanno bene. Il livello di dettaglio cambia, ma le indicazioni sono sempre valide: minificare tutto, comprimere le immagini, aggiungere una CDN, javascript asincroni, eccetera…

Questo risponde in parte anche alla seconda domanda, come ottenere il risultato: questi strumenti ti consentono di verificare ogni singolo elemento di una tua pagina, una pagina alla volta, e di correggere i problemi.
Il problema è uno solo, tuttavia: questi strumenti funzionano su un server – tipicamente con una linea veloce – o sul TUO brower, con la TUA connessione.

Google Analytics invece registra i tempi di caricamento di tutte le pagine oggetto del campione, sui browser dei tuoi utenti, con le linee dei tuoi utenti. Questo gli permette di darti dei report che sono esattamente il risultato di quel che succede nei browser delle persone che dovrebbero starti più a cuore: i tuoi clienti. E non il server di GTmetrix 🙂

Posso anche ottimizzare completamente la mia homepage, sul mio browser e con la mia ADSL. Posso anche essere scrupoloso e recuperare il mio 56k dall’armadio e rifare il processo. Ma se il 43% dei miei utenti si collega dall’Egitto, o se il 61% degli utenti che arrivano da un certo referrer ha un determinato routing lento questa settimana, le mie ottimizzazioni per assurdo potrebbero anche essere inutili. Le considerazioni che mi porta a fare Google Analytics quando guardo i report sulla velocità del sito non hanno quasi mai a che fare con gli elementi delle mie pagine, o con il mio server. Hanno quasi sempre a che fare con i SEGMENTI di traffico che analizzo, per i quali lo strumento mi indica tempi di caricamento differenti. Segmentare in base a una o più dimensioni è un’altra cosa che gli strumenti classici non fanno, sempre perché analizzano una pagina alla volta da una sola location alla volta.

In sostanza, Google Analytics non è GTmetrix perché gli è complementare. GA mi dice se e dove c’è un problema, GTmetrix – o chi per esso – mi consente di risolvere parte di esso. Google Analytics usa i dati reali dei tuoi utenti per dirti se e dove hanno un problema, GTmetrix si astrae e si concentra sull’unico problema che può risolvere.

Come aveva già notato Andrea Pernici, seguito da Sean Carlos, da due settimane è presente su Google Analytics il report “tempi utente”, che però è vuoto. Oggi il blog ufficiale ci svela il perché: per popolarlo è necessario usare la nuova funzione _trackTiming; a cosa serve questa nuova funzione, anzi questa nuova API? serve a misurare i tempi di caricamento di pressoché qualsiasi cosa del nostro sito, che si tratti del caricamento di una libreria piuttosto che il tempo di reazione del server al click su un certo pulsante…

Come avevo più o meno pronosticato, si tratta dell’evoluzione e della codifica di una cosa che si poteva già fare, e si poteva fare con una libreria messa a disposizione da Google su una pagina seminascosta delle pagine dei developer (che però è stata rimossa). Oggi il tutto viene modernizzato con un set di chiamate apposito e ufficializzato. La nuova funzione ha questa sintassi:

_gaq.push(['_trackTiming', 'categoria', 'variabile', 'tempo', 'label_opzionale', 'samplerate_opzionale']);

e come molte delle ultime funzioni introdotte è praticamente una variante della funzione _trackEvent. La categoria ci permette di separare logicamente i vari caricamenti (librerie, immagini, richieste AJAX…), la variabile è il nome dell’oggetto che stiamo tracciando, il tempo sono i millisecondi impiegati per caricare, la label può servire per distinguere ulteriormente differenti tempi di caricamento, e il samplerate ci permette di decidere a quale percentuale di visite applicare il tracciamento.

Si tratta ovviamente di un tracciamento molto avanzato, che richiede un po’ di programmazione, quindi la cosa migliore che posso fare è rimandarvi alla documentazione ufficiale; in fondo alla pagina ci sono altri esempi su cose che si potrebbero tracciare: il tempo speso a guardare un video, il tempo impiegato per finire un livello di un browser-game, il tempo speso per leggere una sezione o una pagina (magari modificando questo metodo di Justin Cutroni).
Mi piacerebbe però anche sapere voi cosa ci fareste o cosa avete intenzione di fare con questa nuova funzione…

Altro giorno, altro post sul blog ufficiale, altra sistemata a un report: ieri è toccato ai report sulla velocità del sito, che pure erano già stati potenziati poche settimane fa.
Le novità di oggi sono l’introduzione di una panoramica, che consente di avere un colpo d’occhio sulla situazione dei tempi di caricamento: ci sono tutti i tempi medi e un grafico esplicativo del tempo medio di caricamento di tutto il sito nel periodo selezionato; inoltre è possibile accedere direttamente a segmentazioni per browser, paese/zona o pagina. Il report precedente è stato rinominato in “Tempi pagine” e conserva le sue tre schede: l’esplorazione delle pagine con le metriche di base, le metriche tecniche e la segmentazione geografica.

Inoltre le metriche sui tempi di caricamento sono da oggi disponibili attraverso le API e negli Eventi Intelligence. Si possono quindi creare degli alert personalizzati sui tempi di caricamento (magari solo per zone geografiche che sappiamo essere problematiche, tipo “avvisami se il tempo medio di caricamento del sito dalla Germania sale oltre i 7 secondi”, magari perché la Germania è un nostro mercato strategico e non vogliamo rovinare l’esperienza utente) o disporre dei dati attraverso le chiamate alle API per farne quel che più ci aggrada: immagino che non ci vorrà molto per vedere spuntare il primo sistema di cache che si attiva da solo quando viene avvisato da Google Analytics che alcune pagine sono troppo lente…

Infine il team ci annuncia le modifiche al campione di caricamento delle pagine, ma noi che leggiamo il changelog lo sapevamo già 🙂

Nel changelog delle modifiche allo script di Analytics è comparsa Venerdì scorso questa piccola ma importante nota:

The maximum allowed site speed sample rate (_setSiteSpeedSampleRate) has been increased from 10% to 100%. [Il massimo tasso di campionamento per la velocità del sito (_setSiteSpeedSampleRate) è stato incrementato dal 10 al 100%]

Come ricorderete la funzione _setSiteSpeedSampleRate serve a dire a Google Analytics quanta parte di pagine viste vogliamo che siano usate per calcolare la velocità delle nostre pagine: quando è stata introdotta aveva un limite del 10% (fino a 10 mila pagine al giorno – 1% se il sito fa oltre un milione di pageviews al giorno) ed era immodificabile, da Venerdì questo limite è stato rilassato.

Questo è molto importante, specialmente per siti di piccole dimensioni, perché fino ad ora il campione statistico era quasi irrilevante. Sapere che una pagina si carica in 25 secondi è inutile, se in un mese ha un campione di 1 pagina soltanto. Se quindi in passato vi ho detto di fare poco affidamento su quei report in presenza di campioni infinitesimali, da oggi potete aggiustare la vostra frequenza di campionamento: più il sito è piccolo, più vi consiglio di alzarla (anche André Scholten la pensa come me); se viceversa siete oltre le 10000 pageviews al giorno, impostate una percentuale che corrisponda appunto a circa 10 mila: tanto quelle eccedenti Analytics non le registrerebbe.

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?”

E’ stato effettuata un’aggiunta nel report della velocità del sito, introdotto lo scorso Maggio. La novità consiste in una nuova tab all’interno del report Velocità del sito (solo per la v5), dal nome tradotto piuttosto malamente in “rendimento” (in inglese è performance), che divide in scaglioni le pagine usate per il campionamento della velocità del sito (che lo ricordo sono solo una parte del totale delle pagine viste) in base al tempo impiegato; quindi quante pagine caricano in meno di 1 secondo, quante tra 1 e 3 secondi e così via.

Esattamente come l’altra parte di report, anche questa è segmentabile usando i segmenti avanzati, e questo ci permette di vedere se i caricamenti lenti affliggono solo una determinata parte dell’utenza ed eventualmente di capire dove indagare. Il blog ufficiale fa gli esempi dei segmenti “con conversioni” oppure segmenti geografici. A mio avviso possono essere interessanti anche segmenti basati sul tempo trascorso sul sito (ipotesi: le persone che trascorrono più tempo sul sito vedono pagine che si caricano più velocemente) o sul numero di pagine viste, per lo stesso motivo. Oppure sicuramente applicare il segmento “visite con transazioni” e vedere come la velocità del sito influenza gli introiti monetari dell’ecommerce.

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.