Google Analytics in 30 secondi

Se leggeste tutti i messaggi, mail, forum e gruppi che leggo io su Analytics (o quantomeno se leggeste gli stessi che leggo io) sapreste benissimo che il mondo delle API che ad alcuni sembra una cosa oscura e “di nicchia” è vivo e vegeto e migliaia di persone creano applicazioni utili attraverso di esse. Non solo, esse vorrebbero di più, e continuamente si lamentano che nelle API non c’è questa metrica, vorrebbero questa dimensione, non si può incrociare quei dati.

Con l’aggiornamento di ieri molti di loro saranno stati soddisfatti, giacché il blog ci informa che sono ora disponibili oltre 40 nuove metriche e dimensioni: la lista completa è in questa pagina.

All’interno dell’ultimo update troveremo quindi metriche relative al social (bottoni sociali e interazioni offsite), ai dispositivi mobili, al dettaglio dei contenuti e ai tempi utente.

Insomma, un sacco di roba, potete provare da voi le novità attraverso il data query explorer 🙂

Non ho mai voluto capire sino in fondo quanto il mio vecchio contatore fosse stato utilizzato da quando lo pubblicai: ovviamente il link di ritorno ha i parametri delle campagne, ma è chiaro che se nessuno clicca, io non posso sapere se e dove è installato. Però a giudicare dalle tre email in rapida successione che mi informano dell’avvenuto disastro – il contatore non conta più – e mi chiedono aiuto su come risolverlo, tanto male non deve essere stato 🙂

E così ne ho approfittato e l’ho aggiornato alla versione 1.1, utilizzando questa volta la libreria GAPI. Il funzionamento è lo stesso, ho solo dovuto aggiungere una dimensione “fasulla” perché la libreria non accetta query senza dimensioni, ma alla fine le tre metriche del contatore vengono mostrate.
Se quindi utilizzavate il contatore e da qualche tempo ha smesso di funzionare… è tempo di aggiornare il tutto. Ogni tanto va fatto! 🙂

Trovate tutto nella pagina apposita

[update 28 agosto: con più calma – in ferie 😀 – ho capito il mio errore. ci sono riuscito. Quando torno scriverò un post di istruzioni…]

Subito prima delle ferie – le MIE ferie – il team di Analytics ci propone uno script per facilitare l’importazione di dati dentro a Google Docs: il sogno di noi tutti sarebbe un analogo per Excel, quantomeno per evitare il doppio salto GA -> Google Docs -> Excel (e lo so che ci sono altri strumenti diretti, io parlavo di uno scrip made in Google 🙂 ), ma ovviamente Google ha tutto l’interesse a spingere Docs usando anche questo genere di argomenti.

Volevo postarvi delle istruzioni carine per farvi già creare qualcosa, ma come al solito voglio essere sincero al 100%: gli ho dedicato 20 minuti ma non sono riuscito a importare un solo dato, usando le funzioni già presenti. Dovrei dedicarmi alla parte “costruisci il tuo script”, ma non mi sembra una cosa da fare la sera prima della partenza per le ferie: se ci riuscissi e venisse una cosa carina so che sarei capace di fare moooolto tardi, e domani devo guidare 🙂

(per quanti si stiano domandando “è meglio questo o quello vecchio postato da SeoMoz?” la risposta è: quello di SeoMoz non richiede nessuna conoscenza particolare, però vuole la password in chiaro e spesso a me dà problemi. Questo richiede di smanacciare almeno un pochino con il pannello delle API, se si vuole scrivere o aggiungere pezzi di codice, però è fatto da Google ma non sono riuscito a farlo funzionare. Vedete voi 🙂 )

Non è detto che riesca a scrivere/leggere durante le ferie, e spero che non succeda nulla di troppo importante nel frattempo: in fondo si tratta di una sola settimana, dite che il team di Google ce la fa a stare buono mentre mi riposo un pochino? 🙂

Questa è una segnalazione molto rapida per informarvi che da adesso sono pubbliche le nuove API dedicate alle canalizzazioni multicanale: ovvero un modo per estrarre i dati presenti nei multi-channel funnel e rielaborarli come meglio ci aggrada; non che mancassero le possibilità, attraverso la creazione di raggruppamenti di canali personalizzati, ma si sa, gli sviluppatori sono sempre avidi di API e le possibilità in questo modo diventano infinite.

Per prima cosa una precisazione: le nuove aPI funzionano solo se state usando la versione 3 delle core reporting API; è un modo come un altro (il migliore che Google conosce) per convincere le persone ad aggiornare le proprie abitudini 🙂
In secondo luogo, se vorrete usarle, dovreste dare un’occhiata alle metriche e alle dimensioni che si possono estrarre attraverso questa nuova feature.

Sono molto curioso di scoprire cosa gli sviluppatori tireranno fuori con queste nuove, potentissime e promettenti, API. Poi uno dice che il mondo non è dei programmatori… 😀

Due giorni fa il team di Google Analytics ha pubblicato una nuova libreria, di cui Nick ci aveva dato un assaggio la settimana scorsa su Google+: questa libreria dovrebbe teoricamente rendere molto facile creare grafici con i dati di base, dovrebbe in qualche modo permettere alle persone di crearsi delle dashboard personalizzate da pubblicare, o da consultare senza dover accedere all’interfaccia di Analytics.

Dico dovrebbe perché ci ho giocherellato un po’, e nonostante abbia seguito le istruzioni (e provato anche a fare di testa mia), non sono riuscito a venirne a capo. Non mi reputo certamente un genio di javascript, ma non mi sento nemmeno un principiante: diciamo che se mi dicono che c’è una nuova “easy library” e c’è un esempio funzionante e del codice sorgente, mi figuro di poterci riuscire.

Comunque sia, la libreria è questa (si trova nella prima riga), l’esempio è nella stessa pagina. La demo funzionante di Nick si trova invece qui (avrete bisogno del numero di Table_ID).

Se qualcuno vuole cimentarsi e mi fa vedere una pagina funzionante, gliene sarò grato 🙂

Qualche tempo fa ho voluto creare un KPI per provare una mia certa teoria (più che altro la fattibilità e l’effettiva utilità del KPI stesso usando dati reali e non astratti), una cosa facile facile tutto sommato, ma ne ho approfittato per giocare un po’ con le API di Urchin, immaginando che non fossero poi troppo diverse da quelle di Analytics. Ho così messo insieme alcune pagine php che assolvevano alla funzione desiderata.

La settimana scorsa volevo adattare il lavoro alle API di GA, ma ho scoperto che da qualche tempo Analytics richiede che le applicazioni siano registrate sulla Google APIs consolle, e che per farlo devono essere su rete pubblica. Poiché il mio sistema è su rete interna (e ho avuto qualche problema con OAuth 2.0, lo ammetto), ne ho approfittato per provare qualcuno dei sistemi per importare dati dentro a Excel, tipo excellentanalytics, nextanalytics, http://www.automateanalytics.com o Tatvic.

Tralasciando quelli a pagamento, il problema principale che riscontro è che spesso la presenza di un proxy impedisce a Excel di connettersi a GA. Mi sono così orientato verso una soluzione che collegasse Analytics a Google Docs, così che il passaggio dei dati sia server-server e si possano evitare intoppi. Per prima cosa sono capitato su questo post di SEOmoz, che sembra promettente ma che non ho ancora sperimentato. La soluzione più immediata – per le mie limitate esigenze del momento – è stato leggere questo post di peakconversion.com.

Le istruzioni sono piuttosto semplici:

• bisogna aprire questo google docs e farsene una copia tramite File->Crea una copia…
• si imposta l’id del profilo da cui prendere i dati (lo si può trovare nell’interfaccia cliccando l’icona delle impostazioni, selezionando il profilo corretto se non lo è già e poi passando alla tab “impostazioni profilo” e guardando a ID profilo)
• si apre l’editor di script Strumenti->editor di script…
• si seleziona la funzione Run|getSettingGADataToSheet e si autorizza una prima volta l’applicazione
• si lancia di nuovo la stessa funziona e si autorizza definitivamente il foglio di calcolo a estrarre i dati
• a questo punto compare una nuova voce di menu “GA”. Si cambiano il resto dei parametri nel foglio _settings e si lancia GA->activate settings query

Il risultato è un nuovo foglio di lavoro con i dati richiesti. Alternativamente si può chiamare in qualsiasi cella la funzione

getMetric(profile, metric, startdate, enddate, [dimensions], [segment], [filter], [sort], [maxresults])

a cui si passano i primi quattro parametri obbigatoriamente e gli altri cinque opzionalmente e che provvede a caricare direttamente i risultati. Fatto questo i dati sono pronti per essere ulteriormente aggregati, elaborati, resi su un grafico o combinati per avere i nostri KPI sempre aggiornati direttamente sul foglio di calcolo.

Mi scrive Imma con questa domanda:

non riesco a capire perché i dati che ottengo dalle API non corrispondono a quelli che vedo in analytics. Come metrica sto utilizzando ga:organicSearches, come intervallo di tempo tutto dicembre, e ottengo come risultato 1421, mentre dalla piattaforma di analytics mi risulta che le visite organiche siano 1520.

La prima risposta porta la soluzione del problema, cioè usare la metrica giusta: ga:visits, dimensione ga:medium e filtro ga:medium==organic
cioè con questa richiesta (cambiando opportunamente le date, ovvio):

https://www.google.com/analytics/feeds/data?ids=ga%3A284804&dimensions=ga%3Amedium&metrics=ga%3Avisits&filters=ga%3Amedium%3D%3Dorganic&start-date=2011-12-09&end-date=2011-12-09&max-results=1000

poi la risposta alla domanda “ma allora ga:organicsearches cosa è?”: secondo la definizione ufficiale rappresenta il numero di ricerche organiche che si verificano durante una sessione. Secondo questa risposta di Nick Mihailovski è un conteggio delle sorgenti organiche per una stessa sessione, quindi nel suo esempio di sessione organic > organic > ppc ga:organicsearches avrebbe valore 2. Ma la sua risposta è precedente al cambio del conteggio delle sessioni in GA, quindi oggi la spiegazione non è più del tutto aderente alla realtà. Poiché ogni volta che cambia il cookie __utmz viene creata una nuova sessione ga:organicsearches dovrebbe combaciare con la visite organiche, tranne per il fatto che quando si fa una visita da organico e poi si ritorna da traffico diretto, Google conteggia la visita come proveniente dal motore di ricerca. ga:visits per quella keyword si incrementa di uno, ma ga:organicsearches no.

E questo dovrebbe spiegare la differenza nei due valori.

[edit: il valore esiste anche nell’interfaccia: basta creare un Custom Report e aggiungere la metrica “Ricerche Organiche”]

Facendo seguito al suo progetto di ridisegnare l’intera infrastruttura di API di tutti i suoi servizi, Google ha annunciato che la Data Export API sarà sostituita dalla Core Reporting API. Non si tratta solo di un cambiamento di nome, perché le novità principali sono:

• nuovo output basato su JSON, più veloce nella risposta. Il post ufficiale dice che la dimensione della risposta è più piccola di 10 volte rispetto al vecchio XML, e secondo i primi test la velocità di risposta raddoppia
• Una serie tutta nuova di librerie, tra cui Object C, Ruby, Go…
• supporto alla Google Discovery API e OAuth 2.0
• richiede che l’applicazione sia registrata e ottenga uno specifico ID

Tutto questo avviene se si migra alla versione 3.0 delle API, che poi è l’unica che sarà aggiornata. La versione 2.4 è mantenuta per compatibilità, mentre la 2.3 è deprecata e smetterà di funzionare tra 6 mesi. A questo punto sia la Management API che la Core Reporting sono allineate, e da ora in poi la strada per i programmatori sarà in discesa…

Cioè, breve sintesi di cosa è successo a Google Analytics mentre ero in ferie e poco prima 🙂

1. E’ uscita una nuova versione del SDK per tracciare le applicazioni Android: la novità principale è nella gestione delle campagne, cioè è adesso possibile conoscere la sorgente che ha portato qualcuno a scaricare l’applicazione al momento dell’installazione sul telefono/tablet oltre che impostare campagne “classiche”
2. I funnel multichannel sono adesso disponibili per tutti: li trovate usando la versione v5 e guardando nella toolbar in alto: CONVERSIONI -> CANALIZZAZIONI MULTICANALE. Avevo scritto un post di panoramica qualche settimana fa, ma ho idea che ci ritorneremo più volte nei prossimi mesi 🙂
3. Le API passano alla versione 3.0, perché Google ha cambiato l’infrastruttura che serve tutte le sue interfacce di programmazione. La versione 2.3 è deprecata – attenzione alle vostre applicazioni quindi – e smetterà di funzionare a fine ottobre sostituita dalla 2.4. La versione 3 apporta alcuni miglioramenti tra cui velocità di risposta, OAuth 2.0 per l’autenticazione, risposte più compatibili con JSON, tutti gli eventi sono ora estrapolabili e altro ancora…
4. Si possono adesso linkare più profili AdWords ad un unico account Analytics, come richiesto ormai da anni da tutte le web agencies del mondo
5. C’è un corso tutto nuovo completamente incentrato sull’ecommerce e Google Analytics a cui ti puoi iscrivere, e il docente sono io! 🙂

Un po’ di segnalazioni sparse che non ho avuto modo di fare prima, ne qui ne sul mio account Twitter (@goanalytics), ma che un utente di Google Analytics potrebbe essere interessato a sapere:

Cambiamenti nel benchmarking:
Con un post piuttosto insolito, il blog ufficiale ha annunciato che nei prossimi giorni ci saranno dei cambiamenti nei report del benchmarking. Non capita spesso che gli ingegneri di Google – e quelli di Analytics in particolar modo – annuncino qualcosa che deve venire, a parte le major release di nuove funzionalità che vengono attivate a “ondate successive”; i cambiamenti di cose già esistenti vengono fatti e annunciati contemporaneamente. Comunque sia, quali cambiamenti non ci è dato sapere, ma se vorrete saperlo dovete assicurarvi di avere la spunta corretta selezionata: dalla schermata panoramica degli account -> “Modifica” a fianco del nome dell’account -> Condividi i miei dati Google Analytics… -> Anonimamente con Google e altri.
Vi ricordo che i rapporti di bechmark sono generati aggregando in forma anonima i dati di almeno altri 100 siti del settore del vostro sito, così scelto da Google o modificabile a vostro piacimento.

Cambiamenti nelle API:
Da qualche giorno sono state aggiunte alcune metriche e dimensioni alle API di esportazione, e precisamente: ga:dayOfWeek, ga:percentVisitsWithSearch, ga:visitsWithEvent e ga:eventsPerVisitWithEvent. Inoltre da ora in poi il codice di errore 401 verrà usato esclusivamente per segnalare i token invalidi, mentre prima veniva usato per errori più generici.

Perdita di dati:
Tramite la Google Analytics Status Dashboard veniamo informati che tra le ore 12:38 e le 14:28 (ora legale del Pacifico) alcuni dati in un datacenteer Europeo non sono stti raccolti, e sono andati persi. Il problema è comunque rientrato. A memoria mia, è la seconda volta in quasi sei anni di servizio.