Google Analytics in 30 secondi

Pochi giorni fa Google ha reso disponibile il suo pulsante +1 per rendere più “social” le ricerche: è un pulsante che serve a segnalare agli amici, durante le loro ricerche, le pagine che noi abbiamo apprezzato. Pochi istanti dopo l’introduzione è stata fatta la fatidica domanda: come si traccia il tutto con Google Analytics?

Joost De Valk ha la risposta, che non era troppo difficile, e siccome l’ha data per prima ve la riporto qui dandone il giusto credito (al contrario di alcuni articoli che mi sono capitati sott’occhio: dannata tendenza italiana a “dimenticare” di attribuire i crediti…): il pulsante è ingegnerizzato bene e consente di specificare una funzione custom da associare al click; nel nostro caso ovviamente si tratterà di una chiamata a _trackEvent. Nel dettaglio:

Bisognerà includere nelle proprie pagine il javascript necessario al pulsante, incollando questa riga prima di /body

<script type="text/javascript" src="http://apis.google.com/js/plusone.js"></script>

Dopodiché si potrà creare il pulsante desiderato tramite l’interfaccia apposita (image credit: yoast.com):

avendo cura di selezionare le opzioni avanzate e specificare nella riga JS Callback function (funzione richiamo JS in italiano) “plusone_vote” (è il nome della funzione che useremo).

Poi incollare la riga che ci verrà fornita dall’interfaccia (se abbiamo selezionato le opzioni come in figura sarà uguale alle seguente)
<g:plusone size="tall" callback="plusone_vote"></g:plusone>

nel punto in cui vogliamo che compaia il pulsante.

Ultimo, specificare dopo la riga del javascript che abbiamo messo prima di /body la seguente funzione

<script type="text/javascript">
  function plusone_vote( obj ) {
    _gaq.push(['_trackEvent','plusone',obj.state]);
  }
</script>

che come vedete sul click esegue un evento con categoria “plusone” e action “on” oppure “off” a seconda che si tratti di un +1 o della rimozione di un +1.

Che tipo di dati ci aspettiamo? banalmente il numero di +1 complessivi per giorno. Che tipo di indicazioni ci darebbe? ben poche, fatto così. Una modifica interessante potrebbe essere aggiungere l’url della pagina, così
_gaq.push(['_trackEvent','plusone',obj.state,location.href]);
in modo da avere i +1 distinti per pagina, e poter correlare poi il numero di +1 precedenti con picchi di traffico nei giorni successivi, se il +1 è in grado di modificare la posizione in SERP. Alcuni amici premono +1, il mio post sale nelle SERP dei loro amici, alcuni di loro premono il +1 e così via…

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!”.

Più di un anno fa vi feci un resoconto abbastanza dettagliato del panorama delle applicazioni Android per gestire Google Analytics. Da allora ogni tanto ho fatto una ricerca per vedere se ne fossero uscite di nuove, ed effettivamente qualcuna nuova c’è stata, ma nessuna mi soddisfava.

L’altro giorno invece ho testato – e comprato – Analytix for Google di Folkert, perché rappresenta qualcosa di nuovo, per certi versi differente dal resto del panorama della applicazioni Android per Google Analytics. L’applicazione è disponibile in versione trial (versione di prova) menomata di alcune funzioni, e in versione completa al costo di 99 centesimi di euro.
La mia recensione è riferita alla versione completa.

La grafica dell’applicazione è molto pulita ed essenziale, e il fatto che non presenti nemmeno un arancione – colore tipico di GA – la rende diversa dalle altre. All’apertura, dopo aver autorizzato l’applicazione ad accedere al nostro account Analytics, ci sono tre opzioni: my accounts, (my favorites se ne abbiamo selezionati), preferences e info. La prima serve ovviamente per accedere ai dati, e la vedremo tra un attimo, preferences permette di personalizzare l’applicazione; ad esempio si può decidere se avere subito i profili preferiti selezionabili (non si tratta di quelli contrassegnati da una stellina su GA, l’app ha una sua gestione interna dei preferiti), o se iniziare con un profilo specifico invece della lista. Si possono decidere quali tab avere a disposizione nell’applicazione (e sono tante, ve l’assicuro), il numero di risultati da mostrare per default, la data finale e quella iniziale per determinare il periodo di reporting, e se permettere o meno l’uso del giorno corrente.

A margine dirò che è disponibile anche un widget per le schermate home, basato sui profili preferiti, in grado di dare il “polso della situazione” in tempo quasi reale sull’andamento di alcuni parametri del proprio sito: il widget predefinito mostra ad esempio le visite, le pagine viste e i visitatori di oggi e di ieri.

Se dalla home selezioniamo “my account” avremo la lista degli account cui abbiamo accesso, e da lì potremo finalmente arrivare a un profilo. Le tab disponibili sono:

• dashboard: riassume i principali indicatori
• charts: grafici a barre per visite, visitatori, nuovi visitatori, bounce rate, pagine viste, tempo medio sul sito, transazioni, revenues e goal completati
• visits: indica giorno per giorno il numero di visite, visitatori, pagine viste, bounce rate. I dati (in questo report e nei successivi) sono sia testuali sia visuali, in modo da avere una buona comprensione dell’andamento già aprendo il report)
• top referring
• visit by country
• visit by region
• page routes: indica i numeri dei visitatori per ogni combinazione di pagina vista e la sua successiva
• search engines
• visitor engagement: è il numero di visite di ogni visitatore (è il report “fedeltà”)
• most popular: le principali pagine viste
• keywords
• top landing pages
• problematic: sono le landing page con un alto bounce rate
• browser
• system information
• connection speed (che in realtà è deprecato per GA)
• newtork information
• mobile traffic
• conversion rate: conversioni per sorgente
• revenues
• revenues by type: elenco dei prodotti e delle revenue generate
• social revenues: revenue con sorgente uguale a una lista di social network non editabile
• social pageviews: pagine viste da parte di utenti provenienti dai social di cui sopra

Ne esistono anche altre, che però vanno abilitate tramite le opzioni dell’applicazione:

• android pageviews
• android events
• ad click: report sui costi adwords
• matched query: sempre relativo ad Adwords, è la keyword realmente cercata
• total events
• event categories
• event actions
• event labels

Per definizione la schermata si apre con il confronto tra oggi e ieri, ma tramite uno slider possiamo far comparire già dalla dashboard una diversa data per il confronto: 3 giorni fa, una settimana fa, un mese fa, 3 mesi fa, un anno fa. Il giorno corrente viene evidenziato in rosso, mentre il periodo passato è grigio, in questo modo è abbastanza facile capire se la performance è migliore o peggiore (o nel caso si stia analizzando il giorno corrente, se l’outlook a fine giornata è positivo o no). La selezione delle possibili tab si fa scorrendo verso destra la lista: non molto intuitivo, ma ci si prende subito la mano.

Tra tutte le applicazioni per GA che ho provato, devo dire che Analytix si è subito ritagliata un suo importante spazio: per soli 99 centesimi dà accesso a moltissimi report, molti più delle altre applicazioni, e inoltre mi sembra un pezzo di software scritto come si deve (c’è addirittura un’opzione per evitare di inviare al Google Analytics dello sviluppatore informazioni sull’utilizzo ricavate tramite la Android SDK per GA!). Anche la presenza di un sito dedicato gioca a suo favore. Per me è un acquisto decisamente consigliato, nonostante sia necessario prendere un po’ la mano con i controlli dell’interfaccia prima di poterla sfruttare al 100%

[image credit: appbrain.com]

Il titolo è una domanda perché non ho sicurezza che sia una novità. In effetti il report recency non è uno di quelli che guardo più spesso, per cui quando oggi l’ho aperto (e parlo ancora della versione “vecchia” di Google Analytics, non della v5) mi sono stupito di trovarlo così:

Ovvero con l’indicazione separata di quanti fossero alla prima visita (il numero corrisponde ai nuovi visitatori) e di quanti siano tornati lo stesso giorno della prima visita. Due numeri che prima erano affogati all’interno della riga “0 giorni fa“, che infatti adesso è sparita (e se la vedete ancora nei report, come mi accade su alcuni profili, riporta esattamente la somma dei due valori precedenti).

Mi sembra una indicazione utile, ma ripeto non ho coscienza di quando abbiano fatto questa modifica. Lo so che ultimamente perdo colpi, ma so anche che voi siete attenti e mi saprete aiutare 🙂

[in questo periodo sono talmente impegnato che ho dimenticato il terzo compleanno di questo blog! il 22 maggio 2011 🙂 ]

Da qualche tempo a questa parte Facebook ha dato la possibilità di inserire sulle proprie pagine dei frame contenenti sorgenti esterni, ad esempio pagine ospitate sul nostro dominio, o pagine del nostro sito esistente. Questo porta alla non trascurabile possibilità di “iniettare” Google Analytics per tracciare cosa accade lì sopra; in passato avevamo già visto alcune soluzioni per provarci, ma erano tutte poco pratiche e anche piuttosto inefficaci a causa di problemi tecnici in larga parte attribuibili a Facebook stesso.

Inserire un frame con una pagina che possiede il necessario codice di GA invece porta al risultato atteso: si può tracciare l’interazione tra gli utenti e il contenuto del frame (ma non ad esempio con quel che accade in bacheca). Per farlo è necessario usare come sorgente del frame una pagina che contenga il nostro codice di Google Analytics, magari dopo aver creato un profilo-copia che include solo le pagine del frame per poterle analizzare in dettaglio. Se state usando lo stesso codice del sito, ad esempio, i cookies saranno i medesimi quindi GA sarà in grado di riconoscere gli utenti e tracciarli come di ritorno, di conteggiare gli unici, eccetera.

Esiste una modifica interessante, che ci suggerisce Lunametrics, e che riguarda le fonti di traffico; se stiamo usando Facebook come landing page di una campagna (ad esempio una pagina tipo apps.facebook.com/my-app-name), usaremo i soliti tag delle campagne per valorizzare correttamente la sorgente di visita.
Se stiamo mandando gli utenti alla pagina con il frame (un tab di un profilo, ad esempio), Facebook oscura il referrer e non lo rende disponibile al frame, per cui sarà sempre qualcosa del tipo static.ak.facebook.com/platform/page_proxy.php. Il workaround consiste nel creare una pagina sul sito con un redirect al tab di Facebook, e impostarlo come landing page della campagna con gli appositi tag delle campagne. Su questa pagina prima di fare il redirect vero e proprio è necessario eseguire il codice di Analytics. Aggiungere poi la funzione _addIgnoredRef(“static.ak.facebook.com”) al GATC della pagina contenuta nel frame.

In questo modo il cookie __utmz viene impostato quando si è ancora sul nostro sito, e ha i parametri corretti, poi quando si arriva su Facebook esso non viene aggiornato per via della funzione addIgnoredRef.

Un po’ macchinoso, forse, ma ingegnoso! 🙂

Per lavoro mi occupo di siti per la pubblica amministrazione, e per questo motivo mi sono trovato davanti agli occhi la versione 11 maggio 2011 delle linee guida per i siti web della PA. Mentre mi addentravo nella lettura mi è caduto l’occhio su questa pagina del capitolo 4 e in particolare sulla nota a fondo pagina

[21] Si raccomanda di considerare, per le statistiche web, un visitatore unico ogni 30 minuti per IP.

La cosa ovviamente non ha senso: un visitatore unico prescinde da un intervallo di tempo, e di sicuro se io faccio una visita di un’ora e mezza non sono tre visitatori, ma uno solo. Inoltre sono anni che si dice che basarsi sugli IP è arcaico, perché le visite aziendali fatte da dietro a un proxy (ma anche gli accessi dalla rete geografica di Fastweb) vengono “annegati” dietro a un unico indirizzo. Migliaia di persone che risultano come una sola, che però ogni mezz’ora va conteggiata come fosse un’altra :-/

Perché – mi direte voi – una scelta così palesemente sbagliata? non lo so, ma di sicuro fa il paio con quanto scritto nel paragrafo “Policy” a proposito dei cookies, che sarebbero la soluzione al problema di cui sopra:

…né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. [omissis] L’utilizzo di cookies permanenti deve essere strettamente limitato all’acquisizione di dati statistici relativi all’accesso al sito e/o per mantenere le preferenze dell’utente (lingua, layout, etc.)

Due frasi in antitesi tra di loro: da un lato sembrerebbe che non si possano utilizzare cookies per il tracciamento, ma per le statistiche si. Ma allora se posso utilizzare i cookies, perché definire gli unici attraverso gli IP?

Infine, tanto per non farsi mancare nulla, le linee guida impongono che i dati del monitoraggio vengano pubblicati periodicamente. Tralasciamo un attimo il fatto che se ogni PA usa un sistema di web analytics differente, i dati non saranno mai confrontabili, e concentriamoci su un altro aspetto: i tre dati da pubblicare sono (sic!) pagine viste, sessioni utente (visite) e visitatori unici.

Solo che, se non si da un intervallo di tempo, parlare di unici non ha senso, per il noto “problema dell’hotel“. Alla linea guida manca fondamentalmente l’indicazione del periodo di tempo da considerare per l’indicazione degli unici. Ogni mese si deve dare il totale annuale degli unici, oppure ogni mese si deve dare il numero di unici del mese precedente?

Molte persone col tempo dimenticano che le espressioni regolari, comprese quelle che si usano dentro a Google Analytics, funzionano per i caratteri, e non per i numeri. Anzi, per dirla meglio, i numeri vengono trattati come caratteri invece che come cifre.

Per questo quando diciamo che l’espressione regolare [0-9] identifica “tutti i numeri da 0 a 9” diciamo una verità e ne sottindendiamo un’altra: essa identifica SOLO i numeri da 0 a 9. Per cui se voglio fare una espressione regolare che prenda da 0 a 39 non posso scrivere [0-39]. Se scrivessi così intenderei qualcosa che intercetta solo numeri di due cifre, la prima delle quali può essere 0, 1, 2 oppure 3 e la seconda delle quali è sicuramente (e solamente) un 9 un numero di una sola cifra, 0, 1, 2, 3 oppure 9 (tnx to Enrico Altavilla per la correzione).

La regular expression per intercettare tutti i numeri da 0 a 39 è un’altra:

[0-3]?[0-9]
^[0-9]$|^[1-3][0-9]$

(o un numero singolo da 0 a 9 oppure un numero di due cifre la cui prima può essere 1, 2 o 3 e la seconda può andare da 0 a 9).

Le cose si complicano ancora di più quando le cifre non sono “tonde” (chiamo tondo il 39 perché comunque si vuole intercettare tutta la decina dei trenta ed escludere dai quaranta in poi), ad esempio se si vuole fare il match da 0 a 33. La regex diventa

^([0-9]|[1-2][0-9]|3[0-3])$

praticamente la scomposizione dei numeri: “da 0 a 9, oppure da 10 a 29, oppure da 30 a 33”. Un po’ verboso, ma funziona così 🙂

Dopo qualche segnalazione di malfunzionamento il team di Google Analytics è riuscito a riprodurre l’anomalia e ad individuare le cause di un baco che mostrava zero visite in alcuni custom report, segmenti avanzati e dimensioni secondarie, quando si guardava ai dati di Aprile.
Non ci è dato sapere perché, ma il post ufficiale ci informa che stanno lavorando alacremente per risolvere il problema; quindi non possiamo fare che attendere speranzosi…

[edit 12/5: tanto piccoli i problemi non devono essere, tanto è vero che la risoluzione prevista, ad oggi, è per il 23 maggio.

We expect to resolve the problem affecting a majority of users of Web Report at May 23, 2011 11:00:00 PM PDT. Please note that this time frame is an estimate and may change.
We are now able to provide a tentative date for resolution of the issue with April data in Advanced Segments, Custom Reports and secondary dimensions of May 23rd. We will continue to update the status dashboard as more information becomes available.

Sarei tanto curioso di capire esattamente cosa è successo, per “incasinare” così a fondo le cose… ]

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.

Ora che – finalmente – Google Shopping è sbarcato anche in Italia, molti si stanno ponendo la fatidica domanda: “come traccio il tutto su Google Analytics?”. Domanda legittima, per capire l’impatto sul traffico di un nuovo motore di ricerca verticale – peraltro presente anche tra le opzioni della ricerca “classica”, e per determinare il ROI dell’effort richiesto a far sì che i nostri prodotti siano nelle liste del motore.

Poiché purtroppo non ho siti miei o di clienti listati in Product Search, e che quindi non ho modo attualmente di verificare direttamente la bontà di questo metodo, devo allora affidarmi ad una soluzione già confezionata, che però dovrebbe funzionare: la scrisse qualche mese fa il blog state of search. Sostanzialmente si tratta di aggiungere un filtro personalizzato avanzato:

Campo A -> Estrai A
Referral -> google\.it\/products

Campo B -> Estrai B
Mezzo -> organic

Output in -> Constructor
Sorgente -> Google Shopping
Campo A richiesto: si
Campo B richiesto: si
Sovrascrivi campo output: si
Maiuscole/minuscole: no

Sostanzialmente, poiché non si cambia il mezzo che resta organic, GA capisce da solo che si tratta sempre di un motore di ricerca, e lo processa esattamente come Google classico, estraendo la keyword usata dal parametro “q”, ma noi cambiamo la sorgente e la isoliamo dal resto modificandola in “Google Shopping”. Questo ci permette di avere al volo la possibilità di isolare le visite provenienti dal motore verticare e capire quali keyword sono state usate, per quali prodotti, su quali landing pages, eccetera…

[edit: come mi fa notare @gpelagatti, si possono anche impostare i normali URL con i parametri delle campagne; non l’ho scritto perché avevo idea che essendo una campagna Analytics non estraesse la keyword usata dal visitatore per trovare il prodotto, ma il suo screenshot è eloquente e mi sbagliavo: a questo punto, dato che siamo nella sperimentazione, varrebbe la pena di provare a impostare i parametri taggati mantenendo “organic” come medium e “google.it” come source, e cambiando solo il campaign. Oppure, come discusso con Tommaso Galli, impostare “organic” come medium, “google-shopping” come source e campaign a piacimento, e vedere se GA lo tiene nei motori di ricerca e mantiene la keyword.

In ogni caso, grazie a entrambi per gli punti 🙂 ]