Google Analytics in 30 secondi

Ieri, per circa un’ora, un problema di routing del traffico di Google ha impedito a Google Analytics di raccogliere correttamente alcuni dati. Il problema non ha interessato tutti i profili, e Google stima in media una perdita dell’1% del traffico del giorno 14 maggio, anche se molto dipende dalla quantità di traffico che i siti hanno ricevuto quando il problema si è presentato, cioè per circa un’ora dalle 7:48 del mattino (ora del Pacifico, in Italia erano le 16:48).

Il fatto, si apprende dal blog ufficiale di Google, è dovuto ad un imprecisato problema ad un loro sistema che ha causato un sovraccarico di traffico nella zona asiatica, che si è tradotto in lentezza nei servizi o complete interruzioni per il 14% degli utenti.

Da quando ne ho memoria, è la prima volta che Google Analytics perde dei dati per strada, e per pochi che essi siano è comunque un precedente, così come fu un precedente il grande disservizio che ebbe Omniture a Gennaio.

photo credit: peasap on Flickr

Le occasioni per vedersi dal vivo ultimamente sono scarseggiate (anzi, la colpa è prevalentemente mia che non mi sono fatto vedere in giro, ma per chi non lo sapesse sono diventato papà da cinque mesi 🙂 ), ma Maggio è un mese che segnerà un ritorno sulle “scene”…

Innanzitutto il 28 maggio sarò presente alla SEObirra, organizzata da Enrico Altavilla a Milano. Se si parlerà solo di SEO starò zitto e buono ad ascoltare, ma se tanto mi da tanto – visti gli argomenti della rediviva newsletter di motoricerca.info – ci sarà spazio anche per un pizzico di web analytics, quindi tra un crodino e un martini bianco un po’ di conversazione potrei farla 🙂

La sera successiva, quindi il 29 maggio, FradeFra organizza una cena post corso di Madri, cui presenzierò per rivedere un po’ di amici e fare anche qui due chiacchiere in allegria.
Già che ci siamo, segnalo che anche quest’anno YoYo – formazione rotolante si avvale della mia presenza come docente ai corsi di web analytics, il prossimo dei quali si terrà a Verona il 18 e 19 novembre 2009

Ultimo, ma non per importanza, segnalo un evento al quale non andrò, ma al quale mi sarebbe piaciuto molto poter andare: SeoPQR a Roma, il 6 giugno 2009. Se aveste modo voi, ho idea che non ve ne pentireste! 🙂

photo credit Swami Stream on flickr

Il report “canalizzazioni abbandonate per obiettivo” è uno di quelli che spesso lascia perplesso chi lo consulta. Infatti è un rapporto che mostra percentuali superiori al 100% ma non è riferito a un confronto. O almeno non a prima vista.
Benjamin Mangold su suo blog googleanalyticsresults.com ha spiegato molto bene la questione, e ho pensato di riprenderla qui perché sempre più persone hanno capito che per sfruttare a pieno Google Analytics è bene aver configurato degli obiettivi, e che se c’è una canalizzazione (funnel) è bene anche monitorare il suo abbandono.

Il tasso di abbandono di un obiettivo è calcolato secondo la seguente formula:

Questo è abbastanza semplice da capire: dato un certo numero di “intenzioni” di arrivare a una conversione, solo una certa percentuale ci arriva mentre gli altri rappresentano il tasso di abbandono.
Però se si guarda agli istogrammi giornalieri, si noteranno in fondo due percentuali (una delle quali tra parentesi). Il numero tra parentesi (che chiameremo tasso di abbandono giornaliero) usa la stessa formula illustrata sopra, ma riferita al singolo giorno, per cui:

Il numero che non è nelle parentesi, e che può anche essere superiore a 100%, rappresenta invece la comparazione del tasso giornaliero di abbandono rispetto al totale del periodo selezionato, per cui:

Vi potete accorgere di questo fenomeno e delle sue variazioni guardando il report e modificando il range di date selezionate. Il numero tra parentesi non varierà, ma la comparazione rispetto al totale invece si.
Il motivo per cui vi sono percentuali superiori a 100 è dunque perché quel numero rappresenta effettivamente una comparazione, ma GA non la mostra con le modalità classiche (segni più e meno, colori verdi o rossi a seconda della performance). Se un dato giorno il tasso di abbandono è particolarmente negativo avrà una percentuale superiore a 100, ma questo non esclude che nell’intero periodo altri giorni abbiano performance migliori e riequilibrino la media totale.

Ormai il team di Google Analytics ci ha abituati alle novità annunciate direttamente durante le conferenze: ieri all’ Emetrics di San Jose ne sono state annunciate quattro, che vedremo prossimamente nei nostri report (dicono qualche settimana):

1. dimensione secondaria: a fianco al menu a tendina “dimensione” apparirà un’altra tendina che ci permetterà di specificare una seconda dimensione e avere per ogni riga del report una combinazione dimensione1-dimensione2. Per esempio nel report keyword, la combinazione di dimensioni keyword-città produrrà per ogni riga qualcosa come “voli low cost – roma”, “voli low cost – milano”, “volare risparmiando – roma”, “voli low cost – firenze” e così via… (e a questo punto immagino che finalmente aumenteranno il limite di righe esportabili – senza trucchi – giacché è facile saturare 500 righe con pochi dati)
2. pivoting (non ho idea di come lo tradurranno, quindi per ora lo indico letteralmente): il pulsante “pivot view” permetterà di aggiungere, ad esempio, colonne con i vari motori di ricerca nel report keyword, e di mostrare per ognuno di essi una serie di dati. In pratica aggiunge metriche specifiche e non generali ai report. Detto così magari non è proprio chiarissimo, infatti Google ha preparato un video per queste due feature nuove

3. condivisione di segmenti avanzati e rapporti personalizzati: finalmente si potranno condividere sia i segmenti avanzti che i custom report, semplicemente inviando un URL (come ad esempio si fa con qualsiasi Google Map). Niente più lunghe telefonate o email per spiegare quali dimensioni e metriche inserire e quali espressioni regolari sono necessarie
4. selezione dei profili ove applicare segmenti avanzati e custom report: invece di avere un segmento avanzato uguale per tutti i profili, sarà possibile specificare a quali profili essi saranno applicati, analogamente a quanto già adesso avviene con i filtri.

Si tratta di novità di rilievo, che facilitano ancora il lavoro e chi usa GA tutti i giorni per la propria attività. Le novità relative alla condivisione invece aiutano chi come me gestisce gli account dei clienti e velocizza il processo di creazione e applicazione definitiva delle modifiche.

Cosa invece continua a mancare, secondo me? la possibilità di fare filtri “al volo” sulle righe dei report, basandosi sulle colonne. Ovvero, voglio vedere le keyword in ordine di percentuale di conversione, ma solo quelle con almeno 10 visite, altrimenti è ovvio che quelle con una visita e una conversione (100% conversation rate) occuperanno le prime posizioni.

Ad Planner Publisher Center è lo strumento che Google mette a disposizione dei publisher per pianificare le proprie campagne pubblicitarie ed effettuare ricerche in ambito pubblicitario, in modo da identificare meglio quali siano i siti su cui conviene investire in advertising. E’ uno strumento gratuito per tutti i possessori di un Google Account, e fino a ieri i dati sul traffico mostrati erano “stimati”, ovvero non erano precisi fino alla singola unità ma bensì basati su un modello congruente elaborato da Google stessa che comunque teneva conto dei dati reali in suo possesso.

Da ieri invece chi lo volesse può esporre i propri dati di Google Analytcs in Ad Planner: per farlo è sufficiente andare nelle impostazioni dell’account di GA e selezionare almeno l’opzione “Condividi i miei dati Google Analytics… Solo con altri prodotti Google“, dopodiché andare nel publisher center di Ad Planner e selezionare quali dati importare da Google Analytics.

Dal punto di vista della grande visione del Google Business Platform, la direzione dei dati è inversa; noi immaginiamo che Google Analytics sarà il centro di tutto, ma in effetti non è detto che sia così. Dal punto di vista della realizzazione del “super centro di controllo” della nostra attività su google, invece, è un ulteriore passo avanti nella direzione che ormai mi sembra imboccata a tutta velocità.

Una delle domande che ho letto più frequentemente in giro per la rete in questi anni di utilizzo di Google Analytics è stata “come faccio a mostrare le pagine viste sul mio sito?” e tutte le sue innumerevoli varianti, figlie della mentalità “a contatore” della preistoria del web e della scarsa conoscenza della web analytics.

La risposta che davo all’inizio cercava di far comprendere la differenza tra un semplice contatore e uno strumento avanzato di web analytics e gli scopi differenti delle due cose. Quando ho saputo che prima o poi sarebbe uscita una API in grado di esporre i dati la risposta è mutata in “ora non si può, ma in futuro si potrà”. Ora che la API è stata rilasciata, ho deciso che l’avrei fatto io, come primo progetto, anche se ovviamente la cosa non mi entusiasma 🙂

LE ISTRUZIONI E IL DOWNLOAD SI SONO TRASFERITI IN UNA PAGINA DEDICATA PER ESIGENZE DI MANUTENZIONE

VAI ALLA PAGINA UFFICIALE DEL PROGETTO

Ho iniziato a studiare come usare le API appena ho avuto cinque minuti di tempo, e come mi aspettavo non è tutto rose e fiori, per un programmatore medio come me. Tuttavia alcuni risultati ho iniziato ad averli, e penso che presto potrò proporre un primo banale utilizzo, e alcune altre idee mi stanno già balenando in testa.

Ma esiste un modo per provare ad estrarre dati senza iniziare a programmare, magari per rendersi conto di cosa si può fare e di che risultati si possono avere: http://vascodegapi.juiceanalytics.com, nuova creatura della ben conosciuta Juice Analytics. Vasco de GAPI è un’interfaccia web che, dopo aver effettuato l’autenticazione in Google Analytics, chiede all’utente di effettuare alcune scelte tramite menu a tendina: ad esempio chiede quale sia l’account dal quale ricavare i dati tra tutti quelli cui abbiamo accesso, le dimensioni e le metriche, il campo che comanda l’ordinamento dei risultati, eventuali filtri sui risultati e il periodo temporale di riferimento.

Una volta effettuate queste scelte, il sistema provvede ad effettuare un riepilogo delle impostazioni scelte e a richiamare i primi dati estratti, fornendo poi la possibilità di scaricarli tutti in un file .csv. A questo proposito c’è da notare che una delle condizioni di utilizzo delle API è che una singola chiamata non può generare più di mille risultati, ma che 1000 è comunque il doppio di 500, cioè del massimo ottenibile attraverso l’interfaccia web (anche se in passato vi ho mostrato un trucco mica male 🙂 ). Usando Vasco de GAPi si possono quindi ottenere senza sforzo, e senza scrivere una riga di codice, le prime mille keyword dell’omonimo report.

L’altro lato positivo è che il sistema provvede anche a fornire un esempio funzionante del codice che può essere usato per ottenere i medesimi risultati: in questo caso però bisogna essere esperti programmatori, poiché il linguaggio utilizzato è Python che implementa Google data.
Il sistema in sé non produce quasi niente che non si possa fare con un custom report, ma ha il grande pregio di mostrare i risultati di un possibile export senza toccare il codice, e di far prendere confidenza con la nomenclatura usata nella API; ad esempio la metrica delle pagine viste si chiama ga:pageview

Vasco de GAPI non ha accesso permanente al vostro account Google, né memorizza ovviamente alcuna password: per utilizzarlo dovete essere loggati in GA oppure dovete loggarvi all’istante, e poi dare esplicitamente il consenso affinché Vasco abbia accesso ai dati. Esiste chiaramente una procedura per rimuovere questa autorizzazione, descritta qui, ma io non trovo il link relativo ai siti autorizzati.

Concludo dicendo che nel post di presentazione dello strumento, Juice Analytics rivela che il loro strumento per la coda lunga Concentrare, di cui vi ho parlato a Gennaio, non usava nessuna API (nemmeno in beta) e si affidava a del sano e vecchio screen-scraping (catturare tramite un programma il contenuto di una pagina web). Mi ero sbagliato 🙂

Come vi ho detto qualche tempo fa, nei nuovi codici di monitoraggio che copiaincollate da Google Analytics è sparita la riga relativa a initData(), funzione soppressa dagli ingegneri di Google e chiamata implicitamente ed automaticamente dallo script. Se non avete provveduto a modificare i vostri codici di tracciamento (GATC) avete, appunto, uno zombie in casa: una funzione morta che cammina ancora tra le vostre pagine 🙂

Non fa male, di per sé, tranne per il caso citato oggi da Lunametrics, ovvero se avete alcune pagine con initData e alcune pagine senza; ad esempio perché avete aggiunto delle pagine nuove e avete copiato il codice dal pannello di Analytics invece che da una vostra pagina vecchia. In questo caso i cookie di GA possono essere scritti in forme leggermente differenti, e questo è fonte di errori e perdita del tracciamento del percorso del visitatore, quindi è male.
E’ un problema che nemmeno i controlli automatici come SitescanGA possono individuare, per cui è vostra cura assicurarvi di avere un GATC coerente su tutte le pagine.

Ricapitolando quindi le due regole fondamentali:

• non possono coesistere chiamate a urchin.js e ga.js nella stessa pagina; possono coesistere nello stesso sito, ma è sconsigliato. Se possibile usate solo ga.js
• se avete codici che contengono la chiamata a initData() dovrete scegliere se rimuoverla da tutte le pagine in cui è presente o aggiungerla in tutte le pagine in cui è assente

Solo un appunto veloce per segnalarvi questo post di Patrick Collision, che nel giro di un weekend ha usato le nuove API di Google Analytics per importare dati dentro a Mathematica, un famoso ambiente di calcolo dotato di un linguaggio di programmazione interno, e fare alcune cose decisamente interessanti. Il post l’ho letto velocemente, le formule non le ho controllate, ma come ha affascinato me, penso possa affascinare voi e darvi un ulteriore spunto su come potranno essere “diverse” le cose in futuro.
Le immagini sono tutte modalità di visualizzazione di dati reali di GA incrociati con altri dati importati dentro Mathematica. La differenza rispetto all’uso di file CSV o XML è che le cose possono essere automatizzate e schedulate, ad esempio come fa Patrick nel video a fine post.

A settembre dello scorso anno vi ho segnalato un post di Justin Cutroni che indicava il grado di aderenza di Google Analytics agli standard definiti dalla Web Analytics Association: il risultato era una metrica non aderente e sei non applicabili. Quel post tra l’altro è stato scritto in “risposta” ad un articolo analogo di Dennis Mortensen e relativo a Yahoo Web Analytics.

Poiché l’adesione agli standard WAA è importante, CMS Watch ha girato la medesima checklist alla lista dei vendor che popolano il suo annuale report sullo stato della WA nel mondo, ottenendo un misero 50% di risposte, che sono servite a compilare il CMS Watch Report Excerpt WAA compatibility 2009. (disponibile gratuitamente in pdf CMS watch ha cambiato sistema di pubblicazione, il pdf non è più disponibile)

La lista dei vendor che hanno risposto è composta da:

• Amethon
• Bango Analytics
• Coremetrics
• Google Analytics
• Intellitracker
• Lyris HQ: ClickTracks
• Mobilytics
• Nedstat
• Unica
• WebTrends

e stupisce sicuramente l’assenza di Omniture, la quale ha affermato che fornirà la sua risposta in separata sede durante il corso dell’anno. Per quel che riguarda Google Analytics, la risposta fornita coincide assolutamente con quanto detto a Settembre, poiché non sono intervenute variazioni nel frattempo.
Se usate uno dei prodotti dei vendor sopracitati, fareste sicuramente bene a leggere il report di CMS Watch, per capire esattamente cosa intende il vostro strumento di web analytics quando dice, ad esempio, “visitatore unico” (anche se alcune risposte date dai vendor sono volutamente vaghe; d’altronde non è possibile questionare anche sulle parole usate per rispondere alle domande, a meno di ridurre tutto alla compilazione di campi predefiniti).

La mia speranza è che questo sia solo il primo di una serie annuale di report analoghi, in modo che cresca la consapevolezza del grado di adesione agli standard e in modo che sempre più clienti inizino a fare pressioni sui propri fornitori di sistemi di web analytics affinché rendano i propri prodotti conformi.