In alto si legge “livello 1 percorso pagina”, e ovviamente se si clicca su una cartella la scritta cambia in “livello 2 percorso pagina”, dandoci sempre modo di capire (il famoso contesto che dobbiamo sempre dare alle analisi) a che livello di nidificazione sono i contenuti che stiamo analizzando.
Inoltre l’icona a fianco di ogni riga del report ci dà una indicazione immediata del fatto che la riga analizzata abbia al proprio interno altre pagine o sia una foglia terminale dell’alberatura del nostro sito.

Sempre nell’ottica di rendere più agevoli le nostre analisi…

I limiti delle custom var sono sempre stati: non più di 5 slot usati contemporaneamente (50 su Analytics Premium) e la lunghezza di nome + valore della variabile non eccedente i 64 caratteri. L’ultima revisione del changelog di Analytics ci informa invece che questo limite è stato raddoppiato: adesso nome + valore possono arrivare a 128 caratteri. L’ultima frase “Additionally, the length is now checked before URL encoding” mi fa tornare in mente un vecchio post letto chissà dove che affermava che in presenza di caratteri “non standard” essi andavano a erodere molti caratteri (per via dell’encoding). Pare che adesso la lunghezza venga controllata PRIMA di effetture l’econdig e l’invio a GA.

Altre modifiche di questo aggiornamento sono l’aumento del limite di eventi inviabili e un diverso modo di registrare il cookie __utmv (usa il separatore ^ invece della virgola).
Dato che c’è una nuova versione del codice di monitoraggio (la 5.2.4) e che è un po’ che non lo faccio, posto la lista dei motori di ricerca conosciuti dallo script. Sicuramente Babylon è nuovo, perché in alcuni miei profili lo vedo sempre nei referrer, altri nuovi non ne vedo (e manca sempre l’italiano arianna):

daum:q
eniro:search_word
naver:query
pchome:q
images.google:q
google:q
yahoo:p
yahoo:q
msn:q
bing:q
aol:query
aol:q
lycos:q
lycos:query
ask:q
netscape:query
cnn:query
about:terms
mamma:q
voila:rdata
virgilio:qs
live:q
baidu:wd
alice:qs
yandex:text
najdi:q
seznam:q
rakuten:qt
biglobe:q
goo.ne:MT
wp:szukaj
onet:qt
yam:k
kvasir:q
ozu:q
terra:query
rambler:query
conduit:q
babylon:q
search-results:q
avg:q
comcast:q
incredimail:q
startsiden:q

1. il primo errore è nel filtro: “traffico dai domini” è la traduzione letterale di “traffic from domains” dell’interfaccia inglese, ma entrambe si prestano a un errore di base; quel che noi dobbiamo filtrare sono le visite con un certo referrer, mentre quel campo agisce sul dominio geografico del visitatore (il fornitore della connessione, ad esempio fastweb o tiscalinet). Si veda l’articolo dell’help ufficiale “che cos’è un filtro?“, dove si legge chiaramente “Escludi il traffico proveniente dai domini: utilizza questo filtro per escludere il traffico proveniente da un dominio specifico, ad esempio un ISP o una rete aziendale.”. Il filtro che serve a noi è quindi un filtro PERSONALIZZATO di tipo ESCLUDI, con campo filtro REFERRAL e pattern filtro forex\-ninjas\.com (oppure rock\.to).
2. il secondo errore è nella frase “A questo punto, ritornando nei report Referral avrete una lista ripulita dai domini spammer.”. I filtri non sono retroattivi (i segmenti avanzati invece lo sono), quindi applicare il filtro avrà effetto solo dal momento in cui si preme SALVA in avanti. Ne consegue anche che un referrer spam può essere eliminato solo dopo che si verificano le prime visite, giacché è impossibile filtrare tutto preventivamente.

Giusto per dovere di chiarezza

Questo ovviamente non ha nessuna implicazione sui dati memorizzati da Analytics, che riguardano i nostri visitatori (in forma anonima e aggregata), e che rimangono nostri.

Quel che invece potrà cambiare, dice il post ufficiale, è che potranno usare i dati di navigazione all’interno dell’interfaccia di GA; perché molti non lo sanno, ma sull’interfaccia di Analytics… c’è Google Analytics, anche se in un forma meno canonica. Ecco qua:

<script type="text/javascript" async="" src="https://ssl.google-analytics.com/u/ga_beta.js"></script>

e poi questa chiamata

<script type="text/javascript">ga.webanalytics.header.setHeaderInfo({"email":"LAMIAEMAILINCHIARO","gUrl":"https:\/\/www.google.com\/accounts\/","tabs":{"H":1,"D":1,"CR":1,"IN":1,"A":1,"R":1,"BF":1,"GO":1,"EC":1},"style":"ANALYITCS","tab":null});ga.webanalytics.header.setLoadBaseData(true);</script>

dal che si evince anche che loro, invece, tracciano eccome i dati personali che a noi sono proibiti.

La seconda novità è che il team di Google Webmaster Tools cambierà la metrica “posizione del sito nelle SERP” che viene riportata da GWT, e di conseguenza importata da Google Analytics. Prima la metrica era la media delle posizioni rilevate, e infatti aveva anche i decimali. Se per una data keyword il sito compariva in 2° e in 5° posizione, la posizione riportata era 3.5; che aveva poco senso in sè, ma ce l’aveva eccome se si teneva presente che era appunto una media. In base alle ricerche del team, secondo loro i webmaster vogliono invece sentirsi dire la “migliore posizione tra quelle riscontrate” e quindi nell’esempio precedente la posizione riportata sarà 2.

Tenendo presente che i dati già registrati non cambieranno, per un certo periodo avremo tutti dati magnifici dopo bisognerà tenere conto di questa modifica.

Scarica il pdf e leggi l’intervista.

Inoltre, come un piccolo prezzemolino, ti segnalo miei contributi sono presenti in questi due libri, che puoi comprare o prenotare:

• Vendere online (Step by step) di Gianluca Diegoli: un libro per imparare a realizzare un ecommerce, con molti consigli utili e risposte alle domande più comuni che sorgono quando si decide di avviare un progetto di vendita digitale.
• Web Marketing per le PMI (Web & marketing 2.0) di Miriam Bertoli: un libro che vuole spiegare un concetto ampio come il web marketing alle piccole e medie imprese, che molto spesso sono ancora legate a logiche di marketing molto poco digitali.

Un po’ per empatia e un po’ per come sono fatto, tendo a interiorizzare l’ansia degli autori verso le scadenze, quando mi chiedono questi contributi. Non so se riuscirei mai a scrivere un libro io stesso

Con questa mossa Google chiude definitivamente una sorta di “bipolarismo” che in alcuni clienti ha generato confusione: “ma perché due prodotti? che differenze ci sono? perché uno traccia l’utente singolo e l’altro no?”. Per altri clienti invece, quelli che per policy sui dati o restrizioni tecniche non possono/riescono a raggiungere i server di Google, questo è un problema e dovranno dotarsi di una soluzione alternativa o continuare ad usare l’ultima versione di Urchin ad libitum.

Io sono affezionato ad Urchin, per due motivi: il primo è che l’ho usato – anzi lo uso tutt’ora su un server aziendale – e l’ho sempre trovato straordinariamente semplice, nella sua configurazione base, e veloce; la seconda – e più importante – è che senza Urchin oggi non ci sarebbe Google Analytics, e che come ogni genitore che si rispetti oggi Urchin sa benissimo chi sopravviverebbe e chi no, chi ha senso che continui ad esistere e chi no, e quindi si fa da parte. Anche perché lo sviluppo di Google Analytics, alla luce delle considerazioni fatte qualche settimana fa, procede spedito e a ritmo esponenziale, mentre Urchin ha più o meno la stessa architettura di Google Analytics v1.

Dobbiamo quindi tutti ringraziare Scott e Brett Crosby, Jack Ancone e Paul Muret, fondatori della Urchin Software Corporation, e tutto il team che lo ha sviluppato per averlo fatto esattamente come lo hanno fatto. Era un bel pezzo di software, ed è diventato un gran bel servizio online. Uno dei servizi online di maggiore successo della storia, se sono veri i numeri sulla diffusione di Google Analytics che si vedono girare di tanto in tanto…

[* il titolo è una citazione del grande Douglas Adams. image copyright wikipedia]

Invece gli errori 404 sono molto fastidiosi per gli utenti, e andrebbero sanati con azioni mirate, con redirect o altro ancora. Per questo motivo Tim Leighton-Boyce propone sul suo blog un approccio leggermente differente alla cosa, cioè l’uso di alert personalizzati; gli alert personalizzati, che finiscono nella sezione Eventi Intelligence (scheda HOME nella v5), hanno tra l’altro il grande pregio di beneficiare della funzione “contributori principali“, che ci aiuta a spiegare i segmenti maggiori che hanno portato a quel risultato. Ciliegina sulla torta, se il 404 è generato da un sito esterno, c’è il link alla pagina incriminata. Come dice Tim: “GA mi dice che c’è qualcosa di sbagliato, mi suggerisce quale può essere la causa e mi aiuta a trovare velocemente una soluzione”. Come si fa a resistere?

I punti salienti del video sono:

• assicurarsi che i 404 siano tracciati
• impostare un goal (una microconversion, dato che di norma avere 404 non è lo scopo principale di un sito) su di essi
• creare un alert personalizzato che si scateni se i 404 salgono di un tot (oppure se ce ne sono più di un tot) rispetto ad un periodo precedente.

Sono convinto che si poteva avere lo stesso risultato anche senza impostare un goal, perché le condizioni degli alert si possono applicare anche direttamente agli URL delle pagine, ma a tim piaceva di più così e così ve l’ho riportato. Altre cose utili che si possono fare sono aggiungere un widget dell’andamento dei 404 alla vostra dashboard e creare un segmento personalizzato che includa solo le visite che hanno visto uno o più 404.

Ad esempio, sono nel report delle keyword e ne clicco una per vedere solo quella, per cambiarla prima dovevo tornare all’elenco e selezionarne un’altra. Adesso invece a fianco al breadcrumb compare una frecciolina, che se cliccata apre un menu a tendina con i record “fratelli” del corrente (ad esempio per le keyword così):

e la possibilità di effettuare una ricerca. La cosa è vera per tutti i report con almeno due record.

Il massimo sarebbe se tenesse in memoria anche la selezione della dimensione secondaria – cosa al momento falsa – ma non è detto che non sia perché la feature è nuovissima e ha bisogno di ancora un pochino di rodaggio.

• richieste di riesumare account cancellati (Google può farlo, ma solo interi account e non singoli profili)
• richieste di ritornare amministratori di account in cui l’admin è scomparso, o peggio è un ex-dipendente con evidenti intenti malevoli
• richieste di conoscere la mail originale che ha aperto l’account

Almeno per questi ultimi casi è stata predisposta una form, a questo indirizzo
https://docs.google.com/spreadsheet/viewform?formkey=dEROdF9uQjF5cWV4Tk9qSzZzZndkcEE6MQ&ndplr=1, in cui è sufficiente dare l’indirizzo del sito, l’UA number relativo all’account e una mail dove essere contattati.

Se funziona tanto la rimozione da account non propri di cui vi ho parlato stiamo freschi, ma come sempre tentar non nuoce. Oppure le richieste vengono elaborate tutte insieme ogni tot giorni, non so…

[edit: nei commenti in realtà c'è il link ad una form per risolvere anche il secondo punto ]

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"]