Google Analytics in 30 secondi

Google Analytics, ormai dovrebbero saperlo anche i muri, è un sistema di web analytics basato su un codice javascript, motivo per cui i bot non vengono tracciati (con qualche rara eccezione). Quando durante i miei corsi avanzati parlo dello snippet di codice dedicato al tracciamento dei siti mobili, spiegando che è completamente lato server e non ha bisogno di javascript, i presenti più attenti subito incalzano con la domanda “ma allora con quello script si potrebbero tracciare anche gli spider?”. La risposta è no – o almeno lo era quando feci la prova direttamente – perché Google sembra applicare una sorta di filtro per non sporcare i dati delle vere visite.

A livello puramente sperimentale già qualche anno fa lessi di qualcuno che aveva riprodotto le chiamate alla gif di 1×1 pixel che serve al tracciamento senza avvalersi del codice di tracciamento di GA, ma la cosa era morta lì: il codice di Analytics cambia, anche le chiamate cambiano, e cmq un SEO ha metodi più efficaci e robusti per controllare quel che fanno gli spider sul proprio sito. Tuttavia non posso non segnalarvi questo articolo di Cardial Path, che fornisce uno script php già pronto che combina il codice di tracciamento dei siti mobili con alcune modifiche fatte da loro, per permettervi di avere anche i crawler nelle vostre statistiche di Google Analytics.

Come prima cosa è consigliato creare un nuovo profilo. Non un profilo copia – che usa lo stesso codice UA dell’originale – ma un nuovo profilo con un nuovo UA. Poi bisogna scaricare il file dal loro sito e decomprimerlo sul proprio computer. Bisogna copiare il contenuto del file sample.php nel proprio sorgente php (tutte le pagine, ovviamente), sostituendo alla riga 5 il proprio account UA-XXXXXX-YY (mi raccomando, UA e non MO) ed eventualmente modificare la riga 6 con il percorso al file ga.php in accordo alla sua posizione sul server. Dopo aver copiato la cartella sul server se tutto è stato configurato per bene inizierete a vedere le visite degli spider nel nuovo profilo creato.

Poiché gli spider non hanno sorgente – vengono di loro spontanea volontà – l’autore dello script ha pensato di usare la sorgente per memorizzare lo User Agent del bot, per averlo a portata di mano nei report drilldown. Inoltre ovviamente il post di Cardinal PAth ci ricorda di focalizzarsi sulle pagine viste e non sulle visite (dato che oltre a non eseguire javascript, i bot mal digeriscono anche i cookies). L’ultima nota riguarda il fatto che per ogni pageview il codice invia anche una variabile personalizzata, di livello pagina appunto, con il timestamp al secondo di quando è stata richiesta, così da sapere chi guarda cosa e quando 🙂

Se vi ricordate, a maggio scrissi un post lamentandomi dei concetti relativi alla web analytics contenuti nella versione preliminare delle linee guida per i siti web della Pubblica Amministrazione. So di essere una persona che si lamenta molto (sono genovese, ce l’ho nel DNA 🙂 ), ma siccome è un argomento cui tengo mi armai di buona pazienza e feci l’iscrizione al forum dove si raccoglievano le osservazioni: le potete leggere a questo indirizzo.

Ieri è uscito l’aggiornamento delle linee guida, la versione finale, e indovinate un po? le mie osservazioni sono state prese in considerazione, infatti la nota è diventata

Il conteggio dei visitatori unici dipende da molteplici variabili. Ai fini statistici, si consiglia di calcolare, tramite cookie, il numero complessivo di visitatori unici in un periodo di tempo limitato a 30 giorni

(ancora perfettibile ma sicuramente migliore di prima), in compenso mi è caduto l’occhio su un’incongruenza mica male. Infatti a pagina 54, nella nota sopra riportata, si raccomanda l’uso dei cookies come avevo suggerito, mentre a pagina 53 essi sono vietati! Cito:

né debbono essere utilizzati cookies persistenti di alcun tipo, ovvero sistemi per il tracciamento degli utenti. L’utilizzo di cookies permanenti è ammissibile unicamente qualora esso sia necessario alla resa di un servizio che rientri nelle funzioni istituzionali dell’Amministrazione.

e direi che la web analytics non è un servizio istituzionale delle Pubbliche Amministrazioni.

In sostanza è obbligatorio pubblicare i dati di visite (v. pagina 55), pagine viste e visitatori unici, si raccomanda di distinguere gli unici tramite cookie, ma è vietato usare i cookies!

Bravi, bene, avanti così! :-/

Confesso che avevo in mente di farlo io (e magari più avanti ne farò uno con i miei), ma per pigrizia non l’ho mai portato a termine, ma questo post con i 5 report personalizzati preferiti da Greg Habermann, volevo scriverlo io. Pazienza, come sempre l’importante è che i concetti attraverso questo blog arrivino a voi, anche se non tutti sono originariamente prodotti da me 🙂

Per ogni custom report Greg mette gentilmente a disposizione il link diretto, che vi riporto. Cliccandolo mentre si è loggati in Google Analytics si entrerà nel report, pronto da salvare nel vostro account.

Visitatori unici per pagina:
Salvalo nel tuo GA

Il custom report mostra visite e visitatori unici per ogni URL del sito, e cliccando l’URL mostra la sorgente ed eventualmente la keyword se si tratta di un motore di ricerca.

Conversioni per ora del giorno:
Salvalo nel tuo GA

Il report è impostato per usare l’obiettivo 1, qualunque esso sia, per cui dovrete modificarlo in base alle vostre esigenze, ma è interessante soprattutto se avete un ecommerce o monitorate i social media. Inoltre una assenza persistente di conversioni in certe ore del giorno potrebbe portarvi a modificare la vostra strategia di PPC.

Comportamento degli utenti:
Salvalo nel tuo GA

Questo report è stato ideato da Peter van Klinken e gli è valso la vincita di una copia del secondo libro di Avinash Kaushik. Viene usato da Peter per confrontare i nuovi visitatori e i vistatori di ritorno; ha tre schede, Traffico, Conversioni ed Eventi, e lui lo usa in forma di pivot table, con pivot per Tipo di Visitatore.

Landing page che convertono di più:
Salvalo nel tuo GA

Questo report mostra le principali pagine di destinazione e come performano basandosi sul numero di conversioni e sul loro valore. Anche qui è bene includere la distinzione tra nuovi e di ritorno perché specialmente nelle landing page i comportamenti possono variare molto. Ottimo report da condividere con il cliente per iniziare a parlare di ottimizzazione delle landing page con poche performance.

Conversioni dalla coda lunga:
Salvalo nel tuo GA [link non più funzionante, non si può ricostruire senza vederlo]

Questo custom report ha bisogno che sia presente e applicato anche un segmento avanzato, che potete trovare sul blog di Avinash (link diretto al segmento): si tratta di un segmento avanzato che include solo le visite con keyword di 3, 4, 5, 10, 20 e più di 20 parole, ma potete modificarlo come più vi aggrada.

Dopodiché applicando il custom report sarà possibile analizzare le performance di queste visite provenienti da chiavi formate da molte parole.

Avete dei custom report che volete condividere? 🙂

La domanda più importante in web analytics è “perché?”
La risposta ad ogni “perché?” in web analytics è ugualmente “perché?”

Questa è una delle tante sfide in questo campo, ma è anche ciò che mantiene la web analytics fresca e interessante. Non c’è una fine, non c’è un sito perfetto. C’è solo “perché?“.
Ciò premesso, a volte ci sono dei “a causa di…” – ma quello spesso significa “probabilmente per via…”

“perché?” è la domanda più importante che possiamo chiedere ad un cliente che dice “per favore, possiamo avere un migliaio di azioni [o goal] nel nostro account?”. Non accettare può sembrare crudele, può sembrare un ostacolo per il futuro, ma c’è una ragione.

[ho tradotto solo questo pezzo di un bel post, che vi consiglio di leggere 🙂 ]

Questa mattina la home page della v5 di Google Analytics presenta un lieve ritocco grafico. Il carattere è più piccolo e grigio, e i profili copia sono adesso compressi ed espandibili usando il più

E’ inoltre presente la dicitura PREDEFINITO che si riferisce a quale profilo verrà aperto al clic diretto sull’url compresso; questa impostazione si può variare dalle opzioni dell’account GA ( opzioni -> impostazioni proprietà web -> profilo predefinito).

Inoltre i report AdWords sono stati spostati dal gruppo “sorgenti di traffico” ad un gruppo nuovo che si chiama “advertising”, segno che forse è in procinto di cambiare qualcosa anche su quel fronte, magari con l’introduzione della capacità di import o gestione anche da altre forme pubblicitarie…

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

Grazie a un twit di LBIAnalytics ho scoperto googleanalyticstest.com, un sito indipendente da Google che propone un quiz sul nostro strumento di web analytics preferito (solo in inglese). Ci sono 162 domande totali, divise per aree di applicazione, e voi potete scegliere sia quali aree sia il numero di domande cui rispondere: massima flessibilità. E devo anche dire che le domande sono parecchio toste. Ho messo su un quiz velocemente per testarlo, 81 domande su tutti gli argomenti, ed ecco il penoso risultato 🙂

[edit: le domande possono essere VERO o FALSO, a risposta singola su 4 opzioni o risposta multipla su 4 opzioni]

La cosa veramente interessante è che a differenza del Google Analytics Indivdual Qualified test, una volta fatto lo score il sistema ci dice in quali domande abbiamo commesso errori, quali risposte di ogni domanda abbiamo sbagliato e inoltre c’è una spiegazione sul perché ogni opzione fosse giusta o sbagliata, e anche dei commenti generali sulla situazione descritta dalla domanda. Veramente istruttivo! Conto di ripetere il test con tutte le 162 domande una sera di queste, con calma. Non posso subire l’onta di un punteggio così basso, non mi fa onore 🙂

In passato vi avevo già dato una lista – minima – di libri che ogni buon web analyst dovrebbe tenere nello scaffale, e tra questi vi era anche Advanced Web Metrics with Google Analytics di Brian Clifton.
Da allora ho avuto modo di leggere anche altre cose, non tante quante avrei voluto ma comunque ho cercato di darmi da fare. La pila di cose da leggere è ancora piuttosto alta, ma forte del fatto che si trattava di una seconda edizione ho affrontato e quasi terminato Advanced Web Metrics with Google Analytics (third edition), sempre di Brian, e vi posso dire che dal punto di vista tecnico è il miglior libro che possiate acquistare. Ovviamente non è solo un libro tecnico, ci sono anche aspetti di marketing, ma se vi interessano quelli esistono altri testi più dedicati. Brian ci parla dello strumento a tutto tondo, in modo chiaro e lineare, senza tralasciare nulla. Ho la grande fortuna di non sapere tutto, nemmeno di Google Analytics, e quindi io stesso mi sono ritrovato più volte a dire “accipicchia! questa mi mancava” (per la verità soprattutto leggendo le note collegate, ma è pur sempre sapere 🙂 ). Forte del fatto che ha lavorato nel team di GA può permettersi di dire cose con una certa sicurezza e inoltre ha approntato sul suo sito una sezione dedicata ai download di script, aggiornamenti, immagini; per la verità non è necessario comprare il libro per accedervi, ma è di complemento 🙂

In definitiva, sebbene esista solo in inglese e sebbene tutto sia riferito ormai alla versione v4, i concetti espressi sono validissimi quindi non posso che consigliarvelo, ancora una volta!
Appena termino le ultime pagine che mi restano cerco di buttarmi su qualcosa di meno tecnico e più relativo all’analisi, e ve ne parlerò qui…

Secondo TechCrunch Google+ è diventata in breve tempo una delle fonti principali di traffico al loro blog. Non si può sapere se per via dell’euforia della novità o perché effettivamente costituisce un buon veicolo di informazioni (il che farebbe ben sperare, dato che al momento tutto va fatto a mano e non ci sono meccanismi di import automatico di nulla)…

Comunque sia, visto che Google+ è attestato sul protocollo https per questioni di maggiore sicurezza, i link postati lì dentro non dovrebbero generare referrer secondo le specifiche HTTP. Ma Google ha optato per un redirect intermedio [edit 7/7/11: non è un redirect lato server, ovviamente. Se avete curiosità tecniche Simone Rinzivillo ha un post in cui spiega come fa Google a tenere il sorgente “pulito” ma indirizzare verso un indirizzo intermedio] su http normale che invece il referrer lo genera. E quindi le visite a link cliccati su Google+ vengono viste dai sistemi di tracking come Google Analytics come normali referrer, però essendo di una property della serie “google.com” essi sono affogati nello stesso referrer di Google Reader, ad esempio.

Se per qualche motivo volete separarlo e tracciare Google Plus separatamente, basta un solo filtro (clicca per ingrandire):

Filtro GooglePlus – personalizzato / avanzato
Campo A -> Estrai A: Referral – google\.com/url\?sa\=z
Campo B -> Estrai B: (vuoto)
Output in -> Constructor: Sorgente Campagna – google-plus
Campo A obbligatorio: Sì
Campo B obbligatorio: No
Sovrascrivi campo output: Sì
Maiuscole/minuscole: No

Il risultato è esattamente quello atteso, cioè la separazione delle visite provenienti da Google+ da quelle del resto della galassia Google:

Scelta insolita, e piuttosto curiosa, quella del team di Google Analytics di trasformare il vecchio rapporto “analisi comparativa” in una newsletter. Curiosa perché da sempre siamo abituati a ragionare in termini di “report” e non di newsletter, insolita perché di norma siamo noi ad andare a cercare le informazioni (appunto aprendo un report) e non sono le informazioni che raggiungono noi, almeno in GA. Esiste una eccezione, ed è rappresentata dall’invio periodico dei report, che però è scatenato su nostra richiesta: e allora perché non aggiungere anche il benchmark tra le opzioni (ovviamente per la v5 intendo “quando ripristineranno l’opzione”)?

Comunque sia, questo primo numero della newsletter sperimentale dell’analisi comparativa contiene dati aggregati e anonimizzati per il periodo 1 novembre 2010 – 1 febbraio 2011 e relativo confronto temporale col periodo precedente. Non ci è dato sapere se 4 mesi sarà il tempo standard o se questo primo invio serviva ad avere un po’ di storico per confronto con i successivi invii. Sebbene non ci sia scritto niente di trascendentale, è piacevole leggere delle considerazioni fatte direttamente da Google e scritte in italiano corrente, senza tecnicismi. Alcuni dati che molte persone chiedono – e che reputo peraltro inutili su un campione così vario – sono finalmente a disposizione e alcune persone potranno finalmente sapere quale è il bounce rate medio della Germania.

Sapete invece quale è la cosa brutta? che per la seconda volta in poco tempo (la prima è il fatto che le regioni italiane non sono ancora disponibili nell’overlay mappa geografica) il nostro paese non compare; anzi, viene nominato soltanto una volta, quando la newsletter ci informa che il tasso di conversione medio è superiore al 3%, ma non ci dice quanto (e comunque è inferiore a città del vaticano, che sono sempre siti italiani che non hanno impostato correttamente il timezone).

Insomma, cambia il mezzo ma mi sembra inutile tanto quanto prima. Se non altro prima potevo scegliere la categoria merceologica contro cui fare il raffronto, e quindi sperare di confrontare i dati solo con siti di giardinaggio, se avevo un sito che trattava giardinaggio!