Google Analytics in 30 secondi

Senza nemmeno troppa pubblicità, il team di Google Analytics ha introdotto un nuovo snippet di codice da utilizzare “per il page tagging”: cosa si intende esattamente? sicuramente si può utilizzare per inviare dati a Google Analytics, come vedremo tra poco. E-nor riporta anche che presto la libreria includerà conversion.js di AdWords. Questo rende il discorso interessante sotto alcuni punti di vista. Ma andiamo con ordine.

Lo snippet da installare appena dopo l’apertura di HEAD è più corto del classico di Universal, vediamo come è fatto

<!-- Global Site Tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=GA_TRACKING_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments)};
  gtag('js', new Date());

  gtag('config', 'UA-XXXXXXX-Y');
</script>

La prima cosa che si nota è che non c’è il comando per l’invio del pageview, e la cosa è voluta. Questo codice, da solo, fa quel che faceva il vecchio codice di base. Se anzi volessi disabilitare l’invio del pageview per qualche motivo, dovrei forzarlo con un parametro aggiuntivo

gtag('config', 'GA_TRACKING_ID', { 'send_page_view': false });

La seconda novità è che si possono gestire i multicodici con più facilità. Ipotizziamo, nemmeno con troppa fantasia, che debba mandare i dati a 4 properties. Oggi dovrei istanziare 4 tracker e fare 4 send pageview, come minimo. Domani, in presenza di un codice così

gtag('config', 'UA-111111-11', {'groups': 'default'});
gtag('config', 'UA-222222-22', {'groups': 'access'});
gtag('config', 'UA-333333-33', {'groups': 'access'});
gtag('config', 'UA-444444-44', {'groups': 'access'});

Verranno inviate 4 pageview, ma potrei anche decidere che un evento lo mando solo alle tre property del gruppo access, tramite l’uso di send_to (che in ogni caso supporta anche la specifica degli ID delle property). Su installazioni complesse e ridondanti può essere un toccasana.

Oltre ai pageview, sappiamo che si possono inviare eventi. gtag.js ovviamente li supporta, in un modo un po’ inusuale però. Sebbene sia possibile sempre fare un “classico” evento con category, action e label, la sintassi della documentazione ufficiale parla genericamente di parametri

gtag('event', 'event_name', {
  // Event parameters
  'parameter_1': 'value_1',
  'parameter_2': 'value_2',
  // ...
});

che a me ricorda MOOOOOLTO DA VICINO un dataLayer.push 🙂
Eventi normali quindi sempre possibili, ma c’è un ma… la guida parla di RECCOMENDED EVENTS e RECCOMENDED PARAMETERS, e qui avviene la magia. Per esempio questo

gtag('event', 'login');

invierà un evento con categoria engagement, action login e nessuna label. Se volessi mandarlo alle 4 property raggruppate come sopra, mi basterebbe fare

gtag('event', 'login', {'send_to': ['default', 'access']});

Simpatico, no? 🙂

Dove troviamo l’elenco degli eventi raccomandati? nella documentazione ovviamente. Se faccio un evento add_to_whishlist, GA registra categoria ecommerce, action add_to_whishlist e label vuota. Se faccio un evento begin_checkout, lui si aspetta i parametri value, curency, items, coupon.
Ora, perché sono importanti questi eventi raccomandati? per due motivi:

1. standardizzazione: sebbene sia lasciata facoltà di personalizzare tutto, gli eventi più comuni possono essere tracciati con nomi automatici, favorendo aggregazioni e confronti e facilitando la lettura dei dati
2. se scorriamo la lista degli eventi, troviamo anche cose interessanti, ad esempio che che gli item parameter hanno origin e destination, e si specifica anche (travel). Non ricorda i parametri del remarketing dinamico per il vertical dei viaggi? e se si, non fa il paio con quanto dice E-nor sul fatto che domani gtag potrebbe incorporare anche lo script di AdWords? in questo modo una sola riga di codice farebbe entrambe le cose…

Infine, le mappe per le custom metric e dimension: supponiamo che dobbiate si mandare i dati a due o tre property, ma che gli indici delle custom metric e dimension non coincidano affatto. Un grande classico, peraltro. Ecco che ci viene in aiuto la mappatura preventiva, così:

gtag('config', 'UA-111111-11', {'groups': 'default', 
   'custom_map': {
     'dimension2': 'age',
     'metric5': 'avg_page_load_time'
   }});
gtag('config', 'UA-222222-22', {'groups': 'access', 
   'custom_map': {
     'dimension33': 'age',
     'metric66': 'avg_page_load_time'
   }});

Questo codice in pratica dice: “sulla property -11 l’età (age) la si manda sulla dimensione 2, e il tempo medio di caricamento della pagina sulla metrica 5. Sulla property -22 invece età va nella custom dimension 33 e load time sulla custom metric 66.”
A questo punto facendo ad esempio un semplice

gtag('event', 'add_to_whishlist', {'age': 'eta', 'avg_page_load_time': 14.5, 'send_to': ['access', 'default']});

avremo gli stessi valori inviati a due property e per giunta negli slot corretti! Interessante, no?

Ora, venendo all’utente medio, la domanda è naturalmente “dovrei migrare o no? questa cosa sostituisce Tag Manager?”
Questo tag NON SOSTITUISCE Tag Manager, che resta per ora il metodo di implementazione consigliato. La sua versatilità è enorme, e va ben oltre l’installazione di Google Analytics. Quindi restano in ballo solo i nuovi e vecchi progetti che vogliono migrare che per un motivo o per l’altro non vogliono o possono usare GTM sulle loro pagine. Per tutti coloro gtag.js è indubbiamente il futuro, sebbene al momento esso ancora non supporti i content experiment (ma che, ancora non sei passato a Google Optimize free? che aspetti? 🙂 ), i custom task e i custom plugin.

Se queste limitazioni non vi dicono nulla, e non avete GTM, allora vi consiglierei di provare a fare una migrazione. Se poi come dice Enor anche altri prodotti tipo AdWords saranno inglobati nel Global Tag, potrebbe essere vantaggioso avere già una installazione pronta.

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.