Google Analytics in 30 secondi

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

L’altro giorno mi accingevo a mostrare il “famoso” metodo per escludere il proprio IP dalle statistiche quando esso non sia fisso, cioè la pagina nascosta con il valore personalizzato impostato tramite _setCustomVar() (la ex- _setVar() ).
Mi accingevo a mostrare il campo da filtrare nel “pattern filtro” della schermata di GA e non trovavo nessun riferimento. Cerce, cerca e cerca ancora, in effetti non c’è nessun riferimento!.

Questo è assolutamente incredibile, e di certo non è un vanto per Google! Google ha deprecato l’uso di _setVar() – il cui valore era richiamabile nei filtri tramite campo “definito dall’utente” – per consigliare la funzione _setCustomVar(), ma nei filtri non c’è modo di escludere o includere alcunché basandosi sui valori impostati tramite di essa!

E’ invece assolutamente possibile fare segmenti avanzati e report personalizzati usando quei valori, come testimoniato dallo screenshot:

In questo topic del forum ufficiale, ma non è il solo, altre persona lamentano questa mancanza, veramente notevole!

Marco, è tutto bellissimo, va bene. Però non ho voglia di fare mille filtri/profili per tracciare tutte le declinazioni di Universal Search. Che si fa?

E’ una richiesta legittima, d’altronde si dà sempre per scontato che quello che interessa ai gestori dei siti sia sempre una sola peculiarità di Universal Search di Google, ma magari invece non è vero. Ecco quindi un paio di filtri che vi permetteranno di avere in un profilo separato – ma unico – tutte le visite che provengono da clic fatti su ricerche “maneggiate” da Universal Search.

Il primo filtro, come sempre, esclude tutto quel che non proviene da ricerche organiche

Filtro 1: Solo google organic
filtro personalizzato – includi
campo filtro: mezzo campagna
pattern filtro: organic
maiuscole/minuscole: no

Filtro 2: traccia universal
filtro personalizzato – avanzato
campo A -> estrai A: Referral (.*)oi=([a-zA-Z_]+)&(.*)
campo B -> estrai B: Referral (\?|&)q=([^&]*)
Output in -> Constructor: Definito dall’utente $B2: $A2
Campo A obbligatorio: si
Campo B obbligatorio: si
Sostituisci campo di output: si
maiuscole/minuscole: no

Nel campo “definito dall’utente” avrete una lista di keyword seguite, dopo i due punti, dal tipo di ricerca universal che vi ha portato la visita. image piuttosto che social_search e tutti gli altri…

Il sempre ottimo Brian Clifton mette in piazza la sua personale visione sulle modalità di scelta tra segmenti avanzati e profili-clone con filtri, visto che le due cose sono molto simili e ultimamente tendono a sfumare l’una nell’altra: Brian considera i profili-clone come una segmentazione “di lunga durata”, destinata a durare nel tempo e destinata a una categoria di visitatori piuttosto importanti, dato che quelli esclusi dal filtro sono persi per sempre (nel solo profilo-clone, ovviamente).

Ecco una comparazione puntuale:

Brian quindi dice di usare i filtri sui profili per filtrare il “rumore” permanente (visite interne), quando il segmento definito è destinato ad essere usato per lungo tempo o quando c’è bisogno di controllare l’accesso ai soli dati segmentati.
Di contro, usate i segmenti avanzati quando state cercando di capire i differenti comportamenti di alcune fasce di utenti, visite da social network, visite da mobile, o se i clienti acquisiti navigano diversamente dai potenziali clienti, oppure quando c’è bisogno di condizioni basate su valori numerici (visite di persone che hanno speso più di 100 dollari per transazione e che restano sul sito almeno 30 secondi).

Direi che mi trovo sostanzialmente d’accordo con Clifton, e che già ora è questo l’uso che faccio dei segmenti avanzati e dei filtri applicati a profili-clone, anche se ultimamente mi è capitato molto meno di creare filtri al profilo. Potrebbe dipendere dalla tipologia di siti che analizzo, indubbiamente, ma non è detto. Capita anche a voi?

Social Search è uno degli esperimenti di Google Search che è possibile sottoscrivere in test (gli altri due al momento sono keyboard shortcut e accessible view). In sostanza è una speciale categoria di ricerche che si preoccupa di cercare contenuti rilevanti per la query da noi inserita nel motore, all’interno della nostra rete di amici e conoscenti online. Il cosiddetto “circolo sociale”.

La settimana scorsa Giorgio Taverniti mi ha chiesto come si potessero tracciare queste ricerche in Analytics, poiché stava preparando il suo intervento al ConvegnoGT 2009. Poiché un giorno Social Search potrebbe essere promosso a funzione ufficiale, eccovi il metodo che ho impiegato, che poi è sostanzialmente una modifica di quello che abbiamo usato per tracciare separatamente i risultati illustrati mantenendo la keyword:

Anche in questo caso servono tre filtri per fare tutta l’operazione. Possiamo pensare a Social Search come a una “branca” di Universal search. Il referrer di una ricerca Social avrà al suo interno il parametro oi=social_search oppure il parametro tbs=frim:1. Poiché ho avuto qualche problema con il filtro in presenza dei due punti, ho inserito soltanto tbs=frim. Ecco i tre filtri:

primo filtro, di tipo personalizzato – avanzato:
nome: SocialSearch – cambia sorgente
Campo A -> Estrai A -> Referral -> (\?|&)q=([^&]*)
Campo B -> Estrai B -> Referral -> (tbs=frim)|(oi=social_search)
Output in -> Constructor -> Sorgente campagna -> Google Social Search
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

secondo filtro, di tipo personalizzato – avanzato
nome: SocialSearch – estrai keyword
Campo A -> Estrai A -> Referral -> (\?|&)q=([^&]*)
Campo B -> Estrai B -> Referral -> (tbs=frim)|(oi=social_search)
Output in -> Constructor -> Termine della campagna -> $A2
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

terzo filtro, di tipo personalizzato – avanzato
nome: SocialSearch – cambia mezzo
Campo A -> Estrai A -> Referral -> (\?|&)q=([^&]*)
Campo B -> Estrai B -> Referral -> (tbs=frim)|(oi=social_search)
Output in -> Constructor -> Mezzo della campagna -> SocialSearch
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

Il risultato dell’operazione sarà poi visibile nel report “tutte le sorgenti di traffico” e sarà segmentabile per parola chiave.
Se vi siete iscritti all’esperimento (che lo ricordo funziona solo su google.com e solo in lingua inglese) avrete notato che Social è solo l’ultima delle scelte nelle opzioni della barra laterale. Ognuna di esse ha un parametro che la distingue, e che potrebbe essere usato modo simile a quanto ho fatto io. Ve li elenco:

Images ha il parametro tbs=isch:1
Videos ha il parametro tbs=vid:1
News ha il parametro tbs=nws:1
Blogs ha il parametro tbs=blg:1
Books ha il parametro tbs=bks:1
Forums ha il parametro tbs=frm:1
Social ha il parametro tbs=frim:1
Edit 9/12: Real-time ha il parametro rltm:1 [Google ha lanciato la ricerca real-time, è anch'essa è disponibile su google.com nella medesima barra delle opzioni]