$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Una domanda che mi sento rivolgere molto spesso è come mai vi siano delle differenze tra il report “sezioni principali” e il report “sezioni per titolo”, visto che entrambi sono espressi in pagine visualizzate. Esistono 3 ordini di risposta, e di norma nessuna di queste sottintende ad un errore di Google Analytics; al massimo deve esserci un errore nella chiamata al javascript. Quando la funzione trackpageview() viene invocata all’interno del GATC vengono raccolti sia l’URL della pagina sia il title della stessa. Quando essi vengono analizzati dai server di Google sono memorizzati in due luoghi distinti, e non mantengono la relazione che c’è al momento della chiamata del javascript. Per questo motivo due pagine con URL differenti ma stesso title generano due record differenti nel report “sezioni principali” ma un solo record (con 2 pagine visualizzate) nel report “sezioni per titolo”.
Questo modo di interrogare i dati di Analytics è peraltro molto usato dai SEO per trovare rapidamente pagine con title uguale. Ammettendo comunque di avere la certezza che tutte le pagine del nostro sito abbiano title e URL univoci possono esistere ancora delle differenze, e sono date dall’uso della funzione trackpageview() per tracciare click su elementi quali link esterni, download, ecc.
La funzione trackpageview() accetta un solo parametro di tipo stringa che rappresenta la URL della pagina virtuale che vogliamo creare e tracciare. Questa pagina prende come default lo stesso title della pagina nella quale la funzione è richiamata, e per quanto esposto in precedenza l’aggregazione avviene a livelli differenti.
Ve lo mostro con due schermate:
Ho selezionato un solo giorno, per avere un margine di errore minore, e una sola URL

Questo è il corrispettivo record del prospetto “sezioni per titolo”, stesso periodo temporale. Ci sono due pagine viste in più.

E questo è il dettaglio del record, in cui si vedono chiaramente i risultati delle due chiamate alla funzione trackpageview() usata per tracciare i link esterni. In questo caso due visitatori hanno cliccato quel link dalla mia pagina di contenuto:

Quando avete dubbi sui dati che Analytics vi propone, riducete il periodo temporale fino all’unità minima (un giorno) per poter isolare meglio l’eventuale fonte di dubbio.
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Con l’arrivo di un pacco da Amazon.com ieri ho completato il corredo minimo essenziale per poter dire di aver affrontato l’argomento Google Analytics correttamente per quel che riguarda il mondo dei libri fisici. Ho infatti ordinato “Advanced Web Metrics with Google Analytics” di Brian Clifton, che è stato il direttore della sezione EMEA (Europe, Middle East and Africa) di Google Analytics sino all’11 aprile.
Per questo motivo lo ritengo un testo fondamentale, da possedere, e me lo sono procurato appena possibile: è scritto da una fonte autorevole, mi sembra parecchio approfondito ma non per questo oscuro o difficoltoso. A questo punto la bibliografia essenziale è costituita da questi quattro testi:

- “Advanced Web Metrics with Google Analytics
” (seconda edizione) di Brian Clifton, appunto;
- “Web analytics an hour a day
” di Avinash Kaushik; sebbene non sia centrato sullo strumento Google, è considerato da moltissime persone un libro fondamentale di web analytics, in grado di aprire la mente su alcuni aspetti fondamentali di questa disciplina. Io sono ancora abbastanza indietro con la lettura, ma leggo regolarmente il blog di Avinash, lo apprezzo e molte persone che stimo e che l’hanno già letto hanno confermato la mia impressione.
- “Google Analytics 2.0” di Jerry L. Ledford e Mary E. Tyler; l’ho letto e non mi ha entusiasmato, l’ho trovato molto basilare, però io mi ritengo un power user, e questo nulla deve togliere al fatto che se si è in cerca di un testo da cui iniziare a conoscere lo strumento questo è quello che fa per noi. [edit: è adesso disponibile la versione 3.0
, che non ho ancora letto]
- “Espressioni Regolari
” di Marco Beri; è una pocket guide, ma assolve egregiamente alla sua funzione di insegnare velocemente le basi delle regular expression che tanto ci sono utili nella scrittura di filtri avanzati per Google Analytics. Quando avremo bisogno di cose parecchio più complicate probabilmente torneremo su Amazon a ordinare il blasonato “Mastering Regular Expression” di Jeffrey Friedl
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Anche se ho iniziato a inserire contenuti da qualche tempo, oggi inauguro ufficialmente questo progetto, che come è facile intuire dal titolo e dagli elementi grafici verte quasi per intero sul sistema gratuito di web analytics made in Google. In questo momento mi trovo a Stresa e sto tenendo proprio una docenza a proposito di GA: mi sembrava bello e di buon auspicio che i due eventi coincidessero.
Mi piacerebbe che questo diventasse un posto in cui riversare i consigli e i trucchi acquisiti in questi anni, discutere di novità e dare una mano a chi ne ha bisogno.
[image credits: theedinburghblog su flickr]
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
C’è un recente post di Ryan Spoon che scrive 20 consigli per migliorare Google Analytics, anche se la sua tesi è che Google non abbia molti incentivi per farlo, poiché il ritorno dell’investimento per Mountain View è in termini di dati e maggiori vendite di AdWords per chi decide di partecipare al programma.
Ve li traduco qui, in corsivo le mie eventuali considerazioni:
Continua a leggere “20 consigli a Google per migliorare Analytics”
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
All’interno del grande disegno unificatore della web analytics fornita da Google, di cui vi ho parlato recentemente (vedi post “il futuro di google analytics“), al servizio di statistiche di Youtube si poteva rimproverare la mancanza di dati come i referral o le keyword usate per trovare i nostri video. Per chi fa web analytics questi due dati sono molto importanti, e lo sono ancora di più se pensiamo che in un video l’ottimizzazione tradizionale delle keyword puà avvenire solo con un margine di manovra ristretto all’interno dei title del video e della sua descrizione, che Youtube mostra a lato.
Da qualche giorno questi dati vengono mostrati:

Nella voce video correlati troveremo gli identificativi dei video che ci hanno portato visitatori, player incorporato sono le visualizzazioni da siti e blog esterni che hanno incollato il codice embed del nostro video, ricerche su youtube ci mostra le keyword usate nel motore interno per arrivare fino a noi, Link esterni mostra un elenco di domini (non URL esatti) che hanno linkato la pagina contenente il video; in Altro e Youtube (altro) finiscono le situazioni in cui questi dati non sono ricostruibili.
La segmentazione di questi dati è possibile, anche se non proprio intuitiva: dalla pagina principale di Insight è possibile scegliere un arco temporale differente (5 giorni, 1 mese, 3 mesi, 6 mesi, 1 anno, tutto il periodo esistente di statistiche) o una zona geografica specifica, e l’indicazione in alto a destra si modificherà di conseguenza, ad esempio scrivendo “Mostra dati per Europa 15/02/08 – 14/05/08”. Fino a che non cambieremo questa visualizzazione essa sarà mantenuta, per cui i dati dei referral e delle keyword saranno relativi solo all’Europa e agli ultimi tre mesi, nel caso in esempio.
Questa mi sembra una ulteriore conferma della mia teoria che presto o tardi questa interfaccia verrà completamente integrata in Google Analytics
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Processo generale
In genere i dati provenienti da una pagina che contiene il codice di monitoraggio di Analytics (d’ora in poi GATC) vengono processati in questo ordine:
- Un browser richiede una pagina correttamente configurata con il GATC
- il GATC crea e inizializza un oggetto di tracciamento associato con il numero di account inserito nel GATC stesso
- Vengono eseguiti i metodi di tracciatura personalizzati
- Il codice di monitoraggio viene inizializzato e viene eseguito il metodo principale, _trackPageview()
– Viene determinato il dominio
– Vengono scritti o aggiornati i cookie
– Vengono registrate le caratteristiche del browser, le informazioni sulla pagina e i tracciamenti delle campagne (se ci sono)
- Il codice richiede una immagine sui server di Google, __utm.gif
– La gif, composta di un singolo pixel trasparente, viene inviata al browser del visitatore
– L’URL della gif contiene un insieme di parametri derivati dall’inizializzazione del codice di monitoraggio. Questa URL viene registrata nei logfiles del webserver di Google.
– Tipicamente la gif risiede sul server di Analytics, ma nel caso di Urchin stand-alone essa risiede su un server locale del cliente
- Questo insieme di parametri viene estrapolato dai logfiles e viene usato per popolare i database, che poi vengono usati per generare i report nell’interfaccia.

Il riferimento al codice di monitoraggio
Le prime cinque righe del tag script di default che incolliamo nelle pagine servono a determinare dinamicamente il protocollo HTTP usato dalla pagina e a richiamare il javascript appropriato dai server di Google. Tramite queste righe possiamo evitare di preoccuparci di dover cambiare il codice se usiamo un misto di pagine sicure e non sicure (http e https).
L’esecuzione del codice di monitoraggio
Il secondo set di tag javascript include i metodi necessari a eseguire la chiamata per la collezione dei dati. Questa parte del codice deve anche contenere i metodi personalizzati che vogliamo applicare alle pagine del sito. L’ordine di chiamata dei metodi fornito nel codice di default è importante, ed bisognerebbe sempre seguire queste linee guida quando si altera il GATC per le proprie necessità:
- La prima linea dello script di tracking dovrebbe sempre inizializzare l’oggetto di tracking
var pageTracker = _gat._getTracker("UA-123456-1");
Questa prima linea inizializza l’oggetto con l’ID del dominio che forniamo come parametro. I metodi che seguono useranno questo oggetto
- Le righe finali del codice dovrebbero chiamare i metodi _initData() e _trackPageview().
Qualsiasi metodo personalizzato che imposta o inizializza un valore dovrebbe essere inserito prima di _initData().
(traduzione e adattamento di Google Analytics Custom Tracking)
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Google Analytics nasce nel novembre 2005, quando il prodotto precedentemente noto come Urchin viene rilasciato gratuitamente con un nuovo brand, dopo l’acquisizione da parte di Mountain View. Durante questi anni ci sono state piccole migliorie e grandi milestone, la più nota delle quali viene comunemente detta “GA 2.0“; è la versione che vediamo adesso, con i grafici “ispirati da Indiana Jones” e i report ridistribuiti, la selezione temporale grafica o le cartine geografiche nuove.
Negli ultimi tempi però si è notata una accelerazione nell’introduzione di nuove funzioni: un codice di monitoraggio riscritto completamente a oggetti, l’introduzione della comparazione anonima tra siti omogenei e altre migliorie più o meno grandi o più o meno desiderate dagli utenti. In parallelo Google ha introdotto una versione beta privata di MeasureMap per Blogger; MeasureMap era un fornitore di servizi di web analytics mirati ai blogger che riscuoteva un discreto successo, e che poi fu acquistato da Google.
I vecchi utenti di MeasureMap ora possono trasformare il loro account in un Google Account, esattamente come tra poco potranno fare gli utenti di FeedBurner, altro sistema acquistato da BigG per le analisi sui feed RSS. Youtube ha già da tempo unificato gli account, e da poche settimane propone alcuni dati di base sulle visualizzazioni dei video (numero di visualizzazioni, popolarità, provenienza (non il referrer) e provenienza geografica.
Il futuro che vedo io per Google Analytics si sta già delineando con queste mosse: da “semplice” interfaccia per le statistiche web dei nostri siti, Google Analytics diventerà centro unificato per il monitoraggio della nostra presenza nel web, almeno per i servizi Google. Si potrà creare un profilo e specificare se è un sito o un blog, ed eventualmente scegliere se usare l’interfaccia classica o quella di MeasureMap, si potrà associare il feed RSS a Feedburner e i propri video di youtube postati nel nostro spazio web avranno un report direttamente dentro ai contenuti dei profili. Non so dire esattamente quanto tempo ci vorrà per unificare il tutto, ma la strada mi sembra assolutamente quella.
(image credits qmonic on flickr)
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Google Analytics è un sistema di web analytics lato client, cioè viene scaricato ed eseguito un piccolo javascript sul browser di ogni visitatore del sito in cui il codice di monitoraggio è installato (ammesso che esegua javascript, naturalmente). Tra le varie operazioni che questo javascript esegue prima di inviare i dati al server collettore di Google, c’è la creazione o l’aggiornamento di 4, 5 o 6 cookie, a seconda del grado di personalizzazione del codice di monitoraggio. I cookie sono piccoli file di testo che risiedono nel computer del visitatore e che contengono informazioni temporanee sul sito web o sul visitatore.
Vediamo in dettaglio come si chiamano e cosa fanno: Continua a leggere “I cookie di Google Analytics”
$post_level = get_post_meta(get_the_ID(), 'level', true);
if ($post_level) { ?>
SemaforoQuesto semaforo indica il livello difficoltà del post
if ($post_level == '1') { ?>

} ?>
if ($post_level == '2') { ?>

} ?>
if ($post_level == '3') { ?>

} ?>
} ?>
Quando si installa il tracking code di Google Analytics su un sito si spende molto tempo ad assicurarsi che il codice sia presente su ogni pagina che vogliamo tracciare, su ogni elemento e su ogni download, nel caso ci interessino in modo specifico anche questi due ultimi elementi. Quello che nella quasi totalità dei casi si tralascia è l’installazione del codice anche sulle pagine di errore 404.
Le pagine di errore 404 sono particolari pagine che il webserver mostra ai navigatori quando richiedono una risorsa che non esiste in quel sito; l’esempio tipico è quando si digita in modo errato il nome di una pagina.

Le persone più attente le conoscono e inseriscono il codice tradizionale anche su quelle, ma pochi sanno che con un piccolo tuning si può ottenere un risultato ancora maggiore: fare in modo che la pagina di errore, oltre che venire conteggiata nei report, ci dia una informazione: in particolare quale era la pagina originale richiesta. Questo per far si che noi possiamo apportare le opportune correzioni al nostro sito ed eliminare il disservizio all’utente. Per far questo bisogna modificare come segue il codice di tracciamento, nella sola pagina 404 che il webserver usa come modello (su Apache si trova in /error_docs/not_found.html e su IIS nelle proprietà del sito – messaggi di errore personalizzati – errore HTTP 404 – modifica proprietà):
<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">
var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._initData();
pageTracker._trackPageview("/404.html?page="+document.location.pathname+document.location.search);
</script>
404.html è il nome della pagina modello di errore che il webserver fornisce
document.location.pathname è il nome della pagina richiesta
document.locarion.search sono i parametri eventuali della pagina richiesta.
Ovviamente, anche se si tratta di una pagina fittizia creata da GA tramite la funzione trackpageview(), essa è segmentabile esattamente come le altre, per cui è possibile conoscere la provenienza, la parola chiave di arrivo se c’è e tutte le altre informazioni tipiche dei report…