Google Analytics in 30 secondi

Tra le ormai pressoché quotidiane novità che abbracciano lo strumento (tipo oggi ho visto i nuovi goal in un tweet di Jehoshua Coren), i filtri non vengono toccati da un po’ di tempo. E’ vero che sono un punto nevralgico del sistema, perché le modifiche ai dati sono permanenti, ma di norma aggiungere qualcosa non è mai foriero di problemi.

Infatti oggi il team di Analytics ci informa sul blog ufficiale che sono disponibili 10 nuovi campi relativi al mobile, 3 relativi ai social, 3 relativi a contenuti e traffico e 1 per l’ecommerce. La lista è sul post del blog ufficiale, e alcuni di essi sono piuttosto interessanti: mi riferisco in particolare a “hit type”, che consentirebbe, ad esempio, di avere un profilo che registra solo e soltanto le transazioni. Oppure a “internal search term”, che consente di fare una cosa che, incredibile a dirsi, era fino ad ora impossibile: rendere tutte le ricerche interne minuscole, per normalizzare il report.

Altra novità (o almeno presunta tale, io non mi ricordo di aver mai visto quella pagina) è la lista completa di tutti i campi filtro e relativa spiegazione, disponibile in lingua inglese a questo indirizzo https://support.google.com/analytics/answer/1034380 o in italiano a questo altro url: https://support.google.com/analytics/answer/1034380?hl=it&uls=it

Mi è capitato recentemente un caso che non vedevo da tempo, e anche se ne ho già parlato in passato è utile una ripassata, perché è una di quelle cose piccole che può far perdere tanto tempo.

Il caso, nella sua forma più estrema, è questo: un profilo non traccia niente, nonostante il codice sia installato correttamente.
Innanzitutto mi accerto che il codice sia davvero installato correttamente: a questo proposito l’estensione GA debug di Google è senza dubbio quella che dà più informazioni in assoluto. Siccome il codice c’è, e le chiamate partono, il problema deve essere per forza nel profilo: di solito è un problema con i filtri, e infatti il profilo dovrebbe raccogliere dati da tre diversi sottodomini. Sono stati quindi approntati tre distinti filtri sul nome host:

• includi solo l’host a.sito.it
• includi solo l’host b.sito.it
• includi solo l’host c.sito.it

Nella testa delle persone, che ragionano come persone, questo si tramute in italiano in “includi solo il traffico da a, oppure da b, oppure da c”. In realtà l’analisi delle hit nei filtri di Google Analytics è sequenziale, e le hit per essere accettate devono passare sempre da tutti i filtri di inclusione.

Quel che accade nel server di Google, che ragiona come un computer, è quindi questo:

ARRIVA UNA HIT DA QUALSIASI ALTRO HOST: il server la passa al primo filtro, e siccome non soddisfa la condizione viene scartata.
ARRIVA UNA HIT DA A: il server la passa attraverso il primo filtro, e soddisfa la condizione, la passa al secondo filtro, ma non soddisfa la condizione: viene scartata.
ARRIVA UNA HIT DA B: al primo filtro viene già scartata.
ARRIVA UNA HIT DA C: al primo filtro viene già scartata.

Anche cambiando l’ordine dei filtri – adesso capite perché è possibile impostare un ordine? – il risultato non cambia; nessuna hit arriverà mai al profilo.

La soluzione è fare un unico filtro di inclusione con espressione regolare (a|b|c)\.sito\.it, in modo che ogni hit debba rispondere ad una sola domanda del server: “questa hit arriva da a OPPURE b OPPURE c?”. tutte le volte che la risposta è “si”, il profilo riceverà quella hit e le informazioni relative.

Il problema potrebbe essere esteso a tutti i casi in cui si debba utilizzare più filtri di inclusione sullo stesso campo, quindi ad esempio “includi solo questi indirizzi IP”, “includi solo queste pagine” e così via. Il consiglio è sempre “un solo filtro di inclusione per campo“.

Sebbene sia un caso un po’ di nicchia, potrebbe esservi capitato di avere due domini o sottodomini tracciati con lo stesso codice, quindi di avere almeno due profili filtrati sulla base del nome host, in cui uno di essi usa il tracking dell’ecommerce; vi sarete sicuramente accorti che le transazioni finiscono in entrambi i report, che non sono filtrabili. Più in generale, i dati dell’ecommerce non venivano mai legati ai dati di livello pagina (altra cosa che non si poteva fare era un filtro del tipo “escludi le transazioni provenienti dalla pagina x”).

Nel prossimo futuro invece questa situazione verrà risolta, ed inoltre verrà esteso il supporto all’utilizzo delle variabili personalizzate nei dati di ecommerce.

Justin Cutroni, che ormai è una fonte ufficiale Google, ha annunciato su Google+ che da qualche giorno sono disponibili dei nuovi campi filtro, che potrete utilizzare per filtrare i dati nei vostri profili. Più precisamente si tratta di:

• Cellulare del visitatore? (orrenda traduzione di “visitor Mobile?”) che identifica se l’utente naviga da mobile o no
• Categoria Evento
• Azione Evento
• Etichetta Evento
• Continente del visitatore

I campi filtro sono inoltre stati riorganizzati e raggruppati logicamente, così da poter essere trovati più facilmente. Con mio sommo disappunto non è stato implementato il filtro sulle variabili personalizzate (quantomeno su quelle impostate con scope=1, cioè permanenti nei browser degli utenti). Questo, ad esempio, ci costringe a usare soluzioni “con la toppa” quando si tratta ad esempio di escludere le proprie visite con un IP dinamico: si veda in proposito questo articolo di Enrico Pavan, in cui si è costretti ad usare ancora la deprecata funzione _setVar (e la sintassi sincrona, anche se io ed Enrico dobbiamo ancora fare due test congiunti per verificare la sua ipotesi illustrata nei commenti).

Altra bella segnalazione, sempre di Justin e sempre su G+, è questa relativa allo script per GreaseMonkey AnnotationManager, che vi consente di copiare annotazioni tra profili/account, rimuoverne molte con un solo clic o anche esportarle. Mi è di recente capitato di dover inserire una annotazione su un profilo: l’ho dovuta ripetere nel profilo di quel sito, nel profilo master senza filtri e in un altro profilo in cui quel sito era combinato con due sottomini. Con AnnotationManager probabilmente avrei risolto con 3 click. Essendo uno script per GreaseMonkey però, è disponibile solo per Firefox/Chrome.

Ultima segnalazione è questo post di Brian Clifton (tra l’altro, come ho detto in questo commento, sta per uscire la versione 3.0 del suo ottimo libro) che riassume gli ultimi studi usciti sulla diffusione di Google Analytics nel web: vari post che più o meno vi avevo segnalato a tempo debito, ma che riassunti così fanno comunque una certa impressione: il 50% del web usa GA, il 45% delle top500 Fortune companies, l’86% di un campione di 800 imprenditori… più esplicativo di così…

Avevo iniziato a scrivere un commento direttamente sul post, ma stava diventando troppo lungo per cui mi scuso sin da ora se ne faccio un post a mia volta. Mi è capitato l’occhio su questo articolo di Filippo Sogus su come filtrare i referrer spam forex-ninjas.com e rock.to, che alcuni di voi potrebbero aver visto nei propri report (a me è successo). Non conosco Filippo, e spero che non se ne avrà a male se faccio due correzioni, la prima delle quali mi consente anche di affrontare un equivoco che ho sempre dimenticato di chiarire su questo blog:

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

Secondo TechCrunch Google+ è diventata in breve tempo una delle fonti principali di traffico al loro blog. Non si può sapere se per via dell’euforia della novità o perché effettivamente costituisce un buon veicolo di informazioni (il che farebbe ben sperare, dato che al momento tutto va fatto a mano e non ci sono meccanismi di import automatico di nulla)…

Comunque sia, visto che Google+ è attestato sul protocollo https per questioni di maggiore sicurezza, i link postati lì dentro non dovrebbero generare referrer secondo le specifiche HTTP. Ma Google ha optato per un redirect intermedio [edit 7/7/11: non è un redirect lato server, ovviamente. Se avete curiosità tecniche Simone Rinzivillo ha un post in cui spiega come fa Google a tenere il sorgente "pulito" ma indirizzare verso un indirizzo intermedio] su http normale che invece il referrer lo genera. E quindi le visite a link cliccati su Google+ vengono viste dai sistemi di tracking come Google Analytics come normali referrer, però essendo di una property della serie “google.com” essi sono affogati nello stesso referrer di Google Reader, ad esempio.

Se per qualche motivo volete separarlo e tracciare Google Plus separatamente, basta un solo filtro (clicca per ingrandire):

Filtro GooglePlus – personalizzato / avanzato
Campo A -> Estrai A: Referral – google\.com/url\?sa\=z
Campo B -> Estrai B: (vuoto)
Output in -> Constructor: Sorgente Campagna – google-plus
Campo A obbligatorio: Sì
Campo B obbligatorio: No
Sovrascrivi campo output: Sì
Maiuscole/minuscole: No

Il risultato è esattamente quello atteso, cioè la separazione delle visite provenienti da Google+ da quelle del resto della galassia Google:

Ora che – finalmente – Google Shopping è sbarcato anche in Italia, molti si stanno ponendo la fatidica domanda: “come traccio il tutto su Google Analytics?”. Domanda legittima, per capire l’impatto sul traffico di un nuovo motore di ricerca verticale – peraltro presente anche tra le opzioni della ricerca “classica”, e per determinare il ROI dell’effort richiesto a far sì che i nostri prodotti siano nelle liste del motore.

Poiché purtroppo non ho siti miei o di clienti listati in Product Search, e che quindi non ho modo attualmente di verificare direttamente la bontà di questo metodo, devo allora affidarmi ad una soluzione già confezionata, che però dovrebbe funzionare: la scrisse qualche mese fa il blog state of search. Sostanzialmente si tratta di aggiungere un filtro personalizzato avanzato:

Campo A -> Estrai A
Referral -> google\.it\/products

Campo B -> Estrai B
Mezzo -> organic

Output in -> Constructor
Sorgente -> Google Shopping
Campo A richiesto: si
Campo B richiesto: si
Sovrascrivi campo output: si
Maiuscole/minuscole: no

Sostanzialmente, poiché non si cambia il mezzo che resta organic, GA capisce da solo che si tratta sempre di un motore di ricerca, e lo processa esattamente come Google classico, estraendo la keyword usata dal parametro “q”, ma noi cambiamo la sorgente e la isoliamo dal resto modificandola in “Google Shopping”. Questo ci permette di avere al volo la possibilità di isolare le visite provenienti dal motore verticare e capire quali keyword sono state usate, per quali prodotti, su quali landing pages, eccetera…

[edit: come mi fa notare @gpelagatti, si possono anche impostare i normali URL con i parametri delle campagne; non l'ho scritto perché avevo idea che essendo una campagna Analytics non estraesse la keyword usata dal visitatore per trovare il prodotto, ma il suo screenshot è eloquente e mi sbagliavo: a questo punto, dato che siamo nella sperimentazione, varrebbe la pena di provare a impostare i parametri taggati mantenendo "organic" come medium e "google.it" come source, e cambiando solo il campaign. Oppure, come discusso con Tommaso Galli, impostare "organic" come medium, "google-shopping" come source e campaign a piacimento, e vedere se GA lo tiene nei motori di ricerca e mantiene la keyword.

In ogni caso, grazie a entrambi per gli punti ]

La novità del giorno, immagino lo sappiate, è la nuova ricerca in tempo reale di Google, che compone la pagina dei risultati mentre voi digitate la query di ricerca, addirittura tentando di prevedere quel che volete sapere. Non mi dilungherò sulla tecnologia e sulle sue implicazioni per i SEO (Search Engine Optimizer), non mi compete e non è la questa la sede. Se siete curiosi ecco il post di presentazione inglese, con video, e il link per istruire Google a farvi provare questa nuova esperienza. Quello di cui volevo parlare, in clamoroso ritardo a causa del fatto che in ufficio Instant Search non funziona e non ho potuto fare prove (pare che sia un problema comune a chi ha un proxy Squid) è il fitto tam-tam dei post che pretendono di indicare come tracciare questa novità.

Il primo post che mi è capitato sotto mano è di webdistortion.com, che pochi minuti dopo l’annuncio di Instant Search ha prodotto la regular expression dedicata. Ho montato il filtro ieri sera, con le opportune modifiche per il mercato italiano e stamattina non c’era nulla; ho fatto altre semplificazioni, mi sono cercato, trovato e cliccato, ma semplicemente il filtro non funziona.

Il secondo link, più interessante, propone una versione del filtro che mi piace di più. Si tratta di semetrical.com (e in particolar modo meglio ancora la modifica suggerita nei commenti, mettendo il risultato dell’estrazione nel campo definito dall’utente, fatta salva la limitazione a 50000 valori al giorno). Questo filtro non l’ho ancora provato, ma sono pronto a scommettere che anch’esso non darà i risultati sperati. Questo perché – come Giovanni ha già detto su Twitter (e come conferma anche il blog ufficiale di Analytics) – il referral non sempre contiene questo parametro oq. Anzi…

Cercando tambu se su Instant Search il secondo risultato è il mio blog personale. L’url della SERP dei risultati è questa

http://www.google.it/#hl=it&expIds=17259,18167,25856,25901,26446,26518&xhr=t&q=tambu+se&cp=8&pf=p&sclient=psy&aq=f&aqi=g4g-o1&aql=&oq=tambu+se&gs_rfai=&pbx=1&fp=5eaace2684328452

Abilitando il debug di Google Analytics per Chrome e cliccando il link, il codice di tracciamento ci informa che il referral interpretato da Analytics (che è poi l’unica cosa che conta per lui, a prescindere dall’indirizzo che vediamo su Google) è invece questo

http://www.google.it/url?sa=t&source=web&cd=2&sqi=2&ved=0CBsQFjAB&url=http%3A%2F%2Fblog.tambuweb.it%2F2010%2F02%2F09%2Fmicrofono-non-funziona-sound-blaser-audigy-se%2F&rct=j&q=tambu%20se&ei=PjiJTO-GNN3NjAfToL1k&usg=AFQjCNHmr_wiYv00Nzau7lUdhcTgbt2VrA&sig2=SEK1Pf6ZlEVlPQ8kJBR0Zg

Per cui nemmeno il filtro proposto, per quanto migliorato, estrarrebbe alcunché di utile da mettere nei nostri report. Quindi, allo stato attuale, possiamo al massimo implementare un filtro di prova su un profilo-copia e stare a vedere cosa succede. Se anche succedesse qualcosa, probabilmente non succederebbe per tutte le query, o peggio ancora potrebbe succedere a fasi alternate per la stessa query. E non c’è niente di più irritante in analisi di avere dati incerti e/o incompleti. Per cui sino a quando non si sarà fatta più luce su questa grande novità potete praticamente dimenticarvi di sapere le digitazioni parziali dei vostri utenti!

Non mi ero mai trovato a dover creare un profilo per tracciare una sottodirectory, e per questo non conoscevo questo “bug” di Google Analytics. In realtà non è proprio un bug, ma più una carenza di chiarezza dell’interfaccia. Supponiamo di voler fare un profilo con un filtro di inclusione solo per la sottodirectory /scarpe/ del nostro sito. Si può fare con un filtro personalizzato di inclusione e una regular expression, naturalmente, ma è anche una situazione coperta da uno dei filtri predefiniti, come potete vedere in figura:

Quale è il “problema”? che senza rifletterci bene, poiché il filtro si chiama “includi solo traffico verso le sottodirectory”, l’utente si aspetta di inserire la sottodirectory e basta, e che il terzo menu a tendina non debba essere toccato. Invece lasciando su “uguali a” Google Analytics conteggerà SOLO ed ESCLUSIVAMENTE il traffico a www.miosito.it/scarpe/ e non ad esempio www.miosito.it/scarpe/index.php e neppure www.miosito.it/scarpe/catalogo.php.

Il terzo menu a tendina, per comprendere tutte le pagine della sottodirectory, deve essere impostato su “che contiene“.

[hat tip a Daniel Jeffery]

L’altro giorno un amico mi ha detto “Marco, c’è una cosa che non quadra in Analytics. Sono certo sia una banalità ma non funziona: o non capisco qualcosa o c’è un problema! Volevo fare un segmento avanzato che mi mostrasse le keyword di arrivo, da google, non-brand e con meno di 10 visite, una sorta di “coda lunga”, ma non funziona”.

Mi sembrava effettivamente strano, ma il ragionamento successivo è stato piuttosto divertente, e niente affatto banale. Vediamo se riesco a spiegarlo anche per iscritto.
Il segmento in oggetto per questo blog potrebbe essere qualcosa di assolutamente simile a questo:

• “parola chiave” non contiene le keyword brand
• “sorgente” corrisponde esattamente a google
• “visite” è inferiore a 10

Secondo lo strumento di test questo segmento corrisponde a 1809 visite. Creandolo e andando a vedere le keyword però troviamo anche parole chiave con 90, 200, 500 visite, segno che effettivamente qualcosa sembra non funzionare. La cosa da notare è che il totale delle visite e il totale parziale della regola “visite inferiore a 10″ corrispondono, come potete vedere in questa immagine ritagliata dalla precedente:

entrambi segnano 5025 visite.
In effetti bisogna ricordare che lo scopo dei segmenti avanzati è isolare una certa porzione di traffico, o meglio un certo quantitativo di visite, che sono riconducibili a determinate regole: quindi dati determinati critieri Google Analytics ci mostra quante VISITE sono contenute in quel segmento. Come potrebbe quindi il dato visite essere una delle condizioni per identificare certe visite?

Oppure possiamo vederla da un altro punto di vista: per creare il segmento avanzato GA deve confrontare OGNI visita con i criteri applicati al segmento. Se una keyword ha portato 30 visite, come fa Analytics quando le guarda una ad una a sapere se quell’una è superiore o inferiore a un certo valore? ogni visita conta come UNA visita (quindi è inferiore a dieci, per restare all’esempio, quindi conta TUTTE le visite).

Il segmento sulla metrica “visite” quindi non ha senso. Per risolvere la domanda iniziale bisogna fare un segmento basato solo su “sorgente” e “keyword” (che mostra comunque lo stesso risultato numerico):

e soltanto dopo applicare un filtro avanzato di visualizzazione, escludendo le keyword con più di 10 visite, in questo modo:

La riprova di quanto dico si può fare guardando alle sorgenti di traffico, poi selezionando google e poi usando un filtro semplice di visualizzazione per escludere le parole chiave brand. Il numero di visite sarà esattamente uguale a quello tirato fuori dal segmento (1809 nel mio caso).

Ma allora la domanda potrebbe diventare “perché Google permette di selezionare la metrica visite nella creazione dei segmenti avanzati?”. Beh, questo proprio non lo so