Facebook: da FQL alle Graph API

Nonostante questi primati non `e facile interagire con Facebook da sviluppatore. Come per gli altri social abbiamo dovuto creare un nuovo account e collegare ad esso un’applicazione autorizzata.

Il passo successivo `e stato capire come interagire con questo network, quindi come effettuare le richieste e come interpretare le risposte. Ci siamo trovati di fronte ad una serie di versioni successive di API.

Figura 3: Le versioni delle FB AP I

Nel 2010 `e stata resa pubblica la prima versione (v1.0 ), la cui caratteristica principale (per quanto ci riguarda) era l’uso di FQL, un linguaggio di interrogazione SQL-like sviluppato per interagire con Facebook. FQL permetteva sostanzialmente di effettuare richieste di vario tipo, era sufficiente creare la query ad hoc ed utilizzare

3.4 Social Network: Facebook

apposite funzioni presenti nelle librerie pubbliche per l’esecuzione e la lettura dei risultati. Ad ogni query Facebook rispondeva con un file json contenente i dati richiesti. Dalla versione v2.0 in poi sono cambiate molte cose. Le pi`u importanti al nostro scopo sono che:

• FQL `e stato deprecato: `e ancora supportato nella v2.0, ma viene reso pubblico che non sar`a pi`u disponibile a partire dalla prossima versione. Le applicazioni create entro l’agosto 2014 potranno ancora eseguire query FQL, ma solo fino all’agosto 2016, data a partire dalla quale FQL non sar`a pi`u disponibile per nessuna applicazione.

• da un lato vengono aggiunte nelle Graph API diverse funzionalit`a, dall’altro ne vengono escluse molte altre, tra le quali anche quella che per noi sarebbe necessaria in sostituzione dell’FQL, ovvero la possibilit`a di fare ricerche sui post pubblici.

Quando abbiamo iniziato ad osservare Facebook e a studiare se e come recuperare informazioni (Aprile 2015) era appena stata pubblicata la versione 2.3 delle AP I, quindi l’applicazione creata supporter`a solo l’ultima versione, alla quale nel tempo non sono state aggiunte funzionalit`a a noi utili.

Nella sezione della documentazione di quest’ultima versione delle AP I dedicata ai post viene detto che l’unica richiesta possibile ha la forma:

m.f acebook.com/ID P OST

e permette di recuperare i dati relativi ad un determinato post conoscendone l’id, ma non un elenco di post pubblici.

Sono recuperabili tramite altre chiamate informazioni su un determinato utente (conoscendone il suo id), dettagli nelle amicizie ed altre funzionalit`a, ma niente che riguardi la ricerca su post pubblici.

La raccolta quindi ha avuto problemi non solo interpretativi sui dati, ma anche, e soprattutto, tecnici (vedi 3.4.3 Problematiche riscontrate e soluzioni adottate).

3.4.2 I dati e la raccolta

La raccolta avviene a partire dalle reali pagine di Facebook, lette in versione mobile poich`e in questo modo la pagina risulta pi`u facilmente leggibile in quanto la grafica `

e semplificata.

Caratteristica di Facebook `e quella di permettere la pubblicazione di post di vario tipo (nuovo messaggio, nuova foto, nuovo album, stato d’animo etc) e ognuno

di raccolta. Per questo abbiamo dovuto scegliere di recuperare per ogni post solo le informazioni che ritroviamo in ognuna delle diverse tipologie di pubblicazione. Abbiamo selezionato data, utente, titolo, messaggio, numero di like e commenti.

E’ stata implementata una funzione di parsing della pagina html in grado di recuperare per ogni post tutti e soli i campi selezionati.

Ulteriori informazioni su ogni post (come il dettaglio dei commenti) sono recuperabili accedendo direttamente al post in questione tramite il suo URL:

m.f acebook.com/ID U T EN T E/posts/ID P OST

Non abbiamo per`o ritenuto necessario a questo livello andare a ricercare ulteriori informazioni, tra l’altro non raccolte nel caso dei precedenti social network, anche perch`e tramite gli id dell’utente e del post, recuperati e salvati, questi dati sono eventualmente recuperabili anche in tempi successivi.

I dati letti dalla pagina html vengono salvati un un file csv su Hadoop.

3.4.3 Problematiche riscontrate e soluzioni adottate

L’assenza di supporto `e stata il principale problema da affrontare. Il modo che abbia- mo scelto per recuperare le informazioni `e stato tramite la lettura delle pagine vere di Facebook in formato html: abbiamo studiato la documentazione a disposizione per capire il modo con cui FB crea le URL per la ricerca degli hashtag:

m.f acebook.com/hashtag/T AG DA CERCARE

Una chiamata in questa forma restituisce la pagina Facebook in cui `e attiva la ricerca per hashtag. Per recuperare questi dati abbiamo pensato di salvare questa pagina e successivamente farne un parse per individuare al suo interno i campi di nostro interesse ed andare a creare, come nei casi precedenti, un file csv riassuntivo.

Risulta evidente il diverso grado di difficolt`a nell’interpretare un json o un xml (come accadeva per Twitter, Instagram e per i blog), creato allo scopo di essere facilmente interpretato, rispetto all’analisi di una pagina html di Facebook e al- l’estrapolazione a partire da essa delle informazioni, soprattutto osservando che la struttura interna della pagina html in termini di nomi e id degli elementi costitutivi della pagina stessa non `e costante, ma varia a seconda del tipo di post mostrati.

Per sviluppare la suddetta procedura, che si occupa di effettuare la chiamata e successivamente interpreta la pagina scaricata ci siamo ispirati a codice pubblicato su GitHub con licenza d’uso gratuita: abbiamo riadattato il codice per fare in modo di recuperare tutte le info a noi utili, quindi renderlo adatto al nostro scopo e alle

3.4 Social Network: Facebook

nostre esigenze. Per quanto riguarda la fase di parsing, sono state utilizzate le funzione messe a disposizione da PHP Simple HTML DOM Parser.

Il codice scaricato `e stato fondamentale per impostare la procedura, ma le mo- difiche apportate sono state molte: il codice nasce per recuperare post singoli e foto, nel nostro caso abbiamo invece a che fare con post di vario genere, quindi `e stato necessario riadattare la fase di parsing alle varie tipologie di post possibili.

Dopo vari tentativi abbiamo ricavato una procedura in grado di interpretare i vari elementi della pagina in modo corretto, siamo riusciti a recuperare dalla pagina molti dei dati disponibili.

Tutto questo `e stato necessario perch´e, al momento in cui `e iniziata la fase di raccolta, Facebook forniva agli sviluppatori una serie molto limitata di AP I, all’interno delle quali non si `e trovata nessuna funzione adatta ai nostri scopi.

All’inizio di Luglio 2015 gli sviluppatori di Facebook hanno pubblicato un ag- giornamento delle AP I all’interno del quale sono presenti molte nuove funzionalit`a, potenzialmente utili anche al nostro scopo. Nonostante questo aggiornamento `e stato deciso di non andare a modificare la procedura sopra descritta, che rimane comunque del tutto corretta, soprattutto perch`e il termine della raccolta dati era ormai prossimo (precedentemente fissato alla fine di Luglio).

3.4.4 Dettagli della procedura di raccolta dati

La procedura di raccolta si sviluppa in 2 fasi, corrispondenti a 2 distinte procedu- re: la prima `e quella di raccolta dei file originali, la seconda corrisponde alla fase di elaborazione e parsing. In particolare la prima procedura avvia, tramite la schedula- zione di un Job, uno script php locale: lo script inizia con l’autenticazione dell’utente Facebook e procede andando a richiedere una ricerca per ogni hashtag e salvando in locale le pagine html trovate.

La seconda procedura effettua il parsing, quindi l’analisi sintattica della pagina html appena salvata: vengono recupete le info interessanti, tra cui id dell’utente e del post, e si crea un csv di forma simile a quelli creati nelle altre raccolte. In questo modo non serve tenere traccia della pagina html poich`e tramite i dati salvati nel csv sar`a possibile in qualunque momento successivo recuperare il post per intero.

Procedure successive si occupano di filtrare i post duplicati e portarli in Hadoop.

3.4.5 Correzioni successive

Questa fase `e stata necessaria per capire quali dati costituiscono i fatti da analizzare e quali delle informazioni riguardo i dati danno vita ad analisi realmente interessanti ed utili: siamo alla ricerca dei fatti e delle dimensioni a partire dai quali successiva- mente creeremo i cubi : scopo ultimo `e trovare la forma da assegnare allo star schema.

Il primo passo `e stato selezionare per ogni fonte il sottoinsieme di dati da utilizzare come test set. In particolare:

• per i blog, Twitter e Facebook abbiamo utilizzato il sottoinsieme dei post relativi ai mesi di Aprile e Maggio,

• per Instagram, data la grande mole di informazioni raccolte, ci siamo limitati ai post di Aprile.

Successivamente, tramite procedure realizzate attraverso Kettle, sono stati crea- ti, per ogni fonte, i file csv contenenti i dati del periodo campione in analisi nella forma adatta per essere interpretati da R. In particolare per il calcolo delle Asso- ciation Rules i csv avevano la struttura < post, tag >, mentre per il calcolo delle distribuzioni sono stati aggiunti i campi relativi alle dimensioni in analisi.

Si `e ritenuto pi`u utile ai fini richiesti calcolare sia le regole, sia le distribuzioni singolarmente per ogni fonte dati: il target degli utenti (e di conseguenza anche l’u- so, dove previsti, degli hashtag) `e molto diverso sui diversi social, perci`o, per poter sfruttare al meglio le informazioni ricavate, ognuno di essi deve essere osservato e gestito in modo indipendente, secondo le norme che vigono al suo interno. Abbiamo per questo ritenuto importante fornire al reparto Marketing e Comunicazione infor- mazioni separate.

In questa fase non scenderemo nel dettaglio dell’interpretazione delle informa- zioni: l’obiettivo `e la decisione di quali dati portare nel DWH, a quale livello di dettaglio e in quale forma.

4.1 Blog

4.1

Blog

Nei blog l’uso degli hashtag `e limitatissimo, praticamente assente. Per questo motivo non abbiamo potuto calcolare le regole associative.

L’osservazione dei blog rimane comunque un punto centrale per il reparto Mar- keting e Comunicazione di Fendi, sono stati loro stessi a fornirci un elenco di blog che sono soliti monitorare. Per questo abbiamo tenuto in considerazione le info pro- venienti dai blog nonostante l’impossibilit`a di analizzarli dal punto di vista degli hashtag.

Abbiamo suddiviso i blog in 2 gruppi: fanno parte del Gruppo A i 13 blog sele- zionati in azienda all’inizio del progetto, nel Gruppo B troviamo invece i 9 suggeriti successivamente dai responsabili Fendi.

Abbiamo ritenuto utile tener separati questi 2 insiemi proprio pensando a come i blog sono stati selezionati: il Gruppo A infatti viene da una selezione effettuata da me in azienda secondo criteri di frequenza di pubblicazione, il Gruppo B invece raccoglie alcuni dei blog attualmente monitorati in Fendi, quindi blog specializzati nella moda e rivolti verso il target di clienti cui riferisce anche Fendi.

Ci aspettiamo perci`o che emergano informazioni diverse, per questo abbiamo mantenuto la distinzione.

Per entrambi i gruppi abbiamo potuto effettuare analisi quantitative e temporali.