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

Quasi un mese fa su SEOmoz è apparso un articolo su come tracciare il ranking del sito usando le variabili personalizzate. Uno dei tanti della serie, direi, perché ciclicamente l’argomento ritorna (io stesso ne scrissi più di un anno fa). Segnalo questo perché è il primo che compare dopo la modifica al passaggio delle keyword per gli utenti loggati ai servizi Google, e quindi prova ad usare il metodo per “indovinare” quali siano queste keyword (not provided). Ma andiamo con ordine: innanzitutto propongo una modifica al suo codice, che presuppone una funzione e una chiamata sull’onload della pagina. Io farei tutto nello script di analytics, così

<script type="text/javascript">
var url = String(document.referrer);

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXXXX-X']);
if (url.indexOf ("google") !=-1)
{  
  var urlVars = {};
  var parts = url.replace(/[?&]+([^=&]+)=([^&]*)/gi, function(m,key,value)
  { urlVars[key] = value; });
  // Push to GA Custom Variables
  _gaq.push(['_setCustomVar', '1', 'Rankings', urlVars["cd"], 1]);
}
_gaq.push(['_trackPageview']);

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

ho inoltre modificato il check sul referrer da “google.com” a “google”, altrimenti per google.it non funzionerebbe (e poi perché privarsi degli altri TLD?)

A questo punto le posizioni delle parole chiave si trovano dentro al report VSITATORI -> DATI DEMOGRAFICI -> VARIABILI PERSONALIZZATE, nella chiave 1 se avete usato lo script qui sopra o nella chiave corrispondente se la 1 era già occupata e avete deciso di usare un altro slot.
Il report così com’è elenca dei numeri, cioè le varie posizioni aggregate in cui il nostro sito è comparso nelle pagine dei risultati di Google, ma usando la dimensione secondaria impostata su PAROLA CHIAVE possiamo dividere ogni riga del report nella combinazione posizione-keyword (l’immagine è di SEOmoz)

L’utilizzo possibile di queste informazioni è molteplice: innanzitutto possiamo creare dei segmenti avanzati su gruppi di posizionamenti. Ad esempio:

SEGMENTO AVANZATO: posizioni da 1 a 3
Variabile personalizzata (chiave 1) CORRISPONDE ESATTAMENTE a Rankings
E
Variabile personalizzata (valore 1) CORRISPONDE ALL’ESPRESSIONE REGOLARE ^[1-3]$

è una segmento che individua solo le visite arrivate con keyword tra la prima e la terza posizione (dove per posizione si intende il conteggio dei link nella SERP, occhio a Universal Search che mette più di 10 posizioni su pagina 1!).

L’autore dell’articolo su SEOmoz però si concentra sulla provenienza geografica e sul tentativo di indovinare le keyword che Google Analytics presenta come (not provided). L’esempio che fa è questo: le keyword (not provided) dagli Stati Uniti sono in posizione #1 e #2, quindi dopo aver esportato su Excel sono in grado di restringere il mio dataset a quelle due posizioni e a quel paese.

Segmentando allora il report delle variabili personalizzate per landing page si vedrà dove atterrano questi (not provided) dalle posizioni #1 e #2, e segmentando poi il report delle keyword sempre per landing pages l’autore immagina che queste keyword nascoste abbiano a che fare con il suo nome, per il quale il sito compare appunto in prima e seconda posizione.

Questo ragionamento non mi fa impazzire di felicità, ve l’ho riportato per completezza, ma mi sembra un po’ empirico e soprattutto non sempre applicabile.

Daniel Waiseberg su searchengineland porta alla nostra attenzione il fatto che il report delle pagine di destinazione è stato da poco rinnovato. Fino a poco tempo fa esso presentava una lista di pagine che sono state le prime di ogni visita nel periodo temporale selezionato e le incrociava con tre metriche: Entrate, Rimbalzi e % di rimbalzo.
Come sanno all’incirca tutti quelli con cui ho avuto modo di parlarne, quello era l’unico report dove aveva senso guardare la frequenza di rimbalzo, per evitare di incorrere in un errore piuttosto diffuso: applicare la percentuale alle visite anziché alla metrica entrate.

Il nuovo report invece presenta le metriche più classiche dei report dei contenuti: pagine/visita, tempo medio sul sito, % nuove visite e frequenza di rimbalzo. Questo ci dà delle informazioni maggiori sull’engagement dei visitatori con il nostro sito, perché è sempre vero che la visita da qualche pagina deve iniziare; inoltre sono state aggiunte al report anche le tab dei GOAL e dell’ECOMMERCE, per cui è possibile segmentare i risultati ottenuti senza fare altro: ogni landing page avrà un certo tasso di conversione globale e per obiettivo, e ci dirà quanti introiti hanno generato le visite che da lì sono iniziate. Niente che non si potesse fare anche prima con segmenti e custom report, ma negli ultimi tempi Google Analytics si sta anche concentrando nell’uniformare e rendere più facili da trovare le informazioni. Meno clic per tutti.

Quel che non mi va giù, tuttavia, è che io trovato utile anche il report precedente; me lo sono ricostruito molto brevemente con un custom report, ve lo condivido per comodità: http://goo.gl/LP6vg. Con un po’ più di cura si potrebbero unire il precedente e l’attuale usando due schede.

Il tempo passa per tutti, software compresi, e anche quest’anno è venuto il momento di celebrare il compleanno di Google Analytics. Sono ormai passati sei anni esatti (al minuto, secondo l’ora dell’annuncio sul blog ufficiale) da quel 14 novembre 2005, e di acqua sotto i ponti ne è passata parecchia.

Se fosse un bambino sarebbe ora di andare in prima elementare, di mettere da parte qualche gioco e iniziare a pensare di studiare seriamente per diventare il primo della classe; ma se fosse un bambino sarebbe anche parecchio – forse troppo – intelligente! 🙂

Google Analytics sta iniziando ad introdurre due nuovi pulsanti nei report di AdWords, pulsanti che servono a separare il traffico complessivo da quello generato da cellulari di fascia alta e da tablet. Niente che non si potesse già fare con dei segmenti avanzati, per carità, ma ritrovarseli già pronti fa sempre piacere. Inoltre possiamo anche azzardare che la separazione avvenga usando lo stesso database che dentro ad AdWords ci permette di selezionare i dispositivi sui quali visualizzare i nostri annunci.

facilitandoci quindi l’analisi dei risultati segmentati per dispositivo e dandoci la possibilità di ottimizzare ancora di più le campagne sui dispositivi mobili.

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… 🙂

Pare che ieri durante il PubCon Ashish Vij abbia dichiarato che entro tre mesi saremo in grado di utilizzare Google Analytics per monitorare le attività delle nuove e fiammanti brand pages di Google+, lanciate qualche giorno fa. Come tecnicamente si potrà fare è ignoto, intendo se basterà fornire il numero di UA come ad esempio per i documenti Google Docs oppure se saranno concesse personalizzazioni al codice, ma è di sicuro una possibilità ghiotta per molti publishers, oltre che una cosa che su Facebook è talmente difficoltosa da risultare nei fatti quasi infattibile, o fonte di enormi problemi per via del caching aggressivo da parte dei server di Facebook o del fatto che bisogna usare iframe e il tracciamento vale solo nei punti in cui è possibile inserirlo.

Se poi ci mettono dentro i ripples, come spero, siamo a posto! 🙂

L’ultima volta che abbiamo parlato del market share di Google Analytics – agosto 2010 – eravamo al 50% del primo milione di domini. A metà ottobre Stépahn Hamel di Cardinal Path ha ripetuto l’analisi prendendo in considerazione soltanto i primi 500 siti di retail americani (si riferisce a questa lista) e ha scoperto che su di essi è presente al 64%

Nel 2008 per la stessa lista la percentuale era del 43%. La stessa analisi ripetuta sui siti delle aziende che rientrano nella lista “Fortune 500” mostra una percentuale del 45%. Se anche facessimo la media, sarebbe comunque il 54,5%. La conclusione di Stéphan è drastica, ma veritiera: non importa se nel report Forrester Wave GA è ancora indietro, se non ha il badge “pronto per la grande azienda” o se non ha la lista di feature più lunga dei concorrenti: risponde alle esigenze degli analisti, e questo basta affinché sia la soluzione più usata nel mondo.

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.

Google Analytics traccia, senza che voi facciate nulla, i click sui pulsanti +1 del vostro sito e popola il report SOCIALE dentro alla sezione VISITATORI. Con un po’ di codice aggiuntivo si possono tracciare anche i pulsanti di Twitter e di Facebook, come documentato nell’apposita sezione dell’help (anche se a dire il vero a me il pulsante di Twitter ha smesso di essere tracciato senza che io abbia fatto alcuna modifica al codice. Devo indagare più a fondo…).

Da qualche giorno sarete felici di sapere che vengono tracciati automaticamente anche altre due “azioni sociali”, senza nessuna modifica richiesta: si tratta dei plugin ShareThis e AddToAny. Se avete questi due plugin sul vostro sito, potete già godere delle nuove voci presenti nei report sociali, che vi dicono esattamente come e quanto i plugin vengono usati, e per premere cosa.

Se invece usate il plugin AddThis, è necessario aggiungere tre righe di codice al vostro sito, come documentato sul loro sito.

Mi piace quando aggiungono funzionalità senza che noi si debba toccare alcunché… 🙂