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:
Si decide una stringa di sicurezza, ad esempio “dhffjsrr12353fdf4253kc“, per mantenere il suo esempio
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.
Si crea un filtro di inclusione di tipo custom con “includi – URI della richiesta – corrisponde a espressione regolare – ^/dhffjsrr12353fdf4253kc
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.
SemaforoQuesto semaforo indica il livello difficoltà del post
