Google Analytics in 30 secondi

Dicevo giustamente nello scorso post “riuscirà il team di Google Analytics a stare buono buonino una settimana?”
evidentemente no! mentre ero in ferie ci sono state due novità, che vado adesso ad illustrare con il dovuto ritardo:

comparazione temporale:
Quando adesso si seleziona “confronta con” nell’intervallo di date è disponibile un menu a tendina con tre opzioni: personalizzato, periodo precedente e anno precedente. Il primo ci permette di selezionare manualmente le date, il secondo attiva il confronto con il periodo precedente, come è stato fino ad ora, e il terzo attiva il confronto con il medesimo periodo dell’anno precedente. Soprattutto l’ultima è molto comoda, specie per rapidi check al volo.

scorciatoie:
Le piccole cose che fanno grande questo prodotto! Quante volte in vita vostra avete maledetto l’assenza di un’opzione per salvare le decine di configurazioni che avete fatto per arrivare ad un certo report? scelgo il report, passo alla scheda e-commerce, metto un filtro alla tabella, applico due segmenti, seleziono la visualizzazione a torta, cambio l’ordine di una colonna. Me lo ricorderò la prossima volta?
Da adesso non c’è più problema: nella barra grigia in alto c’è un nuovo pulsante – Scorciatoia – che permette di salvare la visualizzazione così com’è (escluso il periodo temporale, naturalmente). Lo premo e il mio report finisce in un’area della Home che si chiama Collegamenti: posso dargli un nome mnemonico e riaprirlo così come l’ho salvato quando voglio. Un notevole risparmio di tempo, e una modifica piccola ma che nel lungo periodo può far risparmiare ore di lavoro!

Da qualche giorno nel report delle pagine principali, all’interno della sezione dei contenuti, è comparsa la colonna delle metriche ACCESSI. In realtà è equivalente a dire visite, ma siccome è riferito alle landing page lo chiamano così. Il problema è che in realtà non siamo nel report delle landing pages, delle pagine di destinazione, ma nel report dei contenuti. E quindi?

E quindi questa è la risposta sbagliata ad un problema che esiste da sempre: la frequenza di rimbalzo nel report dei contenuti non è riferita al numero di pagine viste di ogni pagina, ma al numero di volte in cui quella pagina è stata la prima di ogni visita; una landing page, appunto. Questa cosa l’avevo già evidenziata tempo fa, auspicando che la metrica “frequenza di rimbalzo” fosse rimossa da quel report; l’unico posto sensato in cui guardare la frequenza di rimbalzo è infatti il report delle landing page.

Il team di Google invece ha deciso di perseguire la strada contrario, mettendo la metrica accessi nel report dei contenuti: esattamente l’opposto di quanto sperato. Per fortuna si può sempre ovviare con un custom report…

Sono incappato in un interessante post su customreportsharing.com: quali sono i limiti assoluti, intesi come imposti dalla piattaforma o dagli ingegneri di Google, di Analytics? Ecco le risposte che sono uscite fuori:

100 account (200 per gli account certificati, qualsiasi cosa voglia dire)
50 profili per account

500 richieste alla gif per sessione
10 richieste massime in 5 secondi
5 variabili custom per ogni richiesta (ma sono 50 per GA Premium)

256 caratteri nei filtri di visualizzazione
4 segmenti avanzati massimi contemporaneamente (sono 8 solo col confronto temporale)
5 tab per ogni custom report
5 gruppi di metriche per custom report
5 dimensioni annidate per custom report
5 filtri per ogni custom report
10 metriche per ogni gruppo di metriche nei custom report
50 caratteri massimi per il nome di un custom report, per il nome di un gruppo di metriche, per il nome di una tab
500 il numero massimo di righe esportabili per ogni report (ma esiste un trucco e lo sappiamo…)

80 è invece il massimo numero di caratteri nel nome di un alert personalizzato

256 caratteri massimo per il nome di un GOAL
20 goal per profilo
5 gruppi di goal per profilo
5 goal per gruppo
10 passaggi al massimo per ogni funnel che precede un GOAL
99999999999999999999999999999999 è invece il valore massimo che si può attribuire a un GOAL

sembrerebbe non esistere, o non è stato trovato, un limite alle condizioni che si possono impostare nella definizione di un segmento avanzato

12 widget per ogni dashboard
(20 dashboard per profilo, ne sono quasi certo anche se non è elencato nel post)
65536 caratteri massimi nel nome di una dashboard

50000 visite al giorno (in realtà non è un limite, ovviamente: l’help dice che se si inviano più di 50000 visite al giorno si perde l’elaborazione delle informazioni continua ed essa viene fatta una volta al giorno, alle 12:00 UTC (le 2 del mattino pomeriggio in Italia), e il processo dura circa 10 ore)
10 milioni di hits alla gif al mese – PER ACCOUNT

50000 richieste al giorno per ogni progetto che usa le API
10 query al secondo per IP
4 richieste contemporanee dallo stesso IP
non più di 10 richieste al secondo per IP per TUTTE le Google API insieme
10000 richieste al giorno per profilo
10 richieste contemporanee per profilo

Mancano ancora informazioni circa il numero massimo di custom report, di categorie di custom report, di alert per profilo e di utenti cui può essere dato accesso a un profilo. Per cui se siete incorsi in qualcuno di questi limiti, segnalatelo!

Quanti di voi, guardando il report in tempo reale, si sono domandati da quale isola o barca provengono quelle visite che si vedono al largo delle coste tra la Nigeria e il Gabon? In effetti è vicino all’isola di Sant’Elena, e ad Ascensione, ma non corrisponde a nessuna delle due. Non è nemmeno Sao Tomé. Non si tratta di una piattaforma petrolifera, dalla quale tramite una connessione satellitare stanno visitando il vostro sito, e non si tratta nemmeno di una nave.

Siccome è un fenomeno che ho rilevato su moltissimi profili, ho sempre saputo che si trattasse di un errore di Google Analytics, ma non ho mai riflettuto abbastanza sul perché si presentasse. La risposta me l’ha data qualche tempo fa Alessandro Sinigaglia, con il quale si stavano guardando i report in tempo reale. “E’ la coordinata 0,0” mi fa, come se fosse la cosa più naturale del mondo. E ovviamente ha ragione. Il perché questo accada, con precisione non lo so tutt’ora: ma so che quando arriva una visita per capire da dove essa provenga Analytics guarda l’indirizzo IP e consulta il suo enorme geodatabase.
Per fare questa operazione nei “normali” tempi di elaborazione dei report impiega il tempo che ci vuole, per farla nei report real-time ha ovviamente molto meno tempo a disposizione, perché la visita deve essere mostrata subito all’utente: se per qualche motivo l’operazione non riesce, mi sono fatto l’idea che piuttosto che ritentare GA preferisca andare avanti, e gli assegni le coordinate di default 0,0, che poi la mappa mostra e visualizza correttamente.

Infatti per gli stessi report in cui si verifica il fenomeno non rilevo poi visite da Nigeria e paesi limitrofi, segno che si tratta solo di un problema col geocoder del real-time

Escludendo i social-plugin, che richiedono un settaggio apposito sul sito, il bello dei nuovi report sociali è che si attivano da soli, senza bisogno di fare nulla. Nessuna azione è richiesta all’utente, e la magia si compie da sé. E allora che cosa è e a cosa serve quella tab che si vede accedendo all’Amministrazione di un profilo, quella tab chiamata IMPOSTAZIONI SOCIALI e che riporto nell’immagine in apertura?

Si tratta di una serie di campi (se ne possono aggiungere tramite il pulsante + posto alla destra del form) che permettono di AGGIUNGERE altre fonti da considerare nei social report. Cioè di URL che contengono contenuti sociali relativi al nostro sito. L’esempio che fa Google Analytics calza a pennello: il nostro canale youtube contiene sicuramente delle attività sociali, quindi è giusto farlo confluire nei report sociali. Ci sono però due cose da tenere a mente:

1. molto importante: come sottolineato anche dalla schermata di configurazione, se si inserisce uno o più URL in quel campo è necessario anche riportare l’indirizzo del sito tracciato. Questo perché per impostazione predefinita i report sociali tracciano il sito impostato nel profilo di GA, ma se andiamo a toccare questo settaggio allora lui vuole la lista completa degli URL; mi sembra abbastanza assurdo, ma al momento è così.
2. secondariamente: non immaginatevi di trasformare quei report in uno strumento di analisi della concorrenza. Non è che inserendo qualsiasi url i report sociali si popoleranno con i dati delle condivisioni e delle citazioni di quell’URL! ci ho sperato per un secondo anche io (ho provato a vedere cosa si diceva del sito nasa.gov ), ma evidentemente non è così. L’help ufficiale ci viene in aiuto e recita “Activities data is only shown for properties from which your domain has received hits. (I dati delle attività vengono mostrati solo per le proprietà web dalle quali il vostro dominio ha ricevuto visite).

Vi eravate accorti di questa possibilità?

Subito la premessa: il metodo descritto non è stato da me testato, questa è una pura segnalazione! tuttavia è stato scritto un mese fa, non dovrebbero esserci stati sconvolgimenti colossali nel frattempo.

Se analizzate spesso i report mobile, vi sarete accorti che alle righe Iphone e Ipad dei report sui sistemi operativi non corrispondono dei drilldown con le versioni dello stesso (iOS 5, iOS 5.1, eccetera…). La cosa è meno vera per i dispositivi Android, e in parte vera per altri sistemi. La cosa potrebbe avere una certa influenza, a seconda del tipo di business in cui operate, per cui Jay Taylor di Fresh Egg se ne è uscito con una soluzione per ovviare al problema:

il primo passo da fare è quello di scaricare la libreria – trovate il link sul suo sito – e referenziarla PRIMA del codice di Google Analytics.
Secondariamente si deve aggiungere la seguente riga al codice di monitoraggio
_gaq.push(function() { checkMobileAgent(); });
Jay dice di metterla prima o dopo _trackPageview, io la metterei prima.
Terzo bisogna mettere in piedi dei filtri personalizzati.

Filtro 1 – Capture Mobile OS Platform from User Defined
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: definito dall’utente
Campo A -> regex: ^([^:]+)::.+$
Output To -> Constructor: piattaforma del sistema operativo visitatore
Output To -> Constructor value: $A1

Filtro 2 – Capture Mobile OS Version from User Defined
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: definito dall’utente
Campo A -> regex: ^[^:]+::(.+)$
Output To -> Constructor: piattaforma del sistema operativo visitatore
Output To -> Constructor value: $A1

Prestate attenzione alle espressioni regolare, differiscono di pochissimo. Altra cosa interessante del metodo è che usa il valore definito dall’utente impostato tramite la deprecata funzione _setVar, ma aggiunge un terzo filtro che svuota il valore definito dall’utente prima che esso arrivi ai report; in questo modo il relativo rapporto sarà vuoto, oppure se avete degli altri filtri che usano quel campo li potrete accordare a questi tre, e continueranno a funzionare.

Filtro 3 – Prevent __utmv Cookie Data writing to User Defined report
Tipo filtro: personalizzato, avanzato
Campo A -> Estrai A: User-Defined
Campo A -> regex: (.*)
Output To -> Constructor: definito dall’utente
Output To -> Constructor value: (not set)

Il sistema funziona se e solo se lo user agent utilizzato per visitare il vostro sito da mobile corrisponde a uno di questi sistemi: “iPhone”, “iPod”, “iPad”, “Android”, “webOS”, “BlackBerry”, e quindi il nuovo drilldown relativo sarà presente solo per questi sistemi operativi. Ma come vedete dallo screenshot di Jay, direi che funziona!

Qualche mese fa scrissi un post (aggirare il limite dei 50.000 URL giornalieri) con una tecnica per venire a capo di situazioni in cui si vuole analizzare il report delle pagine ma si ha a che fare con siti che inviano più di 50 mila diverse pagine al giorno.
Il problema in realtà si presenta per qualsiasi dimensione: 50 mila è un limite invalicabile del processo di precalcolo dei report di Google Analytics. Nessun dato viene perso, sia chiaro, semplicemente i dati relativi alle eccedenze vengono memorizzati ma mostrati aggregati sotto la riga (other). Ce lo spiega Nick Mihailovski su Google+.

Però… c’è un però. Il limite interviene nel precalcolo dei report, cioè nei report che GA calcola normalmente e che ci mostra quando apriamo il prodotto. Esistono situazioni in cui il motore di Analytics calcola i dati al volo, ad esempio quando creiamo e/o applichiamo un segmento avanzato, che di norma non può essere precalcolato perché dipendente da infinite combinazioni.
Per questo motivo Nick semplifica l’intuizione dei ragazzi di Tatvic di cui vi parlai a Ottobre, e la rende il classico uovo di Colombo: se creiamo un segmento avanzato che intercetti TUTTE le visite, il motore è costretto a interrogare il database e a mostrarci anche quel che c’è dentro ad (other). Ad esempio un segmento così

(INCLUDI – Tipo di visitatore – con espr. reg – .*)

è nominalmente la stessa cosa che applicare il segmento TUTTE LE VISITE, ma essendo un segmento avanzato costringe GA a interrogare il database e a fornirci quel che cerchiamo.

Il limite superiore di questa tecnica è il limite del campionamento: se in dato periodo abbiamo più di 50.000 record per la dimensione, possiamo applicare questo trucco purché l’interrogazione non coinvolga più di 500.000 visite, poiché altrimenti interverrebbe il campionamento.
Spero che vi possa essere utile nelle vostre analisi. E grazie Nick!

Su Twitter scherzando ho detto che non riesco a star dietro a tutti gli aggiornamenti che il team fa al prodotto, ma pensandoci meglio in effetti tanto scherzo non è…
Fatto sta che ieri hanno annunciato alcune migliorie ai report sui flussi di visitatori.
La prima novità sono i flussi di eventi, e rappresentano sequenze di eventi che i visitatori eseguono, al pari delle sequenze di pagine che vedono. Se ad esempio avete tracciato il vostro video player con gli eventi, potrete vedere le sequenze di play, pause, stop, eccetera che vengono fatte su di esso.
Seconda novità: la comparazione temporale tra flussi di visite: questa me l’aspettavo, perché se i flussi aiutano ad ottimizzare l’esperienza dell’utente, la comparazione temporale è il miglior modo per analizzare se le modifiche hanno avuto successo o meno. Sostanzialmente aggiunge le percentuali di variazione nei nodi dei vari flussi, evidenziando ovviamente in verde quelle positive e in rosso quelle negative. Non solo, la comparazione viene effettuata anche sulle singole interconnessioni tra i nodi, e anche sugli abbandoni!

Infine, come se non bastasse, i goal flow adesso supportano anche gli obiettivi di engagement come tempo sul sito o profondità della visita.

Negli ultimi giorni c’è stata una grande accelerata nel rilascio di quelle migliorie che preludono il passaggio definitivo alla versione v5 di Google Analytics: il grande mantra di questi mesi è sempre stato “non faremo sparire la v4 fino a che tutte le sue funzionalità non siano passate alla v5″. E quindi abbiamo assistito prima a un piccolo redesign dell’interfaccia, con contestuale re-introduzione della condivisione di segmenti, custom report e dashboard, poi alla comparsa in alcuni account dei pulsanti “esporta in PDF” e “invia per email” (ad esempio Sebastiano Montino ce li ha, io ancora no ).

La novità di oggi è che nella panoramica degli account sono tornate le stelline per selezionare solo i profili preferiti, e soprattutto una feature chiesta a gran voce da moltissimi utenti: la presenza dell’andamento dei profili direttamente nella panoramica. guardate questo screenshot (clic per ingrandire)

[edit: dopo poche ore quella visualizzazione è scomparsa. forse un test, forse è stata ritirata prima di andare live per tutti. vedremo nei prossimi giorni]

Non si può cambiare il periodo selezionato come nella vecchia versione (è bloccato sugli ultimi 30 giorni comparati ai precedenti 30), ma è comunque utile. E ora che lo rivedo, capisco quanto ne sentissi anche io la mancanza

Direi che non manca più molto al “pareggio” delle funzionalità e quindi all’abbandono della vecchia interfaccia. Decisamente in ritardo – fu annunciato il 2 novembre – ma comunque meglio tardi che mai. Vi ricordo anche la mia pagina radar, per essere sempre aggiornati sullo stato degli upgrade

Il problema delle keyword (not provided), non fornite da Google per gli utenti che fanno ricerche mentre sono loggati, è destinato ad aggravarsi nei prossimi giorni, con la progressiva adozione della “censura” anche nelle declinazioni nazionali del famoso motore di ricerca.
Per fortuna non ho ancor avuto modo di scontrarmi con profili con alti numeri di keyword nascoste, ma siccome nella vita non si può mai sapere, vi segnalo questo post di Ani Lòpez che descrive un metodo per “spalmarle” proporzionalmente sulle chiavi branded e su quelle non-branded. Rispetto all’approccio “non tocco niente e considero le (not provided) come una terza categoria di chiavi”, il metodo di Ani ha il vantaggio della semplicità – ci sono due formule sempre uguali da applicare – e lo svantaggio che al crescere della percentuale di (not provided) sul totale diminuisce l’affidabilità del sistema.

Se volete cimentarvi, le formule sono quelle illustrate in figura

mentre in calce al suo post trovate anche un link ad un foglio Excel già pronto dove dovrete soltanto immettere i dati.