Google Analytics in 30 secondi

Per i prossimi 18 mesi i miei clienti possono dormire sonni tranquilli, ho preso la certificazione individuale di Google Analytics, passando il test con uno score del 94%

Ecco il mio certificato pubblico

Se il numerino in basso a sinistra nel certificato è un progressivo, significa che sono la 186a persona al mondo che lo ottiene; sinceramente pensavo che sarei arrivato oltre il migliaio. Naturalmente l’equazione sei certificato = sei migliore non è vera, ma questo non toglie che passare l’esame era un atto dovuto verso me stesso e verso le persone con le quali collaboro e collaborerò.
Eccovene una copia 🙂

Se avete un account Adwords collegato a quello di Analytics è probabile che abbiate sentito parlare del famoso doppio filtro per avere le chiavi cercate invece di quelle acquistate. Le istruzioni per creare il filtro sono in questo post su semvironment, e una discussione sull’argomento è sul forum Seonida.
Non mi dilungo sul filtro perché non è oggetto di questo post.

Una domanda che mi è stata fatta ieri è questa:

Il Campo A del filtro personalizzato del primo passo di estrazione delle chiavi cercate, tira fuori dal Referral la sequenza (\?|&)(q|p|qs|_nkw)=([^&]*)

Il Campo B tira fuori dal Mezzo della Campagna cpc|ppc
L’output finisce in Campo personalizzato 1, con la stringa $A3

Ma allora, il campo B a che serve, visto che nel campo personalizzato 1 non si prende il considerazione?

La risposta sta in questa immagine, presa dal post di semvironment

Il campo B in effetti guarda dentro al mezzo della campagna e capisce se questo mezzo è cost per clic o pay per clic, ma non fa altro. L’output di quella parte di filtro non solo non viene estratto, ma non verrebbe nemmeno salvato per un uso successivo nè trascritto in un altro campo. A tutti gli effetti quello è un campo che potremmo definire “di controllo“, poiché è un campo obbligatorio ma non genera un output. Se però la condizione non è soddisfatta, se l’output fosse vuoto, il filtro non agirebbe, perché appunto l’impostazione è “campo B obbligatorio”.

Nello specifico un controllo sul solo referrer non è sufficiente, perché non è affatto scontato che il referrer (un qualsiasi referrer) non contenga almeno un parametro tra q, p e qs. Più difficile, ma non impossibile, _nkv…
Il campo B quindi serve solo ed esclusivamente a prevenire che un referrer con uno di quei parametri possa mettere erroneamente in azione il filtro.

Se devo dare un parere personale il nome non mi sembra azzeccatissimo, fatto sta che * Google ha lanciato un test a pagamento per certificare i singoli individui come “professionisti” dello strumento di web analytics made in Google.
Il test online costa 50 dollari e il relativo certificato in caso di successo ha una validità di 18 mesi. Tramite questo programma Google intende ampliare la base di utenza in grado di aiutare il mondo ad usare lo strumento; al momento infatti la certificazione di GAAC (Google Analytics Authorized Consultants) è disponibile solo per le aziende e non per i singoli, ancorché professionisti o aziende personali, e la lista dei requisiti è anche abbastanza “tosta”.

Nei prossimi giorni cercherò di trovare il tempo per seguire i video propedeutici e per dare l’esame, poi vi saprò dire com’è andata.
Ne approfitto anche per fare i complimenti – in ritardo – a Web Ranking, che da un mese circa è diventata la terza azienda italiana certificata GAAC, dopo BitBang e CoreMetrics 🙂

[ * Ho chiaramente frainteso il senso. IQ sta per Individual Qualification, e non per Intelligence Quotient come pensavo. Il fatto che “IQ” fosse vicino a “test” è stato fuorviante 🙂 ]

Durante i giorni scorsi, poco prima del Festival di Sanremo, all’indirizzo www.rai.it è andato online il nuovo portale internet della televisione pubblica italiana, che fa uso della tecnologia Microsoft Silverlight per lo streaming dei contenuti. Per chi non lo sapesse, Silverlight è il “concorrente” di Adobe Flash per quel che concerne le cosiddette “Rich Internet Application”, ovvero quelle applicazioni – soprattutto web – sofisticate che difficilmente riescono ad essere realizzate con i canonici HTML, CSS e Javascript.

Nei sistemi Windows, se non erro, Silverlight dovrebbe essere installato insieme agli aggiornamenti di Miscrosoft Update, ma è sempre comunque possibile installarlo a mano la prima volta che si tenta di accedere ad un contenuto realizzato con quella tecnologia. Google Analytics contiene un intero report dedicato a Flash player che riepiloga quali versioni di Flash sono installate nei browser dei visitatori e in che percentuale essi hanno visitato il sito, ma non ha nessun tipo di report per Silverlight. Se avete la necessità di conoscere anche le percentuali delle due versioni esistenti di Silverlight, Hello Szabi! ha migliorato un precedente script di Mark Monster per farlo.

Dopo aver scaricato e uploadato sul sito lo script ufficiale per il test della versione Silverlight (fornito da Miscrosoft stessa) sarà sufficiente aggiungere queste righe di codice

<script type="text/javascript" src="silverlight.js"></script>
<script type="text/javascript">
  var hasSilverlight = Boolean(window.Silverlight); 
  var hasSilverlight1 = hasSilverlight && Silverlight.isInstalled('1.0'); 
  var hasSilverlight2 = hasSilverlight && Silverlight.isInstalled('2.0'); 
  if (hasSilverlight1) { pageTracker._trackEvent("silverlight", "v1"); }
  if (hasSilverlight2) { pageTracker._trackEvent("silverlight", "v2"); }
  if (!hasSilverlight1 && !hasSilverlight2) { pageTracker._trackEvent("silverlight", "none"); }
</script>

subito DOPO la chiusura del tag SCRIPT di Google Analytics. Nella sezione eventi del vostro profilo troverete un evento di nome “silverlight” con tre azioni: none, v1 e v2. “none” è naturalmente il numero di visitatori che non hanno il plugin installato, mentre v1 e v2 sono rispettivamente il numero di coloro che hanno la prima e la seconda (l’ultima disponibile al momento in cui scrivo) versione

Una delle domande che mi viene rivolta più spesso – e che noto essere un evergreen tra le frasi di ricerca dei visitatori in arrivo – riguarda la presenza di due o più codici di monitoraggio di Google Analytics sulla stessa pagina/sito. Con la vecchia versione dello script, quella che fa riferimento a urchin.js, le cose erano leggermente più complicate di adesso, ma non ne parleremo. Cosa aspettate ad aggiornare il GATC a ga.js? 🙂

Poiché il nuovo codice di monitoraggio è scritto seguendo la logica della programmazione a oggetti, per inviare i dati a due profili differenti è sufficiente creare due distinti oggetti di tracciamento. In GA gli oggetti di tracciamento sono quelli identificati dalla riga di codice
var pageTracker = ...

In effetti quando nei post ci si riferisce a pageTracker si commette una imprecisione: quello è il nome dell’unico oggetto creato per definizione dal codice che Google ci mette a disposizione, ma nulla vieta di cambiargli nome o, appunto, crearne più d’uno. Ecco allora che un codice fatto 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">
var pageTracker = _gat._getTracker("UA-12345-1");
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-99999-3");
MarcoTracker._trackPageview();
</script>

è perfettamente legale e funzionante, ed invierà i dati all’account 12345 profilo 1 e 99999 profilo 3. Se la necessità è quella di inviare dati a più di due account si procederà di conseguenza creando ulteriori oggetti di tracciamento con nomi differenti. Questi oggetti sono (o meglio, dovrebbero essere, ma lo vediamo più tardi) completamente indipendenti l’uno dall’altro, per cui è possibile aggiungere funzioni al primo piuttosto che al secondo.

Nella realtà le cose sono leggermente differenti, e Lunametrics ci spiega perché: nonostante i codici di tracciamento facciano riferimento ad account differenti, i cookie – che ricordo sono scritti in base al dominio e non all’account Analytics – sono gli stessi per tutti e due (o più) oggetti di tracciamento.
Tra i casi di “sicuro insuccesso” relativi alla presenza di più codici di monitoraggio in una stessa pagina, Lunametrics ne cita tre che vale la pena di riportare:

1 – Codici differenti

var pageTracker = _gat._getTracker("UA-11111-1");
pageTracker._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

var MarcoTracker = _gat._getTracker("UA-22222-1");
MarcoTracker._trackPageview();

Nell’esempio di Lunametrics il primo oggetto di tracciamento include le funzioni _setAllowHash e _setAllowLinker e il secondo no. In questo caso i due oggetti tentano di scrivere lo stesso cookie con intenzioni e formati diversi.

2 – Pagine differenti

Nel caso in cui uno dei due codici non sia inserito in tutte le pagine, magari in seguito a una condizione if impostata male o non realizzata, alcune pagine vengono tracciate in un account e in un altro no. Il codice di tracciamento “in difetto” vedrà i cookie che erano originariamente stati creati da una pagina che non ha quel codice. La prima pageview registrata dal secondo codice avrà informazioni di referrer diverse, poiché penserà di essere la prima pagina della visita mentre in realtà è la seconda, e così via…

3 – Segmenti personalizzati in base a _setvar()

Il segmento personalizzato “Valore definito dall’utente” viene impostato tramite la funzione _setVar() e immagazzinato nel cookie __utmv. Siccome i due codici usano gli stessi cookie, un segmento personalizzato creato dal primo codice è automaticamente creato e disponibile anche per il secondo. Questo comporta l’impossibilità di avere, ad esempio, un valore impostato su “loggato/non loggato” per il primo oggetto e “maschio/femmina” per il secondo. Poiché l’esecuzione di javascript è sequenziale nella pagina, il secondo codice sovrascriverà sempre il cookie e l’unica informazione disponibile per il segmento, alla visita/pagina successiva, sarà quella impostata dal quell’oggetto di tracciamento.

Se decidete di implementare più codici di monitoraggio di Google Analytics su uno stesso sito, o una stessa pagina, dovete prestare attenzione alle possibili conseguenze.
[photo credit: oskay su flickr]

Ieri sul blog ufficiale di Google Analytics è comparso un post che illustra l’introduzione di un nuovo segmento personalizzato predefinito per studiare le visite effettuate tramite Iphone e come eventualmente crearne uno che includa Iphone e sistemi basati su Android, considerati di fascia alta. Questi nuovi segmenti saranno probabilmente fondamentali in futuro, mentre al momento – almeno in Italia dove Android nemmeno è commercializzato – i numeri sono piuttosto bassi. L’ho usato su siti di clienti da 9000 visite al giorno e il segmento è irrisorio.

Può essere allora utile allargare la base del segmento e includere anche i cellulari meno “evoluti” ma maggiormente diffusi. Per fare questo Bryson Meunier propone una super espressione regolare da inserire all’interno di un segmento basato sulla dimensione “Risoluzione dello schermo”. L’espressione regolare è questa
(^[1-2]?[0-9]?[0-9]|^3[0-1][0-9]|^320)x([1-3]?[0-9]?[0-9]$|4[0-7][0-9]$|480$)

e include tutte le risoluzioni fino a 320×480 pixel.

Questo segmento produce risultati di maggiore interesse statistico, anche se ha finalità diverse, ma al momento mi sembra il migliore tra i due, posto che non abbiate un sito di particolare interesse per gli utenti del melafonino 🙂

WordPress, che piaccia o meno, è ormai una delle più note piattaforme di Content Management; nato come piattaforma di blogging, col tempo ha incontrato un sempre maggiore numero di estimatori che lo hanno usato e lo usano anche come sistema di gestione dei siti, anche grazie agli innumerevoli plugin che la comunità sviluppa in tal senso. Questo stesso blog è realizzato tramite il prodotto della Automattic, così come il mio blog personale e tutti quelli che ho creato da quando mi interesso di questo modo di pubblicare contenuti.

Molti, moltissimi blog creati con WordPress usano Google Analytics per tenere traccia di quel che accade sulle pagine, ma non tutti lo sfruttano al meglio. Ecco perché ho pensato a un post riassuntivo con alcune indicazioni che ritengo utili.

Usate un plugin per GA

Sembra banale, ma spesso leggo di persone che incollano a mano il codice nel file footer.php del template. Questa operazione ha solo svantaggi: innanzitutto se cambiate il tema dovrete ricordarvi di rifare l’operazione. Se avete un tema che si auto aggiorna è ancora peggio, perché dovrete reincollare il codice di GA dopo ogni update. Inoltre il codice così posizionato viene eseguito sempre e comunque, ovvero viene eseguito anche quando siete voi a visitare il vostro sito (mentre è noto che si dovrebbe evitare di conteggiare le proprie visite).
La grande forza di WordPress sono i plugin, estensioni dell’applicazione che si occupano di un aspetto specifico che solitamente non è incluso nel prodotto originale. Mi sento di consigliarvi due possibili plugin, sebbene ne esistano una moltitudine:

• Google Analytics for WordPress di Joost de Valk. [update: sono passato a questo] Ha tutte le opzioni che ci si aspetta da un plugin serio per Google Analytics, ed inoltre è sviluppato da una persona che si è sempre distinta nella blogosfera per essere un esperto di SEO, Google Analytics e WordPress (ha realizzato anche altri plugin). Un plus fondamentale è che può tenere traccia di Google Images come fosse un organico invece di un referrer, e quindi di tracciare anche le keyword inserite lì.
• Google Analyticator di Ronald Heft. E’ quello che uso io, e tra le altre cose permette di includere righe aggiuntive di codice direttamente dall’interfaccia; utile quando si devono aggiungere funzioni al codice di monitoraggio.

Entrambi i plugin possono disabilitare con un solo click il tracciamento degli utenti loggati, cosicché i dati inviati ai server collettori di Google siano già “puliti” senza bisogno di filtri sull’IP o sul cookie.
Un altro plugin interessante è RSS link tagger, che aggiunge ai link presenti nel feed i parametri necessari ad essere tracciati come campagna (solo se non avete anche il plugin Feedburner Feedsmith)

Create un goal/obiettivo per i commenti

Non è detto che sia l’unico, ma indubbiamente un blog dovrebbe avere come obiettivo almeno quello di instaurare una discussione con i propri lettori, e di conseguenza Google Analytics dovrebbe tracciare il risultato ottenuto. Per fare questo ci sono due strade: la prima è quella di aggiungere un evento onSubmit alla form di invio dei commenti, che di solito si trova nel file comments.php, aggiungendo

onsubmit="javascript:pageTracker._trackPageview('/commenti/commentoinviato');"

L’obiettivo da configurare in GA avrà corrispondenza principale (ma anche esatta funziona all’uopo), nome Commento e valore 1.0, in questo modo:

L’altro modo è descritto da Liviu Taloi, un consulente ecommerce rumeno, ed è leggermente più complicato: si tratta di inserire una variabile all’interno dell’url che viene mostrato dopo aver postato un commento (oppure di scrivere un cookie per via di una funzione nuova di wordpress 2.7) e di modificare il GATC con delle condizioni in php che riscrivono il nome della pagina tracciata se è stato lasciato un commento.

Monitorate la ricerca interna

E’ una cosa fondamentale nei siti, lo è ancora di più per i blog: la ricerca interna è fonte di preziose informazioni sui contenuti che gli utenti richiedono e che – evidentemente – non sono facilmente reperibili. Per i blog aggiungiamo che per la conformazione cronologica inversa i post più vecchi sono sepolti nell’archivio e spesso anche a diversi click di distanza dalla pagina principale dell’archivio, e abbiamo compreso perfettamente quando sia importante capire cosa viene cercato tramite il motore di ricerca interno. Poiché non ha senso riscrivere un ottimo articolo, mi limito a segnalare il post di Simone Carletti, che dice tutto quel che va detto!

Analizzate le pagine 404

Alcuni temi hanno un file che si chiama 404.php, che serve a personalizzare la pagina che viene mostrata all’utente in caso di contenuto non trovato (codice di errore HTTP 404). Se il vostro tema non ha il file specifico, significa che l’errore 404 viene gestito come un caso particolare di pagina singola, ma se avete deciso di usare un plugin per iniettare il codice di GA, il mio consiglio è quello di crearne una. Non costa molta fatica, seguendo le istruzioni della guida ufficiale di WordPress:
potete copiare la pagina 404.php presente nel tema di default e sperare di essere fortunati, oppure potete copiare il file index.php e rinominarlo 404.php, dopodiché cancellare tutta la parte relativa al loop dei post e inserire un messaggio di errore personalizzato. Il report relativo alle pagine non trovate si ottiene dal rapporto “contenuti per titolo” cercando “page not found”. Da lì sarà poi possibile effettuare segmentazioni e analisi mirate a capire da dove vengono le visite che finiscono in pagine di errore ed eventualmente a come rimediare.

Usate la riscrittura dei permalink e il dettaglio contenuto

WordPress consente in maniera molto agevole di abilitare la riscrittura degli URL (url rewrite) dei link permanenti, tramite il menu Settings -> Permalinks. La struttura più usata è quella “day and name” che corrisponde ai parametri
/%year%/%monthnum%/%day%/%postname%/

ma nulla vi vieta di usarne una personalizzata. Con il permalink che ho indicato, ad esempio, gli archivi per anno e mese si trovano agli indirizzi www.dominio.it/2007 o www.dominio.it/2008/04 (aprile 2008). Tramite il report “dettaglio contenuto”, che vi ricordo raggruppa tutti gli url sotto una stessa cartella, sarà quindi molto facile confrontare le performance di tutti i contenuti sotto a cartelle anni o mesi differenti.
Lo stesso discorso può essere applicato alle categorie e ai tag, che vengono ugualmente riscritti nella forma www.dominio.it/categoria e www.dominio.it/tag e permettono di analizzare le performance globali di contenuti trasversali rispetto all’ordine temporale.

Ciao Marco, ieri cercavo di capire quali sono le keyword grazie alle quali gli utenti arrivano direttamente su alcune pagine indicizzate da Google. Sono andato su “content” – “top landing page”. La pagina che mi interessa ha 275 entrances. e fino a qui tutto ok.

Successivamente ho selezionato la pagina e dopo “entrance keyword”. Quindi ho trovato che la pagina in questione è raggiunta attraverso le keyword x,y,z,ecc.. ma con un totale di visite enormemente superiore a 275 (10 volte tanto). Quel numero (2800 circa) mi sembra il numero di utenti che hanno visto quella pagina (dopo essere arrivati sul sito attraverso le varie kw), piuttosto che gli utenti che sono “landati ” sulla pagina grazie a quelle kw.

E’ un caso arbitrario, purtroppo. Io ho alcuni profili in cui tutto combacia perfettamente e altri che si comportano come il tuo. Parte della spiegazione secondo me è riconducibile al discorso delle dimensioni, parte invece è proprio legata all’architettura del sistema. Una conferma mi viene da questa discussione sul forum:

There is no way in Google Analytics to create a report that shows two dimensions at a time (like keyword and landing page) side by side. You can only drilldown from a top level dimension to a lower level dimension (even in a custom report).

In realtà nei custom report si possono annidare più dimensioni, ma il sistema esclude automaticamente le “combinazioni impossibili”, secondo questa tabella. La combinazione che cerchi tu, keyword per pagina di ingresso, è attualmente una di quelle off limits.

(traduzione e adattamento di How does Google Analytics calculate data?. Nei report italiani “metriche” è tradotto come “parametri”, ma la speranza è che prima o poi venga effettuata la correzione).

Metriche e dimensioni

Metriche e dimensioni sono i mattoni fondamentali di tutti i report di Google Analytics. Infatti, quando usate i custom report, selezionate le singole metriche e dimensioni per disegnare i vostri rapporti. E’ più semplice capirle osservando un report, perciò consideriamo il pannello Panoramica Visitatori mostrato qui sotto

Una metrica è un riassunto numerico del comportamento degli utenti sul vostro sito. Per esempio pagine viste è una metrica che riassume il totale delle pagine viste per una pagina particolare. Frequenza di rimbalzo riassume la percentuale di visite di una sola pagina vista sul sito. Visite riassume il numero di sessioni aperte sul sito. Quando le metriche sono visualizzate senza una dimensione, forniscono informazioni su tutto il sito, o in altre parole valori aggregati. Potete vedere queste metriche aggregate nei pannelli riassuntivi delle maggiori sezioni di report. Il report Panoramica Visitatori mostra le metriche applicate all’intero sito come ad esempio:

• visite
• visitatori unici assoluti
• pagine viste
• frequenza di rimbalzo

Una dimensione è un dato o un campo tipicamente in formato stringa. Le dimensioni di per sé non sono significative, ma quando associate alle metriche, possono dividere o segmentare la metrica dal punto di vista di quella dimensione. In generale, le dimensioni rappresentano la più grande categoria di dati usata per guardare alle metriche da un punto di vista significativo. Per esempio, quando si guarda alla Panoramica Visitatori, vedrete che la sezione Profilo Tecnico indica le Visite come metrica, ma usa la dimensione Browser per dividere le visite al sito in quella dimensione. Potete anche notare che un’altra dimensione – Velocità di connessione – è anch’essa associata alla metrica Visita per dividere le visite in base alla velocità della connessione. Quindi, sebbene sia utile vedere che ci sono oltre 10 milioni di visite al sito, è anche importante analizzare questa metrica dal punto di vista dei browser degli utenti e delle velocità di connessione.
Continua a leggere “Come vengono calcolate metriche e dimensioni”

Come detto nel post precedente, la funzione che si usa in Google analytics per controllare la durata di una sessione di visita, ovvero il tempo massimo che può intercorrere tra la vista di due pagine prima che la visita venga considerata (forzatamente) conclusa, è _setSessionTimeout(stringa).

La funzione accetta come parametro una stringa – sebbene in realtà si tratti di numeri – e precisamente vuole il numero di secondi trascorsi i quali la sessione verrà considerata conclusa. Ad esempio aggiungendo prima della chiamata a trackpageview() la riga

pageTracker._setSessionTimeout(“900”);

si imposteranno sessioni di 15 minuti (60*15 = 900).
Questa funzione va maneggiata con cura, non tanto perché distruttiva nei confronti dei dati inviati, ma poiché è in grado di variare pesantemente i risultati delle analisi. Impostare sessioni molto brevi porta fisiologicamente ad aumentare il numero di visite (e di visitatori di ritorno), mentre allungarle sortisce l’effetto inverso. Usatela se ne avete realmente bisogno perché conoscete bene il tipo di utenza del vostro sito e perché avete esigenze particolari.