Google Analytics in 30 secondi

Questo post è il complementare dello scorso “L’unico vero – ma insensato – modo per bloccare i ghost referrals” e ne riprende naturalmente il titolo 🙂

Si diceva che se Google dovesse fare un sistema di blocco preventivo dei ghost referrals dovrebbe studiare un sistema simile a quello descritto nel post, almeno a detta del sottoscritto. Si diceva nei commenti che forse un altro modo potrebbe essere un “segnala come spam” simile a quello di Gmail, ma che la cosa potrebbe avere problemi di workflow di approvazione.

Com’è, come non è, oggi thesempost.com ci informa che Adam Singer, Analytics advocate a Google, ha detto chiaramente durante il Mozcon che Google sta lavorando per risolvere il problema alla radice. Non ci sarà quindi da rivolgersi a terze parti ma soprattutto Singer – secondo l’articolo – ha detto che Google sta lavorando al problema in modo che la soluzione sia scalabile, ovvero che possa risolvere il problema adesso e per sempre, anche se gli spammer cambiassero i loro pattern di invio dei dati fasulli. Sembrerebbe quindi un qualcosa più simile ai filtri antispam di Gmail, ma ovviamente senza prima vederlo in azione non possiamo sbilanciarci troppo.

La creazione di un sistema definitivo spiegherebbe anche la relativa latitanza da parte di Google negli ultimi mesi durante i quali il problema è balzato alle cronache. Meglio tardi che mai, no? 🙂

Sul fenomeno dei cosiddetti ghost referrals hanno scritto più o meno tutti, ma come direbbe il buon Corrado Guzzanti interpretando uno dei suoi personaggi più riusciti (Quelo) “la risposta che cerchi è dentro di te. Solo che è SBAGLIATA!” 🙂

I ghost referrals sono delle visite che vengono registrate dai vostri Google Analytics, ma che non sono originate da veri e propri visitatori sul vostro sito. “sono bot?” no, non sono nemmeno bot, o meglio non nel senso classico con cui siamo abituati a pensare a un agente automatico che NAVIGA il sito. La gente ha difficoltà a comprendere ciò che non riesce a visualizzare, e in questo caso ciò che non riesce a visualizzare è che da qualche tempo si possono inviare dati a Google Analytics anche SENZA l’ausilio del tipico codice javascript, attraverso una cosa chiamata Measurement Protocol.

Intendiamoci, è una cosa che si è sempre potuta fare, bastava copiarsi una richiesta HTTP dell’immagine _utm.gif che veniva usata – prima di Universal Analytics – per inviare i dati ai server Google e che conteneva nei parametri tutte le informazioni necessarie al calcolo delle visite. Con il measurement protocol la cosa è stata standardizzata e ufficializzata, dando peraltro l’avvio a tutta una serie di nuove possibilità di tracking veramente incredibili (tracciare la macchinetta del caffé?)
Quello che accade è che un qualche server da qualche parte del mondo viene istruito per comporre ed effettuare centinaia di chiamate fasulle a tutte le property del mondo. Che sia un fenomeno distribuito e completamente automatizzato se ne è accorto il mio amico Enrico Pavan creando una property di un sito inesistente che ha iniziato a tracciare visite da ghost referrer, ed è confermata da alcune opinioni secondo cui le property che terminano con numeri diversi da 1 (tipo UA-XXXXXXXX-2 e oltre) non sono soggette al problema. Ora, perché non potete semplicemente fare un filtro? perché gli spammer vincono sempre, sono troppi e fanno grossi danni con poco sforzo: voi passate 3 ore a configurare 80 filtri? domani qualche spammer cambierà una lettera nel pattern delle informazioni che invia e passerà i filtri. Quindi, tanto per essere chiari:

• potete usare la “lista esclusione referral” che trovate nella configurazione della property? no, per il motivo sopra ma SOPRATTUTTO perché essa serve a trasformare in dirette (e quindi a non sovrascrivere la sorgente di traffico) le visite da alcuni domini. Quindi peggiorereste il problema
• potete filtrare uno a uno i domini referrer? se proprio volete farlo, il buon vecchio Simo Ahava ha creato un tool per voi, lo spam insertion tool che vi evita gran parte del lavoro. Ma tanto poi lo dovrete mantenere nel tempo…
• potete fare un filtro di inclusione che includa solo le visite al vostro dominio/hostname? tra tutte le alternative è forse quella che può mitigare meglio il problema, ma poiché anche l’hostname può essere inviato come parametro del measurement protocol, alcuni spammer particolarmente ostinati potrebbero aggiungere della logica per controllare l’UA su ogni host e bypassare il problema

e quindi? quindi l’unica soluzione secondo me valida dal punto di vista tecnico, ancorché completamente insensata, l’ho letta sul blog di Himanshu Sharma, Optimizesmart e consiste in un complicato metodo di codifica/decodifica di tutte le hit inviate. Per la precisione:

1. Si decide una stringa di sicurezza, ad esempio “dhffjsrr12353fdf4253kc“, per mantenere il suo esempio
2. Si antepone la stringa di sicurezza a tutte le chiamate a GA. Per farlo si modifica il codice di GA ad esempio così
   ga('send', 'pageview','dhffjsrr12353fdf4253kc' + location.pathname); o si usa un TagManager. ATTENZIONE che l’esempio riportato tronca tutte le query interne, quindi ad esempio la pagina /ricerca.html?key=asd viene tracciata solo come /ricerca.html. Dovrete ingegnarvi con un po’ di javascript per gestire tutti i casi.
3. Si crea un filtro di inclusione di tipo custom con “includi – URI della richiesta – corrisponde a espressione regolare – ^/dhffjsrr12353fdf4253kc
4. Si crea un filtro cerca e sostituisci per evitare di avere nei report degli URL orrendi. quindi filtro custom – cerca e sostituisci – URI della richiesta – cerca ^/dhffjsrr12353fdf4253kc/ – sostituisci con /. Nell’ordine dei filtri questo deve stare sotto al precedente, altrimenti non funziona nulla

Come vedete è una soluzione radicale, che va aggiustata e testata per bene prima di essere portata in produzione, e che a me sinceramente fa anche abbastanza orrore, concettualmente, perché costringe tutti a un lavoro grande e potenzialmente pericoloso per i dati. Ma è anche vero che se dovessi pensare a un metodo radicale per Google di evitare a tutti noi i ghost referrals senza uccidere il measurement protocol non mi viene in mente qualcosa di tanto diverso. Magari la chiave di sicurezza potrebbe essere generata direttamente da GA, e così il filtro di inclusione e replace, e il codice di monitoraggio potrebbe già essere fornito funzionante, ma la sostanza del problema non cambia di molto.

Con un annuncio sul G+ ufficiale, Google Analytics annuncia la nuova possibilità di filtrare bot e spider direttamente con un’opzione nella vista. La cosa ha generato un po’ di confusione, per cui mettetevi comodi e leggete.

Google Analytics, da sempre, è un sistema di web analytics basato su una libreria javascript e sui cookies. Javascript è una tecnologia che funziona sui browser degli utenti, per cui il sistema raccoglie informazioni e poi le invia ai server di Google, che le analizzano. La prima conseguenza di questa affermazione – che resta vera – è che chi non esegue javascript non esegue nemmeno il codice di Google Analytics.
Quindi se io disattivo javascript, GA non mi vede. I bot, da che mondo e mondo, non sono progettati per eseguire javascript e accettare i cookie. Questo però non vieta a nessuno di progettarne uno che invece lo faccia, è già capitato in passato e ancora può capitare. Quindi l’affermazione corretta è “Google Analytics non traccia la maggior parte dei bot”.

Recentemente è stato introdotto anche il Measurement Protocol, ovvero la possibilità di inviare dati ai server Google senza l’uso di javascript. In questo caso ovviamente i bot sono SEMPRE inclusi nel traffico. Ho testato in prima persona una soluzione che addirittura include solo il traffico dei bot in una property Google Analytics. Se invece abbiamo una property “normale” che invia parte o tutti i dati tramite Measurement Protocol, la possibilità di filtrare i bot e gli spider con una spunta è molto comoda.

La cosa era diventata praticamente necessaria anche in virtù delle complessità sempre maggiori in gioco: più i siti diventano interattivi e più gli spider devono diventare “umani” per capire cosa contengono. Questo include anche la possibilità di eseguire javascript per attivare funzioni e contenuti altrimenti inaccessibili. Ultimamente aveva fatto molto scalpore il caso AdRoll, di cui potete leggere in questo post su seroundtable. Un altro caso simile e recente è quello di semalt.

Ovviamente la nuova opzione non è risolutiva nel 100% dei casi: affinché un bot sia escluso deve fare parte della lista ufficiale IAB di bot e spider riconosciuti. La lista non è pubblica perché IAB la fa pagare agli iscritti, quindi presumo non la vedremo mai. La feature non è retroattiva, per cui dovrete tenerne conto in fase di analisi, ma avevo letto un post – che non ritrovo – che diceva che nei primi giorni l’impatto era di circa il 3% di un sito piccolo e ancora meno in un sito grande. Chiaramente dipende dal business, dal settore e da molti altri fattori. Se ritrovo il link aggiornerò il post.

Dopo aver scritto il post sulle novità del Google Tag Manager ho riflettuto su un po’ di cose che ho fatto ultimamente tramite quello strumento, realizzando che effettivamente non erano ne poche ne banali. L’intero impianto del TagManager, per come è costruito, aggiunge un ulteriore livello di possibilità che a volte integrano e a volte si sovrappongono a funzionalità core di Google Analytics. Faccio degli esempi:

• Voglio escludere le visite aziendali interne: lascio il codice ovunque e filtro gli indirizzi IP da Google Analytics. Oppure, più elegante, creo tre viste per la stessa property: una totale, una con solo le visite esterne e una con solo le visite interne, sempre con i filtri di GA. Oppure condiziono l’UA cui inviare i dati (produzione o staging/sviluppo) in base all’host. Senza scrivere una riga di codice. Plus aggiuntivo, in questo modo le hit “inutili” non intaccano il limite mensile e non incidono sul campionamento, che avviene sempre sul totale inviato pre-filtri.
• Voglio riscrivere alcuni indirizzi delle pagine: il filtro “cerca e sostituisci” di GA ha alcune limitazioni, ad esempio non permette di togliere parti (cioè di sostituire con “vuoto”), i filtri avanzati richiedono spesso regular espression e in ogni caso devo farne uno per ogni caso. Nel GTM con una macro di tipo Javascript personalizzato invece posso far scrivere a un programmatore tutta la logica necessaria a gestire molti casi, anche complessi, ed inviare ad Analytics solo quel che mi serve, nella forma che mi serve
• Voglio condizionare un certo tag sulla base di una informazione che è esistita solo in un dato momento passato: posso scriverla in un cookie e leggerla in un secondo momento, sempre senza mettere mano al sito e scrivendo poche righe di codice nel GTM

E così via… quindi alla fine ho pensato di scrivere questo post come puro esercizio, per capire fino a dove si può arrivare. Voi scrivete nei commenti cosa vorreste poter fare, o cosa avreste voluto fare su Analytics che non vi è riuscito – tipicamente con i filtri, ma non solo – e tutti insieme vediamo se il Tag Manager può risolvere. Pronti? via! 🙂

Chi ha configurato la ricerca interna sul proprio profilo (anzi, sulla propria VISTA, che è il nuovo nome dei profili) sa che Google Analytics chiede una e una sola cosa per capire se si tratta di una ricerca interna: il parametro dell’URL che contiene il termine ricercato.
Se ad esempio la vostra ricerca interna produce pagine di risultato come questa

/search/search.asp?txtsearch=genova

basta impostare “txtsearch” nella casella apposita e il report della ricerca interna inizierà a popolarsi. Ma cosa succede se il vostro CMS produce url più “SEO friendly” e quindi scrive cose tipo

/search/search/genova ?

Non c’è nessun parametro da indicare. In passato eravamo costretti a produrre un’altra pagina – virtuale – oppure a riscrivere completamente la pagina corrente per venire incontro alle ridotte capacità di questa parte dello strumento; questo perché, incredibile ma vero, NON SI PUO‘ fare un filtro search&replace sull’url, perché il sitesearch interviene PRIMA dell’applicazione dei filtri.

Però qualche tempo fa c’è stato un corposo aggiornamento dei campi filtro disponibili, e tra questi c’era anche il Site Search, che fino ad allora non era invece presente. Alcuni volenterosi, tra cui Lunametrics, si sono messi a fare prove e sono giunti alla conclusione che adesso le cose si possono risolvere più elegantemente di prima.

Sarà sufficiente fare un filtro personalizzato avanzato del tipo

Campo A -> Estrai A | URI della richiesta | /search/seach/(.*)
Campo B -> Estrai B VUOTO
Output in -> Constructor | Termine di ricerca | $A$1

Campo A obbligatorio SI
Campo B obbligatorio NO
Sovrascrivi campo output SI
Maiuscole/minuscole NO

Ovviamente la vostra espressione regolare per il Campo A dipende strettamente dalla vostra struttura degli URL, il mio è solo un esempio. Ma una volta fatto questo, il vostro report delle ricerche interne verrà popolato. Se il vostro sito usa anche le categorie di ricerca, potete fare la stessa cosa, con un altro filtro, per popolare la “Categoria di ricerca su sito”.

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 🙂