Retweet parser

Trattandosi fondamentalmente di una simulazione della navigazione dell’utente, ciò che lo scraper restituisce è un documento HTML all’interno della quale sono presenti i retweet. Il modulo è stato appunto sviluppato per poter estrarre i retweet da questi documenti e ricostruirli nel formato JSON secondo la seguente struttura:

• timestamp: indica quando è stato raccolto il retweet; • id: l’id del retweet;

• original-id: l’d del tweet;

• author-id: l’id dell’autore del retweet; • original-author-id: l’id dell’autore del tweet;

• author-screen-name: il nome utente dell’autore del retweet; • original-author-screen-name: il nome utente dell’autore del tweet; • text: il testo contenuto dal tweet.

1 { 2 " id ": " 1 0 1 1 2 7 5 6 4 6 4 2 7 9 7 5 6 8 0 " , 3 " o r i g i n a l - author - id ": " 2 7 5 5 0 7 7 3 2 9 " , 4 " author - id ": " 2 1 6 3 7 8 3 3 7 0 " , 5 " t i m e s t a m p ": 1 5 2 9 9 7 7 9 5 7 , 6 " o r i g i n a l - id ": " 1 0 1 1 1 9 0 8 2 1 9 3 9 4 8 2 6 2 4 " ,

7 " t e x t ": " C o m u n q u e io non mi f i d o di chi d i c e che L o k i ha a v u t o una m o r t e d e g n a del p e r s o n a g g i o " ,

8 " o r i g i n a l - author - screen - n a m e ": " x j o k e r s c a r s " ,

9 " author - screen - n a m e ": " t h i s b r o k e n w i n g s " ,

10 }

Listing 4.2: Esempio di oggetto JSON prodotto dal retweet parser

Una volta trasformato in un oggetto JSON, il retweet viene salvato su un server ElasticSearch.

ElasticSearch

Elasticsearch è un database server, scritto in Java, che si occupa della memorizzazione di grandi quantità di dati in un formato sofisticato, ottimizzato per ricerche basate sul testo.

Alcune caratteristiche fondamentali che costituiscono ElasticSearch sono:

• protocollo HTTP/JSON: comunica utilizzando un linguaggio JSON particolare ab- binato alle REST API, sfruttando il protocollo HTTP per il trasferimento di rete, rendendo di fatto standard l’interfaccia di comunicazione. Utilizza JSON per costrui- re il proprio linguaggio di comunicazione e per memorizzare informazioni in maniera organizzata e facilmente accessibile, garantendo che la collezione di dati sia semplice sia da leggere che da accedere;

• scalabilità e affidabilità: è un sistema di ricerca parallelo, la capacità del database può essere aumentata aggiungendo nodi al cluster. Inoltre gestisce autonomamente il problema dell’affidabilità, migrando dati o promuovendo dati replica a dati primari al momento del malfunzionamento di un qualsiasi nodo;

• analisi del testo: dispone di un sistema automatizzato di analisi del testo. Il database è in grado di analizzare porzioni di testo in qualsiasi formato, indicizzando in modo efficiente termini chiave e garantendo un ottime performance per quanto riguarda il sistema di ricerca;

• query DSL: utilizza un particolare linguaggio basato su JSON per codificare la strut- tura di una ricerca. A differenza del linguaggio SQL, il query DSL è componibile a piacere in modo da garantire la massima libertà di ricerca, anche se ciò lo rende almeno inizialmente complesso da utilizzare.

4.2

API Refresher

I retweet salvati, mancano di informazioni essenziali come la data di creazione del retweet e del tweet oltre alla source di entrambi. Queste informazioni non sono ottenibili tramite scraping, perciò si è ricorso alle Twitter API. Utilizzando un set di credenziali per diverse applicazioni (circa settanta), questo modulo aggiorna i retweet salvati sul server con le informazioni aggiuntive fornite dalle API.

Per ottimizzare le performance il modulo esegue tante istanze quante sono le credenziali che ha a disposizione in parallelo, riuscendo ad aggiornare 900 retweet per istanza e facen- dole poi ripartire di nuovo in parallelo dopo quindici minuti, corrispondenti alla finestra temporale imposta da Twitter.

L’API Refresher aggiunge ad ogni retweet i seguenti dati: • created-at: data e ora della pubblicazione del retweet; • original-created-at: data e ora della pubblicazione del tweet;

• original-author-created-at: data e ora della creazione dell’utente che ha condiviso il tweet;

• source: applicazione dalla quale è stato condiviso il retweet; • original-source: applicazione dalla quale è stato condiviso il tweet.

1 { 2 " id ": " 1 0 1 1 2 7 5 6 4 6 4 2 7 9 7 5 6 8 0 " , 3 " created - at ": " 20 18 - 06 - 25 T17 : 5 1 : 1 7 " , 4 " o r i g i n a l - author - id ": " 2 7 5 5 0 7 7 3 2 9 " , 5 " o r i g i n a l - created - at ": " 20 18 - 06 - 25 T12 : 1 4 : 1 3 " , 6 " author - id ": " 2 1 6 3 7 8 3 3 7 0 " , 7 " o r i g i n a l - s o u r c e ": " T w i t t e r for A n d r o i d " , 8 " author - s t a t u s ": " a c t i v e " , 9 " o r i g i n a l - author - created - at ": " 20 14 - 08 - 29 T23 : 1 0 : 0 1 " , 10 " t i m e s t a m p ": 1 5 2 9 9 7 7 9 5 7 , 11 " s o u r c e ": " T w i t t e r for A n d r o i d " , 12 " o r i g i n a l - id ": " 1 0 1 1 1 9 0 8 2 1 9 3 9 4 8 2 6 2 4 " ,

13 " t e x t ": " C o m u n q u e io non mi f i d o di chi d i c e che L o k i ha a v u t o una m o r t e d e g n a del p e r s o n a g g i o " , 14 " o r i g i n a l - author - screen - n a m e ": " x j o k e r s c a r s " , 15 " irt - day ": 157 , 16 " author - screen - n a m e ": " t h i s b r o k e n w i n g s " , 17 " author - created - at ": " 20 13 - 11 - 01 T21 : 4 2 : 2 3 " , 18 }

Listing 4.3: Esempio di JSON aggiornato dall’API refresher

4.3

Dati

I dati raccolti e presi in analisi per lo studio coprono un arco temporale di due settimane, nello specifico dal 18/06/2018 (lunedì) al 01/07/2018 (domenica).

Figura 4.3: Distribuzione dei retweet nella prima settimana di analisi.

Figura 4.4: Distribuzione dei retweet nella seconda settimana di analisi.

La distribuzione dei retweet risulta regolare e si può osservare che i picchi settimanali cambiano tra le due settimane: nella prima si registrano due picchi di giovedì e venerdì,

nella seconda di mercoledì e giovedì. In totale i retweet raccolti sono stati 9.989.819, distribuiti tra 1.446.250 utenti, risultati che portano a calcolare una media di circa sette retweet per utente.

4.3.1 Prime osservazioni

Una volta raccolti i dati sono stati effettuati i primi studi sulla distribuzione dei retweet.

Osservando la distribuzione dei primi 100 utenti che hanno condiviso più retweet durante l’arco di tempo preso in analisi, si possono notare subito delle anomalie.

Figura 4.5: Distribuzione dei retweet tra i 100 utenti che ne hanno condivisi di più.

I primi 10 account contano più di 5.000 retweet pubblicati, l’account @marino29b ne conta 9.253 con una media giornaliera di circa 661 retweet. Si stima che un utente condivida dai 2 ai 40 retweet giornalieri (Firdaus, Ding e Sadeghian 2018): rilassando la soglia a 60 retweet, otteniamo che gli utenti che superano tale soglia sono 1.090. Volendo invece considerare come altamente sospetti gli utenti che hanno una media giornaliera superiore a 100 se ne ottengono 378.

Utente Retweet marino29b 9.253 marobe997 7.226 petra_romano 6.791 AnnaliRampa 5.570 adrianobusolin 5.514 Monica79811279 5.364 cleoliv24 5.133 razorblack66 5.095 SoniaGrotto 5.037 UnTemaAlGiorno 4.921

Tabella 4.1: Distribuzione dei retweet tra i 10 utenti che ne hanno condivisi di più

Analizzando la sorgente dei retweet, ovvero da quale applicazione essi provengono, si scopre che per la maggior parte sono distribuiti da 5 applicazioni diverse: il 48.65% proviene da “Twitter for Android”, il 32.03% da “Twitter for iPhone”, il 9.92% da “Twitter Web Client”, il 4.36% da “Twitter Lite” e il 3.26% da “Twitter for iPad”. Solo il restante 1.78% dei retweet presenti proviene da sorgente diversa e si distribuisce tra 19.688 applicazioni diverse.

Un controllo manuale delle source meno diffuse permette di identificarne alcune alquan- to sospette, in quanto contenenti il termine “bot”. Un esempio è l’account @advpio78 la cui source dei retweet è “sara bot pausini”: l’account condivide soltanto contenuti presenti sul profilo verificato della cantante italiana Laura Pausini.

4.4

Visualizzazione Retweet-Tweet

La visualizzazione Retweet-Tweet (RTT) è stata creata per osservare l’attività tempo- rale degli utenti tenendo conto della data di condivisione del tweet originale: essa proietta ogni retweet rispetto alla sua data di creazione sull’asse X e rispetto alla data di creazione del tweet originale sull’asse Y .

Figura 4.8: Esempio di visualizzazione RTT per l’account @fab_ricci.

I retweet condivisi dall’account sono proiettati in base alla loro data di creazione sull’asse

Il dominio temporale dei due assi è lo stesso, in modo che la condivisione di tweet più vecchi non influenzi l’interpretazione del grafico: in questo modo si perdono i retweet, ma è possibile creare un nuovo grafico che li includa aumentando i domini. I punti vengono proiettati nella metà inferiore del grafico identificata dalla sua bisettrice, poiché non è possibile che un retweet venga condiviso prima del tweet originale.

4.5

Pattern temporali

Attraverso le visualizzazioni RTT è stato possibile riconoscere diversi pattern tempo- rali generati dagli utenti, che possono essere usati come primo indicatore per riconoscere eventuali comportamenti automatizzati.

Dopo varie analisi, si è arrivati a descrivere le caratteristiche che più comunemente si manifestano nel comportamento di un utente:

• la successione di retweet segue l’andamento della bisettrice del grafico, generando un alto valore di correlazione, perché gli utenti tendono a condividere i tweet più recenti;

• possono presentarsi dei sottogruppi di retweet che sembrano seguire un andamento verticale e mostrano una correlazione inversa con la bisettrice del grafico. La presenza di queste “gocce” è dovuta a situazioni in cui l’utente condivide in modo molto veloce tweet di un feed presentato in ordine cronologico inverso, come ad esempio la pagina di un altro utente o di un trend. I tweet originali che compongono queste gocce tendono ad avere un’età massima di tre giorni;

• i tempi di attività non sono regolari, non riempiono l’arco di una giornata ma si pre- sentano delle sessioni di retweet, ovvero finestre temporali dove l’attività di retweet risulta più densa. Le sessioni di retweet risultano temporalmente non distribuiti in maniera regolare.

Figura 4.9: Visualizzazione RTT per l’account @AntonioSpadafo4.

Dalla visualizzazione si possono effettuare le seguenti osservazioni: la maggior parte dei retweet condivisi dall’utente seguono la bisettrice del grafico, alcuni retweet formano delle “gocce” (cerchiate di rosso) e non si registra una regolarità nei periodo di attività.

Queste caratteristiche non vengono però seguite da tutti gli utenti: esistono casi in cui sono stati identificati comportamenti che si discostano da quelli comuni e che seguono invece dei pattern.

Figura 4.10: Dettaglio della visualizzazione RTT per l’account @AntonioSpadafo4.

Il dettaglio mostra come le varie gocce generate dall’utente abbiano comunque un distribuzione temporale non uniforme.