Google Analytics in 30 secondi

Come abbiamo già  avuto modo di notare in passato, Google Analytics non ha mai costretto nessuno a effettuare migrazioni del codice di monitoraggio; esse sono semplicemente consigliate. Se anche non usate il nuovo codice asincrono non cambia nulla. Se addirittura avete ancora il vecchio urchin.js, i vostri dati vengono raccolti ugualmente. In questo ultimo caso non potete avvantaggiarvi di alcune delle ultime funzionalità , tipo il tracciamento degli eventi o molte funzioni che esistono solo per ga.js, ma i vostri dati di base ci sono, vengono analizzati.

Mi è venuta in mente questa cosa perché ho letto che da fine luglio la versione v.4 del codice di tracciamento di Yahoo Web Analytics smetterà di funzionare, in favore della v.5. Da un alto trovo giusto che ogni sistema agisca come vuole – ed in Yahoo avranno sicuramente le loro ragioni ed esigenze – dall’altro mi stavo domandando quale dei due metodi sia preferibile. In Google effettivamente fanno fatica a star dietro ai tre metodi con la documentazione, ed ogni situazione andrebbe descritta tre volte, ma così facendo nessuno ha mai perso un dato. Esisteranno clienti di YWA che non hanno letto, in questi anni, o che non si ricordano della deadline? qualcuno perderà dei dati?

quale pensate che sia la soluzione migliore?

[a margine, già che ci siamo: le richieste HTTP alla gif fatte da codice asincrono (leggi questo post se non sai di cosa sto parlando) contengono un parametro aggiuntivo &gaq=1, che non produce nessun dato in Google Analytics, ma che immagino consenta a Google di conoscere puntualmente il numero di installazioni che usano l’ultimissima versione del GATC]

Detto, fatto! Il nuovo codice da copiaincollare proposto da Google Analytics è adesso quello asincorno. Ecco infatti come mi si presenta la schermata relativa alle 16:00 di oggi 17 maggio (clicca per ingrandire):

La cosa vale anche per i siti vecchi, ovvero se andate su “impostazioni profilo” -> “verifica stato” vedrete che il codice proposto dall’interfaccia è il nuovo codice asincrono.
Dal 4 al 17 maggio, tredici 14 maggio, dieci giorni (tnx to Cristian) tra l’annuncio e la realizzazione: magari tutte le novità fossero così veloci 🙂

Dieci intensi minuti con Twitter surriscaldato dai refresh ci hanno finalmente svelato le attese novità.

In primo luogo è stata lanciata una galleria delle applicazioni utili a estendere le funzionalità di Google Analytics, siano esse siti esterni basati sulle APi, plugin per browser o applicazioni da installare. Tutto quel che vi può essere utile per avere più dati a disposizione è ora elencato e categorizzato nella Google Analytics Application Gallery (al momento sono elencate 32 applicazioni).

Il secondo annuncio è che il tracking code asincrono è uscito dalla fase beta, e in accordo con la politica di rendere più veloce il web presto diventerà il codice di monitoraggio predefinito (quello che per intenderci copiate e incollate quando create un profilo) per tutti.

Infine presto ci saranno nuove integrazioni con AdWords, e più report. La cosa che più piacerà ad alcuni di voi (Fradefra? Gorino? 🙂 ) sarà la possibilità di vedere finalmente la query cercata insieme a quella pagata, senza più bisogno di doppi e tripli filtri. Nel video che spiega brevemente le novità si vede – e sente – più volte “actual search query” come nuova dimensione possibile, oltre al match type e altre cosette interessanti.

Inoltre nelle API di Google Analytics sono state introdotte 5 nuove dimensioni relative ad Adwords

Ci sono alcune novità in Google Analytics, ci informa il bollettino dei changelog. La più importante di tutte è che è stato finalmente corretto il baco che non permetteva di invocare la funzione _trackEvent() senza invocare anche _trackPageview() o _initData() (si veda questo vecchio post in proposito: initdata e tracciamento eventi). Da questo momento è quindi possibile avere una pagina che contiene il codice di monitoraggio di Google Analytics SENZA che essa generi una pagina vista ma che è in grado di tracciare eventi che accadono su di essa.

Un’altra novità è che è stato leggermente variata la sintassi del nuovo script asincrono, in modo da risolvere un problema che si generava su Internet Explorer 6 e 7 quando si posizionava lo script nell’HEAD della pagina; vi consiglio di dare un’occhiata al nuovo snippet – lo trovate qui – perché è abbastanza differente dalla prima versione apparsa.

Per chi invece usa il codice “classico”, è bene sapere che la funzione _getTracker() è stata deprecata. Non l’avete mai usata? dite? secondo me invece si, è una funzione che avete incollato OGNI SINGOLA VOLTA che avete aggiunto un codice di GA a una pagina.

<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-53707-19");
pageTracker._trackPageview();
} catch(err) {}</script>

Fa parte del codice standard e si invoca quando si crea il più famoso oggetto pageTracker. Sebbene l’interfaccia web ancora non rifletta questa modifica quando si crea un nuovo codice di monitoraggio, la funzione _getTracker non esisterà più, e al suo posto andrà usata _createTracker(), cui dedicheremo un post apposito appena avrò qualche notizia più certa. Sostanzialmente il nome dell’oggetto di tracciamento verrà impostato come un parametro di questa nuova funzione, come nella sintassi di esempio

_gat._createTracker('UA-65432-2', 't2');

Se non ho capito male poi ci si potrà riferire all’oggetto semplicemente con t2._trackPageview().
Non è un cambiamento epocale, ma rende il codice di monitoraggio classico più coerente con quello asincrono.

Sempre il buon Andrea mi pone una domanda, e ne approfitto di nuovo per un post: mi fa sempre piacere scoprire cosa non è chiaro alle persone, dato che io con Google Analytics ci faccio anche colazione e quindi tendo a dare per scontate troppe cose 🙂

Il suo quesito è all’incirca “Non sono d’accordo con una persona che sostiene che trackpageview può essere utilizzato anche per rimappare l’url corrente della pagina e fare in modo che sia possibile poi utilizzare il nuovo indirizzo all’interno dei goals per verificare chi converte e chi no. Io ritengo che la funzione del trackpageview è quella si di assegnare una pagina virtuale, ma nel caso in cui si scateni un evento a cui questo è stato associato”

L’errore nasce dal fatto che _trackPageview noi lo vediamo solo in due forme. La prima è all’interno del codice di monitoraggio classico, dove viene sempre richiamata senza parametri, la seconda è quando creiamo pagine virtuali e quindi le passiamo come parametro un indirizzo fittizio. La funzione in realtà è sempre la stessa, e il suo scopo è quello di “fare il punto della situazione” nel codice di monitoraggio, scrivere i cookie nel computer del visitatore e sparare i dati verso i server di Google. Se non gli si passa un parametro, essa invia per impostazione predefinita l’url corrente della pagina così com’è.
Ma nessuno ci vieta, ad esempio, di usare una funzione lato server per inserire dinamicamente all’interno di un codice di monitoraggio degli indirizzi più leggibili ai fini delle nostre analisi.

Ipotizziamo di non avere modo di riscrivere le URL attraverso i metodi “normali” – quali .htaccess o filtri ISAPI per webserver Microsoft – e di aver scritto una funzione in PHP (abbellisciURL() ) che ci restituisce un simil-URL nella forma /categoria/marca/nomeprodotto.html

Se modificassimo il GATC così

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try{
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview(<?php abbellisciURL(); ?>);
} catch(err) {}</script>

dentro a Google Analytics avremmo SOLO ED ESCLUSIVAMENTE i nostri url abbelliti.

Potrete poi usare questi url per definire gli obiettivi? ASSOLUTAMENTE SI, dato che non sappiamo esattamente QUANDO GA elaborerà i dati, e dato che gli url modificati sono I SOLI ad essere stati inviati ai server di Google, è assolutamente lecito e possibile definire dei goal usando gli url fittizzi. Anzi, non potreste fare altrimenti!

_trackPageview() quindi si rivela anche un potente strumento per rendere i vostri report più semplici e chiari, più leggibili, ed eventualmente anche per facilitarvi la vita nell’impostazione degli obiettivi.

Mi fanno notare via email che tempo fa avevo scritto: «Se fatta con le dovute cautele la migrazione è indolore, e vi permetterà di dimenticarvi della “dead line” di Google»

In realtà non c’è mai stata nessuna “dead line” e urchin.js è ancora lì, vivo e vegeto. E’ però stato sorpassato DI FATTO da ga.js, in sordina. Google ha preferito evitare un evento traumatico per l’utente come la sostituzione del codice entro una certa data, preferendo continuare a investire sul nuovo codice e lasciando ad ogni webmaster l’onere di capire se e quando sarebbe stato il momento di abbandonare il vecchio codice. Penso che la mossa sia vincente, perché da sempre uno dei punti forti di Google Analytics è “iscriviti, copia il codice e basta”, che è uno dei tanti motivi per cui oggi è così diffuso. Troppo spesso noi che lavoriamo in questo settore ci dimentichiamo che la maggior parte delle persone non ha approfondite conoscenze di javascript e linguaggi lato server, e che non sa nemmeno che esistono una marea di funzioni che si possono aggiungere al codice di monitoraggio. Copiaincollano oppure usano un plugin/modulo per il loro CMS e vivono felici.

Queste persone piano piano si rendono/renderanno conto che le nuove funzionalità offerte da GA sono pensate espressamente per il nuovo codice di monitoraggio e migreranno volontariamente – o con l’aiuto di qualcuno – a ga.js, rendendo di fatto inutile costringere alla migrazione. Ritengo che in effetti questa sia stata una mossa azzeccata per non intaccare nemmeno di una unità l’ampia base di utilizzatori della nostra piattaforma preferita di web analytics 🙂

Secondo me sicuramente si, l’ho già detto in passato. Mi sembra un passaggio naturale e obbligatorio, dato che lo scopo di Website Optimizer è quello di migliorare le conversioni del sito facendo test A/B e il modo per capire cosa è meglio e cosa no è il tracciamento puntuale delle visite.
Gli strumenti sono già visivamente simili, ed esistono anche soluzioni per integrare i dati dentro a Google Analytics, ma sono piutosto macchinose e non ve ne ho mai parlato (anche perché mi piacerebbe, prima o poi, fare dei test con GWO e parlarvene qui).

Curiosamente però entro le prossime due settimane entrambi gli strumenti subiranno una manutenzione evolutiva; ecco il comunicato del blog di Analytics e quello del blog di Website Optimizer. Prima che qualcuno di voi si spaventi mettiamo subito in chiaro che nessun dato andrà perso e i sistemi continueranno a funzionare regolarmente. In GWO non sarà possibile creare o modificare esperimenti, in Analytics non sarà possibile creare profili, aggiungere utenti o filtri o modificare la configurazione dei profili esistenti. Per entrambi i prodotti sarà invece possibile consultare i dati.

Ma perché insieme? e perché adesso? per come la vedo io l’intervento è teso ad armonizzare i database sui quali si reggono le due applicazioni, e se tutto andrà bene tra qualche mese i due strumenti si fonderanno: d’altronde Google Analytics ha già un sistema di generazione del codice di monitoraggio, e GWO richiede dei codici aggiuntivi da mettere sulle pagine. Se fosse possibile creare e gestire esperimenti direttamente da Analytics si potrebbe demandare a lui la generazione del codice necessario, salvando nel contempo le configuraizoni avanzate, e avere i dati direttamente integrati in Analytics sarebbe indubbiamente vantaggioso e affascinante!

[update 11:27. In realtà la scritta che avvisa della manutenzione dentro al pannello di GA recita:

A partire dal giorno 2-mar-2010, Google Analytics non sarà disponibile approssimativamente dalle ore 7.00 alle ore 23.00 (fuso orario del Pacifico).
Durante questo periodo, potresti non riuscire a visualizzare i dati aggiornati. Tuttavia, i dati continueranno ad essere raccolti ed elaborati e potrai visualizzarli al termine dell’operazione di manutenzione.
Apprezziamo la tua pazienza.

La manutenzione quindi sarà tra le 16:00 del 2 Marzo e le 8:00 del 3]

Facebook è ovunque, e forte dei suoi 400 milioni di utenti macina record su record. Facebook è sulla bocca di tutti, e tutti vogliono sfruttarlo per promuovere se stessi o la propria attività, a volte anche in modo inappropriato (per non dire peggio). A prescindere da tutte queste considerazioni – però – non è mai stato possibile inserire il codice di Google Analytics sulle fan page del famoso social network. Al massimo si poteva utilizzare un tag di FBML (una versione modificata di HTML che si usa nelle pagine di FB), ma esso poteva venire usato solo sulla pagina di presentazione di un’applicazione.

Da qualche giorno è invece disponibile uno strumento esterno che si basa sull’uso di una immagine generata “al volo” da php, in grado di intercettare i dati necessari e di inviarli ai server di Google al posto del javascript che usiamo normalmente. Senza dilungarmi troppo vi segnalo il post di Tiziano Fogliata e il post originale degli autori, dove è anche possibile scaricare il tutto e ospitarlo sui propri server per avere ulteriori personalizzazioni possibili.

E’ un primo timido tentativo di unificare dati provenienti da fonti diverse, problema sempre più annoso, ma secondo me questa mossa a Facebook non piacerà affatto e temo che lo strumento presto cesserà di esistere. Facebook non ha mai supportato troppo l’inserimento di script esterni sulle proprie pagine, basti pensare che il codice di GA generato dal tag usa ancora la vecchia versione dello script, quello con urchintracker().

NO!
In realtà, se vogliamo, esistono due id diversi: uno è l’ID dell’account (nella forma UA-123456) e uno è l’ID di ogni profilo contenuto in ogni account (nella forma UA-123456-1, UA-123456-2 e così via…).
In nessuno dei due casi potete variare questi dati, che vengono generati al momento della creazione di un account e di un profilo, rispettivamente.

Se prendete due qualsiasi codici di monitoraggio, nella loro forma basilare senza personalizzazioni, vedrete che differiscono per una e una sola cosa, la riga:

var pageTracker = _gat._getTracker("UA-xxxxxx-x");

se cambiate i numeri che ci sono al posto delle x semplicemente inviate i dati ad un altro account / profilo (questo si può fare, lo ricordate?). Quindi variare i numeri a livello di codice di monitoraggio è inutile. D’altra parte non si possono fare modifiche a questi dati nella configurazione di GA, quindi abbiamo le mani legate.
Il motivo della domanda presumo sia iniziare un nuovo profilo mantenedo lo storico, cosa che non è possibile dato il legame stretto che abbiamo visto lega codici di monitoraggio a profili e account.

Anche io inizio a far fatica a stare dietro agli aggiornamenti del nostro sistema di web analytics preferito, e vi garantisco che ho innumerevoli fonti che leggo spessissimo. Basta distrarsi un giorno e gli ingegneri di Mountain View lanciano nuove funzionalità, aggiornano l’interfaccia, fanno annunci. Vediamo quindi cosa troveremo nel pacchetto che Google Analytics ha deciso di lasciarci sotto l’albero di Natale:

• Annotazioni: ne aveva già parlato Enrico sul blog di TSW, ma volevo aspettare un post ufficiale. Si tratta di una funzionalità richiesta a gran voce da molti, specie quando si usa GA in team grandi o geograficamente distribuiti. Si tratta di poter aggiungere annotazioni, etichette, scritte, direttamente sui grafici, in modo che sia chiaro a tutti cosa è successo in un dato punto del grafico, oppure che si possa aggiungere un promemoria per una analisi successiva o annotare un down del server. Che siate del reparto marketing, vendite o tecnici informatici, troverete questa funzione molto utile per far sapere a tutti coloro che hanno accesso al profilo cosa succede ai dati.
• Variabili personalizzate nei segmenti avanzati: vi sarà finalmente la possibilità di utilizzare le nuove variabili personalizzate (di cui parleremo a breve) per definire segmenti basati sui dati in esse contenuti.
• Variabili personalizzate nei report personalizzati: come conseguenza del punto precedente, le variabili personalizzate appariranno anche nell’interfaccia di creazione dei rapporti personalizzati, e saranno incrociabili con le altre metriche/dimensioni.
• Nuovo processo di creazione del codice di monitoraggio: questo è interessante. Uno degli scogli più grandi nell’uso di alcune funzioni avanzate è il loro collocamento nello script di tracciamento, dopo aver capito quale fosse la funzione adatta allo scopo (l’esempio classico è il tracciamento multidominio o multisottodominio). D’ora in poi Google Analytics proporrà un processo di creazione del codice guidato, e rispondendo ad alcune domande sarà possibile avere il codice già bello e pronto da incollare. Come bonus c’è la possibilità di inviare per email il codice finito.
  
  [immagine di Google]
• Nuova versione delle API: per ora solo un annuncio, le novità devono essere così corpose che stanno preparando un post a parte solo per le API

Che ne dite, Babbo Natale Analytics è stato buono con noi quest’anno? 😉