Google Analytics in 30 secondi

A margine del post di aggiornamento sul metodo per tracciare il posizionamento sono venuto a conoscenza di un altro strumento per Google Analytics che i SEO penso troveranno utile. Si tratta di un unico file javascript che tramite gli eventi – quindi senza inflazionare il numero di pagine viste – si occuperà di:

• tracciare il numero di referral dai diversi motori: Google, Yahoo, AOL, Live, MSN
• distinguere gli arrivi dai diversi siti Google, compresi i verticali come Google News, Reader, eccetera
• trovare il posizionamento medio per ogni estensione nazionale di Google
• tirare fuori le keyword e altre informazioni utili dagli arrivi via Google Immagini

Importante da tenere a mente: Anche questo sistema, per quel che concerne il posizionamento, agisce solo ed esclusivamente sui referrer generati dai datacenter google che hanno già subito l’aggiornamento, cioè quelli i cui indirizzi delle pagine di risultato hanno il cancelletto #

Per usarlo è sufficiente scaricare il file seopositionplus.js dal sito di abtesting, copiarlo sul proprio server ed aggiungere la riga

<script src="seopositionplus.js" type="text/javascript" language="javascript"></script>

subito dopo il codice di tracciamento di Analytics, eventualmente modificando l’indirizzo del file secondo necessità.
La schermata dentro agli eventi si presenterà all’incirca così:

e la parte relativa al posizionamento è dentro a “SEO Google Position”. Dentro a “SEO Google TLD” ad esempio c’è la parte relativa agli arrivi tramite le estensioni nazionali del motore di ricerca.
Come giustamente fanno notare nei commenti del post, è doveroso ricordarvi che un evento conta come un’azione, per cui l’uso di questo sistema avrà un impatto decisamente pesante sul vostro bounce rate. Il mio consiglio è quello di creare un altro profilo (non un profilo copia, che condivide lo script di tracciamento, proprio un altro profilo).

Anche se molti di voi non lo sanno, il mio lavoro principale è quello di web developer, e per questo ho assolutamente presenti e ben chiari i problemi che si incontrano quando si vuole che la resa grafica di un sito sia assolutamente coerente in tutti i principali browser sul mercato. Questo comprende anche Internet Explorer, che nonostante abbia fatto alcuni passi avanti nelle versioni 7 e 8, risulta ancora problematico per molti versi.
E’ vero che ci sono buone pratiche, hack, prassi comuni e anche strumenti che aiutano a minimizzare il lavoro da svolgere, ma allo stato attuale delle cose è sempre necessario controllare e in molti casi mettere mano al lavoro per aggiustare la resa su IE.

Per questo motivo ieri Google ha presentato Chrome frame, un plugin open source che si occupa di far usare al browser Microsoft il motore di visualizzazione delle pagine di Chrome, che poi è Webkit/Safari. In questo modo, ad esempio, Internet Explorer passa il test Acid3 con un punteggio di 100/100 (l’acid test è una prova di compatibilità con gli standard del web) e ogni sito si vedrà in uguale maniera sia su Chrome sia su Safari sia su Internet Explorer.

Poiché l’installazione per gli utenti è su base volontaria – anche se la si può suggerire automaticamente – per un webdesign potrebbe essere molto utile sapere quanti degli utenti che visitano un sito usano il Chome framework; ho quindi ideato un segmento avanzato che risponde a questa domanda.

Poiché però Google Analytics non tiene traccia dello User-Agent, sarà necessario aggiungere la riga

pageTracker._setVar(navigator.userAgent);

subito dopo la chiamata a _trackPageview().

Dopodiché bisogna accedere ad Analytics, cliccare sui segmenti avanzati, poi “crea un nuovo segmento personalizzato”, e poi bisogna impostare le cose come in figura:

Ovvero dobbiamo selezionare solo le visite che contengono nel Valore Definito dall’utente (cioè dove vanno a finire i dati impostati via _setVar) il valore chromeframe, che viene aggiunto allo user agent di Internet Explorer dal programma di Google.

Già che ci siete create anche questo segmento:

che non è altro che il numero di utenti che usano Internet Explorer.
Quando questo segmento avrà lo stesso numero di visite del segmento chromeframe (potete selezionarli entrambi e verificare lo scostamento), potrete dimenticarvi del tutto di aprire IE per controllare la resa dei vostri prodotti web 🙂

Marco, non mi ricordo mai quali sono i parametri obbligatori quando si crea una URL per una campagna di Google Analytics

Tranquillo, sei solo l’ultimo della serie, è una cosa comune (e comunque anche io ogni tanto devo dare una rinfrescatina 🙂 ). Come ho detto nel post dettagliato in cui descrivo come si gestiscono le campagne, i parametri obbligatori sono utm_campaign, utm_medium, e utm_source.

Ma che mondo sarebbe se qualcuno non si fosse preso l’onere di controllare se questa affermazione è totalmente vera? Così hanno fatto quelli di Lunametrics, arrivando a una conclusione inaspettata: fintanto che si include utm_source, la campagna funzionerà e il cookie __utmz verrà aggiornato correttamente, se invece il parametro manca il cookie non viene modificato affatto (esattamente come avviene usando il parametro utm_nooverride=1). L’inclusione del solo utm_source genera correttamente un record nel report campagne, attribuendo però al mezzo e alla fonte il valore di (not set).

Il consiglio dei ragazzi inglesi è quindi di mettere sempre per primo nell’URL l’utm_source, in modo che siano minimizzate le possibilità che esso venga troncato (si pensi ad esempio a un client email che fa l’accapo automatico dopo un tot di caratteri).

La cosa veramente buffa è che ho avuto un esempio sotto gli occhi per molto tempo, ma non ci ho mai fatto caso. Al vecchio URL cui puntava la campagna di Google Acqua che ho ospitato a inizio anno, e che è da poco tornata online, mancava del tutto il parametro utm_campaign, a meno che non fosse generato automaticamente lato server assumendo che tutti gli ingressi a quella pagina fossero provenienti dalla stessa – e unica – campagna.

André Scholten ha scritto su yoast.com un aggiornamento del suo metodo per tracciare il posizionamento delle parole chiave nelle SERP (le pagine dei risultati) di Google. E per me è doveroso darvene comunicazione, in modo che anche voi possiate fare le relative modifiche, se avevate letto soltanto il mio post relativo. L’aggiornamento è necessario perché Google sta introducendo un nuovo url delle SERP che veicolano traffico verso i siti, basato su tecnologia AJAX, che riporta come informazione aggiuntiva anche la posizione del link al momento del click.

Nel caso in cui stiate mettendo il piedi il metodo per la prima volta, vi ricordo che è necessario creare un profilo-copia, perché i primi due filtri sono distruttivi nei confronti di tutto il traffico che non proviene da Google organico. Una volta fatto il nuovo profilo-clone, si possono creare e applicare i primi due filtri descritti nel vecchio post (Ranking 1 e Ranking 2), e dopo aggiungere il terzo

Ranking 3:
filtro personalizzato – avanzato
campo A -> estrai A: Termine della campagna (.*)
campo B -> estrai B: Referral (\?|&)cd=([^&]*)
Output in -> Constructor: Definito dall’utente $A1 (posizione: $B2)
Campo A obbligatorio: si
Campo B obbligatorio: si
Sostituisci campo di output: si
maiuscole/minuscole: no

(che in realtà noi conosciamo già, ve l’ho descritto in questo post).
Questi tre filtri insieme mostrano il posizionamento, e la cosa vale per tutti coloro che cliccano un risultato dopo aver fatto una ricerca su un datacenter che è già stato aggiornato. Le SERP che implementano il cosiddetto “universal search” non sono da meno. Nel post su yoast, André fa l’esempio di una ricerca per “pizza Amsterdam”, la cui parte superiore della pagina dei risultati è monopolizzata da una mappa e dai risultati del Local Business Center. Un eventuale click sul primo risultato “classico” porterà come posizione 11, e non 1, perché Google li elenca così (è una cosa che avevamo già trattato parlando del tracciamento delle immagini nelle SERP).

Discorso inverso invece per i sitelink, che inviano un numero compreso tra 1 e 8 a seconda della posizione in cui si trovano all’interno della voce che li contiene. Se siete fortemente interessati ai sitelink, André propone di creare un ulteriore profilo-copia, applicare i tre filtri menzionati sopra, e di aggiungerne uno (che si chiama erronamente Ranking 5 solo perché era presente un quarto filtro eliminato dopo alcuni commenti di attenti lettori):

Ranking 5:
filtro personalizzato – includi
Campo filtro: Referral
Pattern filtro: oi=(oneline_sitelinks|smap)

oneline_sitelinks sono i sitelink su una riga, smap quelli “classici” su due colonne. Includendo questo filtro gli unici risultati che vengono mostrati nel profilo sono quelli relativi ai sitelink, pertanto vi permette di fare accurate analisi su quali e quanto essi vengano cliccati.

Come chicca finale – che non conoscevo – André dice che le ricerche fatte sulle declinazioni nazionali di Google (quindi tutte le versioni tranne google.com) hanno un ulteriore parametro meta= che indica quale tra le tre scelte è stata fatta dal navigatore sulle opzioni “Cerca: nel web, pagine in italiano, pagine provenienti da: Italia”

Creando l’ennesimo profilo-clone ed applicando il filtro

Web/Lingua/Paese
filtro personalizzato – avanzato
campo A -> estrai A: Referral (\?|&)meta=([^&]*)
Output in -> Definito dall’utente $A2

avrete anche la possibilità di capire in che percentuale vengono usate quelle tre opzioni per arrivare al vostro sito. Avete visto a quante domande si può dare risposta con Google Analytics? 😉

La primissima funzione richiesta dagli utenti quando uscirono le API ufficiali fu la possibilità di interrogare il database di Google Analytics riguardo gli eventi tracciati nei profili; forse in effetti fu la seconda, ma a pochissima distanza, segno che questa era una esigenza reale e molto sentita. Ci sono voluti cinque mesi quasi esatti, ma adesso si può fare. Il tracciamento degli eventi è stata una delle novità più apprezzate nel corso dell’esistenza di GA, ed è stato quindi naturale che Google abbia lavorato per includerlo nelle export API. A poco a poco tutte le informazioni disponibili nell’interfaccia di Analytics saranno disponibili per l’export, e alla fine sarà anche possibile non accedere affatto all’indirizzo www.google.com/analytics.

Un’altra novità nelle API è la possibilità di estrarre i dati di navigazione (gruppo di report “contenuti”, sezione “analisi di navigazione”) degli utenti, affinché sia possibile utilizzarli nei propri strumenti o report. Il post ufficiale fa l’esempio di report di overlay customizzati (e sicuramente migliori di quello di Google, che lascia molto a desiderare). Infine, per i tecnici, la lunghezza massima della stringa di filtro è stata portata a 128 caratteri (dai 32 precedenti), e questo permetterà di comporre espressioni più complesse.

Una piccola nota sui report che lasciano a desiderare: oltre all’overlay, un altro della serie è “percorso obiettivo inverso”, ma da qualche giorno su di esso compare questo avviso (tnx to Marco Ziero):

Il rapporto del percorso indiretto per l’obiettivo verrà sospeso a breve.

Se notate c’è scritto “sospeso”, e questo mi dà fiducia riguardo al fatto che prima o poi verrà fatto un redesign del report, che così com’è è utile solo fino a un certo punto. L’obiettivo è sempre quello di migliorare!

Phil Pearce, ai più noto come PPC Guru, ha postato sul forum di supporto di Google Analytics alcune interessanti precisazioni riguardo la funzione _trackEvent, che viene utilizzata per tracciare interattivamente eventi senza incrementare il numero di pagine viste.
Sono quattro precisazioni “tecniche”, ma vi può essere utile conoscerle sia che mettiate mano direttamente al codice sia che lo facciate fare a qualcuno. Eccole:

1. il parametro opzionale “valore” deve essere per forza un intero, ovvero non avere decimali.
2. Poiché è un valore intero, non c’è bisogno di racchiuderlo tra gli apici, come si fa con le stringhe.
3. Virgole, virgolette e apici contenuti nei valori vanno preceduti dal carattere di escape \ (backslash). Ad esempio se passiamo il valore Genova\,Italia
4. Se si usa _trackEvent e _trackPageview insieme è necessario porre attenzione all’ordine di apici e virgolette, specie quando le funzioni sono racchiuse in un evento onclick.

In effetti ogni tanto la documentazione ufficiale non è allineatissima, ma ho sempre riscontrato che segnalando gli errori questi venissero sistemati.

E così ieri Adobe ha proposto l’acquisizione di Omniture, che è solo il più grande fornitore di soluzioni web analytics del pianeta. Avrete sicuramente sentito parlare di Omniture, ne abbiamo parlato da poco nel post sull’evoluzione dei fornitori di sistemi di WA. Il costo dell’operazione è stimato in 1,8 miliardi di dollari.

La domanda che tutto il mondo si fa è ovviamente “cosa se ne fa Adobe di un prodotto, anzi del più rinomato e probabilmente costoso prodotto, di web analytics del mondo?”, e le risposte sono molteplici.
Ieri ho subito detto “Adobe Analytics è alle porte?”, riferendomi alla altrettanto strana – per allora – acquisizione di Urchin da parte di Google, che come sappiamo ci ha poi regalato Google Analytics. A pensarci meglio, però, Adobe è un produttore di software, e almeno due di essi sono direttamente legati ai contenuti: sto parlando di Dreamweaver, editor di sorgenti, e di Flash, croce degli esperti di WA e delizia dei webdesigner creativi.

Il primo pensiero quindi è stato: Adobe vuole integrare una soluzione di web analytics nei suoi prodotti, in modo che per l’utente sia semplice avere i dati una volta pubblicato il progetto perché gli strumenti si occuperanno di integrare le necessarie chiamate dei codici di tracciamento (e non al livello di adesso, cioè aggiungendo chiamate ad ogni pulsante flash, ma in modo automatico). Ma è anche vero che Omniture non è proprio uno strumento alla portata delle tasche di tutti gli utenti.

In seconda istanza ho letto un post di CMS watch, che si spinge oltre: a parte la Creative Suite, Adobe ha un rinomato Flash Media Streaming Server, il player di Flash è sul 98% dei computer del pianeta, e ci sono quasi un miliardo di installazioni di Flash Lite sui cellulari. E ancora, Adobe AIR è in grado di portare tecnologia Adobe anche su programmi desktop. Da questo punto di vista Omniture potrebbe presto “invadere” la maggior parte dei dispositivi web oriented che abbiamo per le mani, e sarebbe una espansione di mercato pazzesca.

Dall’altro lato, quello prettamente finanziario, è vero che Omniture ha un portafoglio clienti di tutto rispetto, formato dalle più grandi aziende mondiali, quelle che hanno abbastanza budget per comprare e mantenere il suo prodotto di punta, SiteCatalyst, quindi la mossa di Adobe potrebbe essere giustificata anche così.

Da quanto leggo in giro, tuttavia, pochi scommettono su un “downgrade” dei prodotti Omniture; quasi nessuno si aspetta un Adobe Analytics rilasciato gratis o a prezzo ridotto, per intenderci, anche se la cosa potrebbe invece avere un senso: Omniture da un po’ di tempo sente la pressione dei clienti che guardano anche alle soluzioni low-cost che crescono. Se Adobe, forte dei suoi risultati economici, riuscisse ad abbassare i costi del servizio, i ragazzi di Omniture potrebbero lavorare più serenamente allo sviluppo di nuove funzionalità. Ma questo lo sapremo solo col tempo…

Quando parliamo di “Mobile Analytics” ci riferiamo allo studio dei comportamenti degli utenti che utilizzano dispositivi mobili evoluti (tipicamente cellulari di ultima generazione) per visitare i siti di cui curiamo la web analytics. E’ un settore che inizia a riscuotere un certo interesse, complici anche i successi di Apple tramite il suo Iphone e di Google tramite il suo sistema operativo mobile Android.

Esiste tuttavia un altro punto di vista possibile, che non prende in considerazione l’interazione utente-sito, ma copre esclusivamente l’esperienza d’uso dell’applicazione, che non è assolutamente detto abbia a che fare con il web. E’ un argomento piuttosto delicato, poiché al contrario dei computer i dispositivi mobili sono riconducibili sempre ad un numero di telefono, unico, e quindi a un nome e cognome. Un nome abbastanza famoso per le applicazioni Iphone e Ipod Touch è quello di Pinch Media Pinchanalytics, che fornisce una piattaforma molto completa per questo genere di operazioni.

Andrea Baccega ha invece realizzato un “ponte” tra le applicazioni Android e Google Analytics, che consentirà agli sviluppatori Android di avere una libreria pronta da includere nelle loro applicazioni per tracciare cosa e quanto fanno gli utenti mentre le utilizzano. La libreria ha due metodi _trackPageview e _trackEvent che possono essere usati ad esempio per tracciare pannelli e pulsanti delle applicazioni, per sapere quante persone usano un certo pulsante su una certa “pagina”, oppure per recuperare informazioni sulle opzioni scelte dentro all’applicazione.
Le istruzioni per l’utilizzo e il download si trovano sul blog di Andrea, e non le riporto qui. Il mio consiglio, qualora voleste cimentarvi nell’integrazione, è di specificare a chiare lettere prima e durante l’utilizzo (magari con una finestra di dialogo obbligatoria al primo utilizzo, ove premere OK e RIFIUTO) che la vostra applicazione traccerà in modo anonimo i dati di utilizzo.

Andrea inoltre è stato così gentile da darmi l’accesso alle statistiche di una sua applicazione già in giro sui telefonini e mi ha aiutato a comprendere meglio il funzionamento della sua creatura. Infatti sappiamo tutti che Google Analytics si basa sull’utilizzo di cookie, che invece le app non usano. In questo, Andrea ha fatto un lavorone, sostituendo l’uso dei cookie con file xml in modo del tutto trasparente sia all’applicazione sia a Google Analytics, e consentendo quindi di tracciare praticamente tutte le informazioni che normalmente vediamo in GA, compresi quindi la fedeltà dei visitatori, la lingua del sistema operativo o la risoluzione dello schermo del telefonino. Chiaramente in questo tipo di report la sorgente di traffico è unicamente “diretto”, e infatti quella sezione di rapporti è pressoché inutile, ma i restanti – se siete sviluppatori Android – valgono sicuramente la pena. Ancora complimenti, Andrea!

E’ un settembre ricco di novità dal punto di vista degli utenti di Google Analytics, che durante l’estate devono aver ricaricato le pile alla grande e sono tornati dalle ferie proponendo ricche novità. L’ultima in ordine di tempo che mi è giunta sotto gli occhi è uno script GreaseMonkey – sempre lui, l’onniopresente – che permette di “aggirare” il limite di export dei report in CSV.

Come saprete se frequentate questo blog da un po’, aggiungendo il parametro &limit=50000 all’url di un report si può forzare Google Analytics a creare un file separato da virgole con cinquantamila righe, utile ad esempio se si hanno moltissime keyword di ingresso al sito, magari su lunghi archi temporali. Se però le righe sono 200000 è necessario ripetere lo stesso l’operazione quattro volte.
Questo script invece si occupa di far comparire link aggiuntivi nella sezione Export, in modo da poter accedere subito ai file e non dover armeggiare troppo con gli URL.

Ovviamente, trattandosi di GreaseMonkey, funziona solo su Firefox.

(image credit: arjansnaterse.nl)

Google Insights è un servizio che esiste già da qualche tempo, ma solo recentemente è venuto alla ribalta anche in Italia grazie all’introduzione dell’interfaccia nella nostra lingua. Tralasciando i titoli sensazionalistici dei giornali tipo “Google svela i segreti degli italiani”, Insight è uno strumento che permette di conoscere, valutare e comparare i trend di ricerca nel tempo o in base a diverse località, per le ricerche su web, immagini, news o prodotti, in tutto il mondo o in aree specifiche e/o su determinati intervalli temporali.

Questo ad esempio è l’andamento delle ricerche relative a “Google Analytics”, in tutto il mondo, dal 2004 a oggi. Anche se non l’avete mai usato, se frequentate la rete è probabile che vi siate già imbattuti in Insight, magari quando è mancato Michael Jackson e molti siti pubblicavano il grafico dell’esplosione di ricerche online relative al cantante pop.

E’ uno strumento indubbiamente utile, anche se non va preso per oro colato, e da oggi grazie a Seoverflow.com è possibile selezionare fino a cinque keyword nell’interfaccia di Google Analytics e interrogare direttamente Insights per le ricerche relative a quelle chiavi, in tutto il mondo e su un arco temporale di 90 giorni. Si tratta di niente di più di una scorciatoia, ma può essere utile per velocizzare un po’ il lavoro.

Per esempio, mentre scrivevo questo post e ho usato un po’ lo strumento con le prime cinque keyword di ingresso a questo blog, mi sono accorto che fatto 100 il volume massimo di ricerche della keyword principale (il 2 settembre), la media su 90 giorni è 81. La seconda keyword principale per contro quota 1. Eppure in termini di ingressi percentuali su Analytics la differenza non è così marcata (nemmeno restringendo Insights alle sole query italiane, per aderire meglio alle visite al blog). Questa “vista” sui dati può essere utile se stessi decidendo di spingere di più sulla seconda keyword: Dovrei misurare i miei sforzi sul fatto che il volume di ricerche relativo non è poi così tanto grande, oppure avrei comunque un dato in più per fare ulteriori approfondimenti prima di buttarmi a capofitto a spendere energie per fare il lavoro.

Per l’installazione è necessario il solito Firefox con GreaseMonkey. Lo script funziona solo se usate Google Analytics in lingua inglese.