Ciao,
sono Daniele Simonin (melodycode.com).
Volevo avvisarti di un probabile bug (l'ho testato per 2 giorni) che
andrebbe ad inquinare il numero dei subscribers di feedburner:
http://read.melodycode.com/news/324/feedburner_bug.html</p>

Quanto sopra pubblicato è l'inizio di un'email che ho ricevuto in mattinata da Daniele, che innanzi tutto ringrazio per la segnalazione. Oggetto dell'email di Daniele è questo post, dove lui stesso ha raccolto una segnalazione di un presunto bug che affligge FeedBurner.

Vorrei coglierei l'occasione di questo intervento proprio per spiegare in breve parte del funzionamento di FeedBurner e della web (feed) analytics. Al termine di queste poche righe capirete perché in realtà non si tratta di un vero bug ma, come direbbero oltre oceano, that's the way it works. Ma andiamo per gradi.

Il bug: statistiche accessi al feed falsate

A spiegare il bug è lo stesso Daniele. In poche parole, navigando il proprio feed -- e ribadisco il proprio feed e non il proprio blog -- con una user agent opportunamente modificata è possibile falsare il numero di utenti iscritti al feed inducendo FeedBurner ad un calcolo errato.

Ma questo come è possibile? Il bug è realmente reale? La risposta è sì, vediamo perché.

Riprodurre il bug

Premesso che questo articolo non ha in alcun modo secondi fini se non quello di spiegare il funzionamento del sistema, vediamo come è possibile riprodurre questo bug.

Innanzi tutto è necessario modificare la user agent del proprio browser. Il consiglio è di usare Firefox ed installare l'estensione User Agent Switcher. Ora impostate la vostra user agent su una stringa riconducibile ad uno dei lettori per feed con indicazione di numero di iscritti, come ad esempio Bloglines

Bloglines/3.1 (http://www.bloglines.com; 4317 subscriber)

Al posto del valore 4317 potete sostituire un qualsiasi valore intero positivo.

Non appena visiterete il feed verrete tracciati da FeedBurner che identificherà la vostra user agent analizzando il contenuto. Se siete stati fortunati, e tra poco capirete perché, il bug causerà un aumento del numero dei visitatori di un valore almeno pari a quanto indicato nella stringa.

Il funzionamento del tracciamento

Arriviamo al punto cruciale di questo sistema. Perché accade questo? Dovete sapere l'arte della web analytics non è per nulla semplice. Tracciare un utente, riconoscere se è un visitatore o meno, non è banale. Tracciare il numero di iscritti al feed è ulteriormente complicato se si considera che il bot di Google, ad esempio, passa una sola volta indipendentemente se Google Reader conta 1 o 1000 iscritti al nostro feed.

Come capire dunque se gli iscritti sono 1 o 1000? Ci sono diverse soluzioni, a seconda del client che accede al feed.

Conteggio della singola hit

Questo è il caso più semplice: 1 accesso = 1 visitatore. E' questo il caso della maggior parte degli aggregatori desktop come RSSOwl, FeedReader, RSS Bandit e così via.

Ogni qual volta arriva una richiesta al feed si verifica se in un certo arco di tempo è presente un'altra richiesta con lo stesso IP. In caso affermativo il visitatore è lo stesso, in caso alternativo è un nuovo iscritto. Ma non è sempre così semplice.

Conteggio del valore visitatori nella User Agent

Molti web aggregator, come Google, NewsGator, Bloglines e Rojo visitano il feed una volta sola indipendentemente dal numero degli utenti iscritti, per ovvie ragioni di ottimizzazione delle performance.
Per fornire un valore indicativo degli utenti iscritti inseriscono all'interno della user agent del proprio crawler un numero corrispondente al conteggio dei lettori.

Va da sé che questa pratica si regge sul buon senso poiché facilmente alterabile se si cammuffa la propria user agent, come Daniele ha dimostrato.

L'analisi delle user agent è tutt'altro che banale.
Per darvi un'idea della complessità vi invito a leggere questo intervento dove Eric Lunt, uno dei 4 fondatori di FeedBurner, descrive alcune situazioni tipo per l'individuazione di aggregatori basati su IE 7 e Firefox.

Conteggio del valore negli Header HTTP

Altri aggregatori, invece di fornire il valore di iscritti nella user agent lo accodano tra gli header HTTP inviati al client.
E' infatti possibile aggiungere alla richiesta o risposta HTTP un numero indefinito di header non standard semplicemente anteponendo la stringa x- al nome dell'header.

Ad esempio

x-subscribers: 123

potrebbe essere l'header fornito da un client a FeedBurner.

Anche questa tecnica si basa sul buon senso poiché anche gli header possono essere alterati... più difficilmente, ma comunque possono essere alterati.

Soluzioni

Come avrete capito, è abbastanza facile alterare i dati sui quali si basa un sistema di feed analytics, per la natura complessa del sistema di tracciamento.
Ma quali potrebbero essere le soluzioni a questo problema? E soprattutto, come possono le piattaforme di feed analytics cautelarsi da variazioni "costruite"?

Controllo incrociato

Il controllo incrociato è una pratica che non andrebbe mai, e poi mai, esclusa.
Basare un'analisi su un unico valore aumenta esponenzialmente la probabilità di fallire l'analisi stessa. Al minimo variare del valore qualsiasi algoritmo correlato cambia, spesso pesantemente.

Un controllo incrociato permette di identificare se esistono anomalie, se la modifica di un valore dell'analisi corrisponde ad una modifica coerente degli altri valori.
In caso negativo, si esclude il valore "non affidabile" senza alterare il normale funzionamento dell'algoritmo.

Come si traduce quanto appena esposto? Ecco in seguito alcuni controlli incrociati possibili:

Controllo IP

Il controllo con l'IP è uno dei più affidabili ma anche uno dei più complessi.
Il bug descritto non avrebbe avuto esito positivo, ad esempio, se si tenesse conto solo delle user agent di IP corrispondenti al client in oggetto.

Per esempio, ipotizzando che Bloglines ha un range di IP 123.123.123.x, ovvero da 123.123.123.1 a 123.123.123.254, si avrebbe

123.123.123.34
Bloglines/3.1 (http://www.bloglines.com; 4316 subscriber)
123.123.123.34
Bloglines/3.1 (http://www.bloglines.com; 4317 subscriber)
122.54.234.234
Bloglines/3.1 (http://www.bloglines.com; 10000 subscriber)
123.123.123.34
Bloglines/3.1 (http://www.bloglines.com; 4310 subscriber)

La terza visita non verrebbe conteggiata poiché corrispondente ad un IP fasullo. Le statistiche sono salve.

Su questo sistema si basano molti filtri antispam per blog ed email, come anche Akismet.
Ad esempio, se il mio blog riceve un trackback dal blog www.xyz.com che risponde ad un host 123.123.123.123 ma l'IP del trackback non è lo stesso, ecco che il trackback non viene inviato.
Allo stesso modo, se mi arriva un'email dal mail server @simonecarletti.com che risponde ad un IP specifico ma l'host del mail server di invio non è lo stesso, ecco che scatta il filtro antispam.

Controllo del Trend

Il controllo del trend è uno strumenti di analisi potente e sofisticato, ma complesso e pericoloso.
Si basa sul principio che una qualsiasi variazione percentuale rispetto alla media è un'anomalia.

Prendiamo ad esempio un range di una settimana

2007-03-18 - 105 subscribers
2007-03-19 - 120 subscribers
2007-03-20 - 110 subscribers
2007-03-21 - 456 subscribers
2007-03-22 - 112 subscribers
2007-03-23 - 100 subscribers
2007-03-24 - 80 subscribers

Come potete notare, se si escludesse il 21 Marzo, la media è circa di 100 visitatori unici giorno.
Se si confronta ogni giorno con la media periodica, l'incremento del 21 farebbe immediatamente presupporre un'anomalia, poiché ci troviamo di fronte ad uno sbalzo del 400%.

Lo stesso calcolo, eseguito non sul totale ma sulle singole user agent, ci permette di identificare quale sia il valore fallato e ci consente di escluderlo, limitarlo o normalizzarlo.

Questo sistema presenta però molte, troppe variabili.

Innanzi tutto uno sbalzo di questo genere è possibile. Si potrebbe per tanto studiare di valutare se ad uno sbalzo corrisponde poi una tendenza alla crescita o un valore progressivo con base coerente (nel nostro caso, un innalzamento alla media di 400 iscritti).

Dobbiamo poi scegliere correttamente i range che identificano un cambiamento come "nella norma". Se sono troppo ampi rischiamo di perderci analisi non corrette, se sono troppo ristretti potremmo cadere in una quantità troppo elevata di falsi positivi.

Infine, in un sistema di analisi come questo è opportuno considerare che il sabato è normale avere meno utenti della settimana, per un sito classico.
Opposto l'andamento per un ristorante o una struttura ricettiva, ad esempio.

API

Avevo cominciato a parlarvi delle API diversi mesi fa... cavolo, mi ero scordato che dovevo continuare con qualche altro post!

Se ogni aggregatore invece di fornire il numero di utenti in una stringa offrisse un servizio centralizzato dove qualsiasi sistema di feed analytics può richiedere questo valore, eventualmente previa autorizzazione, il problema non si porrebbe.

Immaginate quindi di bussare alla porta di Bloglines e chiedergli: "Ciao Bloglines, sai mica quanti iscritti ha il feed di Weppos?" Lui vi risponderà: "Ma curiosone, come mai lo vuoi sapere, non sei mica Weppos!"... cioè no, volevo dire, "Ma ciao FeedBurner, che piacere vederti. Il feed di Weppos ha 134546 iscritti." ed ecco che questo valore certo potrà essere dato in pasto al sistema di calcolo.

Technorati già adotta un sistema di questo tipo. Se volete sapere il numero di Blog che linkano un determinato URL potete chiederlo a Cosmos. Lo stesso FeedBurner offre questo servizio. Tramite le FeedBurner Awareness API è possibile conoscere il numero di iscritti al feed. Ne è un esempio il servizio che ho creato per trasformare le statistiche di feedburner in un feed.

Altre idee

Di idee aggiuntive che ne sarebbero a decine. Immaginate ad esempio all'invio di un header specifico al sistema di feed analytics, per identificare la veridicità del client collegato. Chi più ne ha, più ne progetti!

Bug correlati

Esistono alcuni bug correlati a questo problema. Il primo che mi viene in mente è la possibilità di sottrarre iscritti, invece di aggiungerne. Cosa succederebbe, ad esempio, se invece di mostrare la user agent

Bloglines/3.1 (http://www.bloglines.com; 4317 subscriber)

io scrivessi

Bloglines/3.1 (http://www.bloglines.com; -4317 subscriber)

con un valore di iscritti negativo? (NON) provare per credere!

In conclusione

Il problema segnalato da Daniele è in effetti una situazione anomala, ma sarei un attimo prudente a definirlo bug. E' categorizzabile come bug quando si tratta di un comportamento inaspettato, in questo caso, purtroppo, potrebbero non esserci alternative che ne incrementino il livello di sicurezza.