Audience e Tweet: verso un modello predittivo più preciso

Con nuove variabili ed un modello più complesso si può prevedere l’audience di un talk show politico con Twitter?

Dopo aver scritto il post che presentava l’idea generale del modello predittivo dell’audience di un talk-show politico a partire dall’attività su Twitter (nel post anche il volume medio dei Tweet generati dagli hashtag ufficiali delle principali trasmissioni nella prima parte di stagione) mi è venuto in mente un modo semplice per migliorare significativamente le capacità predittive del modello.

Guardando l’audience delle 376 puntate prese in considerazione sembra piuttosto evidente che le variazioni nelle puntate di un singolo programma siano piuttosto contenute.

Audience Standard Deviation per Show

 

Questo significa che ogni talk-show ha un pubblico piuttosto affezionato ed abitudinario che produce un audience che non si differenzia molto di puntata in puntata. La trasmissione con la varianza maggiore è Omnibus (28% dell’audience media), quella con la minore varianza è ServizioPubblico (0.09%). 

Frazione di varianza per ShowQuesti dati ci danno un’idea di massima di quanto ogni trasmissione abbia un pubblico stabile di puntata in puntata (anche se va tenuto presente che la varianza, di solito, cresce al crescere dal numero di puntate trasmesse). Al di là del dettaglio sul singolo programma quello che conta è che l’audience non cambia molto di puntata in puntata. Questo significa che la media dell’audience delle puntate precedenti dovrebbe essere un buon predittore dell’audience della puntata futura. Infatti le performance di un modello di regressione lineare semplice basato sull’audience media come variabile indipendente vanta performance decisamente migliori di quelli testati in precedenza.

Residuals:
Min 1Q Median 3Q Max
-966867 -96515 -8538 84705 936133

Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 2.305e-09 1.770e+04 0.00 1
showdata$avg_audience 1.000e+00 1.331e-02 75.16 —
Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 221300 on 374 degrees of freedom
Multiple R-squared: 0.9379, Adjusted R-squared: 0.9377
F-statistic: 5648 on 1 and 374 DF, p-value: < 2.2e-16

A questo punto possiamo chiederci se l’aggiunta della variabile volume dei Tweet al minuto migliori le performance del modello ed infatti…

Residuals:
Min 1Q Median 3Q Max
-919587 -90990 -8523 82001 928457

Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 1.557e+04 1.700e+04 0.916 0.36
showdata$avg_audience 9.141e-01 1.846e-02 49.512 < 2e-16 ***
showdata$tm 7.485e+03 1.172e+03 6.389 4.97e-10 ***

Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 210400 on 373 degrees of freedom
Multiple R-squared: 0.944, Adjusted R-squared: 0.9437
F-statistic: 3145 on 2 and 373 DF, p-value: < 2.2e-16

L’errore standard diminuisce da 221300 a 210400 e la percentuale di varianza spiegata dal modello sale dallo 0.93 allo 0.94%. La differenza fra i due modelli, ancorché contenuta è tuttavia significativa.

Analysis of Variance Table

Model 1: showdata$audience ~ showdata$avg_audience
Model 2: showdata$audience ~ showdata$avg_audience + showdata$tm
Res.Df RSS Df Sum of Sq F Pr(>F)
1 374 1.8314e+13
2 373 1.6508e+13 1 1.8067e+12 40.823 4.972e-10 ***

Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

A questo punto rimane solo da fare un’ultima prova. Cosa accade inserendo nel modello anche la variabile networked_publics (ovvero il valore medio del rapporto fra volume di Tweet ed audience – cioè la percentuale di attività dell’audience) propria di ciascuna trasmissione?

Residuals:
Min 1Q Median 3Q Max
-884852 -85906 -29916 89933 893697

Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 8.913e+04 1.938e+04 4.599 5.83e-06 ***
showdata$avg_audience 8.613e-01 1.910e-02 45.098 < 2e-16 ***
showdata$tm 1.501e+04 1.567e+03 9.579 < 2e-16 ***
showdata$networked_publics -9.494e+07 1.400e+07 -6.783 4.66e-11 ***

Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 198700 on 372 degrees of freedom
Multiple R-squared: 0.9502, Adjusted R-squared: 0.9498
F-statistic: 2365 on 3 and 372 DF, p-value: < 2.2e-16

Si ottiene un modello ancora più preciso caratterizzato da un errore standard di 198700 ed un Adjusted R-squared di 0.95. In pratica questo modello è in grado di prevedere l’audience di un talk show politico sulla base del volume dei Tweet prodotto dall’hashtag ufficiale della trasmissione con un margine di errore che inizia a diventare interessante e forse utile nella pratica.

L’analisi della varianza degli ultimi due modelli testati conferma che la differenza fra i modelli è statisticamente significativa

Analysis of Variance Table

Model 1: showdata$audience ~ showdata$avg_audience + showdata$tm
Model 2: showdata$audience ~ showdata$avg_audience + showdata$tm + showdata$networked_publics
Res.Df RSS Df Sum of Sq F Pr(>F)
1 373 1.6508e+13
2 372 1.4691e+13 1 1.8168e+12 46.005 4.655e-11 ***

Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Adozione ed utilizzo dei social media negli atenei italiani

Oltre il 60% (+11% rispetto al 2011) delle homepage dei siti web degli atenei italiani linkano Facebook, Twitter, YouTube o un altro media sociale. Ma quale social media è più utilizzato? E quale ateneo utilizza al meglio queste presenze?

Anche quest’anno, con Alessandro Lovari, abbiamo analizzato le home page dei siti internet di tutti gli atenei italiani alla ricerca dei link agli spazi ufficiali sui social media. Da questi abbiamo raccolto tutti i dati disponibili attraverso le API delle diverse piattaforme e calcolato le performance dei diversi atenei sulle diverse piattaforme. Infine abbiamo calcolato il così detto University Social Media Performance Index (descritto brevemente qui e nel dettaglio qui).

I dati di maggiore interesse sono riassunti in questa info-grafica:

Ho anche aggiornato l’Osservatorio Università Italiane su Facebook con gli indirizzi di tutte le pagine rintracciate con la rilevazione 2012.

Osservatorio Università Italiane su Facebook

Dati in tempo reale per valutare la social media strategy degli atenei italiani

Oltre il 40% degli atenei italiani ha una presenza ufficiale su Facebook (fonte: http://ssrn.com/abstract=1978393). I dati cambiano tuttavia con frequenza quotidiana ed eventi specifici (come ad esempio le recenti nevicate) possono modificare significativamente l’intensità di utilizzo di questi strumenti da parte della comunità di riferimento di un ateneo. Per questo motivo ho deciso di dedicare un po’ di tempo a realizzare uno strumento in grado di tenere traccia di questi cambiamenti nel tempo. A questo scopo ho raffinato alcuni strumenti che avevo già utilizzato in passato per creare un vero e proprio osservatorio che racconti gli atenei italiani su Facebook calcolando quotidianamente indici sintetici di popolarità, popolarità ponderata sul numero degli iscritti e trend dell’attività sulla pagina ponderato in base alla popolarità della pagina stessa.
Alla pagina dell’osservatorio troverete i dati aggiornati quotidianamente. Il reperimento dei dati è affidato ad un script che aggiorna automaticamente il foglio di calcolo prelevandoli da Facebook Graph, archivia i dati del giorno precedente e crea le tabelle riassuntive ed i grafici.
Il servizio è in fase sperimentale. C’è un problema noto che riguarda la pagina dell’Università di Foggia i cui dati sono disponibili solo ad utenti di Facebook autenticati (probabilmente è attivo qualche limitazione geografica o di età sul target di utenti che può visualizzare la pagina). Questo fa si che lo script non sia in grado di reperire i dati di quella pagina.
Potrebbero inoltre mancare delle pagine. Nella pagina dell’osservatorio è descritta la metodologia che ci ha consentito di individuare le pagine ufficiali. Potrebbero tuttavia essere intercorsi dei cambiamenti dalla data di rilevazione e nuovi atenei potrebbero aver aperto pagine ufficiali. Provvederò ad aggiungere queste pagine dietro segnalazione.
Vai alla pagina dell’osservatorio.

Performance e diffusione dei social media nelle Università italiane

Uno studio empirico su come le Università italiane usano Facebook, YouTube e Twitter

Alessandro Lovari, durante la scuola di dottorato Meris, mi ha proposto, avendo letto il post sulla popolarità delle pagine Facebook delle Università italiane, di sviluppare insieme l’idea di analizzare se e come gli atenei italiani usassero i social media.
Dopo un paio di incontri in Skype, qualche telefonata e diverse ore di lavoro abbiamo completato la scrittura di questo articolo che prende in esame le presenze ufficiali sui media sociali di tutte i 95 atenei italiani. Poco più della metà degli atenei è presente su almeno un social media. Facebook è il più diffuso seguito da YouTube e Twitter. Gli atenei di medie dimensioni e le università private sono più presenti ed attive. Per valutare meglio le performance delle Università sui social media abbiamo sviluppato un indice che abbiamo denominato USMPI ovvero “university social media performance index”. Questo indice valuta la presenza e le performance degli atenei sui social media usando combinando una serie di metriche e rapportando alcune di esse alla dimensione dell’ateneo (i dettagli metodologici sono nel paragrafo 4.1 dell’articolo).
I dieci atenei che hanno fatto registrare le migliori performance sono:
Ateneo, USMPI
Libera Univ. Inter.le Studi Sociali “Guido Carli” LUISS-ROMA, 0.31
Università Commerciale “Luigi Bocconi” MILANO, 0.31
Politecnico di MILANO, 0.25
Università degli Studi di MILANO-BICOCCA, 0.24
Università degli Studi di URBINO “Carlo BO”, 0.19
Libera Univ. degli Studi “Maria SS.Assunta” – LUMSA – Roma, 0.19
Università “Cà Foscari” VENEZIA, 0.17
Libera Università di lingue e comunicazione IULM-MI, 0.17
Università degli Studi di PAVIA, 0.16
Università degli Studi di UDINE, 0.16
USMPI nel complesso varia da un minimo di 0 ad un massimo di 0.31. La media è 0.0502 e la deviazione standard 0.07351.
L’indice è stato realizzato con l’intento di essere facilmente calcolabile con un intervento umano minimo o nullo. Tutte le metriche analizzate sono basate su dati esposti pubblicamente dalle API delle piattaforme di social media.
Maggiori dettagli sull’indice e su tutta la ricerca sono disponibili nell’articolo (in inglese) che abbiamo pubblicato, in versione pre-print, su ssrn.
Lovari, Alessandro and Giglietto, Fabio, Social Media and Italian Universities: An Empirical Study on the Adoption and Use of Facebook, Twitter and Youtube (January 2, 2012). Available at SSRN: http://ssrn.com/abstract=1978393.
Consigli e suggerimenti sono più che benvenuti 🙂

Breve analisi della partecipazione dei fan nella pagina Facebook di Servizio Pubblico

Testando il nuovo social network importer plugin di nodexl

I ricercatori della social media research foundation hanno rilasciato ieri un plugin per Node XL che consente di accedere ad alcuni dati che riguardano gli utenti che interagiscono con una pagina Facebook facendo like o commentando un post.
Ho deciso di provare subito i plugin usando la pagina di Servizio Pubblico.
La prima scoperta che ho fatto è che il plugin consente di scaricare i dati degli ultimi dieci post.
Nel caso della pagina del programma di Santoro si tratta nello specifico dei post che vanno da questo a questo.
Il plugin considera un nodo ogni utente che ha interagito con la pagina e crea un arco ogni volta che due utenti hanno commentato (o fatto like) sullo stesso post. Suppongo che il legame creato rappresenti un mutuo interesse di un utente verso uno specifico tema.
Il testo dei post e di tutti i commenti vengono salvati e collegati all’utente rendendo questo plugin utile per piccoli progetti sull’analisi del contenuto. Per ogni nodo vengono scaricate tutte le informazioni disponibili pubblicamente (o alle quale si può accedere in virtù di un legame di amicizia). I dati che sono disponibili nella maggior parte dei casi sono nome, cognome, link alla foto profilo di Facebook e genere.
I dieci post presi in esame hanno ricevuto in totale 954 commenti da 703 utenti diversi. Il numero massimo di commenti per utente è 6. Non sorprendentemente la distribuzione è caratterizzata da pochi utenti che commentano molto e molti che commentano poco (543 o il 77,2% ha commentato solo una volta).
Chi commenta è in grande prevalenza maschio (71% m, 27% f ed il restante non specificato).
I post in questione hanno ricevuto in totale 1635 Mi Piace da 1016 utenti diversi. Il numero massimo di like per utente è 9. Considerate che mentre è possibile commentare più di una volta su un post non si può fare altrettanto con i Mi Piace. La distribuzione dei Mi Piace ha la consueta forma anche se, in questo caso, la percentuale di partecipanti che ha fatto un solo Like è inferiore (44,2%).
Anche chi clicca su Mi Piace è in prevalenza maschio anche se meno di quanto non avvenga per i commenti (60% m, 38% f ed il restante non specificato).
I temi che più hanno colpito l’immaginario degli spettatori attivi sono ben evidenziati in questa tagcloud.

Tagcloud dei commenti

Invece questa è la visualizzazione della rete dei commentatori.
Per dimensionare i nodi ho usato la metrica degree (avrei anche potuto usare il semplice numero di commenti ma poi mi sarei perso il fatto che un commento postato in un thread dove hanno postato poche persone è diverso da uno postato in un thread con molti partecipanti). Per posizionare i nodi ho usato l’algoritmo Fruchterman-Reingo (scelta di default in Node XL). Non ho aggiunto le etichette con i nomi sui nodi, ma avrei potuto.

Con un po’ di pazienza, ovvero scaricando i post in blocchi da 10 mentre la trasmissione è in onda, si possono ottenere i dati dei circa 30/40 post pubblicati durante la messa in onda per una analisi più completa.

Urbino su Facebook

o come Facebook rende visibili le relazioni in una comunità

Visto l’interesse destato dall’analisi del gruppo Facebook dell’Università di Urbino ho deciso di estendere questa visualizzazione per includere più gruppi. L’idea è quella di rappresentare le relazioni di amicizia dei più rappresentativi gruppi Facebook di Urbino.
In una prima fase ho dunque dovuto cercare e selezionare i gruppi da prendere in considerazione.
Sono dunque partito da una semplice ricerca con la chiave urbino nel motore interno di Facebook limitando i risultati ai soli gruppi. Degli oltre 364 gruppi restituiti, ho deciso di escludere tutti quelli che, dal titolo, sembravano chiaramente riferirsi a realtà più grandi (ad esempio tutti quelli Pesaro e Urbino). Ho inoltre deciso di prendere in considerazione solo i gruppi con oltre 50 membri. Di questi alcuni erano aperti ed altri chiusi. Per quelli aperti mi sono semplicemente unito al gruppo, per quelli chiusi ho richiesto l’autorizzazione a diventare membro (solo in un caso mi è stato chiesto il perché ed ho spiegato che stavo conducendo una ricerca). Ho avuto così accesso ai dati di 72 gruppi. Per ciascuno di essi ho scaricato il grafo delle relazioni intergruppo (usando netvizz) e aggregato i risultati in un unico file .gdf copiando in questo file la lista dei membri del gruppo e quella delle loro relazioni. Questa procedura ha causato ovviamente la duplicazione di molti nodi con il rispettivo numero identificativo. Questa duplicazione non ha tuttavia causato problemi all’atto dell’importazione in Gephi durante la quale i nodi duplicati sono stati automaticamente eliminati.
Il grafo risultato dall’aggregazione di tutte le relazioni fra i membri dei gruppi presi in considerazione consiste alla fine di 14014 nodi e 175188 archi.
Su questo grafo ho calcolato i soliti indici di centralità (eigenvector, betweenness, closeness ed eccentricity) e la modularity per individuare le comunità.
Ho inoltre posizionato i nodi utilizzando l’algortimo ForceAtlas 2 (con il paramento Gravity a 100 per evitare una eccessiva disgregazione).
L’analisi della modularità, definita come una misura di quanto bene una rete possa essere scomposta in comunità modulari, si attesta intorno allo 0,6 ed il numero di comunità identificato oscilla (si tratta di algoritmo randomizzato che genera risultati diversi ogni volta che viene eseguito) intorno alle 1000.

Da questo migliaio di comunità ne emergono tre che da sole raccolgono quasi il 50% dei nodi.
Si tratta di quelle che ho identificato come UNIURB (15,5% e colore Verde), URBINATI (15,02% Blu) e MOVIDA (13,15% Rosso). Significativa inoltre la dimensione del gruppo del COLLEGI (7,34% Giallo), GIURISPRUDENZA (5,41% Azzurro), ANNUNCI E RICHIESTE (5,35% Grigio), LICEO CLASSICO RAFFAELLO (5,26% Fucsia). Fra le altre comunità che ho identificato figurano inoltre quella dell’ISIA, dell’Istituto d’Arte, dell’Istituto per la Formazione al Giornalismo e quella degli studenti Greci.

Nelle immagini che seguono due visualizzazioni dei 250 utenti meglio connessi secondo, rispettivamente, la metrica della betweenness centrality e dell’eigenvector centrality.


Infine, visto che zoom.it si rifiuta di creare l’immagine zoommabile, potete scaricare le visualizzazioni totali in formto pdf con la dimensione dei nodi legate alla betweenness e all’eigenvector centrality (i nomi, in queste visualizzazioni complessive, sono stati volutamente rimossi per questioni di privacy).Visto l’interesse destato dall’analisi del gruppo Facebook dell’Università di Urbino ho deciso di estendere questa visualizzazione per includere più gruppi. L’idea è quella di rappresentare le relazioni di amicizia dei più rappresentativi gruppi Facebook di Urbino.
In una prima fase ho dunque dovuto cercare e selezionare i gruppi da prendere in considerazione.
Sono dunque partito da una semplice ricerca con la chiave urbino nel motore interno di Facebook limitando i risultati ai soli gruppi. Degli oltre 364 gruppi restituiti, ho deciso di escludere tutti quelli che, dal titolo, sembravano chiaramente riferirsi a realtà più grandi (ad esempio tutti quelli Pesaro e Urbino). Ho inoltre deciso di prendere in considerazione solo i gruppi con oltre 50 membri. Di questi alcuni erano aperti ed altri chiusi. Per quelli aperti mi sono semplicemente unito al gruppo, per quelli chiusi ho richiesto l’autorizzazione a diventare membro (solo in un caso mi è stato chiesto il perché ed ho spiegato che stavo conducendo una ricerca). Ho avuto così accesso ai dati di 72 gruppi. Per ciascuno di essi ho scaricato il grafo delle relazioni intergruppo (usando netvizz) e aggregato i risultati in un unico file .gdf copiando in questo file la lista dei membri del gruppo e quella delle loro relazioni. Questa procedura ha causato ovviamente la duplicazione di molti nodi con il rispettivo numero identificativo. Questa duplicazione non ha tuttavia causato problemi all’atto dell’importazione in Gephi durante la quale i nodi duplicati sono stati automaticamente eliminati.
Il grafo risultato dall’aggregazione di tutte le relazioni fra i membri dei gruppi presi in considerazione consiste alla fine di 14014 nodi e 175188 archi.
Su questo grafo ho calcolato i soliti indici di centralità (eigenvector, betweenness, closeness ed eccentricity) e la modularity per individuare le comunità.
Ho inoltre posizionato i nodi utilizzando l’algortimo ForceAtlas 2 (con il paramento Gravity a 100 per evitare una eccessiva disgregazione).
L’analisi della modularità, definita come una misura di quanto bene una rete possa essere scomposta in comunità modulari, si attesta intorno allo 0,6 ed il numero di comunità identificato oscilla (si tratta di algoritmo randomizzato che genera risultati diversi ogni volta che viene eseguito) intorno alle 1000.
Da questo migliaio di comunità ne emergono tre che da sole raccolgono quasi il 50% dei nodi.
Si tratta di quelle che ho identificato come UNIURB (15,5% e colore Verde), URBINATI (15,02% Blu) e MOVIDA (13,15% Rosso). Significativa inoltre la dimensione del gruppo del COLLEGI (7,34% Giallo), GIURISPRUDENZA (5,41% Azzurro), ANNUNCI E RICHIESTE (5,35% Grigio), LICEO CLASSICO RAFFAELLO (5,26% Fucsia). Fra le altre comunità che ho identificato figurano inoltre quella dell’ISIA, dell’Istituto d’Arte, dell’Istituto per la Formazione al Giornalismo e quella degli studenti Greci.
Nelle immagini che seguono due visualizzazioni dei 250 utenti meglio connessi secondo, rispettivamente, la metrica della betweenness centrality e dell’eigenvector centrality.


Infine, visto che zoom.it si rifiuta di creare l’immagine zoommabile, potete scaricare le visualizzazioni total in pdf con la dimensione dei nodi legate alla betweenness e all’eigenvector centrality (i nomi, in queste visualizzazioni complessive, sono stati volutamente rimossi per questioni di privacy).Visto l’interesse destato dall’analisi del gruppo Facebook dell’Università di Urbino ho deciso di estendere questa visualizzazione per includere più gruppi. L’idea è quella di rappresentare le relazioni di amicizia dei più rappresentativi gruppi Facebook di Urbino.
In una prima fase ho dunque dovuto cercare e selezionare i gruppi da prendere in considerazione.
Sono dunque partito da una semplice ricerca con la chiave urbino nel motore interno di Facebook limitando i risultati ai soli gruppi. Degli oltre 364 gruppi restituiti, ho deciso di escludere tutti quelli che, dal titolo, sembravano chiaramente riferirsi a realtà più grandi (ad esempio tutti quelli Pesaro e Urbino). Ho inoltre deciso di prendere in considerazione solo i gruppi con oltre 50 membri. Di questi alcuni erano aperti ed altri chiusi. Per quelli aperti mi sono semplicemente unito al gruppo, per quelli chiusi ho richiesto l’autorizzazione a diventare membro (solo in un caso mi è stato chiesto il perché ed ho spiegato che stavo conducendo una ricerca). Ho avuto così accesso ai dati di 72 gruppi. Per ciascuno di essi ho scaricato il grafo delle relazioni intergruppo (usando netvizz) e aggregato i risultati in un unico file .gdf copiando in questo file la lista dei membri del gruppo e quella delle loro relazioni. Questa procedura ha causato ovviamente la duplicazione di molti nodi con il rispettivo numero identificativo. Questa duplicazione non ha tuttavia causato problemi all’atto dell’importazione in Gephi durante la quale i nodi duplicati sono stati automaticamente eliminati.
Il grafo risultato dall’aggregazione di tutte le relazioni fra i membri dei gruppi presi in considerazione consiste alla fine di 14014 nodi e 175188 archi.
Su questo grafo ho calcolato i soliti indici di centralità (eigenvector, betweenness, closeness ed eccentricity) e la modularity per individuare le comunità.
Ho inoltre posizionato i nodi utilizzando l’algortimo ForceAtlas 2 (con il paramento Gravity a 100 per evitare una eccessiva disgregazione).
L’analisi della modularità, definita come una misura di quanto bene una rete possa essere scomposta in comunità modulari, si attesta intorno allo 0,6 ed il numero di comunità identificato oscilla (si tratta di algoritmo randomizzato che genera risultati diversi ogni volta che viene eseguito) intorno alle 1000.
Da questo migliaio di comunità ne emergono tre che da sole raccolgono quasi il 50% dei nodi.
Si tratta di quelle che ho identificato come UNIURB (15,5% e colore Verde), URBINATI (15,02% Blu) e MOVIDA (13,15% Rosso). Significativa inoltre la dimensione del gruppo del COLLEGI (7,34% Giallo), GIURISPRUDENZA (5,41% Azzurro), ANNUNCI E RICHIESTE (5,35% Grigio), LICEO CLASSICO RAFFAELLO (5,26% Fucsia). Fra le altre comunità che ho identificato figurano inoltre quella dell’ISIA, dell’Istituto d’Arte, dell’Istituto per la Formazione al Giornalismo e quella degli studenti Greci.
Nelle immagini che seguono due visualizzazioni dei 250 utenti meglio connessi secondo, rispettivamente, la metrica della betweenness centrality e dell’eigenvector centrality.


Infine, visto che zoom.it si rifiuta di creare l’immagine zoommabile, potete scaricare le visualizzazioni total in pdf con la dimensione dei nodi legate alla betweenness e all’eigenvector centrality (i nomi, in queste visualizzazioni complessive, sono stati volutamente rimossi per questioni di privacy).

Alcuni dati sui Twitter trending topic in Italia

Gli argomenti della settimana su Twitter in Italia analizzati con il GnipPowerTrack importer di DiscoverText

Come accennato nel precedente post, ho avuto la possibilità di testare per alcuni giorni una nuova funzionalità di DiscoverText che consente di reperire gli status di Twitter (Tweet) in tempo (quasi) reale.  Grazie all’accordo con Gnip, DiscoverText consente dunque di accedere alla così detta Firehose (il flusso di tutti gli status di Twitter) e di raccogliere questi contenuti per una successiva analisi.
La partecipazione a questo programma di beta test è durata dal 19 al 24 Ottobre (anche se il servizio è ancora al momento attivo).
DiscoverText, già nella versione in produzione, consente di importare contenuti da diverse fonti:

Per quanto riguarda Twitter era già disponibile il Live Feed Import basato sulle REST API di Twitter che richiede l’autenticazione con il proprio nome utente e password ed ha il vantaggio di poter reperire i Tweet da un archivio degli ultimi 5/6 giorni e lo svantaggio di non garantire la completezza dei risultati (si veda il precedente post per i dettagli su questo).
La novità è il GNIP PowerTrack importer.
Questa modalità di importazione dei Tweet ha il vantaggio di restituire il flusso completo di tutti gli status pubblici e lo svantaggio di non consentire l’accesso ad alcun archivio (il flusso che si riesce a reperire parte dal momento in cui si inizia a raccogliere i dati).
Una combinazione delle due metodologie di importazione descritte dovrebbe consentire dunque una ragionevole fedeltà nella raccolta dati (ovviamente bisognerà rimuovere i duplicati, cosa che DiscoverText consente di fare in automatico).
La metodologia di importazione GNIP PowerTrack si basa sulla costruzione di una regola di importazione che può essere costruita da un massimo di 10 termini o operatori fino a una lunghezza complessiva di 255 caratteri per l’intera regola. In pratica si tratta di filtrare il flusso dei contenuti secondo certi criteri.
Si possono cercare frasi esatte, usare gli operatori – per escludere un termine, usare un hashtag – vengono identificati alla fonte da Twitter – come chiave di ricerca, una mention di un utente specifico (@nomeutente compresi i RT), status prodotti o destinati ad un utente specifico (from: e to:), contenenti smile, status prodotti da un client specifico, status che siano retweet di uno specifico utente, status contenenti luoghi, stringhe specifiche, che contengono un certo indirizzo internet, status prodotti da utenti che abbiano un klout score compreso fra due valori minimo e massimo, status che contengono link, che siano geo-referenziati, che contengono almeno una mentions (compresi dunque i retweet) o almeno un hashtag e infine status classificati da Gnip come appartenenti ad una certa lingua (compreso l’italiano).
Per testare la funzionalità ho raccolto i dati per molti dei trending topics (per capire meglio come vengono calcolati consiglio la lettura di questo articolo) italiani emersi nel corso degli ultimi giorni da #erpelliccia a #gheddafi, da #nubifragio a #notav (+ “val di susa”) senza dimenticare #XF5 e #gf12.  Ho anche provato per breve tempo a monitorare un trending topic globale e sponsorizzato come “Paranormal Activity 3”. Per completare i test ho anche provato a raccogliere i dati dell’interno stream di contenuti in lingua italiana allo scopo di comprendere meglio la consistenza del flusso di tweet prodotti nella nostra lingua.
Iniziamo l’analisi da questi ultimi.
Usando il filtro lang:it avrei dovuto reperire il flusso di Tweet in italiano. Purtroppo questo filtro si è dimostrato del tutto inefficace. Per motivi che non mi sono chiari oltre ai Tweet in italiano sono stati anche reperiti i Tweet in altre lingue fra cui indonesiano, malese, vietnamita, turco e chissà quante altre (ho usato Google Translate per identificarle). Questa errata identificazione della lingua ha reso impossibile raggiungere l’obiettivo che mi ero posto ed i sotto-obiettivi che sarebbero stati identificare quanti di questi Tweet prodotti nella nostra lingua fossero geo-referenziati, contenessero link, mentions ed hashtag.
Passiamo dunque all’analisi del flusso di un trending topic globale e sponsorizzato come “Paranormal Activity 3”.
In questo caso, usando la semplice ricerca per frase esatta, sono stati reperiti 21333 status updates in circa due ore e mezza (nello specifico fra  il 10/21/2011 2:36:13 AM ed il 10/21/2011 5:05:37 AM EST: Eastern Standard Time).  Si tratta di 142 Tweet circa al minuto. DiscoverText supporta l’analisi di grandi quantità di dati attraverso uno strumento chiamato CloudExplorer. Si tratta in pratica di una semplice tagcloud che consente però di cliccare su ogni voce per accedere alla lista dei contenuti filtrati per quella parola chiave.

 
Cliccando ad esempio su See si accede ad una lista filtrata dei 7260 Tweet in archivio che contengono questo termine.  L’archivio può inoltre essere ricercato liberamente per parola chiave e filtrato usando uno o più criteri basati sugli stessi metadati disponibili per la costruzione di un filtro. Posso ad esempio sapere con facilità quanti status in archivio contengono un hashtag (in questo caso 2433) o quanti contengono menzioni di altri utenti (8004).
Dal pannello filtri avanzati della ricerca è inoltre possibile ottenere alcuni altri dati sull’archivio. Si può ad esempio conoscere il numero degli utenti che hanno usato l’hashtag (19360) e quale di questi lo abbia fatto più volte (15). Conoscere l’hashtag più utilizzato è Paranormal con 281 occorrenze seguito curiosamente da iDontSupport con 66 occorrenze. In totale sono stati utilizzati 1342 hastag diversi. Ci sono invece 5930 utenti diversi menzionati con in testa l’account ufficiale del film chiamato in causa da 531 status.
Il risultato di una ricerca può essere salvato in un bucket (un contenitore di passaggio con il quale miscelare i dati unendo ad esempio più di un bucket) dal quale costruire poi un dataset. Al dataset possono essere applicate le classiche tecniche di analisi del contenuto basate su griglie di analisi date o costruite a partire dai dati. Il dataset toolbox comprende strumenti piuttosto avanzati per il supporto della collaborazione fra più ricercatori nella codifica dello stesso dataset.
Veniamo adesso ai dati che riguardano i trending topics italiani.
Mi soffermerò sui casi di #gheddafi lang:it, #nubifragio, #notav, #XF5 e #gf12.
L’importer avviato alle il 20/10/2011 alle 13:50 (l’ANSA con la notizia della morte di Gheddafi è delle 13:11) ha raccolto 6601 Tweet. Il primo contenuto reperito è datato 20/10/2011 alle 13:49, l’ultimo 24/10/2011 alle 11:17.
Nel GNIP Feed Management è possibile visualizzare un grafico dell’andamento dei Tweet per ogni importer attivo.
Questo è il grafico per #gheddafi (gli orari sono in EST – Eastern Standard Time e gli slot temporali da circa 15 minuti).

 
Il picco è di oltre 300 Tweet in 15 minuti circa e corrisponde con il momento di attivazione dell’importer. Sarebbe stato bello poter raccogliere i dati di quella mezz’ora intercorsa fra l’annuncio della morte ed il momento di attivazione dell’importer. Raccogliere dataset completi relativi a breaking news è veramente difficile con questo metodo.
Per questo motivo ho provato nel caso di #nubifragio ad utilizzare sia l’importer basato sulle REST API sia il GNIP Power Track.
Con questo metodo ho reperito 4005 (1886 con GNIP e 2119 con le REST API) Tweet. La rimozione dei duplicati esatti ha ridotto l’archivio a 1783 status. Non mi è chiarissimo con questo elenco dei duplicati esatti venga creato e dopo averlo applicato anche ad altri archivi che non avrebbero dovuto contenere duplicati temo posso rimuovere anche i retweet identici. Purtroppo è difficile estrarre da questo archivio elementi utili sulle date perché, apparentemente, i Tweet importati da GNIP e quelli importati dalle REST API sono riferiti a fusi orari diversi.  Questo status duplicato ha come ora di pubblicazione rispettivamente le 9:33 AM EST e le 5:33 AM di un fuso orario sconosciuto.
Più semplice è invece lavorare su eventi programmati per i quali è possibile attivare l’importer per tempo.
Per la manifestazione di Val di Susa ho seguito l’hashtag #notav e la stringa di ricerca “val di susa”. Ho attivato l’importer alle 8:34 23/10 e reperito nel complesso 5501 Tweet.
Di seguito il grafico per l’hashtag #notav.

 
In questo caso sono riuscito a fotografare l’andamento del fenomeno prima che raggiungesse il picco (avvenuto intorno all’ora di pranzo con oltre 300 Tweet prodotti durante lo slot di 15 minuti circa).
Gli hashtag più utilizzati sono stati #diamociuntaglio (1014) e #report (117). Dei 429 utenti menzionati, notav_info è il più citato (645). In totale hanno contribuito a questo hashtag 1300 utenti diversi. Il più attivo è stato ViceVersa_1917 con 146 Tweet.
Durante il periodo di betatest sono inoltre andati in onda le prime puntate della quinta stagione di X Factor e della dodicesima edizione de Il Grande Fratello.
Per X Factor ho monitorato l’hashtag #xf5 con colpevole ritardo a partire dalla mattina successiva alla messa in onda.

 
Anche la mattina dopo c’è stato un discreto volume di conversazioni che ha superato il picco di 200 Tweet in 15 minuti. Se dovessi avere ancora accesso al servizio proverò a raccogliere i dati relativi alla messa in onda della seconda puntata in onda domani.
Infine per quanto riguarda la prima puntata della dodicesima stagione de Il Grande Fratello ho monitorato sia l’hashtag #gf12 che la stringa “grande fratello” a partire da pochi minuti prima della messa in onda (20:56 del 24/10).
Ecco il volume di Tweet durante la messa in onda (il primo grafico è riferito a “grande fratello” e il secondo a #gf12) [le 3 PM del grafico equivalgono alle nostre 21:00].

 

 
In entrambi i casi l’andamento è simile con le discussioni che si protraggono fino a oltre mezza notte (le 6 PM nel grafico). Il buco delle 5 PM del grafico credo sia dovuto a qualche problema nel flusso di importazione dei dati.
Nel secondo caso si sono toccati e superati gli 800 Tweet in 15 minuti. Inoltre questo volume è stato mantenuto per tutta la durata del programma.
Nel complesso ho reperito 13308 generati da 5169 utenti il più attivo dei quali è stato w4rr10r_0 con i suoi 160 status. Oltre a #gf12 sono stati utilizzati altri 883 diversi hashtag. Il più utilizzato dopo #gf12 è stato #GrandeFratello.
Fra i xxx menzionati nei Tweet etichettati #gf12 spicca @Microsatira il cui tweet ironico è stato retweettato oltre 100 volte (in totale ha ricevuto 189 mentions).
La seguente tagcloud dovrebbe dare un’idea dei temi più citati:

Come spesso accade nei discorsi sui programmi televisivi di grande richiamo i commenti veri e propri al programma si sommano ai giudizi di chi non riesce a capacitarsi di come quel programma possa avere successo o si lamenta della qualità della televisione italiana.
In conclusione credo che DiscoverText sia uno strumento con delle caratteristiche uniche. Non si tratta di un prodotto perfetto e non sono mancate le volte nelle quali, specie su grandi quantità di dati, mi sono stati restituiti dei messaggi di errore. L’accordo che stanno perfezionando con Gnip potrebbe rendere questo strumento essenziale per chi voglia fare ricerca su Twitter. Le modalità di implementazione di questa funzionalità rendono bene le potenzialità di estensibilità della piattaforma. La gestione delle timezones appare migliorabile (forse renderanno in futuro possibile scegliere all’utente il fuso orario per il grafico). Nel complesso il sistema si comporta bene anche su grandi quantità di dati mostrando eccellenti performance nella creazione delle tagclouds (che necessiterebbero però della possibilità di escludere liste di parole comuni) e nelle ricerche che richiedono sempre tempi ragionevolmente brevi per essere portate a termine.
Credo ci siano più di uno spunto
Come ho avuto modo di scrivere altrove, l’utilizzo di una piattaforma web collaborativa per l’analisi del contenuto rappresenta un percorso obbligato per chi desideri fare ricerca qualitativa su grandi quantità di dati (come quelli provenienti dai media sociali).
DiscoverText è un prodotto della Texifter LLC. Si tratta di una società nata come spin-off a partire dall’attività di ricerca di Stuart W. Shulman presso la University of Massachusetts Amherst.
Non mi resta dunque che augurare buon lavoro a Stuart e al suo team di sviluppatori.
P.S. Durante il periodo di beta-test i dati non sono esportabili quindi non chiedetemeli 😉
 
 
 
 
 Come accennato nel precedente post, ho avuto la possibilità di testare per alcuni giorni una nuova funzionalità di DiscoverText che consente di reperire gli status di Twitter (Tweet) in tempo (quasi) reale.  Grazie all’accordo con Gnip, DiscoverText consente dunque di accedere alla così detta Firehose (il flusso di tutti gli status di Twitter) e di raccogliere questi contenuti per una successiva analisi.
La partecipazione a questo programma di beta test è durata dal 19 al 24 Ottobre (anche se il servizio è ancora al momento attivo).
DiscoverText, già nella versione in produzione, consente di importare contenuti da diverse fonti:

Per quanto riguarda Twitter era già disponibile il Live Feed Import basato sulle REST API di Twitter che richiede l’autenticazione con il proprio nome utente e password ed ha il vantaggio di poter reperire i Tweet da un archivio degli ultimi 5/6 giorni e lo svantaggio di non garantire la completezza dei risultati (si veda il precedente post per i dettagli su questo).
La novità è il GNIP PowerTrack importer.
Questa modalità di importazione dei Tweet ha il vantaggio di restituire il flusso completo di tutti gli status pubblici e lo svantaggio di non consentire l’accesso ad alcun archivio (il flusso che si riesce a reperire parte dal momento in cui si inizia a raccogliere i dati).
Una combinazione delle due metodologie di importazione descritte dovrebbe consentire dunque una ragionevole fedeltà nella raccolta dati (ovviamente bisognerà rimuovere i duplicati, cosa che DiscoverText consente di fare in automatico).
La metodologia di importazione GNIP PowerTrack si basa sulla costruzione di una regola di importazione che può essere costruita da un massimo di 10 termini o operatori fino a una lunghezza complessiva di 255 caratteri per l’intera regola. In pratica si tratta di filtrare il flusso dei contenuti secondo certi criteri.
Si possono cercare frasi esatte, usare gli operatori – per escludere un termine, usare un hashtag – vengono identificati alla fonte da Twitter – come chiave di ricerca, una mention di un utente specifico (@nomeutente compresi i RT), status prodotti o destinati ad un utente specifico (from: e to:), contenenti smile, status prodotti da un client specifico, status che siano retweet di uno specifico utente, status contenenti luoghi, stringhe specifiche, che contengono un certo indirizzo internet, status prodotti da utenti che abbiano un klout score compreso fra due valori minimo e massimo, status che contengono link, che siano geo-referenziati, che contengono almeno una mentions (compresi dunque i retweet) o almeno un hashtag e infine status classificati da Gnip come appartenenti ad una certa lingua (compreso l’italiano).
Per testare la funzionalità ho raccolto i dati per molti dei trending topics (per capire meglio come vengono calcolati consiglio la lettura di questo articolo) italiani emersi nel corso degli ultimi giorni da #erpelliccia a #gheddafi, da #nubifragio a #notav (+ “val di susa”) senza dimenticare #XF5 e #gf12.  Ho anche provato per breve tempo a monitorare un trending topic globale e sponsorizzato come “Paranormal Activity 3”. Per completare i test ho anche provato a raccogliere i dati dell’interno stream di contenuti in lingua italiana allo scopo di comprendere meglio la consistenza del flusso di tweet prodotti nella nostra lingua.
Iniziamo l’analisi da questi ultimi.
Usando il filtro lang:it avrei dovuto reperire il flusso di Tweet in italiano. Purtroppo questo filtro si è dimostrato del tutto inefficace. Per motivi che non mi sono chiari oltre ai Tweet in italiano sono stati anche reperiti i Tweet in altre lingue fra cui indonesiano, malese, vietnamita, turco e chissà quante altre (ho usato Google Translate per identificarle). Questa errata identificazione della lingua ha reso impossibile raggiungere l’obiettivo che mi ero posto ed i sotto-obiettivi che sarebbero stati identificare quanti di questi Tweet prodotti nella nostra lingua fossero geo-referenziati, contenessero link, mentions ed hashtag.
Passiamo dunque all’analisi del flusso di un trending topic globale e sponsorizzato come “Paranormal Activity 3”.
In questo caso, usando la semplice ricerca per frase esatta, sono stati reperiti 21333 status updates in circa due ore e mezza (nello specifico fra  il 10/21/2011 2:36:13 AM ed il 10/21/2011 5:05:37 AM EST: Eastern Standard Time).  Si tratta di 142 Tweet circa al minuto. DiscoverText supporta l’analisi di grandi quantità di dati attraverso uno strumento chiamato CloudExplorer. Si tratta in pratica di una semplice tagcloud che consente però di cliccare su ogni voce per accedere alla lista dei contenuti filtrati per quella parola chiave.

 
Cliccando ad esempio su See si accede ad una lista filtrata dei 7260 Tweet in archivio che contengono questo termine.  L’archivio può inoltre essere ricercato liberamente per parola chiave e filtrato usando uno o più criteri basati sugli stessi metadati disponibili per la costruzione di un filtro. Posso ad esempio sapere con facilità quanti status in archivio contengono un hashtag (in questo caso 2433) o quanti contengono menzioni di altri utenti (8004).
Dal pannello filtri avanzati della ricerca è inoltre possibile ottenere alcuni altri dati sull’archivio. Si può ad esempio conoscere il numero degli utenti che hanno usato l’hashtag (19360) e quale di questi lo abbia fatto più volte (15). Conoscere l’hashtag più utilizzato è Paranormal con 281 occorrenze seguito curiosamente da iDontSupport con 66 occorrenze. In totale sono stati utilizzati 1342 hastag diversi. Ci sono invece 5930 utenti diversi menzionati con in testa l’account ufficiale del film chiamato in causa da 531 status.
Il risultato di una ricerca può essere salvato in un bucket (un contenitore di passaggio con il quale miscelare i dati unendo ad esempio più di un bucket) dal quale costruire poi un dataset. Al dataset possono essere applicate le classiche tecniche di analisi del contenuto basate su griglie di analisi date o costruite a partire dai dati. Il dataset toolbox comprende strumenti piuttosto avanzati per il supporto della collaborazione fra più ricercatori nella codifica dello stesso dataset.
Veniamo adesso ai dati che riguardano i trending topics italiani.
Mi soffermerò sui casi di #gheddafi lang:it, #nubifragio, #notav, #XF5 e #gf12.
L’importer avviato alle il 20/10/2011 alle 13:50 (l’ANSA con la notizia della morte di Gheddafi è delle 13:11) ha raccolto 6601 Tweet. Il primo contenuto reperito è datato 20/10/2011 alle 13:49, l’ultimo 24/10/2011 alle 11:17.
Nel GNIP Feed Management è possibile visualizzare un grafico dell’andamento dei Tweet per ogni importer attivo.
Questo è il grafico per #gheddafi (gli orari sono in EST – Eastern Standard Time e gli slot temporali da circa 15 minuti).

 
Il picco è di oltre 300 Tweet in 15 minuti circa e corrisponde con il momento di attivazione dell’importer. Sarebbe stato bello poter raccogliere i dati di quella mezz’ora intercorsa fra l’annuncio della morte ed il momento di attivazione dell’importer. Raccogliere dataset completi relativi a breaking news è veramente difficile con questo metodo.
Per questo motivo ho provato nel caso di #nubifragio ad utilizzare sia l’importer basato sulle REST API sia il GNIP Power Track.
Con questo metodo ho reperito 4005 (1886 con GNIP e 2119 con le REST API) Tweet. La rimozione dei duplicati esatti ha ridotto l’archivio a 1783 status. Non mi è chiarissimo con questo elenco dei duplicati esatti venga creato e dopo averlo applicato anche ad altri archivi che non avrebbero dovuto contenere duplicati temo posso rimuovere anche i retweet identici. Purtroppo è difficile estrarre da questo archivio elementi utili sulle date perché, apparentemente, i Tweet importati da GNIP e quelli importati dalle REST API sono riferiti a fusi orari diversi.  Questo status duplicato ha come ora di pubblicazione rispettivamente le 9:33 AM EST e le 5:33 AM di un fuso orario sconosciuto.
Più semplice è invece lavorare su eventi programmati per i quali è possibile attivare l’importer per tempo.
Per la manifestazione di Val di Susa ho seguito l’hashtag #notav e la stringa di ricerca “val di susa”. Ho attivato l’importer alle 8:34 23/10 e reperito nel complesso 5501 Tweet.
Di seguito il grafico per l’hashtag #notav.

 
In questo caso sono riuscito a fotografare l’andamento del fenomeno prima che raggiungesse il picco (avvenuto intorno all’ora di pranzo con oltre 300 Tweet prodotti durante lo slot di 15 minuti circa).
Gli hashtag più utilizzati sono stati #diamociuntaglio (1014) e #report (117). Dei 429 utenti menzionati, notav_info è il più citato (645). In totale hanno contribuito a questo hashtag 1300 utenti diversi. Il più attivo è stato ViceVersa_1917 con 146 Tweet.
Durante il periodo di betatest sono inoltre andati in onda le prime puntate della quinta stagione di X Factor e della dodicesima edizione de Il Grande Fratello.
Per X Factor ho monitorato l’hashtag #xf5 con colpevole ritardo a partire dalla mattina successiva alla messa in onda.

 
Anche la mattina dopo c’è stato un discreto volume di conversazioni che ha superato il picco di 200 Tweet in 15 minuti. Se dovessi avere ancora accesso al servizio proverò a raccogliere i dati relativi alla messa in onda della seconda puntata in onda domani.
Infine per quanto riguarda la prima puntata della dodicesima stagione de Il Grande Fratello ho monitorato sia l’hashtag #gf12 che la stringa “grande fratello” a partire da pochi minuti prima della messa in onda (20:56 del 24/10).
Ecco il volume di Tweet durante la messa in onda (il primo grafico è riferito a “grande fratello” e il secondo a #gf12) [le 3 PM del grafico equivalgono alle nostre 21:00].

 

 
In entrambi i casi l’andamento è simile con le discussioni che si protraggono fino a oltre mezza notte (le 6 PM nel grafico). Il buco delle 5 PM del grafico credo sia dovuto a qualche problema nel flusso di importazione dei dati.
Nel secondo caso si sono toccati e superati gli 800 Tweet in 15 minuti. Inoltre questo volume è stato mantenuto per tutta la durata del programma.
Nel complesso ho reperito 13308 generati da 5169 utenti il più attivo dei quali è stato w4rr10r_0 con i suoi 160 status. Oltre a #gf12 sono stati utilizzati altri 883 diversi hashtag. Il più utilizzato dopo #gf12 è stato #GrandeFratello.
Fra i xxx menzionati nei Tweet etichettati #gf12 spicca @Microsatira il cui tweet ironico è stato retweettato oltre 100 volte (in totale ha ricevuto 189 mentions).
La seguente tagcloud dovrebbe dare un’idea dei temi più citati:

Come spesso accade nei discorsi sui programmi televisivi di grande richiamo i commenti veri e propri al programma si sommano ai giudizi di chi non riesce a capacitarsi di come quel programma possa avere successo o si lamenta della qualità della televisione italiana.
In conclusione credo che DiscoverText sia uno strumento con delle caratteristiche uniche. Non si tratta di un prodotto perfetto e non sono mancate le volte nelle quali, specie su grandi quantità di dati, mi sono stati restituiti dei messaggi di errore. L’accordo che stanno perfezionando con Gnip potrebbe rendere questo strumento essenziale per chi voglia fare ricerca su Twitter. Le modalità di implementazione di questa funzionalità rendono bene le potenzialità di estensibilità della piattaforma. La gestione delle timezones appare migliorabile (forse renderanno in futuro possibile scegliere all’utente il fuso orario per il grafico). Nel complesso il sistema si comporta bene anche su grandi quantità di dati mostrando eccellenti performance nella creazione delle tagclouds (che necessiterebbero però della possibilità di escludere liste di parole comuni) e nelle ricerche che richiedono sempre tempi ragionevolmente brevi per essere portate a termine.
Credo ci siano più di uno spunto
Come ho avuto modo di scrivere altrove, l’utilizzo di una piattaforma web collaborativa per l’analisi del contenuto rappresenta un percorso obbligato per chi desideri fare ricerca qualitativa su grandi quantità di dati (come quelli provenienti dai media sociali).
DiscoverText è un prodotto della Texifter LLC. Si tratta di una società nata come spin-off a partire dall’attività di ricerca di Stuart W. Shulman presso la University of Massachusetts Amherst.
Non mi resta dunque che augurare buon lavoro a Stuart e al suo team di sviluppatori.
P.S. Durante il periodo di beta-test i dati non sono esportabili quindi non chiedetemeli 😉
 
 
 
 
 Come accennato nel precedente post, ho avuto la possibilità di testare per alcuni giorni una nuova funzionalità di DiscoverText che consente di reperire gli status di Twitter (Tweet) in tempo (quasi) reale.  Grazie all’accordo con Gnip, DiscoverText consente dunque di accedere alla così detta Firehose (il flusso di tutti gli status di Twitter) e di raccogliere questi contenuti per una successiva analisi.
La partecipazione a questo programma di beta test è durata dal 19 al 24 Ottobre (anche se il servizio è ancora al momento attivo).
DiscoverText, già nella versione in produzione, consente di importare contenuti da diverse fonti:

Per quanto riguarda Twitter era già disponibile il Live Feed Import basato sulle REST API di Twitter che richiede l’autenticazione con il proprio nome utente e password ed ha il vantaggio di poter reperire i Tweet da un archivio degli ultimi 5/6 giorni e lo svantaggio di non garantire la completezza dei risultati (si veda il precedente post per i dettagli su questo).
La novità è il GNIP PowerTrack importer.
Questa modalità di importazione dei Tweet ha il vantaggio di restituire il flusso completo di tutti gli status pubblici e lo svantaggio di non consentire l’accesso ad alcun archivio (il flusso che si riesce a reperire parte dal momento in cui si inizia a raccogliere i dati).
Una combinazione delle due metodologie di importazione descritte dovrebbe consentire dunque una ragionevole fedeltà nella raccolta dati (ovviamente bisognerà rimuovere i duplicati, cosa che DiscoverText consente di fare in automatico).
La metodologia di importazione GNIP PowerTrack si basa sulla costruzione di una regola di importazione che può essere costruita da un massimo di 10 termini o operatori fino a una lunghezza complessiva di 255 caratteri per l’intera regola. In pratica si tratta di filtrare il flusso dei contenuti secondo certi criteri.
Si possono cercare frasi esatte, usare gli operatori – per escludere un termine, usare un hashtag – vengono identificati alla fonte da Twitter – come chiave di ricerca, una mention di un utente specifico (@nomeutente compresi i RT), status prodotti o destinati ad un utente specifico (from: e to:), contenenti smile, status prodotti da un client specifico, status che siano retweet di uno specifico utente, status contenenti luoghi, stringhe specifiche, che contengono un certo indirizzo internet, status prodotti da utenti che abbiano un klout score compreso fra due valori minimo e massimo, status che contengono link, che siano geo-referenziati, che contengono almeno una mentions (compresi dunque i retweet) o almeno un hashtag e infine status classificati da Gnip come appartenenti ad una certa lingua (compreso l’italiano).
Per testare la funzionalità ho raccolto i dati per molti dei trending topics (per capire meglio come vengono calcolati consiglio la lettura di questo articolo) italiani emersi nel corso degli ultimi giorni da #erpelliccia a #gheddafi, da #nubifragio a #notav (+ “val di susa”) senza dimenticare #XF5 e #gf12.  Ho anche provato per breve tempo a monitorare un trending topic globale e sponsorizzato come “Paranormal Activity 3”. Per completare i test ho anche provato a raccogliere i dati dell’interno stream di contenuti in lingua italiana allo scopo di comprendere meglio la consistenza del flusso di tweet prodotti nella nostra lingua.
Iniziamo l’analisi da questi ultimi.
Usando il filtro lang:it avrei dovuto reperire il flusso di Tweet in italiano. Purtroppo questo filtro si è dimostrato del tutto inefficace. Per motivi che non mi sono chiari oltre ai Tweet in italiano sono stati anche reperiti i Tweet in altre lingue fra cui indonesiano, malese, vietnamita, turco e chissà quante altre (ho usato Google Translate per identificarle). Questa errata identificazione della lingua ha reso impossibile raggiungere l’obiettivo che mi ero posto ed i sotto-obiettivi che sarebbero stati identificare quanti di questi Tweet prodotti nella nostra lingua fossero geo-referenziati, contenessero link, mentions ed hashtag.
Passiamo dunque all’analisi del flusso di un trending topic globale e sponsorizzato come “Paranormal Activity 3”.
In questo caso, usando la semplice ricerca per frase esatta, sono stati reperiti 21333 status updates in circa due ore e mezza (nello specifico fra  il 10/21/2011 2:36:13 AM ed il 10/21/2011 5:05:37 AM EST: Eastern Standard Time).  Si tratta di 142 Tweet circa al minuto. DiscoverText supporta l’analisi di grandi quantità di dati attraverso uno strumento chiamato CloudExplorer. Si tratta in pratica di una semplice tagcloud che consente però di cliccare su ogni voce per accedere alla lista dei contenuti filtrati per quella parola chiave.

 
Cliccando ad esempio su See si accede ad una lista filtrata dei 7260 Tweet in archivio che contengono questo termine.  L’archivio può inoltre essere ricercato liberamente per parola chiave e filtrato usando uno o più criteri basati sugli stessi metadati disponibili per la costruzione di un filtro. Posso ad esempio sapere con facilità quanti status in archivio contengono un hashtag (in questo caso 2433) o quanti contengono menzioni di altri utenti (8004).
Dal pannello filtri avanzati della ricerca è inoltre possibile ottenere alcuni altri dati sull’archivio. Si può ad esempio conoscere il numero degli utenti che hanno usato l’hashtag (19360) e quale di questi lo abbia fatto più volte (15). Conoscere l’hashtag più utilizzato è Paranormal con 281 occorrenze seguito curiosamente da iDontSupport con 66 occorrenze. In totale sono stati utilizzati 1342 hastag diversi. Ci sono invece 5930 utenti diversi menzionati con in testa l’account ufficiale del film chiamato in causa da 531 status.
Il risultato di una ricerca può essere salvato in un bucket (un contenitore di passaggio con il quale miscelare i dati unendo ad esempio più di un bucket) dal quale costruire poi un dataset. Al dataset possono essere applicate le classiche tecniche di analisi del contenuto basate su griglie di analisi date o costruite a partire dai dati. Il dataset toolbox comprende strumenti piuttosto avanzati per il supporto della collaborazione fra più ricercatori nella codifica dello stesso dataset.
Veniamo adesso ai dati che riguardano i trending topics italiani.
Mi soffermerò sui casi di #gheddafi lang:it, #nubifragio, #notav, #XF5 e #gf12.
L’importer avviato alle il 20/10/2011 alle 13:50 (l’ANSA con la notizia della morte di Gheddafi è delle 13:11) ha raccolto 6601 Tweet. Il primo contenuto reperito è datato 20/10/2011 alle 13:49, l’ultimo 24/10/2011 alle 11:17.
Nel GNIP Feed Management è possibile visualizzare un grafico dell’andamento dei Tweet per ogni importer attivo.
Questo è il grafico per #gheddafi (gli orari sono in EST – Eastern Standard Time e gli slot temporali da circa 15 minuti).

 
Il picco è di oltre 300 Tweet in 15 minuti circa e corrisponde con il momento di attivazione dell’importer. Sarebbe stato bello poter raccogliere i dati di quella mezz’ora intercorsa fra l’annuncio della morte ed il momento di attivazione dell’importer. Raccogliere dataset completi relativi a breaking news è veramente difficile con questo metodo.
Per questo motivo ho provato nel caso di #nubifragio ad utilizzare sia l’importer basato sulle REST API sia il GNIP Power Track.
Con questo metodo ho reperito 4005 (1886 con GNIP e 2119 con le REST API) Tweet. La rimozione dei duplicati esatti ha ridotto l’archivio a 1783 status. Non mi è chiarissimo con questo elenco dei duplicati esatti venga creato e dopo averlo applicato anche ad altri archivi che non avrebbero dovuto contenere duplicati temo posso rimuovere anche i retweet identici. Purtroppo è difficile estrarre da questo archivio elementi utili sulle date perché, apparentemente, i Tweet importati da GNIP e quelli importati dalle REST API sono riferiti a fusi orari diversi.  Questo status duplicato ha come ora di pubblicazione rispettivamente le 9:33 AM EST e le 5:33 AM di un fuso orario sconosciuto.
Più semplice è invece lavorare su eventi programmati per i quali è possibile attivare l’importer per tempo.
Per la manifestazione di Val di Susa ho seguito l’hashtag #notav e la stringa di ricerca “val di susa”. Ho attivato l’importer alle 8:34 23/10 e reperito nel complesso 5501 Tweet.
Di seguito il grafico per l’hashtag #notav.

 
In questo caso sono riuscito a fotografare l’andamento del fenomeno prima che raggiungesse il picco (avvenuto intorno all’ora di pranzo con oltre 300 Tweet prodotti durante lo slot di 15 minuti circa).
Gli hashtag più utilizzati sono stati #diamociuntaglio (1014) e #report (117). Dei 429 utenti menzionati, notav_info è il più citato (645). In totale hanno contribuito a questo hashtag 1300 utenti diversi. Il più attivo è stato ViceVersa_1917 con 146 Tweet.
Durante il periodo di betatest sono inoltre andati in onda le prime puntate della quinta stagione di X Factor e della dodicesima edizione de Il Grande Fratello.
Per X Factor ho monitorato l’hashtag #xf5 con colpevole ritardo a partire dalla mattina successiva alla messa in onda.

 
Anche la mattina dopo c’è stato un discreto volume di conversazioni che ha superato il picco di 200 Tweet in 15 minuti. Se dovessi avere ancora accesso al servizio proverò a raccogliere i dati relativi alla messa in onda della seconda puntata in onda domani.
Infine per quanto riguarda la prima puntata della dodicesima stagione de Il Grande Fratello ho monitorato sia l’hashtag #gf12 che la stringa “grande fratello” a partire da pochi minuti prima della messa in onda (20:56 del 24/10).
Ecco il volume di Tweet durante la messa in onda (il primo grafico è riferito a “grande fratello” e il secondo a #gf12) [le 3 PM del grafico equivalgono alle nostre 21:00].

 

 
In entrambi i casi l’andamento è simile con le discussioni che si protraggono fino a oltre mezza notte (le 6 PM nel grafico). Il buco delle 5 PM del grafico credo sia dovuto a qualche problema nel flusso di importazione dei dati.
Nel secondo caso si sono toccati e superati gli 800 Tweet in 15 minuti. Inoltre questo volume è stato mantenuto per tutta la durata del programma.
Nel complesso ho reperito 13308 generati da 5169 utenti il più attivo dei quali è stato w4rr10r_0 con i suoi 160 status. Oltre a #gf12 sono stati utilizzati altri 883 diversi hashtag. Il più utilizzato dopo #gf12 è stato #GrandeFratello.
Fra i xxx menzionati nei Tweet etichettati #gf12 spicca @Microsatira il cui tweet ironico è stato retweettato oltre 100 volte (in totale ha ricevuto 189 mentions).
La seguente tagcloud dovrebbe dare un’idea dei temi più citati:

Come spesso accade nei discorsi sui programmi televisivi di grande richiamo i commenti veri e propri al programma si sommano ai giudizi di chi non riesce a capacitarsi di come quel programma possa avere successo o si lamenta della qualità della televisione italiana.
In conclusione credo che DiscoverText sia uno strumento con delle caratteristiche uniche. Non si tratta di un prodotto perfetto e non sono mancate le volte nelle quali, specie su grandi quantità di dati, mi sono stati restituiti dei messaggi di errore. L’accordo che stanno perfezionando con Gnip potrebbe rendere questo strumento essenziale per chi voglia fare ricerca su Twitter. Le modalità di implementazione di questa funzionalità rendono bene le potenzialità di estensibilità della piattaforma. La gestione delle timezones appare migliorabile (forse renderanno in futuro possibile scegliere all’utente il fuso orario per il grafico). Nel complesso il sistema si comporta bene anche su grandi quantità di dati mostrando eccellenti performance nella creazione delle tagclouds (che necessiterebbero però della possibilità di escludere liste di parole comuni) e nelle ricerche che richiedono sempre tempi ragionevolmente brevi per essere portate a termine.
Credo ci siano più di uno spunto
Come ho avuto modo di scrivere altrove, l’utilizzo di una piattaforma web collaborativa per l’analisi del contenuto rappresenta un percorso obbligato per chi desideri fare ricerca qualitativa su grandi quantità di dati (come quelli provenienti dai media sociali).
DiscoverText è un prodotto della Texifter LLC. Si tratta di una società nata come spin-off a partire dall’attività di ricerca di Stuart W. Shulman presso la University of Massachusetts Amherst.
Non mi resta dunque che augurare buon lavoro a Stuart e al suo team di sviluppatori.
P.S. Durante il periodo di beta-test i dati non sono esportabili quindi non chiedetemeli 😉
 
 
 
 
 

Limiti e possibilità della ricerca su Twitter

Il crescere del numero di ricercatori che scelgono i social media come luogo di osservazione per studiare le dinamiche sociali rende indispensabile fare il punto su limiti e possibilità offerti da queste piattaforme

Facendo seguito al diffondersi dei social media presso la popolazione del nostro Paese, si va progressivamente affermando, anche nella comunità accademica italiana, l’idea che questi spazi possano essere considerati un luogo di osservazione per le dinamiche sociali interne ed esterne alla rete.
Come all’estero anche in Italia, i ricercatori, al pari dei media, dedicano a Twitter un’attenzione talvolta non giustificata dai dati sulla diffusione della piattaforma stessa.
Sul blog ufficiale di Twitter si legge che la piattaforma ha recentemente tagliato il traguardo dei 100 milioni di account attivi nel mondo, che la metà di questi accede quotidianamente e che il 40% di essi legge i Tweet creati da altri utenti senza produrne di propri. Dopo questo annuncio, Vincenzo Cosenza ha messo a confronto questi dati con quelli rilasciati da Facebook.
Twitter non rilascia dati ufficiali sul numero di utenti registrati o attivi in ogni nazione, ma fonti attendibili stimavano circa 1,3 milioni di utenti italiani registrati di cui circa 350.000 attivi (che avevano cioè fatto login durante i precedenti trenta giorni attraverso Twitter o le sue API) a ottobre 2010. Per darvi un termine di paragone, nello stesso periodo Facebook aveva oltre 16 milioni di utenti italiani registrati e Linkedin 1,1.
Capire la situazione a oggi non è affatto semplice.
Stimare il traffico verso il sito non è infatti, in questo caso, un buon indicatore perché una significativa fetta di utenti accede a Twitter usando client che consentono di fruire della piattaforma senza passare dal sito twitter.com. Le statistiche di ricerca di Google evidenziano un interesse crescente, in Italia, per questa piattaforma con un volume che, tuttavia, non si discosta molto da quello di siti come Badoo, Netlog o Flickr. Provate voi stessi ad aggiungere la parola chiave Facebook per farvi un’idea dei rapporti fra i volumi di ricerca (che rappresentano un indicatore dell’interesse degli utenti verso una certa piattaforma).
Chiarite le proporzioni ci sarebbe da attendersi una analoga sproporzione nell’interesse dei ricercatori italiani.
Di fatto così non è. Anche se non ho dati specifici a riguardo ho la sensazione che gli studi basati sull’analisi dei contenuti generati dagli utenti su Facebook e su Twitter si equivalgano o propendano piuttosto per quest’ultima piattaforma. Basta scorrere il resoconto del recente convegno dell’associazione internazionale dei ricercatori che studiano internet, per capire che non si tratta di un fenomeno italiano e che l’interesse della comunità accademica è centrato, a dispetto dei dati sull’utilizzo, più su Twitter che su Facebook. Questa tendenza è particolarmente curiosa in Paesi come il nostro dove i dati sulla diffusione delle piattaforme restituiscono una mappa che indica piuttosto chiaramente dove si trova la maggior parte di utenti e dunque le dinamiche sociali che riguardano settori significativi della popolazione.
Credo ci siano diversi motivi che contribuiscono in vario modo a rendere Twitter una piattaforma attraente dal punto di vista dei ricercatori:
1. Il sistema di privacy e le pratiche d’uso di Facebook rendono inaccessibile gran parte dei contenuti. Su Twitter la maggior parte dei contenuti sono pubblici ed accessibili tramite semplici (o apparentemente semplici) ricerche;
2. L’interesse dei media verso Twitter rende notiziabili le ricerche che riguardano questa piattaforma;
3. La natura orientata all’informazione (la domanda di Twitter è “Cosa sta succedendo” e non “A cosa stai pensando”) lo rendono particolarmente indicato per studi orientati a comprendere i percorsi di diffusione delle notizie;
4. L’emergere di pratiche come l’uso degli hashtag, il retweet, il replay e trending topics (ormai parte delle funzionalità interne della piattaforma) rendono più semplice comprendere la struttura delle conversazioni.
Dunque ci sono diversi buoni motivi per usare Twitter come luogo di osservazione.
L’apparente semplicità di accesso cela tuttavia dei rischi di cui il ricercatore dovrebbe essere, quanto meno, al correte.
Intanto i Tweet reperibili sono, ovviamente, solo quelli pubblici. Per la maggior parte dei progetti non si tratta di un grosso problema che va semplicemente rendicontato specificando, quando ci si riferisce al corpus di dati, di Tweet pubblici.
Ma c’è dell’altro. Come forse saprete Twitter impone dei limiti di accesso per l’utilizzo delle sue API pubbliche.
Purtroppo questi limiti non sono affatto chiari.
Si sa che le Twitter REST API sono soggette ai seguenti limiti:
– 150 richieste non autenticate ogni ora (basate sul numero ip dal quale proviene la richiesta);
– 350 richieste autenticate all’ora (basate sull’identificativo dell’utente che fa la richiesta).
Si sa inoltre che ogni richiesta può restituire un massimo di 1500 tweet.
La documentazione che riguarda le Twitter Search API specifica che la ricerca non dà accesso all’indice completo di tutti i Tweet ma solo di quelli recenti (fino a 6-9 giorni prima) e che non si possono usare le Search API per trovare Tweet più vecchi di una settimana.
Inoltre aggiunge:

The Rate Limits for the Search API are not the same as for the REST API. When using the Search API you are not restricted by a certain number of API requests per hour, but instead by the complexity and frequency.
As requests to the Search API are anonymous, the rate limit is measured against the requesting client IP.
To prevent abuse the rate limit for Search is not published. If you are rate limited, the Search API will respond with an HTTP 420 Error. {"error":"You have been rate limited. Enhance your calm."}.

Dunque i Tweet reperiti attraverso questa API non garantiscono la completezza (la documentazione parla invece di focus sulla rilevanza) e alcuni Tweet potrebbero mancare all’appello per raggiunti limiti di richieste, perché l’utente che ha generato il tweet ha un basso ranking o, infine, semplicemente perché, a causa della limitatezza delle risorse, non tutti i Tweet possono essere indicizzati in Twitter Search (si veda qui).
Se si desidera la completezza (un requisito di solito indispensabile per chi fa ricerca), dice sempre la documentazione di Twitter, conviene usare le Streaming API.
Le Straming API restituiscono i Tweet in tempo reale. Questo significa che non è possibile tornare indietro nel tempo.
Ma anche le Streaming API hanno dei limiti.

Both the Streaming API and the Search API filter, and on some end-points, discard, statuses created by a small proportion of accounts based upon status quality metrics.

In compenso

 The Streaming API results are a superset of the Search API result. The Search API filters and ranks statuses for relevance. On certain queries, the Search relevance filtering can be quite selective. The Streaming API does not perform any relevance filtering or ranking. All statuses that pass the Result Quality filter are available on Streaming API.

L’uso delle Streaming API richiede l’autenticazione.
Di seguito, nel paragrafo su accesso e limiti di utilizzo, si dice che tutti gli utenti di Twitter sono abilitati a usare due metodi chiamati statuses/sample e statuses/filter e che per tutti gli altri metodi bisogna contattare Twitter.
Ora cosa sono questi statuses/sample e statuses/filter?
Il primo restituisce un campione di Tweet basato sull’universo costituito dal flusso di tutti gli status pubblici (il cui flusso è chiamato da Twitter Firehose).
Le proporzioni di questo campione possono cambiare senza preavviso ma al momento sono le seguenti:
– Circa l’1% degli status pubblici per il flusso che Twitter chiama Spritzer (disponibile a tutti);
– Circa il 10% per il flusso denominato Gardenhose (disponibile su richiesta).
Il metodo statuses/filter è quello che dovrebbe maggiormente interessare un ricercatore. Consente in pratica di filtrare il flusso per specifiche parole chiave (ad esempio un certo hashtag), per posizione geografica, che contengono il nome di un utente (@nomeutente) come un replay o un retweet o una semplice menzione.
Il livello di accesso di default consente l’accesso ad un massimo di 400 parole chiave, di 5000 nomi utente e 25 luoghi geografici (non è chiaro se si tratta di limiti legati alla storia del singolo utente o contemporanei).
In aggiunta a questi limiti la documentazione di Twitter contiene un paragrafo intitolato Filter Limiting nel quale si specifica che le ricerche per parole (track) chiave e quelle per luogo sono soggette ad un limite di utilizzo e aggiunge…

Reasonably focused track and location predicates will return all occurrences in the full Firehose stream of public statuses. Overly broad predicates will cause the output to be periodically limited. After the limitation period expires, all matching statuses will once again be delivered, along with a limit message that enumerates the total number of statuses that have been eliminated from the stream since the start of the connection. Limit messages are described in Parsing Responses.

Non è dato sapere cosa costituisca una ricerca ragionevolmente focalizzata. Rimane dunque la sensazione di una certa confusione.  Nell’articolo Six Provocations for Big Data le autrici affermano che

Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access. Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts.Is the data representative of all public tweets? Perhaps, but not necessarily.

Di recente DiscoverText ha siglato un accordo con Gnip per offrire ai ricercatori che usano questa piattaforma l’accesso alla Firehose di Twitter. Al momento il servizio è in beta limitata ad un ristretto numero di utenti.
Da ieri ho accesso a questo servizio e lo avrò per i prossimi 4 giorni. Ho già iniziato a raccogliere dati per i principali trending topic italiani. In questi giorni cercherò di capire meglio i vantaggi e gli eventuali limiti di questa soluzione e ne parlerò in un prossimo post.Facendo seguito al diffondersi dei social media presso la popolazione del nostro Paese, si va progressivamente affermando, anche presso la comunità accademica italiana, l’idea che questi spazi possano essere considerati un luogo di osservazione per le dinamiche sociali interne ed esterne alla rete.
Come all’estero anche in Italia, i ricercatori, come i media, dedicano a Twitter un’attenzione talvolta non giustificata dai dati sulla diffusione della piattaforma stessa.
Sul blog ufficiale di Twitter si legge che la piattaforma ha recentemente tagliato il traguardo dei 100 milioni di account attivi nel mondo, che la metà di questi accede quotidianamente e che il 40% di essi legge i Tweet creati da altri utenti senza produrne di propri. Dopo questo annuncio, Vincenzo Cosenza ha messo a confronto questi dati con quelli rilasciati da Facebook.
Twitter non rilascia dati ufficiali sul numero di utenti registrati o attivi in ogni nazione, ma fonti attendibili stimavano circa 1,3 milioni di utenti italiani registrati di cui circa 350.000 attivi (che avevano cioè fatto login durante i precedenti trenta giorni attraverso Twitter o le sue API) a ottobre 2010. Per darvi un termine di paragone, nello stesso periodo Facebook aveva oltre 16 milioni di utenti italiani registrati e Linkedin 1,1.
Capire la situazione a oggi non è affatto semplice.
Stimare il traffico verso il sito non è infatti, in questo caso, un buon indicatore perché una significativa fetta di utenti accede a Twitter usando client che consentono di fruire della piattaforma senza passare dal sito twitter.com. Le statistiche di ricerca di Google evidenziano un interesse crescente, in Italia, per questa piattaforma con un volume che, tuttavia, non si discosta molto da quello di siti come Badoo, Netlog o Flickr. Provate voi stessi ad aggiungere la parola chiave Facebook per farvi un’idea dei rapporti fra i volumi di ricerca (che rappresentano un indicatore dell’interesse degli utenti verso una certa piattaforma).
Chiarite le proporzioni ci sarebbe da attendersi una analoga sproporzione nell’interesse dei ricercatori italiani.
Di fatto così non è. Anche se non ho dati specifici a riguardo ho la sensazione che gli studi basati sull’analisi dei contenuti generati dagli utenti su Facebook e su Twitter si equivalgano o propendano piuttosto per quest’ultima piattaforma. Basta scorrere il resoconto del recente convegno dell’associazione internazionale dei ricercatori che studiano internet, per capire che non si tratta di un fenomeno italiano e che l’interesse della comunità accademica è centrato, a dispetto dei dati sull’utilizzo, più su Twitter che su Facebook. Questa tendenza è particolarmente curiosa in Paesi come il nostro dove i dati sulla diffusione delle piattaforme restituiscono una mappa che indica piuttosto chiaramente dove si trova la maggior parte di utenti e dunque le dinamiche sociali che riguardano settori significativi della popolazione.
Credo ci siano diversi motivi che contribuiscono in vario modo a rendere Twitter una piattaforma attraente dal punto di vista dei ricercatori:
1. Il sistema di privacy e le pratiche d’uso di Facebook rendono inaccessibile gran parte dei contenuti. Su Twitter la maggior parte dei contenuti sono pubblici ed accessibili tramite semplici (o apparentemente semplici) ricerche;
2. L’interesse dei media verso Twitter rende notiziabili le ricerche che riguardano questa piattaforma;
3. La natura orientata all’informazione (la domanda di Twitter è “Cosa sta succedendo” e non “A cosa stai pensando”) lo rendono particolarmente indicato per studi orientati a comprendere i percorsi di diffusione delle notizie;
4. L’emergere di pratiche come l’uso degli hashtag, il retweet, il replay e trending topics (ormai parte delle funzionalità interne della piattaforma) rendono più semplice comprendere la struttura delle conversazioni.
Dunque ci sono diversi buoni motivi per usare Twitter come luogo di osservazione.
L’apparente semplicità di accesso cela tuttavia dei rischi di cui il ricercatore dovrebbe essere, quanto meno, al correte.
Intanto i Tweet reperibili sono, ovviamente, solo quelli pubblici. Per la maggior parte dei progetti non si tratta di un grosso problema che va semplicemente rendicontato specificando, quando ci si riferisce al corpus di dati, di Tweet pubblici.
Ma c’è dell’altro. Come forse saprete Twitter impone dei limiti di accesso per l’utilizzo delle sue API pubbliche.
Purtroppo questi limiti non sono affatto chiari.
Si sa che le Twitter REST API sono soggette ai seguenti limiti:
– 150 richieste non autenticate ogni ora (basate sul numero ip dal quale proviene la richiesta);
– 350 richieste autenticate all’ora (basate sull’identificativo dell’utente che fa la richiesta).
Si sa inoltre che ogni richiesta può restituire un massimo di 1500 tweet.
La documentazione che riguarda le Twitter Search API specifica che la ricerca non dà accesso all’indice completo di tutti i Tweet ma solo di quelli recenti (fino a 6-9 giorni prima) e che non si possono usare le Search API per trovare Tweet più vecchi di una settimana.
Inoltre aggiunge:

The Rate Limits for the Search API are not the same as for the REST API. When using the Search API you are not restricted by a certain number of API requests per hour, but instead by the complexity and frequency.
As requests to the Search API are anonymous, the rate limit is measured against the requesting client IP.
To prevent abuse the rate limit for Search is not published. If you are rate limited, the Search API will respond with an HTTP 420 Error. {"error":"You have been rate limited. Enhance your calm."}.

Dunque i Tweet reperiti attraverso questa API non garantiscono la completezza (la documentazione parla invece di focus sulla rilevanza) e alcuni Tweet potrebbero mancare all’appello per raggiunti limiti di richieste, perché l’utente che ha generato il tweet ha un basso ranking o, infine, semplicemente perché, a causa della limitatezza delle risorse, non tutti i Tweet possono essere indicizzati in Twitter Search (si veda qui).
Se si desidera la completezza (un requisito di solito indispensabile per chi fa ricerca), dice sempre la documentazione di Twitter, conviene usare le Streaming API.
Le Straming API restituiscono i Tweet in tempo reale. Questo significa che non è possibile tornare indietro nel tempo.
Ma anche le Streaming API hanno dei limiti.

Both the Streaming API and the Search API filter, and on some end-points, discard, statuses created by a small proportion of accounts based upon status quality metrics.

In compenso

 The Streaming API results are a superset of the Search API result. The Search API filters and ranks statuses for relevance. On certain queries, the Search relevance filtering can be quite selective. The Streaming API does not perform any relevance filtering or ranking. All statuses that pass the Result Quality filter are available on Streaming API.

L’uso delle Streaming API richiede l’autenticazione.
Di seguito, nel paragrafo su accesso e limiti di utilizzo, si dice che tutti gli utenti di Twitter sono abilitati a usare due metodi chiamati statuses/sample e statuses/filter e che per tutti gli altri metodi bisogna contattare Twitter.
Ora cosa sono questi statuses/sample e statuses/filter?
Il primo restituisce un campione di Tweet basato sull’universo costituito dal flusso di tutti gli status pubblici (il cui flusso è chiamato da Twitter Firehose).
Le proporzioni di questo campione possono cambiare senza preavviso ma al momento sono le seguenti:
– Circa l’1% degli status pubblici per il flusso che Twitter chiama Spritzer (disponibile a tutti);
– Circa il 10% per il flusso denominato Gardenhose (disponibile su richiesta).
Il metodo statuses/filter è quello che dovrebbe maggiormente interessare un ricercatore. Consente in pratica di filtrare il flusso per specifiche parole chiave (ad esempio un certo hashtag), per posizione geografica, che contengono il nome di un utente (@nomeutente) come un replay o un retweet o una semplice menzione.
Il livello di accesso di default consente l’accesso ad un massimo di 400 parole chiave, di 5000 nomi utente e 25 luoghi geografici (non è chiaro se si tratta di limiti legati alla storia del singolo utente o contemporanei).
In aggiunta a questi limiti la documentazione di Twitter contiene un paragrafo intitolato Filter Limiting nel quale si specifica che le ricerche per parole (track) chiave e quelle per luogo sono soggette ad un limite di utilizzo e aggiunge…

Reasonably focused track and location predicates will return all occurrences in the full Firehose stream of public statuses. Overly broad predicates will cause the output to be periodically limited. After the limitation period expires, all matching statuses will once again be delivered, along with a limit message that enumerates the total number of statuses that have been eliminated from the stream since the start of the connection. Limit messages are described in Parsing Responses.

Non è dato sapere cosa costituisca una ricerca ragionevolmente focalizzata. Rimane dunque la sensazione di una certa confusione.  Nell’articolo Six Provocations for Big Data le autrici affermano che

Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access. Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts.Is the data representative of all public tweets? Perhaps, but not necessarily.

Di recente DiscoverText ha siglato un accordo con Gnip per offrire ai ricercatori che usano questa piattaforma l’accesso alla Firehose di Twitter. Al momento il servizio è in beta limitata ad un ristretto numero di utenti.
Da ieri ho accesso a questo servizio e lo avrò per i prossimi 4 giorni. Ho già iniziato a raccogliere dati per i principali trending topic italiani. In questi giorni cercherò di capire meglio i vantaggi e gli eventuali limiti di questa soluzione e ne parlerò in un prossimo post.Facendo seguito al diffondersi dei social media presso la popolazione del nostro Paese, si va progressivamente affermando, anche presso la comunità accademica italiana, l’idea che questi spazi possano essere considerati un luogo di osservazione per le dinamiche sociali interne ed esterne alla rete.
Come all’estero anche in Italia, i ricercatori, come i media, dedicano a Twitter un’attenzione talvolta non giustificata dai dati sulla diffusione della piattaforma stessa.
Sul blog ufficiale di Twitter si legge che la piattaforma ha recentemente tagliato il traguardo dei 100 milioni di account attivi nel mondo, che la metà di questi accede quotidianamente e che il 40% di essi legge i Tweet creati da altri utenti senza produrne di propri. Dopo questo annuncio, Vincenzo Cosenza ha messo a confronto questi dati con quelli rilasciati da Facebook.
Twitter non rilascia dati ufficiali sul numero di utenti registrati o attivi in ogni nazione, ma fonti attendibili stimavano circa 1,3 milioni di utenti italiani registrati di cui circa 350.000 attivi (che avevano cioè fatto login durante i precedenti trenta giorni attraverso Twitter o le sue API) a ottobre 2010. Per darvi un termine di paragone, nello stesso periodo Facebook aveva oltre 16 milioni di utenti italiani registrati e Linkedin 1,1.
Capire la situazione a oggi non è affatto semplice.
Stimare il traffico verso il sito non è infatti, in questo caso, un buon indicatore perché una significativa fetta di utenti accede a Twitter usando client che consentono di fruire della piattaforma senza passare dal sito twitter.com. Le statistiche di ricerca di Google evidenziano un interesse crescente, in Italia, per questa piattaforma con un volume che, tuttavia, non si discosta molto da quello di siti come Badoo, Netlog o Flickr. Provate voi stessi ad aggiungere la parola chiave Facebook per farvi un’idea dei rapporti fra i volumi di ricerca (che rappresentano un indicatore dell’interesse degli utenti verso una certa piattaforma).
Chiarite le proporzioni ci sarebbe da attendersi una analoga sproporzione nell’interesse dei ricercatori italiani.
Di fatto così non è. Anche se non ho dati specifici a riguardo ho la sensazione che gli studi basati sull’analisi dei contenuti generati dagli utenti su Facebook e su Twitter si equivalgano o propendano piuttosto per quest’ultima piattaforma. Basta scorrere il resoconto del recente convegno dell’associazione internazionale dei ricercatori che studiano internet, per capire che non si tratta di un fenomeno italiano e che l’interesse della comunità accademica è centrato, a dispetto dei dati sull’utilizzo, più su Twitter che su Facebook. Questa tendenza è particolarmente curiosa in Paesi come il nostro dove i dati sulla diffusione delle piattaforme restituiscono una mappa che indica piuttosto chiaramente dove si trova la maggior parte di utenti e dunque le dinamiche sociali che riguardano settori significativi della popolazione.
Credo ci siano diversi motivi che contribuiscono in vario modo a rendere Twitter una piattaforma attraente dal punto di vista dei ricercatori:
1. Il sistema di privacy e le pratiche d’uso di Facebook rendono inaccessibile gran parte dei contenuti. Su Twitter la maggior parte dei contenuti sono pubblici ed accessibili tramite semplici (o apparentemente semplici) ricerche;
2. L’interesse dei media verso Twitter rende notiziabili le ricerche che riguardano questa piattaforma;
3. La natura orientata all’informazione (la domanda di Twitter è “Cosa sta succedendo” e non “A cosa stai pensando”) lo rendono particolarmente indicato per studi orientati a comprendere i percorsi di diffusione delle notizie;
4. L’emergere di pratiche come l’uso degli hashtag, il retweet, il replay e trending topics (ormai parte delle funzionalità interne della piattaforma) rendono più semplice comprendere la struttura delle conversazioni.
Dunque ci sono diversi buoni motivi per usare Twitter come luogo di osservazione.
L’apparente semplicità di accesso cela tuttavia dei rischi di cui il ricercatore dovrebbe essere, quanto meno, al correte.
Intanto i Tweet reperibili sono, ovviamente, solo quelli pubblici. Per la maggior parte dei progetti non si tratta di un grosso problema che va semplicemente rendicontato specificando, quando ci si riferisce al corpus di dati, di Tweet pubblici.
Ma c’è dell’altro. Come forse saprete Twitter impone dei limiti di accesso per l’utilizzo delle sue API pubbliche.
Purtroppo questi limiti non sono affatto chiari.
Si sa che le Twitter REST API sono soggette ai seguenti limiti:
– 150 richieste non autenticate ogni ora (basate sul numero ip dal quale proviene la richiesta);
– 350 richieste autenticate all’ora (basate sull’identificativo dell’utente che fa la richiesta).
Si sa inoltre che ogni richiesta può restituire un massimo di 1500 tweet.
La documentazione che riguarda le Twitter Search API specifica che la ricerca non dà accesso all’indice completo di tutti i Tweet ma solo di quelli recenti (fino a 6-9 giorni prima) e che non si possono usare le Search API per trovare Tweet più vecchi di una settimana.
Inoltre aggiunge:

The Rate Limits for the Search API are not the same as for the REST API. When using the Search API you are not restricted by a certain number of API requests per hour, but instead by the complexity and frequency.
As requests to the Search API are anonymous, the rate limit is measured against the requesting client IP.
To prevent abuse the rate limit for Search is not published. If you are rate limited, the Search API will respond with an HTTP 420 Error. {"error":"You have been rate limited. Enhance your calm."}.

Dunque i Tweet reperiti attraverso questa API non garantiscono la completezza (la documentazione parla invece di focus sulla rilevanza) e alcuni Tweet potrebbero mancare all’appello per raggiunti limiti di richieste, perché l’utente che ha generato il tweet ha un basso ranking o, infine, semplicemente perché, a causa della limitatezza delle risorse, non tutti i Tweet possono essere indicizzati in Twitter Search (si veda qui).
Se si desidera la completezza (un requisito di solito indispensabile per chi fa ricerca), dice sempre la documentazione di Twitter, conviene usare le Streaming API.
Le Straming API restituiscono i Tweet in tempo reale. Questo significa che non è possibile tornare indietro nel tempo.
Ma anche le Streaming API hanno dei limiti.

Both the Streaming API and the Search API filter, and on some end-points, discard, statuses created by a small proportion of accounts based upon status quality metrics.

In compenso

 The Streaming API results are a superset of the Search API result. The Search API filters and ranks statuses for relevance. On certain queries, the Search relevance filtering can be quite selective. The Streaming API does not perform any relevance filtering or ranking. All statuses that pass the Result Quality filter are available on Streaming API.

L’uso delle Streaming API richiede l’autenticazione.
Di seguito, nel paragrafo su accesso e limiti di utilizzo, si dice che tutti gli utenti di Twitter sono abilitati a usare due metodi chiamati statuses/sample e statuses/filter e che per tutti gli altri metodi bisogna contattare Twitter.
Ora cosa sono questi statuses/sample e statuses/filter?
Il primo restituisce un campione di Tweet basato sull’universo costituito dal flusso di tutti gli status pubblici (il cui flusso è chiamato da Twitter Firehose).
Le proporzioni di questo campione possono cambiare senza preavviso ma al momento sono le seguenti:
– Circa l’1% degli status pubblici per il flusso che Twitter chiama Spritzer (disponibile a tutti);
– Circa il 10% per il flusso denominato Gardenhose (disponibile su richiesta).
Il metodo statuses/filter è quello che dovrebbe maggiormente interessare un ricercatore. Consente in pratica di filtrare il flusso per specifiche parole chiave (ad esempio un certo hashtag), per posizione geografica, che contengono il nome di un utente (@nomeutente) come un replay o un retweet o una semplice menzione.
Il livello di accesso di default consente l’accesso ad un massimo di 400 parole chiave, di 5000 nomi utente e 25 luoghi geografici (non è chiaro se si tratta di limiti legati alla storia del singolo utente o contemporanei).
In aggiunta a questi limiti la documentazione di Twitter contiene un paragrafo intitolato Filter Limiting nel quale si specifica che le ricerche per parole (track) chiave e quelle per luogo sono soggette ad un limite di utilizzo e aggiunge…

Reasonably focused track and location predicates will return all occurrences in the full Firehose stream of public statuses. Overly broad predicates will cause the output to be periodically limited. After the limitation period expires, all matching statuses will once again be delivered, along with a limit message that enumerates the total number of statuses that have been eliminated from the stream since the start of the connection. Limit messages are described in Parsing Responses.

Non è dato sapere cosa costituisca una ricerca ragionevolmente focalizzata. Rimane dunque la sensazione di una certa confusione.  Nell’articolo Six Provocations for Big Data le autrici affermano che

Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access. Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts.Is the data representative of all public tweets? Perhaps, but not necessarily.

Di recente DiscoverText ha siglato un accordo con Gnip per offrire ai ricercatori che usano questa piattaforma l’accesso alla Firehose di Twitter. Al momento il servizio è in beta limitata ad un ristretto numero di utenti.
Da ieri ho accesso a questo servizio e lo avrò per i prossimi 4 giorni. Ho già iniziato a raccogliere dati per i principali trending topic italiani. In questi giorni cercherò di capire meglio i vantaggi e gli eventuali limiti di questa soluzione e ne parlerò in un prossimo post.

Storifying IR12

Visto che non sono a Seattle per partecipare all’annuale conferenza dell’Associazione dei Ricercatori che Studiano Internet ho deciso di sperimentare storify per provare a raccontare, a partire da contenuti trovati in rete, la conferenza.
Since this year I’ll not be able to attend the annual conference of the Association of Internet Researchers I’ll try to collect and curate interesting contents with storify.

Note sulla raccolta tweet in realtime con DiscoverText

Ho provato a fare un piccolo esperimento per capire meglio i limiti del reperimento tweet su temi d’attualità.
Nel corso delle ultime 24 ore ho raccolto 9429 tweet contenenti l’hashtag #tunnelgelmini.
Per la raccolta ho usato DiscoverText che, come quasi tutti i tool attualmente disponibili (vedi la terza delle sei provocazione sui Big Data di danah boyd a Kate Crawford), non garantisce comunque che tutti i tweet della timeline pubblica siano stati effettivamente reperiti. Il limite imposto dalle API di Twitter è di 1500 tweet restituiti e DiscoverText consente di reperire i dati ogni 15 minuti. Quindi tutte le volte che sono generati più di 1500 tweet in un quarto d’ora si perdono quelli eccedenti questa soglia.
Ho iniziato a raccogliere i dati alle 17:52 di ieri 24/09 ed il primo tweet reperito è delle 16:36 del 24/09 (http://twitter.com/#!/paoloduina/status/117608339399127040).
Bisogna dunque essere molto rapidi se si desidera ottenere una collezione completa di tweet su fenomeni come questo. Annoto incidentalmente che tutte le date in DiscoverText sono relative al fuso GMT-7 e non ho trovato il modo di settare il fuso orario dell’utente.
Della collezione di tweet reperiti 4734 (50,2%) sono retweet (RT @) e 365 (3,87) sono risposte ad un utente (@ replay). I 9429 tweet sono stati generati da 4377 account diversi. Sarebbero poco più di due ad account se non fosse che la distribuzione è, come sempre avviene in questi casi, non normale. L’utente più prolifico ha pubblicato 50 tweet. I 10 utenti più prolifici hanno generato 358 tweet pari al 3,79% del totale.