Il Bot di Ask può gonfiare le visite e “sporcare” la tua Web Analysis

Parto da una doverosa premessa, ma cercherò di essere breve e generico perchè se queste cose le sai non c’è bisogno che le ripeta, se non le sai non basterebbe un post per impararle.
Web Analytics: 2 modi diversi di raccogliere dati
E’ possibile fare della Web Analysis utilizzando due tipi di strumenti. Esistono software di Web Analytics che si basano sui log del server e software che funzionano grazie a un codice Javascript incluso nelle pagine del sito.
Proprio per la diversa natura dei due metodi, il risultato finale può essere profondamente diverso e questa differenza deve essere conosciuta da chi interpreta i dati.
A grandi linee è possibile affermare che i log vengono prodotti in base alle richieste che gli utenti fanno al server. Generandosi lato server, nei log mancano alcune informazioni sul tipo di browser, sulla risoluzione dello schermo, sul sistema operativo e altre informazioni relative a chi/come naviga.
Al contrario il sistema a Tag (con il Javascript inserito nel footer) riesce a raccogliere tutti i dati in possesso del pc dell’utente.
Google Analytics appartiene al secondo gruppo e non è il miglior software di cui disporre se l’utenza del tuo sito ha Javascript disabilitato, o se hai la necessità di monitorare le attività di crawling di spider e bot.
In realtà, benchè sia stato Google in primis ad affermare che con il Javascript anche gli spider dei motori di ricerca potrebbero riscontrare problemi durante la scansione del tuo sito, ultimamente leggo sempre più spesso di possibili interazioni fra crawler e javascript.
Un problema con la Web Analytics
Di recente mi è stato fatto notare che su un sito di cui seguo la Web Analysis abbiamo parecchie visite dirette (circa 40 al giorno) dagli Stati Uniti d’America.
Partendo dal presupposto di cui sopra, ovvero che l’Analytics di Google non conteggia bot e spider e la natura diretta degli accessi, ho pensato subito ad una qualche attività di spamming.
L’altra cosa anomala a proposito di queste visite è che pur essendo vicine, nel tempo e geograficamente, vengono considerate tutte visite nuove al 100%. Non solo, il tempo medio di permanenza è 00:00:00, praticamente nullo.
Il fatto che il 90% di queste visite si riferisse alla pagina 404.php mi ha indirizzato verso una qualche attività di crawling. Se l’accesso è diretto e genera un’errore 404 (pagina non trovata) significa che il mio visitatore aveva già un riferimento e che questa visita è forse una visita di “controllo”.
Successivamente ho controllato il network da cui provengono queste visite e ho notato che partono tutte dal network-location di Ask: iac search media inc e ask jeeves. Ho avuto la conferma di ciò incrociando i log sul server e sono arrivato alla conclusione che il responsabile di ciò è: crawler6132.ask.com.
Ask può sporcare in modo sistematico le tue Web Analysis
Dall’incrocio di queste informazioni l’unica conclusione a cui siamo arrivati (io e lghinelli) è che il crawler di Ask si comporta in modo analogo ad un Web Browser. Non solo può leggere i Javascript, ma nel nostro caso decide addirittura di eseguire il Javascript di Analytics.
Sul come faccia e perchè i dati raccolti dall’Analytics siano così strani (100% visite nuove, 100% bounce rate e tempo di premanenza pari a 0 secondi), mi rimetto a voi, ma una cosa è certa per un Web Analyst il comportamento di Ask è dannosissimo.
Ask in questo modo non solo inficia sul numero di visite uniche, ma nel caso in cui eseguisse non solo il Javascript dell’Analytics, ma ad esempio anche qualche attività sugli OnClick a cui abbiamo associato un obiettivo, averemmo falsati anche i Conversion Rate settati sul’Analytics.
Come rimediare ai guai combinati da Ask
L’unico modo che mi viene in mente per ripulire i report dalla sporcizia generata dal bot di Ask è quella di escludere il suo indirizzo IP. A giudicare dalle mie osservazioni giornaliere questa soluzione funziona, ma non è da escludere che un domani il crawler possa cambiare indirizzo.
Per rimuovere l’IP di questo Bot, se utilizzi Google Analytics, è possibile impostare un filtro. Il mio consiglio è di lasciare comunque un profilo senza filtri, visto che qualsiasi filtro applicherai effettureà dei tagli sulla reportistica che non potrai più recuperare.
Per creare un profilo clone dell’originale, a cui decurtare le visite del bot di Ask, puoi andare, dalla schermata di ingresso, ad Aggiungi profilo sito web. Setta l’impostazione “Aggiungi un profilo per un dominio già esistente” e dai al nuovo profilo un nome abbastanza esplicativo. Per aggiungere il filtro al profilo appena creato vai sul Filter Manager e successivamante su + Aggiungi Filtro. In questa pagina troverai il filtro escludi traffico da un indirizzo IP, fra i filtri comuni, ricordati di non applicare questo filtro al profilo originale. Nel momento in cui scrivo l’indirizzo IP del crawler di Ask è 212.48.8.140.
Francesco ha scritto questo post il 15th gennaio, 2009 | File Under Best Practice, Web Analytics | -


























Vuoi pubblicare i tuoi post qui?
gennaio 15th, 2009 a 11:02
Grazie per aver condiviso queste osservazioni, Francesco.
Purtroppo non so attribuire una spiegazione esaustiva a questo fenomeno; l’unico aspetto sul quale mi sento di intervenire è la soluzione: un’alternativa alla creazione di un profilo “clone” + filtro è quella di realizzare un segmento avanzato che escluda quell’indirizzo IP e che poi venga applicato al report. Il vantaggio, in questo caso, è che il calcolo è retroattivo.
Grazie ancora per il post.
gennaio 15th, 2009 a 11:07
Anzi, non sono certo che si possa realizzare un segmento avanzato indicando l’indirizzo IP.
La connessione in treno va da schifo e non riesco ad accedere ad Analytics…
gennaio 15th, 2009 a 11:56
Una precisazione, nei log server sai anche li che tipo di browser è stato usato. Non la risoluzione video o il resto, ma il sistema operativo e il tipo di browser si.
gennaio 15th, 2009 a 13:18
@Marco Ziero ottimo suggerimento!
@Abruzzo Seo, grazie per la precisazione.
gennaio 15th, 2009 a 15:49
Interessante il post.
Le web analytics possono essere sporcare in un sacco di modi comunque:
- si può usare il plugin di firefox http://noscript.net/ che non si fa eseguire gli script che scegli, ad esempio quello di GA
- si può usare TOR in vari modi http://www.torproject.org/ c’è anche un plugin molto semplice di Firefox https://addons.mozilla.org/it/firefox/addon/2275 e così ti saltano un sacco di informazioni
- servizi come http://fooldns.com/ che non fanno girare lo script…
Mi sa che in qualche modo si dovranno prendere anche i dati di log
gennaio 15th, 2009 a 16:00
Ciao Luca, questi a cui ti riferisci tu sono metodi per navigare bloccando il codice di GA, giusto?
Comunque sì, tutte modalità di navigazione che fanno slatare le Web Analysis Tag oriented. L’unica cosa è che nella mia situazione 50 visite al giorno, sistematiche sono parecchie.
Ciao e grazie per essere intervenuto.
gennaio 15th, 2009 a 16:17
Con TOR in realtà falsi l’ip
ma con il Proxy collegaro puoi far saltare anche altri dati, tra cui gli script.
Con tutti gli altri metodi elimini “chirurgicamente” gli script.
gennaio 15th, 2009 a 16:50
Veramente interessante questo articolo, non credevo che il bot di un motore di ricerca caricasse i JavaScript, soprattutto qualli di un programma di stats famoso come Analytics..
gennaio 15th, 2009 a 18:28
Il fatto che compaiono sempre come nuove visite è indice che il bot non recepisce nè invia i cookies, unico modo che ha Analytics per identificare una visita ripetuta dello stesso utente.
Non capisco comunque il senso di fare un bot che esegue il codice javascript, che raramente influenza il vero contenuto informativo della pagina. In più, se fosse mio, escluderei a priori di eseguire il codice di Google in quanto facilmente identificabile ed assolutamente inutile ai fini del crawling.
Ipotizzo quindi qualche altra cosa, come un browsing automatizzato pilotando l’engine di un normale browser per confrontare i risultati spiderati con quelli realmente visualizzati dall’utente. Ma se sono tutti 404….. Boh!
gennaio 15th, 2009 a 19:14
Francesco, diciamoci la verità: ma che t’importa di essere indicizzato… su Ask?!
Proporrei una soluzione brutale, in questo caso: blocco dell’IP o range di IP da .htaccess, con controllo aggiuntivo di Reverse DNS Lookup per non lasciarsi sfuggire nemmeno altre richieste che da quell’hostname dovessero arrivare mediante IP sconosciuti.
E agli spider di Ask, che comunque non ti danno in cambio nulla, mostri un bel 403 “Access Denied”.
Sarai rimosso dall’indice di Ask, ma che t’importa? Perderesti sicuramente più accessi da crawler che da utenti del motore!
gennaio 15th, 2009 a 19:18
Ed aggiungo: qualora la soluzione tecnica fosse troppo difficile, basterebbero due righe di Robots.txt:
User-agent: Teoma
Disallow: /
gennaio 15th, 2009 a 19:25
strano perché Ask è sempre stato abbastanza attento agli standard. A me capitò una cosa simile con un bot di Symantec, ma poi la cosa rientrò da sé…
gennaio 16th, 2009 a 08:41
Ask ha anche una sede a Pisa, seguita da Antonio Gulli. Fategli uno squillo direttamente.
gennaio 16th, 2009 a 09:55
@Inox63, non sono tutto 404, ma la maggior parte sì. Sacrosanta l’osservazione sui coockies.
@Petro, in effetti non è cruciale essere indicizzato da Ask, anche se è un motore che apprezzo molto, però mi sono trovato in questa situazione mio malgrado.
Ho ripreso in mano un lavoro già esistente e ho decurtato parecchie URL, alcune le ho redirettate verso le nuove pagine, altre le ho semplicemente eliminate. Queste ultime sembrano aver dato problemi ad Ask, visto che gran parte delle pagine richieste da Ask sono errori 404.
@Marco Cilia anche io sono rimasto piuttosto sorpreso.
@Luca Bove cercherò di segnalare la cosa ad Antonio Gulli.
Grazie a tutti per i suggerimenti.
gennaio 17th, 2009 a 02:56
Ciao Francesco,
come abbiamo già avuto modo di parlare in privato, anch’io ho riscontrato una situazione molto simile. Nel mio caso non si è trattato di Ask ma di Live e non di accessi diretti, ma accessi con chiavi secche (”bluetooth”, “telefono”).
Anche nel mio caso bounce 100% e riscontro delle visite sui log che hanno confermato la responsabilità del bot di Live. Ne ho fatto accenno sul forum Seonida in questa discussione.
Questi due casi dimostrino come ormai i motori siano in grado di leggere ed eseguire javascript… ma se da un lato leggere tali script può essere utile (leggo il contenuto per capire cosa farne) non capisco - come già affermato da Inox63 - a cosa possa servire eseguirli.
Riguardo al bot Live (che ho rilevato con una piattaforma diversa da GA) da casa Microsoft si sono espressi molto vagamente.
Tu, Francesco, hai visto Ask; io Live (e non sono il solo). Le domande nascono spontanee: Google? Yahoo? Non eseguono javascript? Non si fanno individuare?
Io credo che oltre a tentare di raggirare il problema filtrando i report (in un profilo copia, così da poter confrontare con dati grezzi) sia necessario studiarlo nell’ottica di un’esigenza commerciale dei due motori colti in fallo.
Tentano di attirare la nostra attenzione? Mi resta difficile credere che Ask e Microsoft siano così dispettosi da volerci sporcare i report! Che motivo hanno per farlo?
Saluti a tutti e complimenti a Francesco per l’ottimo spunto di discussione.
gennaio 22nd, 2009 a 17:49
Ciao Francesco, grazie per aver riportato anche qui le tue considerazioni. Sarebbe molto bello sapere che ne pensa Simone Carletti, visto che proprio lui ultimamente ha parlato di come i bot possono (o non possono) leggere, eseguire ed interpretare i javascript.
Ciao ciao
gennaio 23rd, 2009 a 00:31
Ciao Francesco,
Tempo fa Ask utilizzava “Ask Jeeves/Teoma” come user agent, tipo
65.214.45.101 - - [23/Jan/2008:20:00:02 -0800] “GET /robots.txt HTTP/1.0″ 200 669 “-” “Mozilla/5.0 (compatible; Ask Jeeves/Teoma; +http://about.ask.com/en/docs/about/webmasters.shtml)”
ma mi sembra che Ask più o meno ha smesso di scansionare il web in febbraio 2008 [ http://www.antezeta.it/blog/ask-com-rip/ ].
Ora che scrivo e’ tarde, ma mi SEMBRA che c’è qualcosa che non va. L’IP che hai citato (E i crawler avranno di piu’) mi sembra di essere di Telecom:
inetnum: 212.48.8.0 - 212.48.11.255
netname: MATRIXNET
descr: On Line services for advertising, marketing, media,
descr: publishing and shopping
country: IT
admin-c: MNAS1-RIPE
tech-c: MNAS1-RIPE
status: ASSIGNED PA
mnt-by: AS8660-MNT
source: RIPE # Filtered
role: Matrix Network Administration Staff
address: Matrix S.p.A.
address: C.so Garibaldi, 99
address: 20121 Milano
address: Italy
Se puo’ essere utile, finche’ sappia io, il centro a Pisa, se c’e’ ancora :-), lavora(va) sulla ricerca immagini.
gennaio 23rd, 2009 a 12:03
Ciao Sean, grazie anche a te per essere intervenuto.
Avevo letto del dimissionario Bot di Ask, ma ti assicuro che nei log del mio server è sempre presente. In particolare io sto incrociando i report dell’Analytics di Google con i log relativi a Dicembre 2008 e Gennaio 2009 e crawler6132.ask.com è sempre presente ed assegnato a questo ip 212.48.8.140 per lo meno, nei 2 mesi che sto prendendo in considerazione.
Non sono un’esperto di reti e se mi dici che quell’IP è di telecom ok, ma di fatto gli accessi attribuiti dai log al bot di Ask, collimano con gli accessi diretti provenienti dalla network location individuata da Google Analytics: iac search media inc e ask jeeves.
Comunque per aiutarvi ad aiutarmi, insomma per aiutarci, posto lo screen shot con qualche dato in più.
Ciao e grazie Sean.
gennaio 30th, 2009 a 06:21
Ecco, ora capisco, ho avuto situzioni simili su alcuni blog. Misà che è proprio questo il fattore. E il comportamento di Ask è sicuramente dannoso per l’analisi. Propongo blocco del range IP su .htaccess o dell’IP stesso