Google Analytics in 30 secondi

Non è una novità che esistano script di GreaseMonkey su Firefox che aiutano ad usare meglio Google Analytics: su questo blog vi ho descritto come aggiungere annotazioni e vi ho descritto alcuni di quegli script.

L’estensione è morta per mano del suo stesso autore. Ho scoperto solo da poco l’estensione di Firefox Better Google Analytics, scritta da Erik Vold sulla base dello script “cleaner profile switching”. Questa estensione semplicemente raggruppa in una unica installazione – e senza il bisogno di installare GreaseMonkey – alcuni dei più utili script utente. Ecco quali sono le funzionalità e gli script che sostituisce (il dominio è morto quindi i link sono stati rimossi):

1. Accede automaticamente a GA, invece di far premere all’utente il pulsante blu
2. Cleaner Profile Switching – ricorda le impostazioni quando si cambia profilo, e permette di aprire altri profili in una nuova scheda del browser
3. Export to Google Docs – aggiunge un pulsante per esportare direttamente i report su Google Spreadsheet
4. Google Analytics absolute conversion – converte le percentuali in valori assoluti
5. Advanced date selection – aggiunge la possibilità di selezionare con un clic il confronto temporale rispetto allo stesso periodo dell’anno precedente (al momento non mi funziona, ne con l’interfaccia in italiano ne in inglese)
6. Table sorting – permette di ordinare qualsiasi tabella in base alla sua intestazione (anche questa al momento è leggermente problematica e devasta il layout della pagina)
7. Social Media Metrics – aggiunge le informazioni sui social network all’interno del dettaglio dei contenuti. Ve ne avevo parlato in questo vecchio post

Ovviamente essendo una estensione che si basa su altre realizzazioni non è sempre aggiornatissima, lo dimostra il fatto che due funzionalità sono al momento “rotte”, ma il vantaggio è quello di dover aggiornare un solo componente invece di controllare a mano se esistono nuove versioni di molti user script. La scelta è vostra. Better Google Analytics è installabile sia dal sito ufficiale vkistudios sia dal sito di mozilla.org; in quest’ultimo caso, trattandosi di una nuova estensione – è ancora al vaglio del giudizio qualitativo di Mozilla ed è considerata “experimental”, ovvero possono installarla solo gli iscritti al sito AMO

Già che siamo in tema, vorrei segnalare un vecchio script realizzato da Lunametrics che al momento non funziona, ma che sarebbe estremamente utile per chi come me gestisce profili corposi: si chiama Show100 ed imposta per definizione la visualizzazione di 100 profili, invece dei 10 disponibili. Che in realtà adesso sono solo 5, ma Google non ha mai corretto l’errore, considerando “profilo” qualsiasi riga della tabella “profili siti web”. L’unica soluzione è tenere d’occhio la pagina che ho segnalato e sperare in un aggiornamento.

Sul forum ufficiale di Google Analytics da qualche tempo appaiono e continuano ad apparire richieste di correzione di un errore che attribuisce le visite al traffico diretto invece che al traffico pagato. Una cosa analoga era successa ai primi di marzo, ma era rientrata da sé; questa volta invece il problema perdura.

La prima cosa da sapere è che non si tratta di un baco, né di un errore. Leggendo questo topic una dipendente di Google ha detto ufficialmente

Please check if auto-tagging is enabled and cost data is applied. Going forward, your CPC data will be reported only if these two are enabled. If you enable auto-tagging and do not apply cost data, you will see an increase in direct traffic.

(per favore controlla se hai abilitato l’autotagging e l’import dei costi. D’ora in avanti, i dati CPC saranno riportati solo se hai abilitato entrambe le opzioni. Se abiliti l’auto-tagging ma non applichi l’import dei costi, vedrai un incremento del traffico diretto)

La modifica è avvenuta tra il 23 e il 24 marzo, ma la cosa assurda è che non se ne fa menzione nè sul blog ufficiale di Adwords né su quello di Analytics.

Il mio post di ieri sugli IP ha innescato un paio di domande in privato che mi hanno convinto a fare un post di approfondimento.
Riassumo la situazione: una grande azienda, sparpagliata in tutto il territorio e con una infrastruttura di rete molto ampia, gestisce centinaia di siti web. Su uno di questi viene implementato Google Analytics, con un normale filtro sugli indirizzi di rete pubblici dei due proxy aziendali. Normalmente questo è sufficiente a filtrare il traffico degli impiegati.

Ci sono due complicazioni, una gestita e una no. La prima complicazione è che gli impiegati dell’azienda, quando richiedono il sito web, non passano attraverso il proxy ma si presentano al server web direttamente con il loro indirizzo di rete interna (10.10.1.76 o 192,168.1.34 o simili, dipende dalla rete). Il proxy serve solo a veicolare le richieste a risorse esterne. In questo caso però non è necessario filtrare gli indirizzi interni, perché la GIF trasparente di 1×1 pixel che serve a Google Analytics per registrare i dati si trova all’indirizzo (esterno) http://www.google-analytics.com/__utm.gif, quindi passa dal proxy. L’indirizzo IP che GA registra, quindi, è quello del proxy e il filtro funziona. Chiarisco con una immagine (cliccala per ingrandirla):

(tutto il contenuto della pagina viene servito dal server web, tranne una immagine linkata su un server esterno e il codice e la GIF di Google Analytics. Questi due elementi vengono a tutti gli effetti richiesti dal proxy al posto del computer interno).
Questo caso viene quindi ovviato dal filtro imposto al profilo.

Il caso non gestito è quello in cui mi sono trovato io: alcune porzioni della rete escono da proxy differenti dai due noti, ma non c’è modo di sapere quali e che indirizzi pubblici abbiano. Solo dopo aver isolato gli IP interni dei dipendenti che accedevano alle pagine tramite l’uso che vi ho mostrato di _setVar() (che incapsula l’IP e lo spedisce in chiaro a GA) si è potuto risalire alla porzione di rete che sfuggiva al filtro e al relativo proxy.

Il disegno che ho inserito è secondo me la chiara dimostrazione che è difficile fare web analytics senza conoscere il funzionamento basilare della rete: bisogna conoscere il funzionamento del TCP/IP e dell’HTTP, capire come funziona un proxy, come e perché alcune cose passano da lui e altre no, eccetera. Senza sapere queste cose si possono leggere lo stesso i dati di GA e degli altri programmi, ma si dipenderà sempre da qualcun altro per risolvere i propri problemi sui profili. In un sistema di web analytics “as a service” senza la possibilità di riprocessare i dati passati come è Google Analytics, ogni giorno perso è un giorno in cui si hanno dati “sbagliati”, e i dati sbagliati in ingresso sono dati sbagliati in uscita (gli anglofoni dicono molto saggiamente “garbage in, garbage out” 🙂 )

Domanda ricorrente, risposta breve: perché Google non vuole, considera l’IP un dato personale e poiché è sempre nell’occhio del ciclone per le questioni di privacy, taglia corto e non lo consente.

Risposta articolata: i termini del servizio di Google Analytics, al punto 8.1 escludono questa possibilità tramite la dicitura

Google non assocerà il vostro indirizzo IP a nessun altro dato posseduto da Google

Un’altra conseguenza di questa regola, che con gli IP non c’entra, è che in Google Analytics non si possono tracciare o ripercorrere i path delle singole visite, cosa che invece altri software riescono a fare senza sforzo. Probabilmente avrete letto o avrete sentito dire da me in tempi remoti che con un banale trucco la cosa era ancora fattibile: infatti creando un filtro personalizzato di tipo avanzato il campo “indirizzo IP visitatore” è presente, come testimoniato dallo screenshot qui sotto (e come potete verificare voi stessi guardando il sorgente della pagina di creazione di un filtro come quello)

ecco come FireBug presenta la riga incriminata

<option value="31" style="display: none;">Indirizzo IP visitatore</option>

ma è selezionabile solo tramite tastiera, scorrendo la select tramite freccia su/giu. Io dicevo, ed era vero, che un filtro avanzato poteva prelevare l’intero campo IP e trascriverlo nel campo “Definito dall’utente”; la cosa è stata sanata da tempo da Google e un filtro come quello, al momento, semplicemente non fa nulla.

Allora, quale altra soluzione rimane?

rimane la possibilità di estrarre a mano l’indirizzo IP del visitatore e di scriverlo direttamente nel campo “definito dall’utente”, tramite la funzione _setVar() richiamata subito dopo _trackPageview().

Quindi in ASP

pageTracker._setVar("<%=Request.ServerVariables("REMOTE_ADDR")%>");

in ASP.NET

pageTracker._setVar("<%= Request.UserHostAddress>");

in PHP

pageTracker._setVar("<?php echo $_SERVER['REMOTE_ADDR'];?>");

in SHTML (server side include HTML)

pageTracker._serVar("<!--#echo var="REMOTE_ADDR"-->");

Proprio oggi ho dovuto ricorrere a questa tecnica: una grossa azienda con una infrastruttura di rete molto ampia (con decine di sistemisti sparsi sul territorio) implementa Google Analytics su un sito, ma nonostante due filtri per escludere le visite dei propri proxy, il report “Ubicazione di rete” riporta visite provenienti dal nome di rete dell’azienda. Poiché non se ne viene a capo, sistemo la funzione _setVar per catturare gli IP dei navigatori (in questo caso gli IP di rete interna, poiché i siti visti dall’interno non necessitano di proxy, ma l’immagine trasparente 1×1 di GA invece si), e dopo un paio d’ore sono già in grado di chiedere al sistemista dove siano ubicati e con che proxy escano gli IP del gruppo che “sfuggono” dai due filtri.

Risolta la questione ho eliminato la funzione setVar e sono ritornato nelle grazie di Google Analytics.

Nella giornata di ieri, Google ha aggiornato il servizio YouTube Insight, strumento analitico per capire meglio cosa accade intorno ai video caricati sul popolare servizio di condivisione filmati.

Come ho già avuto modo di dire in passato, questo servizio – che al momento viene erogato tramite le pagine di YouTube – trova il suo sbocco naturale dentro ai report e all’interfaccia di Google Analytics, con cui condivide parte del “framework”, ad esempio il sistema di selezione temporale basata sulla cronologia.
Nella prima schermata (visualizzazioni) è presente una selezione che permette di visualizzare il numero di utenti unici oltre che di visualizzazioni; questo è un concetto che esiste praticamente solo in web analytics. Nella schermata “origine delle visite” è possibile conoscere il “referrer” di chi ha visualizzato il filmato: se proviene da video correalti Insight ci dice quali, se proviene da una ricerca ci dice quali chiavi sono state usate e se la visualizzazione è stata fatta tramite il player incorporato lo strumento ci dice in quale sito questo è successo, eccetera…

La nuova schermata “community” invece è la vera novità: essa presenta il grado di interazione degli utenti con il video presentato, suddividendo i voti, i commenti o i click per rendere il video uno dei preferiti o fornendo un totale. Inoltre si possono conoscere i numeri puri o la percentuale in base al numero di visualizzazioni (2 commenti su 4 visite portano un grado di interesse del 50%, per i commenti). Questo è quello che potremmo fare con Google Analytics impostando degli obiettivi, appunto, sull’inserimento di un commento, di un voto o sul click sui preferiti; il fatto che nell’interfaccia inglese si parli espressamente di “engagement” dovrebbe togliere ogni ulteriore dubbio su quale sia il futuro di questo splendido pezzo di software.

Vorrei fare altre due menzioni: la prima è per la schermata sul grado di interesse del pubblico rispetto alla durata del video, cosa tipica dei sistemi di analisi dei video, la seconda è per la schermata riepilogativa con i dati demografici degli utenti che hanno visualizzato il sito. Se e quando (secondo me solo “se”) YouTube Insight si fonderà con Google Analytics potrebbe essere interessante far leggere a GA il cookie di Youtube, che contiene anche questa informazione e potrebbe quindi trasmetterla ad Analytics e fornire quel dato anche per le “normali” pageviews.

Nell’ipotesi in cui stiate diramando comunicati stampa per promuovere il vostro business, o stiate facendo article marketing e per qualche ragione non stiate aggiungendo i parametri delle campagne, Allaedin Ezzedin di morevisibility.com ha pensato a una soluzione per voi: tramite la sua funzione sarà sufficiente aggiungere un solo parametro al link (meno invasivo rispetto ai tag delle campagne) e demandare ad uno script sul sito il compito di ricostruire i tag ed attribuire le visite alla corretta campagna.

L’intero script è disponibile nel post, e si occupa di controllare il valore di un parametro chiamato “id”, di memorizzare il referrer nel caso id sia uguale a 1 e di aggiungere i parametri utm_source, utm_medium e utm_campagin correttamente valorizzati.

In pratica un link come
http://www.miosito.com/myfile.html#id=1

diventerebbe
http://www.miosito.com/myfile.html#utm_source=www.cnn.com&utm_medium=press_release&utm_campaign=hurricane_katrina

l’uso del cancelletto # è giustificato da ragioni di SEO (Google infatti non indicizza nulla dopo il #, mantenendo nell’indice l’URL originale) e richiede l’uso della funzione _setAllowAnchor(true)

Se non cambierete il nome del mezzo usato nello script, tramite un segmento avanzato che corrisponda esattamente a press_release avrete all’istante una vista sui dati del traffico portato dai vostri comunicati stampa.

La soluzione non è certamente innovativa, ma ha il pregio di non dover mettere in piedi una nuova pagina che faccia un redirect lato server dopo aver aggiunto i parametri, soluzione che personalmente preferisco ma che non è alla portata di tutti. Il difetto è che dovrete aggiungere un if per ogni campagna/parametro che vorrete diffondere. Sappiate comunque che si può fare anche come dice Allaedin…

La domanda che sempre più spesso sento fare è “ma Google Analytics va bene per il mondo enterprise?”, ed è una domanda che si fa largo nella testa delle persone per due motivi concomitanti: il primo è che più o meno regolarmente GA acquisisce nuove funzioni, il secondo è che la crisi dei mercati sta spingendo le aziende al risparmio, oppure a cercare di ottenere più controllo sui dati per minimizzare i “rami secchi”.

Ecco cinque motivi per cui secondo Zetainteractive il prodotto Google può andare bene per le aziende:

1. Le nuovi funzioni enterprise, che lo hanno avvicinato a prodotti più blasonati.
2. l’annuncio di un set di API, tutt’ora in beta privata, la cui introduzione darà una spinta decisiva al fiorire di nuove soluzioni terze basate sui dati incapsulati nei database di Google
3. l’usabilità del prodotto. A differenza di altri sistemi, l’interfaccia è curata e pulita e le funzioni sono chiare. Il sistema è facile da usare ed è semplice accedere ai dati di alto livello
4. il tasso di crescita; a maggio del 2008 il 53% di un campione del mercato statunitense stava usando Google Analytics, con un +12% rispetto all’anno precedente; e questo prima di sapere delle nuove funzionalità
5. il prezzo, perché è gratuito (non è del tutto vero, sapete come la penso). Molte aziende lo stanno usando, e utilizzano il budget risparmiato investendolo in marketing

A chi dice che l’anello debole è il supporto ricordo che, oltre ai nuovi GAIQ la cui certificazione non è automaticamente sinonimo di qualità, esistono i GAAC, aziende autorizzate da Google a fornire supporto a pagamento. Oltre a Coresecure, BitBang e Webranking, colgo con questo post l’occasione di fare i miei complimenti a TSW, che oggi ha annunciato di avere avuto l’ambita certificazione. (beh, e come dimenticare Simone Carletti? 🙂 edit: e Enrico?)

Microsoft ha comunicato ieri la decisione di sospendere il programma Adcenter Analytics, un sistema di web analytics nato dall’acquisizione di DeepMetrix di due anni fa e inizialmente noto con il nome di Gatineau.

Io non ho mai preso parte alla beta, e non voglio dare quindi giudizi sul prodotto. Amici che l’avevano provato mi dissero che di bello c’era una forte segmentazione demografica dei visitatori, anche se non ho mai capito dove prendesse i dati. Quel che è certo è che da oggi il settore ha un player in meno, e questo è ovviamente un dato negativo.

The insights you’ve contributed through your use of the tool and your feedback have helped us immeasurably in shaping Microsoft’s future in web analytics.
Your feedback has helped us confidently determine that we can serve advertisers and publishers best by offering a tailored solution that meets more specialized needs.

Microsoft ammette che i dati che riusciva a presentare ai publisher non erano sufficienti ad essere di reale aiuto, e che è necessaria una soluzione maggiormente customizzabile (c’è chi dice Microsoft Commerce). Il fatto che l’avventura del colosso di Redmond nel mondo della web analytics non finisca qua è confermato anche dalle parole (e dalle non parole) del post di Ian Thomas, che col team di AdCenter Analytics ci è stato a stretto contatto. Secondo Dennis Mortesen la chiusura di AdCenter non ha nulla a che vedere con il fatto che i sistemi free di web analytics non portano guadagno nelle casse di chi li rilascia, anzi il settore è più vivo e in fermento che mai (vedi anche la prossima release di Yahoo Web Analytics), ma semplicemente il costo si è trasformato da dollari a dati (ancorché i costi non si siano azzerati, ma siano solo diminuiti).

Why do you think Google Analytics provides “Last Click Campaign Attribution“ and Yahoo! Web Analytics provides multiple models including “Original Source Campaign Attribution”? – Because last click favors Search and Google owns search and thus present a positive picture of their channel, Original Source on the other hand favors Display and Yahoo! owns Display and thus present a positive picture of their channel – same data, two different stories.

In questi due scenari, Microsoft non controlla nessun settore, mentre come sappiamo è forte nell’ambito software, e questo chiude il cerchio con l’affermazione di prima sul ritorno del prodotto di analytics integrato in una piattaforma più ampia.

Visto che siamo in tema di scenari futuri, vale la pena di segnalare anche un post di rise the top sulle implicazioni del recente programma IQ di Google Analytics.
Le implicazioni positive sono:

• maggiore conoscenza di GA a livello internazionale
• Il programma accrescerà l’interesse intorno a GA
• Più individui potranno ricevere interesse da parte delle aziende che cercano consulenze nel settore della web analytics
• Il programma aiuterà le aziende che fanno internet marketing ad assumere personale più qualificato
• Un maggiore supporto alle aziende che necessitano di assistenza su GA

e quelle negative:

• Crescente insoddisfazione da parte delle aziende che crederanno di avere lo stesso livello di servizio dei Google Analytics Authorized Consultants
• Supporto diluito per via del fatto che i GAIQ saranno confusi coi GAAC
• Svilimento del prodotto dal vasto numero di GAIQ che hanno la certificazione di esperti ma che non necessariamente danno consigli da esperti

Dubbi sacrosanti, ma il programma di Google contribuirà ancora di più ad aumentare l’interesse intorno alla web analytics, e di questo non possiamo che rallegrarci…

Un paio di settimane fa sul blog australiano dell’azienda Marketing Results è apparsa una mappa mentale di una pagina con lo schema del processo per iniziare a usare Google Analytics. L’idea mi è sembrata carina, e ho subito scritto all’autore chiedendo il permesso di tradurla e proporla qui.
Purtroppo non ho mai ottenuto alcuna risposta, nemmeno un rifiuto. Mi assumo la responsabilità e lo faccio ugualmente, lasciando intatto il copyright e aggiungendo una nota per la traduzione, sperando ovviamente di farvi cosa gradita.

Scarica la mappa mentale per Google Analytics

ieri su Twitter è comparsa una interessante discussione: l’esigenza era quella di ottenere il numero di visitatori unici per una pagina. La faccio breve: dinamicamente non si può fare. Non può farlo Google Analytics, e ad esempio Webtrends lo fa solo effettuando alcune operazioni sullo script e solo per quattro report predefiniti (unici giornalieri, settimanali, mensili e annuali).

Più difficile è spiegare il perché, o almeno quello che io ritengo essere il perché. Ci ho provato ieri con due persone, ma entrambe le conversazioni non mi sono sembrate sufficientemente chiare, per cui ho promesso un post in cui ci riprovo.

Google Analytics e gli altri sistemi di web analytics usano un database in cui immagazzinano i dati ricevuti tramite lo script di tracciamento o la lettura dei log. Come sia fatto questo database non è importante adesso, quello che è importante è cercare di capire che esistono dei limiti, fisici e concettuali, in questo sistema. Il limite è che i dati devono essere “spezzettati” e trovare posto in tabelle, colonne e record differenti. Di sicuro non ci può essere un solo record per ogni visita, o peggio per ogni pagina vista, che includa tutte le informazioni. O magari può anche esserci, ma non potrà contenere l’informazione “visitatore unico”.

“Visitatore unico” perché? la domanda giusta sarebbe “visitatore unico per quale periodo?”, perché il dato visitatore unico viene calcolato al volo durante la consultazione del report. Proviamo a ragionare come Google Analytics ma in linguaggio naturale: oggi [* vedi nota ] ho registrato 160 diverse sessioni (visite) e 700 pagine viste. Posso sicuramente scrivere nel database 160 visite e 700 PV, e posso anche calcolare le pagine medie per visita. Posso sapere quanti utenti unici ho avuto? teoricamente si, ma non mi conviene scriverlo nel database, perché il dato utenti unici dipende esclusivamente dal periodo temporale della richiesta. Potrei anche scrivere “oggi 100 visitatori unici”, ma quel dato varrebbe esclusivamente se l’utente mi interrogasse per la data di oggi. Se domani avessi solo 50 unici, quanti unici avrei per l’insieme dei due giorni? non 150 (o meglio, 150 è solo uno dei centocinquanta casi possibili), ma un numero compreso tra 1 e 150 e dipendente dal numero di cookie unici che posso estrarre interrogando il database.

L’informazione “visitatore unico” non è mai conosciuta a priori ma sempre a posteriori; non viene registrata nel database come numero puro, tanto che i visitatori unici assoluti sono presenti in Google Analytics solo nel report omonimo, e il dato non è segmentabile e non è incrociabile con niente. Se create un custom report e selezionate la metrica “visitatori”, la maggior parte delle metriche e delle dimensioni smettono di essere selezionabili: a parte quelle del gruppo “uso del sito”, restano disponibili soltanto giorno, settimana e mese.

La soluzione non è per niente elegante, ma è l’unica possibile (e vale anche per Webtrends, a quanto posso leggere sul forum): conoscendo a priori la pagina di cui si vuole avere il dato, si creerà un profilo-copia che includerà soltanto la pagina in questione. A quel punto il dato visitatori unici assoluti corrisponderà ai visitatori unici della sola pagina considerata.
Questo significa che – per quanto riguarda Google Analytics – se decidete oggi la pagina di cui volete avere gli unici, avrete i dati da oggi in poi. Con altri sistemi di web analytics invece dovrete invece riprocessare i dati pregressi.

[* nota: “oggi” tra le altre cose è anche fuorviante, perché l’analisi dei dati Google Analytics la fa una volta ogni ora, e questo rende ancora più semplice capire perché non sappia se un visitatore è unico]

photo credit: kyz su Flickr