Simone Carletti's Blog » Analytics

Chi usa ancora FeedBurner?

Simone Carletti — Sat, 19 Sep 2009 09:32:41 +0000

Oggi mi sono accorto che erano almeno 4 mesi che non entravo più nel pannello di controllo di FeedBurner. Forse anche di più. Dall’acquisizione di FeedBurner da parte di Google, credo di essere entrato nella mia dashboard non più di una decina di volte.

In realtà non saprei bene il perché. Scomodità? Disinteresse? Disorganizzazione delle informazioni? Ho idea che l’unico modo per ristuzzicare il mio interesse possa essere l’integrazione di FeedBurner in Google Analytics. Sono l’unico?

Non ho seguito bene le vicende negli ultimi mesi. Per caso c’è qualche remota possibilità che ciò avvenga?

Certificazione di Google Analytics

Simone Carletti — Sat, 14 Mar 2009 16:05:59 +0000

Approfittando della trasferta Torinese e di un po’ di tempo libero, in questi ultimi giorni mi sono documentato per la certificazione individuale di Google Analytics. L’esame è stata l’occasione giusta per approfondire alcuni aspetti di Google Analytics che normalmente non rientrano nelle mie attività quotidiane.

Consigli per la preparazione all’esame

Per chi utilizza Google Analytics quotidianamente, l’esame è abbastanza semplice. Inoltre, la documentazione disponibile sul Conversion University Help è sufficiente a coprire oltre il 90% delle domande. Tuttavia, se desiderate sostenere la certificazione vi consiglio di non prendere l’esame sotto gamba. Alcune domande richiedono un’interpretazione personale e la conoscenza di alcuni dettagli tecnici di una sessione di navigazione di un utente.

Il Conversion University Help è senza dubbio il punto di partenza. Offre una panoramica completa delle funzioni di Google Analytics. Non abbiate fretta a saltare gli argomenti che pensate di conoscere. Alcune domande sono molto specifiche e richiedono, ad esempio, di sapere l’esatta precedenza attribuita a Google Analytics in caso di comportamenti comuni come multipli referer, conversioni con campagne in sovrapposizione o preferenze riguardo ai cookie.

Oltre al Conversion University Help vi consiglio di approfondire i seguenti temi, se ancora non avete avuto modo:

Site Search
Integrazione con Google AdWords
Tracciamento di Conversioni e Goal
Tracciamento di Transazioni e E-Commerce

Per ciascuno di questi temi assicuratevi di configurare un profilo di Google Analytics per test ed esplorate le funzionalità disponibili prima di affrontare l’esame. Non cancellate il profilo, potrebbe servirvi in fase d’esame.

Sempre in tema di risorse, merita senz’altro una citazione il sito Google Analytics in 30 secondi, una miniera di risorse sapientemente raccolte e pubblicate da Marco, già autore della Guida a Google Analytics per HTML.it. A proposito, complimenti a Marco che, per quanto ne so, è stato uno dei primi italiani a vincere il bollino.

Approfondimenti tecnici necessari

Normalmente è più facile per un tecnico apprendere caratteristiche comportamentali di un prodotto lato marketing che per un utente Marketing apprendere competenze tecniche. Questo perché alcune competenze tecniche richiedono prerequisiti a loro volta di carattere tecnico.

Per questo motivo, agli utenti non tecnici consiglio di approfondire gli argomenti:

Regular Expression, per una guida base in Italiano consiglio l’articolo di Vincenzo
Funzionamento e caratteristiche dei cookie: scadenza, first-cookie, last-cookie, possibilità di personalizzazione
Funzionamento e caratteristiche di una sessione di navigazione di un utente
Funzionamento e classificazione di una sessione in visitatore, visita unica e pageview

Caratteristiche del test

Il test è composto da 70 domande ed avete a disposizione 90 minuti per rispondere. Le domande sono per la maggior parte scelta singola da una lista di possibilità, in altri casi scelta multipla.

Non abbiate fretta di rispondere subito a tutte le domande. 90 minuti sono tanti, oltre 1 minuto a risposta ed alcune risposte richiedono meno di 10 secondi. Contrassegnate con Mark le risposte delle quali non siete sicuri, riprendetele in seguito. Se dopo 1 minuto non avete ancora assegnato una risposta, andate avanti. Riprenderete la risposta in seguito a test ultimato.

Durante il test è possibile consultare siti, Google Analytics ed altro materiale online. Tuttavia questo richiede tempo e vi consiglio di posticipare alla fine le domande per le quali avete bisogno di approfondimenti. Se avete seguito le indicazioni sopra per la preparazione, il numero di risposte da rivedere sarà molto limitato.

Suggerimenti per il test

Prima di iniziare il test tenete a portata di mano le seguenti risorse:

Conversion University Help
L’URL Builder
Lo strumento per il filtro IP
Il vostro account di Google Analytics, eventualmente con attivo il profilo indicato ad inizio post
Se siete un inserzionista AdWords, il vostro account AdWords. Se non lo siete, assicuratevi di conoscere bene il funzionamento di AdWords e Google Analytics

Buon esame!

Come reindirizzare una pagina rimuovendo il tracciamento di Google Analytics

Simone Carletti — Tue, 24 Feb 2009 16:11:03 +0000

Da qualche giorno i principali motori di ricerca hanno siglato un accordo introducendo il canonical link tag nel tentativo di trovare una possibile soluzione al fenomeno delle pagine con multiple URL.

Una delle situazioni più comuni che rientrano in questo caso è rappresentata dalle pagine oggetto di campagne online. Il canonical link è un compromesso molto recente e supportato solo da un ristretto numero di motori di ricerca. Nell’incertezza, qualcuno preferisce ancora ricorrere al buon vecchio metodo dell’URL rewrite e del redirect.

Questa mattina mi ha citofonato Francesco, intento a risolvere proprio questa situazione. Tutto nasce dal problema che non è possibile utilizzare mod_alias per impostare un redirect basato su un parametro in querystring. Per approfondimenti vi rimando all’articolo Apache .htaccess query string redirects.

Per la gioia di chi non ama gli indovinelli, ecco la soluzione al problema.

Il codice seguente è una regola di riscrittura di Apache. Può essere inserita direttamente nel file di configurazione del virtual host o all’interno dell’.htaccess. Nel caso la querystring contenga un parametro di Google Analytics per il tracciamento di una campagna, esegue il reindirizzamento alla pagina a se stessa rimuovendo la querystring.

RewriteEngine On
RewriteCond %{QUERY_STRING} utm_source=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_medium=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_content=(.*?)  [OR]
RewriteCond %{QUERY_STRING} utm_campaign=(.*?)
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1? [R=301,L]

Se desiderate eseguire la riscrittura forzata per una pagina specifica o un gruppo di pagine, è sufficiente aggiungere una condizione sulla pagina richiesta. L’esempio seguente applica il redirect solo nel caso in cui i parametri si trovino sulla query string della homepage.

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/$
RewriteCond %{QUERY_STRING} utm_source=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_medium=(.*?)   [OR]
RewriteCond %{QUERY_STRING} utm_content=(.*?)  [OR]
RewriteCond %{QUERY_STRING} utm_campaign=(.*?)
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1? [R=301,L]

Altre soluzioni o suggerimenti sono ben accetti. Segretamente, Francesco mi ha confessato che alla soluzione migliore regalerà un viaggio premio in Brasile per assistere al Carnevale di Rio.

Google Analytics: nell’head o nel body?

Simone Carletti — Tue, 17 Feb 2009 08:20:53 +0000

Il dibattito su dove inserire il codice di tracciamento di Google Analytics è sempre stato molto acceso, fin dal rilascio del software.

Inizialmente, quando Urchin era appena stato ribrandizzato in Google Analytics ed il prodotto era poco più che un cambio di nome, ricordo che la documentazione suggeriva di inserire il codice di tracciamento all’interno del tag della pagina. Non ho mai verificato direttamente, ma la motivazione ufficiale era che alcune caratteristiche richiedevano di essere inserite all’interno delle intestazioni per funzionare correttamente.

Poi è arrivato il nuovo codice di tracciamento di Google Analytics, per intenderci quello definito dal file ga.js. La documentazione ufficiale di Google Analytics indica di inserire il codice di tracciamento immediatamente prima la chiusura del tag , ovvero la chiusura della pagina HTML.

Prendendo a campione un centinaio di siti, soprattutto quelli che utilizzando Google Anaytics dai primi tempi, è facile notare come la posizione in cui è inserito il codice di tracciamento è assolutamente arbitraria. Alcuni la tengono a chiusura pagina, altri nell’header.

Le motivazioni sono essenzialmente due. Nel caso in cui il codice di tracciamento sia inserito ad inizio pagina, la probabilità di perdersi per strada dei dati è decisamente inferiore. Con il codice di tracciamento al fondo, infatti, l’utente potrebbe chiudere il browser prima che il tracciamento sia inizializzato.

Viceversa, l’inserimento di un javascript nell’head forza il browser ad attendere il suo caricamento prima di proseguire il rendering completo della pagina. Nel caso in cui Google ritardi a fornire il codice di tracciamento, la nostra pagina cadrà in uno stato di sospensione apparente ed il browser continuerà a mostrare l’avviso di caricamento in corso fino ad un eventuale timeout o ad una risposta del javascript esterno.

Lo screenshot seguente è emblematico: 357ms per restituire la pagina al browser, 35 secondi per eseguire il codice di tracciamento di Google Analytics.

Purtroppo il fenomeno non è così raro. Limitato, certo, ma spesso mi capita di imbattermi in comportamenti simili.

Il dilemma resta. Top della pagina per tutti i visitatori ma rischi al caricamento, fondo della pagina per dati potenzialmente incompleti ma utente felice?

Leggendo i log ho scoperto… #11 – Twingly Blog Search

Simone Carletti — Mon, 09 Feb 2009 19:52:40 +0000

… Twingly.com, un motore di ricerca per blog orientato alla ricerca in blog e microblog.

Nel primo caso Twingly è in qualche modo paragonabile al funzionamento di Google Blog Search o altre vecchie conoscenze come Technorati. A differenza di quest’ultimo però, Twingly sembra passarsela meglio. Nel secondo caso Twingly permette ricerche tra i dati di Twitter ed altri servizi dei quali non conoscevo neppure l’esistenza. Non c’è da stupirsi, dato che sono diametralmente opposto a questi prodotti.

Il bot di Twingly si presenta con la seguente user agent

Mozilla/5.0 (compatible; Twingly Recon; twingly.com)

Analizzando i log ho avuto modo di notare che si ciba sia di feed sia di pagine del blog.

Twingly sembra un progetto ben studiato. E’ pieno di widget ripubblicabili, offre una top100 per la gioia dei classifica-dipendenti e, molto interessante, permette di interagire attraverso un sistema di API. Quest’ultima funzione, dal mio punto di vista, è forse la parte più attraente.

Come abilitare Google Analytics Site Search su WordPress

Simone Carletti — Sat, 24 Jan 2009 14:43:53 +0000

Google Analytics offre una funzionalità chiamata Site Search che permette di tracciare le ricerche effettuate all’interno del nostro sito, ammesso che il nostro sito offra un motore di ricerca interno.

Nel caso di WordPress è possibile impostare Google Analytics per tracciare le ricerche sul nostro blog in pochissimi click, senza neanche intervenire sul template del blog. L’unico requisito è che il blog sià già tracciato da Google Analytics. In caso negativo, vi consiglio l’eccellente plugin Google Analytics for WordPress.

Per abilitare Google Analytics Site Search entrate pannello di controllo di Google Analytics ed accedete alla pagina di modifica del profilo selezionando il collegamento Edit.

Selezionate nuovamente Edit per modificare la sezione Main Website Profile Information e, al fondo, assicuratevi di spostare la selezione su Do Track Site Search.

A questo punto si espanderà una una sezione dedicata alle impostazioni della funzionalità Site Search. Inserite il parametro della query string che identifica una ricerca, nel caso di WordPress corrisponde a s, inoltre vi consiglio di selezionare la voce Yes, strip query parameters out of URL per evitare di ottenere dei report sporcati da altri dati come i valori di x e y del bottone di ricerca.

Una volta salvato il profilo Google Analytics comincerà a tracciare immediatamente le ricerche nel vostro blog. Ci vorrà comunque qualche ora prima che i dati siano visibili nei report.

I dati relativi alle ricerche sono consultabili nella sezione Content > Site Search. E’ interessante tracciare le ricerche eseguite da un utente sul blog per diversi motivi. Ad esempio potete individuare i termini di ricerca più frequenti e scrivere degli articoli dedicati o più specifici.

A seconda del tipo di sito o blog le ricerche possono anche rivelare potenziali bug, problemi di reputation management o curiosi aneddoti sui brand. Nel mio caso, da quando sono passato a WordPress ho scoperto che la query più cercata è Enter search keyword: un chiaro segnale che devo rendere quel box di ricerca più user friendly!

Leggendo i log ho scoperto… #10 – PDF Search Engine

Simone Carletti — Mon, 03 Nov 2008 07:01:01 +0000

… PDFind.com, un motore di ricerca che non conoscevo specifico per l’indicizzazione di file PDF.

Il motore di ricerca dispone di un proprio crawler, chiamato PDFBot ed identificato dalla user agent PDFBot (crawler@pdfind.com).

83.233.122.64 - - [15/Aug/2008:02:27:53 -0700] "GET /robots.txt HTTP/1.0" 200 405 "-" "PDFBot (crawler@pdfind.com)"

Il crawler individua e scarica file pdf. Il motore di ricerca analizza i file, mantiene una copia cache ed indicizza i documenti nel proprio archivio. E’ possibile visualizzare un’anteprima del PDF direttamente online.

Leggendo i log ho scoperto… #9 – Errori nella configurazione server

Simone Carletti — Mon, 13 Oct 2008 17:04:03 +0000

… quanto sia facile accorgersi tempestivamente di configurazioni errate sul proprio server.

Torniamo indietro di qualche settimana quando Simone Cabrino mi segnalò un problema nella configurazione del sito. A causa di un errore nelle regole del file .htaccess, ogni richiesta inviata ad un URL specifico di questo blog era indirizzata ad un percorso invalido nel sito, composto dall’indirizzo del blog più l’indirizzo fisico di questo blog sul server.
Questo problema, oltre ad essere fastidioso e prevenire l’indicizzazione di alcune pagine del sito, è pericoloso poiché espone all’esterno informazioni preziose sull’archittura del sito e del server che potrebbero comprometterne la sicurezza.

Questo problema avrebbe potuto essere individuato prima se avessi analizzato più attentamente i log, eventualmente prevedendo una qualche utility che mi avvisi nel caso in cui qualche richiesta contenga dei percorsi anomali come il percorso fisico sul server.

$ zgrep '/home/simonecarletti/simonecarletti.com' access.log.*.gz
64.34.195.155 - - [15/Aug/2008:12:14:00 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 1963 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.2); http://spinn3r.com/robot) Gecko/20021130"
74.6.31.165 - - [15/Aug/2008:12:51:12 -0700] "GET /blog/home/simonecarletti/simonecarletti.com/blog HTTP/1.0" 200 1963 "-" "Mozilla/5.0 (compatible; Yahoo! DE Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
82.63.157.52 - - [27/Aug/2008:01:34:50 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 2000 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1"
82.63.157.52 - - [27/Aug/2008:01:36:01 -0700] "GET //home/simonecarletti/simonecarletti.com/code HTTP/1.1" 404 596 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1"
87.28.229.37 - - [27/Aug/2008:01:50:15 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 2000 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"
87.28.229.37 - - [27/Aug/2008:01:50:17 -0700] "GET /blog/styles.css HTTP/1.1" 200 4454 "http://www.simonecarletti.com/blog//home/simonecarletti/simonecarletti.com/blog" "Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"

Ad oggi, conoscendo l’errore e la causa, anche il problema appare molto più semplice. Vediamo come potrei procedere se mi trovassi di fronte a questo problema per la prima volta.

Come prima cosa è fondamentale ottenere le informazioni filtrate, da analizzare singolarmente. Possiamo procedere esportando la lista delle corrispondenze in un file chiamato, ad esempio, file.txt.

zgrep '/home/simonecarletti/simonecarletti.com' access.log.*.gz > file.txt

A questo punto, cominciamo a leggere il file alla ricerca di qualche dettaglio utile. A seconda del tipo di problema, oltre alla riga di log contenente l’errore potrei aver bisogno di tutte quelle correlate appartenenti alla sessione di navigazione.

In questo caso, ecco due righe di log che potrebbero fornirmi un indizio.

64.34.195.137 - - [15/Aug/2008:02:45:35 -0700] "GET /blog HTTP/1.1" 301 610 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.2); http://spinn3r.com/robot) Gecko/20021130"
64.34.195.137 - - [15/Aug/2008:02:45:36 -0700] "GET /blog//home/simonecarletti/simonecarletti.com/blog HTTP/1.1" 200 1963 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1; aggregator:Tailrank (Spinn3r 2.2); http://spinn3r.com/robot) Gecko/20021130"

Come potete osservare, in un client richiede la pagina /blog//home/simonecarletti/simonecarletti.com/blog. Immediatamente prima, lo stesso client ha inviato una richiesta al percorso /blog ottenendo in risposta un redirect 301.

A questo punto, conosco il problema e l’origine. Non mi resta che individuare la causa e correggerla.

In conclusione, analizzate sempre i log del server alla ricerca di richieste anomale. Se non sapete cosa cercare, cominciate con il verificare richieste che contengono all’interno percorsi a file fisici sul vostro server.

Leggendo i log ho scoperto… #8 – iearthworm

Simone Carletti — Mon, 06 Oct 2008 04:00:16 +0000

… che Yahoo sembrerebbe avere una collezione di crawler non documentati particolarmente ricca. Dopo il Yahoo-MMCrawler ed il bot travestito da utente, è la volta di iearthworm, un’altro misteriosa creatura di Yahoo! in versione sol levante.

Di iearthworm non se ne parla molto in giro, giusto qualche post neppure troppo recente.
Secondo approfondimenti, questo crawler sembra prediligere elementi come immagini ed icone.

Anche l’analisi recente dei miei log lo conferma.

$ zgrep 'iearthworm' access.log*
[17/Sep/2008:10:21:11 -0700] "HEAD /blog/public/2008/04/ce-posta-per-te/mailwasher-on-action.png HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[16/Sep/2008:18:57:27 -0700] "HEAD /blog/public/2008/05/benvenuto-ruby-html/guida_thumb_975ccb77f298cabc.gif HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[17/Aug/2008:09:09:11 -0700] "HEAD /blog/public/2008/05/benvenuto-ruby-html/guida_thumb_975ccb77f298cabc.gif HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[18/Aug/2008:01:59:30 -0700] "HEAD /blog/public/2008/04/ce-posta-per-te/mailwasher-on-action.png HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[21/Aug/2008:09:59:42 -0700] "HEAD /blog/public/2008/05/benvenuto-ruby-html/guida_thumb_975ccb77f298cabc.gif HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[22/Aug/2008:03:08:28 -0700] "HEAD /blog/public/2008/04/ce-posta-per-te/mailwasher-on-action.png HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[25/Aug/2008:07:22:58 -0700] "HEAD /blog/public/2008/05/benvenuto-ruby-html/guida_thumb_975ccb77f298cabc.gif HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[25/Aug/2008:23:56:43 -0700] "HEAD /blog/public/2008/04/ce-posta-per-te/mailwasher-on-action.png HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"
[29/Aug/2008:06:28:52 -0700] "HEAD /blog/public/2008/05/benvenuto-ruby-html/guida_thumb_975ccb77f298cabc.gif HTTP/1.1" 200 361 "-" "iearthworm/1.0, mailto:iearthworm@yahoo.com.cn"

Il fatto curioso è che l’accesso, almeno sul sito analizzato, avviene essenzialmente ad un paio di risorse ben precise. Inoltre, il crawler sembra aver cambiato nel tempo anche funzione o comportamento, essendo passato dall’uso del metodo HTTP GET a HEAD.

L’uso del metodo HEAD è comune nel caso in cui sia sufficiente analizzare gli header HTTP di una risorsa, in genere per validarne la presenza sul server. Azzardando qualche ipotesi, si direbbe che il compito di questo crawler sia di verificare la presenza sul server di una risorsa, ad esempio, per mantenerla nell’indice di ricerca.

La conferma che si tratta di un crawler di Yahoo! e non di un falso arriva, ancora una volta, da un reverse dns.

$ nslookup 203.209.240.151
Server:         85.37.17.16
Address:        85.37.17.16#53

Non-authoritative answer:
151.240.209.203.in-addr.arpa    name = dlk06.image.cn3.yahoo.com.

Authoritative answers can be found from:

Leggendo i log ho scoperto… #7 – Proximic.com

Simone Carletti — Mon, 29 Sep 2008 09:27:08 +0000

… che esiste un programma pubblicitario chiamato Proximic che sembra avere delle caratteristiche molto simili a Google Adsense.
Proximic, del quale fino ad oggi non conoscevo l’esistenza, utilizza un crawler per analizzare il contenuto della pagina e mostrare annunci contestuali in base a dove l’annuncio è pubblicato.

Il modello di remunerazione è sia CPC sia CPA. Per iscriversi al programma è necessario che il target del sito nel quale si desidera pubblicare gli annunci provenga in prevalenza da Stati Uniti, Regno Unito o Germania. Non mi stupisce dunque che in Italia sia poco conosciuto.

Nonostante la ristretta diffusione, il suo crawler è relativamente attivo avendo scansionato decine di pagine nel giro di qualche settimana.

$ zgrep 'proximic' access.log.*
access.log.2008-08-05.gz:87.152.80.95 - - [05/Aug/2008:13:58:04 -0700] "GET /robots.txt HTTP/1.1" 200 442 "-" "Mozilla/5.0 (compatible; proximic; +http://www.proximic.com)"
access.log.2008-08-05.gz:87.152.80.95 - - [05/Aug/2008:13:58:04 -0700] "GET /blog/2007/03/strumenti-sviluppo-subversion-svn.php HTTP/1.1" 200 53851 "-" "Mozilla/5.0 (compatible; proximic; +http://www.proximic.com)"
access.log.2008-08-05.gz:213.239.213.230 - - [05/Aug/2008:14:22:35 -0700] "GET /robots.txt HTTP/1.1" 200 442 "-" "Mozilla/5.0 (compatible; proximic; +http://www.proximic.com)"
access.log.2008-08-05.gz:213.239.213.230 - - [05/Aug/2008:14:22:35 -0700] "GET /blog/2007/07/svuotare-cache-dns.php HTTP/1.1" 200 27977 "-" "Mozilla/5.0 (compatible; proximic; +http://www.proximic.com)"
access.log.2008-08-08.gz:85.25.151.158 - - [08/Aug/2008:04:40:12 -0700] "GET /robots.txt HTTP/1.1" 200 442 "-" "Mozilla/5.0 (compatible; proximic; +http://www.proximic.com)"
access.log.2008-08-08.gz:85.25.151.158 - - [08/Aug/2008:04:40:13 -0700] "GET /blog/2008/08/nuovo-microsoft-webmaster-center.php HTTP/1.1" 200 28239 "-" "Mozilla/5.0 (compatible; proximic; +http://www.proximic.com)"

Se il numero vi dovesse apparire limitato, non dimenticate che in realtà sul mio sito non sono presenti annunci Proximic. Nonostante questo, il crawler scansiona ugualmente i link in uscita da pagine di inserzionisti iscritti al circuito, per offrire una maggiore contestualizzazione della pubblicità.