Fashion Analysis: analisi di dati pubblici provenienti dal web

(1)

Dipartimento di Informatica

Laurea Magistrale in Informatica per l’Economia e per l’Azienda

(Business Informatics)

Fashion Web Analysis: Analisi di BI dei dati pubblici

reperiti dal web (blog e Social Network) riferiti al

marchio Fendi orientata ai Big Data.

Autore: Relatore:

Laura Margara Dino Pedreschi

Tutore aziendale: Controrelatore:

Serena Arrighi Giorgio Ghelli

(2)

Indice

1 Introduzione 1

1.1 Fasi del progetto . . . 3

1.2 Tirocinio in BNova . . . 5

2 Tools 6 2.1 I Big Data . . . 6

2.2 Pentaho . . . 7

2.3 Apache Hadoop e Hortonworks . . . 8

2.4 R Data Mining . . . 10

2.5 DWH: HP Vertica . . . 11

3 Fase 1: Raccolta dati 12 3.1 Blog e giornali web . . . 13

3.1.1 I dati e la raccolta . . . 13

3.1.2 Problematiche riscontrate e soluzioni adottate . . . 14

3.1.3 Dettagli della procedura di raccolta dati . . . 16

3.1.4 Altri blog . . . 18

3.2 Social Network: Twitter . . . 19

3.2.1 Twitter AP I . . . 19

3.2.5 Correzioni successive . . . 22

3.2.6 Contenuto del json e csv di Twitter . . . 24

3.3 Social Network: Instagram . . . 25

3.3.1 Instagram AP I . . . 25

3.3.6 Contenuto del json e del csv di Instagram . . . 31

3.4 Social Network: Facebook . . . 32

(3)

4 Fase 2: Data Mining 36 4.1 Blog . . . 37

4.1.1 Blog: Gruppo A . . . 37

4.1.2 Blog: Gruppo B . . . 40

4.2 Twitter . . . 43

4.2.1 Association Rules . . . 43

4.2.2 Distribuzioni Gruppo 1: Fendi . . . 46

4.2.3 Distribuzioni Gruppo 0: nonFendi . . . 47

4.3 Instagram . . . 49

4.4 Facebook . . . 54

5 Fase 3: DWH 57 5.1 Struttura dei dati e del DWH . . . 57

5.1.1 Fasi di progettazione . . . 58

5.2 Riempimento del DWH . . . 63

6 Fase 4: Cubi e report 66 6.1 Creazione dei cubi . . . 66

6.2 Visualizzazione dei cubi . . . 69

7 Fase 5: Suggerimenti interpretativi dei dati 70 7.1 I blog . . . 70

7.1.1 Altro gruppo di blog . . . 74

7.2 Twitter . . . 76

7.3 Instagram . . . 80

7.4 Facebook . . . 85

8 Commento di Fendi al lavoro 87 9 Conclusioni e sviluppi futuri 88 10 Appendice 90 10.1 Appendice A: Gli hashtag . . . 90

(4)

1 Introduzione

Alla base di questa tesi c’è un progetto interno di BNova che si propone di eseguire per il marchio Fendi, importante casa di moda e pelletteria italiana, analisi dei dati pubblici presenti nel web e legati al marchio. Scopo ultimo è offrire all’azienda un sistema di supporto decisionale che possa essere utile al reparto Marketing, Pubblicità e Comunicazione per ottimizzare le loro attività sul web.

Fendi è già da tempo cliente di BNova, in quanto tale è stata coinvolta nel progetto da subito, sia nella fase iniziale di selezione delle fonti, sia durante lo svolgimento del progetto. In entrambe le situazioni abbiamo ricevuto riscon-tri positivi: il marchio non stava ponendo eccessiva attenzione al mondo del web, ma soltanto perchè scelte di marketing avevano portato a concentrare la loro attenzione su altri mezzi di comunicazione. In effetti senza gli strumenti adeguati è difficile comprendere le potenzialità di analisi in questo senso.

Di fronte alla proposta di un lavoro di approfondimento nel web si sono di-mostrati molto interessati, soprattutto quando durante lo svolgimento hanno cominciato ad emergere i primi risultati utili.

Alla base del supporto decisionale, obiettivo di questo lavoro, ci dovranno essere indicazioni e consigli di comportamento per la compilazione e la pubbli-cazione di post nel web in modo da ottimizzare la diffusione dell’informazione. Oltre a ciò saranno interessanti per l’azienda indicazioni per la creazione di campagne pubblicitarie ad hoc, eventualmente personalizzate, in modo da coinvolgere non tanto il maggior numero di utenti del web, quanto concen-trandosi sugli influencer : con questo termine si indica una persona capace di influenzare i pensieri e le decisioni degli altri grazie a ciò che dice e scrive. I commenti, gli articoli e le opinioni espresse da un influencer vengono tenute in alta considerazione da chi si interessa dell’argomento e, tra tutte, sono ritenute tra le più autorevoli. Se l’obiettivo finale è ottimizzare la diffusione delle in-formazioni risulta evidente quanto possa essere importante per Fendi scoprire quali sono gli influencer che si occupano del mondo della moda.

In questo progetto abbiamo concentrato l’attenzione sullo studio di blog (selezionati anche con il supporto del marchio) e Social Network, in particolare

(5)

versi dati raccolti a partire dai post, sono emerse informazioni importanti con un valore aggiunto molto alto, soprattutto se pensiamo che quello proposto `e solo un primo approccio e pu`o essere approfondito da moltissimi punti di vista.

Ad esempio dall’analisi dei blog emergono considerazioni molto utili per l’azienda dal punto di vista temporale: siamo riusciti, ad esempio, ad indivi-duare i giorni e gli orari in cui `e pi`u probabile riuscire a catturare l’attenzione del blogger.

Per quanto riguarda Twitter e Instagram l’informazione più rilevante che abbiamo trovato riguarda l’uso degli hashtag: è sorprendentemente emerso infatti che alcuni di essi, decisamente non sospetti, rischiano di andare a di-sperdersi in dataset non coerenti al marchio se utilizzati senza il supporto di altri hashtag più contestualizzanti.

Dai dati di Facebook `e invece emerso, anche in questo caso sorprendendoci, che gli hashtag hanno un peso molto limitato. In compenso abbiamo compreso quali dinamiche potrebbe essere interessante approfondire e quali invece nel nostro caso rischiano di non portare informazioni utili.

In generale per ogni fonte, oltre ad informazioni a valore aggiunto gi`a ben sfruttabili, sono emersi molti spunti di riflessione e molti punti di vista per successive analisi di approfondimento.

Oltre all’ambizioso obiettivo analitico sopra descritto, il progetto ha anche e soprattutto un importante obiettivo formativo: l’intento di BNova `e formare il tirocinante perch`e possa imparare a muoversi agevolmente all’interno di un progetto di Business Intelligence e, quindi, raggiungere alla fine del lavoro una buona conoscenza dei meccanismi alla base di ogni fase di questo genere di progetti.

Per questo motivo l’intero tirocinio è stato trattato come un reale progetto di BI, anzi, è stato impostato addirittura nell’ottica di un futuro approccio verso i Big Data. In questo senso tutti i tools utilizzati sono stati selezionati non tanto osservando la mole effettiva di dati da trattare, quanto pensando alla finalità formativa da raggiungere, per questo sono stati scelti come se il progetto fosse realmente di Big Data.

(6)

1.1 Fasi del progetto

Se scopo finale del progetto era la ricerca di info interessanti e utili, mio sco-po personale `e stato cercare di sfruttare al meglio questa opportunit`a e fare esperienza di un progetto completo.

In accordo con il mio responsabile aziendale, ho deciso di occuparmi del progetto in tutte le sue fasi, dall’analisi iniziale, alla raccolta, alla struttura-zione dei dati e alla loro interpretastruttura-zione.

In particolare il progetto si `e svolto in conformit`a con la struttura standard dei progetti di Business Intelligence.

Indivuduiamo le 4 fasi principali:

• Fase 1 - Data sources e Data Movement : si tratta della fase ini-ziale di osservazione del contesto. Sono stati monitorati i dati provenienti da diverse fonti per alcuni giorni con lo scopo di prendere confidenza con il mondo che andremo ad analizzare per scoprire quali fonti sono real-mente interessanti.

(7)

Nel nostro caso abbiamo scelto di osservare blog e social network. In questa fase abbiamo anche messo a punto attraverso l’ETL di Pentaho le procedure di recovery dei dati.

• Fase 2 - Data Mining : abbiamo deciso di anticipare in parte la fase di mining. Una prima analisi sulla forma e sulla distribuzione dei dati `e stata necessaria per fare data sensing, ovvero per comprendere non sol-tanto i dati nella loro forma, ma anche il loro significato all’interno del contesto generale. Il mining `e stato utile per capire quali informazioni riguardo i dati raccolti sono effettivamente rilevanti, quindi quali possia-mo ritenere interessanti al punto di decidere di portarle nel DWH. Abbiamo utilizzato R, un linguaggio di programmazione nato per l’analisi statistica.

• Fase 3 - Data warehouse: in questa fase si è decisa la forma da dare ai dati all’interno del DWH. Oltre a fissarne la struttura, sono state messe a punto le procedure necessarie per archiviare i dati raccolti: ogni post raccolto nella prima fase è stato elaborato in modo da assumere la forma scelta, quella che è stata calcolata come la più adatta alle analisi successive sulla base dei risultati ottenuti dal mining.

In conformit`a con gli strumenti utilizzati in azienda `e stato scelto come base del DWH HP Vertica.

• Fase 4 - Mining e Reportistica: in questa fase sono stati creati i cubi sul DWH. Si tratta della definizione degli schemi attraverso i quali i dati presenti nel DWH vengono interpretati dalle applicazioni front-end per la reportistica.

Attraverso questi schemi abbiamo potuto assegnare ai dati un’ulteriore strutturazione che possiamo definire virtuale, in quanto non influisce sulla loro forma fisica, ma sul modo con cui vengono letti ed interpretati. Elementi centrali di questa fase sono sia la creazione dei cubi e dei report, sia (e soprattutto) l’interpretazione dei dati raccolti.

Per la creazione degli schemi `e stato usato Pentaho Schema Workbench, un’interfaccia di design che consente di creare e testare cubi OLAP. Per la pubblicazione dei cubi abbiamo utilizzato l’Analyzer di Pentaho.

(8)

1.2 Tirocinio in BNova

Il tirocinio ha avuto una durata di 6 mesi, per un totale di 900 ore (da Marzo ad Agosto 2015) ed `e stato svolto presso BNova, un’azienda che da anni si occupa di Business Intelligence.

La missione di BNova `e quella di essere un partner a supporto dei clienti sulle scelte strategiche e sullo sviluppo di soluzioni di Business Intelligence.

BNova basa le proprie attivit`a principalmente su prodotti Open Source, scegliendo soluzioni che siano diventate nel tempo standard de facto e che abbiano una comunit`a di sviluppatori/utilizzatori numerosa e molto attiva.

I principali vantaggi nell’utilizzo dei prodotti Open Source riguardano non solo i bassi costi e la libera distribuzione e replicabilità, ma anche le maggiori possibilità di personalizzazione, interoperabilità e semplicità di integrazione.

Questa idea costituisce non solo la principale norma di comportamento aziendale, ma è anche la base del progetto di tesi: l’intenzione è quella di pre-parare il tirocinante, futuro Data Scientist, ad affrontare progetti di Business Intelligence e di Data Mining complessi attraverso l’uso di prodotti Open Sour-ce. Durante il tirocinio si è cercato di utilizzare tutti prodotti open e adatti a gestire questo genere di progetti con moli di dati molto alte, proprio per offrire al tirocinante un’esperienza quanto più possibile concreta e completa.

I tools proposti da BNova, e presentati nel dettaglio nel prossimo capito-lo, mi hanno permesso di mettere in pratica e di approfondire le conoscenze teoriche acquisite in ambito universitario, a partire dall’analisi iniziale dei re-quisiti e delle fonti, attraverso una fase pi`u tecnica riguardante la raccolta e strutturazione delle informazioni, fino alla fase pi`u scientifica e analitica di interpretazione dei risultati, obiettivo finale e compito del Data Scientist.

(9)

L’utilizzo di numerosi tools nelle varie fasi `e stata una specifica scelta didattica. La selezione di quali tools usare per ogni fase `e stata fatta nell’ottica di mo-strare al tirocinante ambienti e strumenti di sviluppo performanti e realmente utilizzati in progetti di BI, anche in presenza di Big Data.

2.1 I Big Data

Big data `e il termine usato per descrivere una raccolta di dati cos`ı estesa in termini di volumi da richiedere, per poter garantire buone prestazioni in termini di velocit`a elaborativa, tecnologie e metodi analitici specifici.

Il progressivo aumento della dimensione dei dataset, a causa anche della crescente quantità e varietà delle fonti, è legato alla necessità di analisi dei dati su un unico insieme con l’obiettivo di estrarre informazioni aggiuntive rispetto a quelle che si potrebbero ottenere analizzando piccole serie separatamente.

Per questo motivo all’inizio di un lavoro `e necessario conoscere da subito la mole di dati che dovranno essere analizzati: se ci si dovesse trovare di fronte a Big Data `e necessario impostare il progetto su strumenti particolari in grado di gestirli.

Nel nostro caso le raccolte riguardano il mondo del web, blog e social net-work, tipico caso di Big Data. Ma in questo progetto i dati utilizzati sono tutti e soli quelli raccolti nel periodo di tirocinio ed è stato chiaro da subito che la mole non avrebbe superato la quantità gestibile con un DWH e strumenti stan-dard di BI, ma, in un’ottica formativa, si è scelto comunque di pensare alle informazioni da elaborare come a Big Data.

In questo senso all’interno del progetto sono stati utilizzati strumenti e tec-nologie ad hoc per la gestione dei Big Data (Hadoop, R, HP Vertica).

Nella fase iniziale `e stato utilizzato un FeedReader (Vienna) per osservare le attivit`a di una serie di blog precedentemente selezionati.

Una volta scelti i blog di interesse, la fase di interfacciamento con essi `e stata implementata tramite l’ETL di Pentaho.

(10)

2.2 Pentaho

Pentaho Business Analytics `e una suite Open Source. Si tratta di un pro-dotto di Business Intelligence (BI ) che offre data integration, servizi OLAP, reporting, dashboarding e funzionalit`a di ETL (Extract, Transform, Load ).

La suite è distribuita in diverse versioni (Community ed Enterprise) ognuna delle quali offre supporto e funzionalità diverse. La versione utilizzata nel progetto è l’Enterprise 5.3 .

BNova `e partner italiano ufficiale della suite Pentaho dal 2009. Nel 2014, per la terza volta consecutiva, `e vincitrice del premio Pentaho Partner EMEA of the year.

Ad oggi BNova `e l’unica azienda in Italia autorizzata da Pentaho a fare formazione certificata per la suite.

I diversi moduli sono stati utilizzati in varie fasi del progetto:

• nella prima fase di data recovery e di storicizzazione in Hadoop dei dati, le procedure sono state implementate attraverso Kettle, l’ETL di Pentaho,

• Kettle `e stato utilizzato anche per implementare job che sono stati utili in fase di mining per creare file csv nella forma adatta per essere analizzati da R,

• l’ETL `e servita nuovamente per implementare e avviare le procedure di caricamento dei dati nel DWH

• infine l’Analyzer della suite `e servito, dopo la creazione dei cubi, per la visualizzazione del loro contenuto e per la reportistica.

(11)

2.3 Apache Hadoop e Hortonworks

Hadoop `e un sistema di calcolo MapReduce distribuito in grado di maneggiare terabyte o petabyte di dati (adatto quindi alla gestione di Big Data).

Un sistema Hadoop `e formato da diversi componenti che implementano rispettivamente un filesystem distribuito ed il sistema di calcolo MapReduce.

Il filesystem distribuito, chiamato HDFS, non `e conforme alle specifiche POSIX perch´e consente di creare, cancellare, spostare file, ma non di mo-dificarli. Questo compromesso ha consentito di ottenere prestazioni molto superiori rispetto all’uso di un normale filesystem distribuito.

Il modello di calcolo MapReduce deve il suo nome alle due funzioni centrali, entrambe specificabili dal programmatore, quella di map e quella di reduce: in una elaborazione di questo tipo i dati iniziali sono una serie di record che ven-gono trattati singolarmente dai processi Mapper e successivamente aggregati dai processi Reducer.

In HDFS i file sono suddivisi in blocchi distribuiti tra pi`u nodi del cluster, anche replicati per garantire maggiore sicurezza. All’atto del calcolo MapRe-duce Hadoop cerca di fare eseguire a ciascun nodo i calcoli sui blocchi che ha sul proprio disco: in questo modo si ottiene una data locality altissima ed un traffico di rete molto basso.

L’impostazione originale del progetto era di utilizzare entrambe le compo-nenti di Hadoop, ma ci siamo presto resi conto che la mole di dati non avrebbe raggiunto nel periodo di tirocinio livelli tali da giustificare l’uso della MapRe-duce. Ci siamo quindi limitati all’uso della componente HDFS come datalake.

Hadoop `e disponibile in diverse distribuzioni, tra cui Hortonworks (HDP, Hortonworks Data Platform).

(12)

2.3 Apache Hadoop e Hortonworks

Strutturato, sviluppato e costruito completamente in modalit`a open, Hor-tonworks fornisce una piattaforma di livello enterprise che consente alle aziende di adottare con poco sforzo una moderna architettura Hadoop.

Hortonworks fornisce una piattaforma multi-workload data processing, in-cludendo funzionalit`a per la gestione, integrazione e sicurezza del sistema stesso.

Alcune caratteristiche di Hortonworks sono le seguenti:

• `e completamente Open Source: HDP `e una distribuzione Hadoop intera-mente open: tutte le soluzioni sono sviluppate come progetti dalla Apa-che Software Foundation (ASF) e nessuna di essere diventa un’estensione proprietaria.

• è scalabile: HDP è un sistema nativamente scalabile, con molteplici fun-zionalità per accedere ai dati: batch, interattive, real time, funzionalità di searching.

• `e integrabile: HDP si integra bene con le applicazioni e i sistemi esistenti, ci`o permette di usufruire di Hadoop da molteplici piattaforme soltanto con un minimo cambiamento nell’architettura dei dati.

Nel progetto `e stata utilizzata HDP Sandbox v2.4 : si tratta di un ambiente HDP che contiene i componenti centrali di Hadoop, HDFS e MapReduce, ma anche tutti i tools necessari per la raccolta e il processing dei dati.

(13)

2.4 R Data Mining

R è un linguaggio di programmazione destinato alle analisi statistiche. Nasce nel 1993 nell’Università di Auckland per aiutare i ricercatori a lavorare con le grandi quantità di dati già allora prodotte dagli elaboratori. Negli anni l’uso di R si è espando a macchia d’olio grazie alle ottime prestazioni che offre anche di fronte a quantità di dati enormi (si pensi che, ad esempio, viene utilizzato al CERN di Ginevra).

L’interprete ufficiale `e a riga di comando, ma esistono anche diverse inter-facce grafiche che rendono pi`u semplici ed intuitive le funzioni di base.

R offre una serie di funzioni di base estendibili tramite packages, ad esempio nel nostro progetto per il calcolo delle regole associative sono stati utilizzati i pacchetti arules e arulesViz, rispettivamente per l’applicazione degli algoritmi e per la visualizzazione delle regole. Il package di visualizzazione offre una serie di modi diversi di visualizzare le regole calcolate, da Scatter Plot, a Matrici di vario genere, Grafi, Parallel coordinate, e molti altri.

Nel nostro progetto abbiamo ritenuto utile mostrare alcune regole tramite Grouped matrix.

Oltre ad effettuare calcoli con prestazioni ottime, R `e in grado di realizzare grafici di vario genere, ad esempio grafici a barre, grafici a dispersione, pie e molti altri.

In fase di mining `e stato molto utile utilizzare queste funzionalit`a ed osser-vare le informazioni in forma visuale.

(14)

2.5 DWH: HP Vertica

Vertica `e un DB colonnare. Si tratta di una piattaforma analitica verticale (orientata su colonne), cluster-based, creata per operare su dati numerosi e in continua crescita. E’ stato scelto questo DB per le ottime prestazioni che `e in grado di offrire.

(a) HP Vertica (b) DBeaver

Osserviamo alcune caratteristiche di Vertica: lo storage dei dati orientato a colonna porta un importante aumento delle prestazioni in caso di accesso a record sequenziali a scapito di operazioni transazionali comuni, come il recu-pero di un singolo record, aggiornamenti ed eliminazioni. In effetti le query tipiche eseguite su un DWH solitamente sono basate su raggruppamenti.

Nonostante queste importanti caratteristiche `e facile interfacciarsi al siste-ma poich`e Vertica supporta l’SQL standard.

Il prodotto si propone di migliorare drasticamente le prestazioni delle que-ry rispetto agli RDBMS tradizionali e di fornire alta disponibilità e scalabilità anche su grandi quantità di dati.

Per interrogare il DWH abbiamo utilizzato DBeaver, un tool Open Source universale per la gestione di database pensato per sviluppatori ed amministra-tori. E’ uno strumento multipiattaforma e supporta decine di DB sia relazionali sia NoSql.

(15)

Scopo del progetto `e la raccolta e l’analisi dei dati pubblici riguardandi il marchio, in particolare l’analisi d’uso degli hashtag composti dalle parole chiave del marchio.

L’obiettivo finale non `e soltanto un’analisi quantitativa, il quanto se ne parla, ma anche qualitativa, quindi i contesti in cui il marchio appare nei Social Media. Il tutto `e finalizzato alla ricerca delle regole di diffusione delle informazioni, degli influencer e di regole di comportamento legate a specifici eventi, quindi alla creazione di uno strumento di supporto decisionale per il reparto Marketing e Comunicazione dell’azienda stessa.

In questo senso il primo passo `e stato cercare di capire, nel nostro caso, quali sono le migliori fonti di dati: per quel che riguarda il web abbiamo deciso di osservare blog di moda, giornali web e social network.

La fase di raccolta dati `e stata svolta principalmente nei mesi di Marzo e Aprile. In questo periodo si sono studiate le caratteristiche dei Social selezio-nati, delle AP I da essi fornite o comunque le possibili modalit`a di interazione con essi e sono state messe a punto le diverse procedure di recovery, ad hoc per ciascuna fonte dati.

Mi sono occupata di un social alla volta, e ho scelto l’ordine sulla base della documentazione esistente riguardo le modalit`a di interazione successivamente descritte.

Fonte Inizio raccolta

Blog 24/03/2015 Twitter 08/04/2015 Instagram 14/04/2015 Altri blog 22/04/2015 Facebook 27/04/2015

Considerando che tipicamente le analisi andranno a riguardare i vari Social separatamente, non si `e ritenuto necessario fissare una data di inizio della rac-colta che fosse la stessa per tutti. E’ stato deciso, invece, di fissare una data di fine raccolta comune per tutti i Social Media: si `e scelto di concludere questa fase con la fine di Luglio.

(16)

3.1 Blog e giornali web

Nei primi giorni del tirocinio `e stata fatta una selezione di blog di moda e giornali web.

Abbiamo inizialmente effettuato una ricerca del marchio Fendi da motore di ricerca: a partire dai risultati ottenuti abbiamo selezionato circa 30 tra blog e giornali web che hanno pubblicato articoli sul marchio nel recente passato (abbiamo ricercato articoli successivi al 01/01/2015).

Successivamente abbiamo utilizzato un FeedReader (Vienna) per monito-rare l’attività dei blog e abbiamo applicato un filtro sulla parola Fendi per osservare sia l’attività in generale, sia quella a riguardo del marchio per 15-20 giorni. Alla fine abbiamo selezionato le 13 fonti, tra blog e giornali, con atti-vità maggiore. In particolare osserviamo:

FashionBlog Vogue Italia

Blog di Moda Gossip News

Contatto News The blonde salad

Il sole 24 ore (sezione moda) Grazia

Purseblog CMM: Cosamimetto

al Femminile Rock’n’Mode

Oh my bag!

3.1.1 I dati e la raccolta

I blog e giornali web osservati si avvalgono dell’uso di F eedRSS: si tratta di feed creati automaticamente che contengono i dati dei post in prima pagina. I feed sono recuperabili in formato xml tramite apposite chiamate sui relativi siti e contengono i dati attualmente visibili in homepage.

Le url utilizzate per recuperare i feed sono tipicamente diverse per ogni blog, ma l’xml ottenuto ha formato molto simile, a meno eventualmente di alcuni campi: ad esempio i blog rispetto ai giornali web hanno in pi`u un campo relativo al numero di commenti, oppure abbiamo notato che in alcuni casi i post o gli articoli sono catalogati per categoria, mentre in altri no.

La raccolta dei dati avviene tramite una procedura (Job) creata con l’ETL di Pentaho che richiama a sua volta una sottoprocedura personalizzata per

(17)

ogni blog o giornale in grado di richiedere, salvare ed elaborare i vari feed.

3.1.2 Problematiche riscontrate e soluzioni adottate

Il primo problema riscontrato `e stato la scelta della data di partenza: se ini-zialmente l’idea era di analizzare dati a partire dal 01/01/2015, la scelta finale `

e stata dettata dal modo di interazione con i blog e i giornali selezionati. I dati presenti in homepage sono facilemente recuperabili tramite richiesta del feed (in formato xml), gli archivi invece sono comunque accessibili, ma i dati recuperati si trovano all’interno di pagine html. La loro elaborazione per-ci`o comporta un grande incremento di lavoro e di conseguenza un significativo aumento del tempo dedicato alla raccolta dei dati, poich`e ogni pagina di ogni sito ha indirizzo dinamico e struttura diversa, quindi per recuperarli sarebbe necessario creare per ogni sito apposite procedure che vadano dinamicamente a creare l’url, raggiungere la pagina ed elaborarla in modo personalizzato.

Si tratterebbe di una lavoro interessante, ma vista la complessit`a di questa elaborazione abbiamo deciso per adesso di tralasciare i dati storici presenti negli archivi e tenere come data di inizio quella in cui si d`a il via la procedura di raccolta.

Osservando poi l’attività dei 13 blog e giornali selezionati ci siamo accorti che la quantità di post pubblicati può essere molto variabile, da 1-2 post al giorno per alcuni blog, fino a 60-70 giornalieri come capita per i giornali web: nel primo caso potrebbe bastare la richiesta del feed anche una sola volta al giorno (tipicamente in home page si visualizzano dai 10 ai 20 articoli), mentre nel secondo caso la rotazione degli articoli è tale per cui c’è bisogno di recupe-rare il feed con una frequenza maggiore.

Ogni quanto dobbiamo raccogliere i dati per essere sicuri di non avere perdita di informazioni?

Per ognuno dei 13 blog e giornali abbiamo monitorato i post pubblicati e gli orari di pubblicazione per alcuni giorni, dal 20 Marzo all’8 Aprile. Dei 20 giorni monitorati ne abbiamo selezionati 8 per ogni blog, quelli con attivit`a maggiore, in modo da avere una stima per eccesso delle pubblicazioni giornaliere.

Per avere un quadro di insieme abbiamo riunito le funzioni dei singoli blog in un unico grafico e osservandolo abbiamo potuto individuare 2 diversi tipi di comportamenti a seconda della frequenza di pubblicazione:

(18)

Figura 1: Attivit`a dei Blog

Per meglio pianificare la raccolta abbiamo deciso di suddividere i blog nei 2 gruppi sopra individuati: Gruppo A (Arancio) contenente i 10 blog con minore attivit`a, e Gruppo B (Blu) contenente i 3 con maggiore attivit`a.

In particolare i gruppi individuati sono cos`ı composti:

Gruppo A Gruppo B

fashionblog vogue

blogdimoda gossipnews

contattonews grazia

ilsole24ore (sezione moda) purseblog alfemminile ohmybag theblondesalad rock’n’mode cosamimetto

Abbiamo personalizzato la procedura di recupero del feed per i due gruppi e, successivamente, abbiamo utilizzato uno schedulatore per pianificare l’avvio ripetuto delle procedure. Valutando il numero medio di pubblicazioni abbiamo scelto di avviare la procedura 6 volte al giorno per i blog del Gruppo A e 12 volte al giorno per i blog del Gruppo B.

(19)

in cui le pubblicazioni sono mediamente pi`u frequenti in modo da scegliere gli orari di avvio delle procedure per minimizzare il rischio di perdita di infor-mazioni, rendendo quindi la raccolta efficiente ed utile, in particolare gli orari selezionati per il primo gruppo sono: 07:00, 09:00, 10:30, 14:00, 17:00, 21:00.

Gli orari dei secondo gruppo sono invece: 05:30, 06:00, 06:30, 07:30, 08:00, 9:00, 11:00, 13:00, 15:00, 16:00, 18:00, 20:00.

Tutto questo porta però alla raccolta di molti dati ridondanti: in senso quantitativo, l’attività sui blog, se pur frequente, risulta comunque limitata, quindi gestibile anche in caso di molte ridondanze. Non spaventa quindi avvia-re la raccolta come sopra descritto, anche perchè, se pur con cadenza minore, sono previste procedure di ripulitura ed eliminazione delle ridondanze.

Altro aspetto da considerare è che ogni post può essere commentato da-gli utenti registrati in qualunque momento successivo alla pubblicazione, an-che a distanza di giorni o mesi: questo non comporta nessun cambiamen-to sulla visibilità del post poichè essi rimangono ordinati solo sulla data di pubblicazione.

Il recupero dei dati effettuato come sopra descritto perci`o, se da un lato ci da una sicurezza vicina al 100% di recuperare tutti i post che in un qualche mo-mento, successivo alla data iniziale scelta, sono visibili in homepage, dall’altro comporta una potenziale perdita di informazioni relative agli eventuali suc-cessivi commenti sui post una volta che essi hanno abbandonato l’homepage. Queste informazioni sarebbero recuperabili solo osservando gli archivi, quindi per adesso tralasciamo l’analisi dei commenti e ci concentriamo su quella dei post.

3.1.3 Dettagli della procedura di raccolta dati

Per prima cosa abbiamo creato tramite l’ETL di Pentaho le procedure di rac-colta personalizzate per ognuno dei 2 gruppi: ad ogni avvio corrisponde la raccolta dei feed originali di ogni blog in formato xml e la creazione, per ognuno di essi, di un file csv riassuntivo contenente solo le informazioni consi-derate rilevanti in questa fase. In particolare nel csv troviamo: il link diretto al post, il titolo, il testo, la data di pubblicazione (timestamp) e, nei casi in

(20)

cui erano presenti, anche la categoria e il numeri di commenti.

La scelta di salvare i dati sia nel formato xml originale, sia in un csv riassuntivo è dovuta al fatto che il csv è più maneggevole e leggero, ma non contiene tutte le informazioni relative ai post. E’ possibile, infatti, che nella prossima fase di analisi emerga la necessità di osservare informazioni sui dati non riportate nei csv perchè inizialmente considerate non utili: in questo caso sarà sufficiente recuperare dagli xml originali ciò di cui abbiamo bisogno.

Abbiamo inoltre creato un’altra procedura che si avvia una volta al giorno e che, per ogni blog, crea un unico csv unendo tra loro i dati raccolti nelle 24 ore precedenti eliminando le ridonzanze: per ogni post si tiene copia solo del-l’istanza più recente in modo da tenere traccia, là dove presenti, dei commenti pubblicati finchè il post è visibile in homepage. Questa procedura ha anche il compito di caricare i dati su Hadoop: in particolare vengono caricati tutti gli xml originali corrispondenti ai feed e i csv riassuntivi. Ultima operazione è la cancellazione di tutti i file salvati in locale, sia xml, sia csv.

Fase successiva è stata quella di scheduling dell’avvio delle procedure: il Job relativo ai blog del Gruppo A viene avviato 6 volte al giorni, quello relativo ai blog del Gruppo B 12 volte. In entrambi i casi non si tratta di intervalli rego-lari, ma di istanti appositamente selezionati: gli orari di avvio delle procedure sono stati scelti osservando il grafico in Fig.1, facendo in modo di garantire una raccolta efficiente ed efficace: efficiente nel senso che si è cercato di non esage-rare per evitare inutili ed eccessive ridondanze, efficace nel senso che abbiamo previsto una raccolta comunque superiore rispetto alle necessità osservate nel grafico, per poterci assicurare di recuperare sempre tutto il pubblicato, anche in caso di attività del blog superiore alla norma.

(21)

3.1.4 Altri blog

In occasione di una riunione con Fendi i responsabili del marketing ci hanno fornito un elenco di blog di loro interesse da monitorare.

La lista originale proposta comprendeva circa 25 elementi, alcuni gi`a presi in analisi. Tra quelli non ancora monitorati ne abbiamo selezionati 9.

Il criterio di scelta è lo stesso applicato precedentemente: inizialmente ab-biamo escluso i blog già processati, poi abbiamo monitorato tutti gli altri per qualche giorno e abbiamo osservato la frequenza di pubblicazione di post sia in generale, sia riguardo il marchio, scegliendo infine i blog più attivi.

Sono stati selezionati i seguenti blog:

• AdR Factory (www.annadellorusso.com)

• BragMyBag (www.bragmybag.com)

• CocoPerez (perezhilton.com/cocoperez/)

• The Wall (www.elin-kling.com/the-wall/)

• Garance Dor´e (versione inglese su www.garancedore.fr/en/)

• Man Repeller (www.manrepeller.com)

• The Sartorialist (www.thesartorialist.com)

• StyleList (www.stylelist.com)

• The Couveteur (www.thecoveteur.com)

La raccolta dei dati riguardanti questi blog avviene, come per i precedenti 13, tramite la raccolta periodica di feed e la loro storicizzazione.

Anche in questo caso abbiamo effettuato un’analisi della frequenza giorna-liera di pubblicazione e abbiamo deciso di avviare la procedura di raccolta dei feed 7 volte al giorno (a partire dalle 5 del mattino ogni 3 ore)

(22)

3.2 Social Network: Twitter

Twitter `e un social network che permette agli utenti registrati di crearsi un microblog personale, composto dalle pubblicazioni dell’utente stesso.

Hanno accesso a Twitter in lettura anche gli utenti non registrati, mentre quelli registrati possono commentare i post e interagire con gli altri utenti.

Su Twitter un utente registrato pubblica tweet di testo, eventualmente allegando una foto.

Twitter `e stato il primo social a proporre (e imporre) l’uso degli hashtag: si tratta di collegamenti ipertestuali che permettono agli utenti di fare ricer-che o seguire un determinato argomento partecipando alle discussioni ricer-che lo riguardano. Si trovano nella forma #etichetta (dall’inglese hash: cancelletto e tag: etichetta).

La popolarità degli hashtag è legata alla loro introduzione su Twitter, non sorprende perciò che la quasi totalità dei post pubblicati contenga almeno un hashtag.

3.2.1 Twitter AP I

Twitter mette a disposizione degli sviluppatori una serie di AP I, chiamate ad apposite funzioni in grado di richiedere dati di diverso tipo e natura, e ricevere in risposta un file nel formato json contenente le informazioni richieste, ad esempio relative ai post pubblicati da un determinato utente, quelli in cui compare un determinato hashtag, ricerche per area geografica, e molto altro.

Le API di Twitter possono essere usate da qualunque utente iscritto al social che abbia registrato un’applicazione online legata al suo account: l’idea alla base di questa scelta `e quella di permettere la visualizzazione dei post di Twitter solo ad applicazioni web autorizzate.

E’ stato quindi necessario creare un account e un’applicazione su Twitter. L’applicazione `e collegata ad uno script php che chiama le API ed elabora il json che Twitter invia come risposta.

(23)

Le API di Twitter permettono di settare fino ad un massimo di 200 il numero post recuperabili per ogni chiamata e di eseguire fino a 180 operazioni all’ora per ogni app registrata.

Per poterci fare un’idea della quantit`a e del tipo di dati raccoglibili da Twitter `

e stato necessario fare dei test: abbiamo iniziato monitorando le pubblicazioni dell’utente @Fendi e quelle legati ad alcuni tag, in particolare ad 11 hashtag legati al marchio che, oltre ad esserci sembrati interessanti, hanno dimostrato di essere molto utilizzati nei post.

• #fendi • #peekaboo • #bytheway • #baguette • #fendifw15 • #fendiss15 • #lovefendi • #karlito • #thierrylasry • #2jours • #mybaguette

Descrizione dettagliata degli tag in Appendice A.

Ci siamo resi conto che l’attività su Twitter sia per l’utente @Fendi, sia per gli hashtag relativi al marchio, è alta, ma ben gestibile e ben al di sotto delle limitazioni imposte dalle AP I. Per questo abbiamo deciso di utilizzare Twitter in modo più ampio recuperando non solo le informazioni riguardo @Fendi e gli 11 precedenti hashtag, ma anche monitorando l’attività su Twitter degli utenti ufficiali relativi ai 13 blog (vedi Blog e Giornali ) precedentemente scelti.

In questo modo possiamo anche confrontare le attivit`a dei blogger (si dedicano di pi`u al loro blog o a Twitter?)

La prima problematica relativa al recupero dei dati da Twitter `e legata all’uso delle AP I: i dati sono recuperabili soltanto tramite loro ed `e quindi stato ne-cessario studiarne il funzionamento per capire come interagire con esse e quali

(24)

delle chiamate che mettono a disposizione sono effettivamente utili al nostro scopo.

Come possiamo interagire con le AP I di Twitter?

Twitter prevede la registrazione sull’account di un’applicazione autorizzata al recupero delle informazioni, quindi all’uso delle API.

La politica scelta da Twitter prevede che all’applicazione corrisponda una pagina web realmente online in quanto l’URL completo verr`a utilizzato nel codice sorgente per dare la possibilit`a all’applicazione stessa di creare nuovi tweet e pubblicarli direttamente.

Abbiamo quindi dovuto pubblicare lo script php che richiama le funzioni delle API, in particolare `e stato caricato su un server di BNova.

Quali e quanti dati recuperare?

A questa domanda abbiamo già risposto nel paragrafo precedente: la quantità e la frequenza di pubblicazione dei tweet è ben gestibile, inoltre le API di Twitter permettono per ogni richiesta di raccogliere un numero di tweet molto alto, quindi sono necessarie poche chiamate per raccogliere molto dati.

La combinazione di queste 2 condizioni rende agevole la raccolta e ci per-mette di recuperare dati sia degli utenti, sia degli hashtag senza eccedere nel numero di richieste:

Tipo chiamata Chiamate orarie/ricerca Tot. chiamate orarie Utenti (Fendi + utenti blog) 2 30

Hashtag (11) 2 22

52

La procedura per Twitter prevede la creazione, tramite ETL di Pentaho, di un Job all’interno del quale vengono richiamati 2 script: il primo `e lo script php posizionato sul server che si occupa, richiamando le API, di recuperare i json contenenti i dati originali dei tweet e di salvarli sul server. Il secondo script si trova in locale, ha il compito di scaricare i json dal server ed elaborare per

(25)

ognuno il relativo csv riassuntivo, come accadeva per i blog.

Anche in questo caso notiamo che gli hashtag non sono utilizzati tutti con la stessa frequenza, ma alcuni sono molto pi`u attivi di altri (per alcuni troviamo decine di tweet in poche ore, per altri poche unit`a al giorno).

Decidiamo anche in questo caso di suddividere i tag in 2 gruppi separando quelli più attivi, quindi quelli per i quali la raccolta dovrà essere più densa, e quelli meno attivi, per i quali è sufficiente una raccolta più blanda.

Dopo una prima analisi di frequenza otteniamo questa divisione:

Gruppo A Gruppo B fendifw15 fendi fendiss15 peekaboo lovefendi bytheway karlito baguette thierrylasry 2jours mybaguette

Abbiamo utilizzato la precedente suddivisione dei blog e quella degli hash-tag per impostare le quantit`a di dati da richiedere: per i blog dei Gruppo A e per gli hashtag del Gruppo C (meno attivi ) richiediamo 100 tweet ad ogni chiamata, mentre per i blog del Gruppo B e gli hashtag del Gruppo D (pi`u attivi ) ne richiediamo 200.

La procedura si avvia ogni mezz’ora per ogni utente e per ogni hashtag.

Un secondo Job, avviato 4 volte al giorno (una volta ogni 6 ore) si occupa di creare un csv senza duplicati per ogni utente e per ogni hashtag, e di caricare su Hadoop sia i csv creati, sia i json originali.

3.2.5 Correzioni successive

La procedura di raccolta, cos`ı come per le altre fonti, `e stata costantemente monitorata nei mesi successivi allo scopo sia di correggere eventuali errori, sia

(26)

di ottimizzare l’esecuzione e l’archiviazione.

Nel caso di Twitter, ad esempio, `e stato necessario aggiungere filtri sul testo dei messaggi e soprattutto sugli hashtag: essi per definizione sono composti da sole lettere e numeri, non dovrebbero contenere caratteri speciali, invece abbiamo riscontrato molti casi in cui questi caratteri apparivano.

Dopo la creazione e la messa a punto della procedura di raccolta, una volta sicuri di raccogliere i dati in modo corretto, la nostra attenzione si è rivolta agli hashtag: uno degli obiettivi del progetto è monitorare l’andamento nell’uso degli hashtag, per questo è anche necessario anticipare per quanto possibile le tendenze e iniziare il monitoraggio degli hashtag prima della loro esplosione.

Per poter rimanere aggiornati abbiamo continuato costantemente ad osser-vare blog e social, leggendo gli articoli e informandoci sulle nuove collezioni.

Altre indicazioni interessanti in merito ci sono state fornite direttamente da Fendi, sia tramite comunicazioni interne, sia osservando il contenuto delle newsletter.

In questo senso nei mesi successivi alla messa punto della procedura di recovery abbiamo aggiunto dei tag alla lista di quelli osservati:

• attorno a met`a Maggio abbiamo aggiunto alla lista #fendiorchidea, tag corrispondente alla nuova linea di occhiali in uscita per la collezione primavera/estate 2015,

• all’inizio di Luglio abbiamo aggiunto #fendifw16 e #fendiss16 :

#fendifw16 viene usato sia in corrispondenza della collezione invernale (fall/winter ) 2016, sia in relazione della prossima Fashion Week,

#fendiss16 usato in corrispondenza della nuova collezione Privamera/Estate (spring/summer ) 2016.

(27)

3.2.6 Contenuto del json e csv di Twitter

Info ritenute potenzialmente utili contenute nel json:

• Data creazione • Id del tweet • Testo del tweet

• Dati del post/utente di cui `e un retweet

• Dati dell’utente: id, nome, locazione (se attivo), descrizione, url del sito, num. follower, num. amici, num. liste (sono gruppi di utenti) in cui appare, data registrazione, num.favourites, zona (del fuso orario), dati geografici (se abilitati), num. tweet pubblicati, contributori, info sull’immagine del profilo e di background, colori e personalizzazioni della relativa pagina,

• Dati geografici del post (quasi sempre assenti) • Contributori

• Num. retweet

• Hashtag, simboli, utenti e url presenti nel testo del tweet

• Info su eventuali immagini allegate al tweet: url del media, dimensioni reali e dei resize, tipo del media

• Num. volte segnato come favorite • Lingua

Info che sono state ritenute utili in conseguenza a consultazioni telefoniche con i responsabili Marketing di Fendi e che quindi si `e deciso di portare nel csv:

• data formattata

• data pubblicazione (timestamp) • id e nome dell’utente

• locatione • id

• link del post • lingua • testo

• lista hashtag • num. retweet • num. favourite

(28)

3.3 Social Network: Instagram

Instagram nasce come applicazione gratuita nel 2010: inizialmente era disponibile solo per computer, ma nell’arco di 3 anni è stata distribuita anche per dispositivi mobile e si è diffusa al punto che oggi è usata quasi esclusivamente l’app mobile piuttosto dell’originale.

Instagram permette agli utenti iscritti di scattare foto, modificarle e pubblicarle direttamente sul proprio profilo per condividerle con gli altri utenti della rete. La forza di Instagram sta nella sua immediatezza e spontaneit`a dovuta proprio alla possibilit`a per gli utenti di esprimersi per immagini.

Ogni foto pubblicata pu`o essere accompagnata da una commento dell’autore, e successivamente da like e commenti di altri utenti.

Instagram permette l’uso degli hashtag: si tratta di parole chiave che descrivono l’oggetto. Dopo la loro introduzione su Twitter, l’uso degli hashtag si è diffuso moltissimo anche su Instagram al punto che adesso è più frequente trovare una foto che contiene nel suo commento solo hashtag piuttosto che una foto che non ne contiene nemmeno uno.

3.3.1 Instagram AP I

Come Twitter, anche Instagram mette a disposizione degli sviluppatori una serie di API, chiamate alle quali anche in questo caso si riceve in risposta un file nel formato json contente le informazioni richieste.

A differenza di Twitter, in questo caso ogni json contiene un massimo di 33 post: utilizzando le diverse chiamate `e possibile recuperare praticamente qualunque informazione su qualunque utente, o ricercando qualunque hashtag, ed `e possibile personalizzare le ricerche impostando filtri diversi, ad esempio cercando solo foto, solo commenti, facendo ricerche dal punto di vista geografico, ed altro ancora.

Come in Twitter, anche qui le API possono essere utilizzate da qualunque utente iscritto ad Instagram, `e sufficiente registrare sul proprio profilo un’applicazione ed autorizzarla ad usare i dati dell’account per chiamare le API.

(29)

Trattandosi di un’analisi riguardo il mondo della moda non risulta strano che i post riguardanti Fendi siano numericamente moltissimi. Non tutti sono attendi-bili, come ovvio, ma la scrematura di quali siano rilevanti e quali no verr`a fatta successivamente.

Come accennato nel relativo paragrafo, le Instagram API permettono di lanciare richieste di vario genere: prima di decidere quali utilizzare abbiamo effettuato diverse prove relative a diversi tipi di richiesta, poi ci siamo fermati ad osservare i risultati. Abbiamo iniziato richiedendo ad Instagram i dati relativi ai post pubblicati dal-l’utente @Fendi. In effetti però abbiamo poi pensato che, al fine della nostra analisi, queste informazioni abbiano un’utilità relativa: a noi interessa sapere quanto il mon-do del web parla di Fendi, non quanto Fendi parla di sè (sarebbe interessante, ma si tratta di un’altro tipo di analisi). Inoltre è ovvio che l’attività dell’utente @Fendi abbia una corrispondenza con il lancio di nuovi prodotti o con eventi riguardanti più o meno direttamente il marchio. Questi dati quindi ci forniscono informazioni ovvie, quindi poco utili al nostro scopo se non come termine di confronto.

Altro tentativo ha riguardato le ricerche tramite hashtag, e per testarne il com-portamento abbiamo provato con gli 11 hashtag gi`a precedentemente analizzati in Twitter.

Anche in questo caso abbiamo riscontrato la presenza di hashtag pi`u e meno attivi : per i pi`u attivi i post sono molti e molto frequenti (siamo nell’ordine di qualche migliaia in pochi minuti), per i meno attivi i post sono decisamente meno frequenti, anche se si tratta comunque di centinaia di post giornalieri.

Questi dati sembrano utili al nostro scopo, in quanto si tratta dell’osservazione di quanto se ne parla in generale, indipendentemente da chi ne parla. Per que-sto motivo abbiamo deciso di effettuare solo ricerche per hashtag: abbiamo trovato corrispondenza con la precedente suddivisione fatta in Twitter e abbiamo deciso di mantenere gli stessi hashtag suddivisi negli stessi 2 gruppi.

Una volta deciso quali dati recuperare ci siamo dovuti porre il problema di come recuperarli.

Il problema principale `e che i dati di Instagram non sono statici, ma sono in continua evoluzione: lo stesso post pu`o essere modificato dal suo autore successi-vamente alla pubblicazione e gli possono essere aggiunti commenti e like dagli altri utenti.

(30)

Inoltre Instagram attua una politica di ordinamento secondo cui i post vengono ordinati non in base alla data di pubblicazione, ma in base alla data dell’ultima attività sul post (può essere la pubblicazione, ma anche la data dell’inserimento dell’ultimo commento o like): è quindi possibile che risultino in prima pagina un post appena pubblicato insieme ad un post molto vecchio a cui è stato appena aggiunto un like o un commento.

I post vengono prima ordinati, poi organizzati in pagine contenenti ognuna 33 post (nella pagina 1 saranno presenti i 33 post pi`u recenti, nella pagina 2 i successivi 33 e cos`ı via). Le pagine vengono lette una alla volta, ognuna tramite la chiamata di una funzione delle API.

Quante pagine dobbiamo recuperare ad ogni iterazione?

Una prima idea è stata creare una procedura che legga un alto (e fissato) numero di pagine e che si avii ad intervalli regolari. Dopo le prime prove però ci siamo resi conto che ciò risulta poco sensato: a parità di numero di pagine scegliere un inter-vallo eccessivamente ampio comporta il rischio in troppi casi di perdere informazioni interessanti, d’altra parte scegliere un intervallo eccessivamente breve comporta il rischio di raccogliere molti più dati del necessario e tra loro ridondanti.

Non dobbiamo perdere di vista la politica di ordinamento scelta da Instagram, che da un lato risolve il problema presente nel caso dei blog di perdita dei commenti relativi a post vecchi, dall’altro però dobbiamo considerare che su Instagram l’atti-vità è spesso molto frenetica, perciò il contenuto delle pagine cambia continuamente: può capitare, ad esempio, in momenti di grande attività, di trovare nella generica pagina x + 1 post successivi a quelli appena letti nella pagina precedente x.

Come raccogliere i post assicurandoci di recuperare tutti i dati relativi ad un hashtag? Abbiamo ragionato sul fatto che i dati sono organizzati in ordine crescente, quin-di i dati pi`u recenti saranno presenti in pagina 1, e abbiamo trovato una soluzione implementando una procedura di raccolta in avanti : dato un intervallo di tempo di riferimento (ad esempio: da adesso per i prossimi 20 minuti), rileggiamo la prima pagina un numero di volte non fissato, finch`e i dati presenti nella pagina corrispondo-no all’intervallo di riferimento (maggiori dettagli riguardo la procedura nel prossimo paragrafo).

In questo modo il rischio (teorico) di perdita di informazioni `e pari a 0, nella pratica per`o non possiamo considerarlo del tutto azzerato a causa dei ritardi inevi-tabili dovuti ai tempi di elaborazione locale e di risposta del server Instagram: per quanto possano essere macchine performanti, comunque non permettono una vera e

(31)

propria elaborazione real time, quindi se pur minimi i ritardi non possono essere del tutto azzerati.

Quante richieste alle AP I possiamo effettuare?

Il limite fissato da Instagram `e di 5000 richieste orarie per ogni account.

Si tratta di un parametro non modificabile e ben inferiore al numero di richieste che partono attualmente dalle nostre procedure (sono in media 200 ogni 10 secondi, per un totale di circa 70000).

La soluzione migliore sembra essere rallentare le procedure, quindi inserire tra due chiamate successive delle sleep calcolate in modo da ridurre a 5000 le richieste totali orarie.

Scendere da 70000 a 5000 richieste significa diminuire il numero di chiamate da 20 al secondo a circa 1,4 al secondo: una sola chiamata al secondo con 11 procedure attive significa che ogni procedura pu`o effettuare 7,5 chiamate al minuto, ovvero una chiamata ogni 8 secondi.

Questo intervallo corrisponde al recupero massimo di circa 15000 post orari per hashtag, valore pi`u che sufficiente per gli hashtag meno attivi, ma troppo basso per i 4 hashtag pi`u attivi.

Provando con diverse combinazioni, abbiamo calcolato valori di attesa in sleep diversi per i due gruppi di hashtag che sembrano dare risultati soddisfacenti:

Numero chiamate per ogni Numero massimo Gruppo Hashtag sleep(..) minuto ora chiamate orarie Molto attivi (4) 4 sec 15 900 3600

Poco attivi (7) 20 sec 3 180 1260 4860

In questo modo il numero massimo di chiamate orarie risulta 4860. Parliamo di numero massimo perchè agli sleep vanno aggiunti i ritardi di elaborazione in locale e di risposta del server: si tratta di valori tipicamente molto piccoli, ma non controllabili e non eliminabili. Questi ritardi esistono e vanno a rallentare, se pur di poco, l’esecuzione della procedura, quindi, rispetto al numero di chiamate previste, quelle effettivamente eseguite risulteranno minori. Fissare sleep più brevi comporta però il rischio di superare il numero massimo di chiamate: questa combinazione sembra essere la migliore.

Un modo per aumentare il numero di richieste possibili è utilizzare più account: in quel caso avremmo a disposizione 5000 richieste per ogni account. Sembra però

(32)

non necessario nel nostro caso: osservando il contenuto dei dati raccolti abbiamo potuto appurare che non rimangono intervalli di tempo scoperti, o che comunque questi sono sufficientemente rari e brevi da non giustificare l’uso di altri account.

La raccolta deve avvenire in parallelo per ognuno degli hashtag, per questo sono stati creati Job separati per ogni hashtag da cercare: abbiamo deciso di lasciarli separati in modo da semplificarne l’esecuzione schedulata parallela.

I singoli Job prevedono la chiamata di uno script php al quale vengono passa-ti i criteri di ricerca, il tempo di sleep e le informazioni necessarie per impostare l’intervallo di osservazione.

Lo script procede iterativamente: ad ogni passo viene letta page=1 e, se si rilevano informazioni diverse da quelle precedentemente lette, viene salvato lo stream ritornato dalla richiesta.

Ogni fase di raccolta copre un’intervallo di osservazione fissato a 20 minuti. Si `e scelto questo intervallo dopo una serie di prove con intervalli di dimensioni minori e maggiori: con intervalli pi`u brevi avremmo avuto molti file piccoli e maneggevoli, ma un maggior numero di ridondanze, mentre con intervalli maggiori il numero di ridondanze sarebbe diminuito, ma si sarebbero andati a creare json di dimensioni poco maneggevoli: 20 minuti sembra il giusto compromesso.

Al termine dell’intervallo termina anche la fase di raccolta ed inizia quella di elaborazione durante la quale vengono creati un csv per ogni json: nel csv, come nel caso dei blog, si tiene traccia solo di alcuni campi, quelli che sembrano utili per le prossime analisi, in particolare: data di pubblicazione del post, id e nome dell’utente, id del post, link diretto al post, lingua, testo, lista degli hashtag utilizzati nel post, numero di retweet (condivisioni di un post gi`a precedentemente pubblicato) e numero dei preferiti (corrispondono al like di Facebook).

Nello stesso momento in cui termina una raccolta, la procedura viene riavviata sull’intervallo successivo.

Suddividere la raccolta in intervalli temporali di osservazione ha il vantaggio di permettere di dividere la fase di raccolta e quella di elaborazione: in questo modo si evita che i ritardi di elaborazione in locale della seconda vadano ad influire sulla prima, gi`a oggetto dei ritardi di risposta del server Instagram.

Alla fine dell’intervallo, ovvero nel momento in cui termina la fase di raccolta per la procedura A, inizia la fase di raccolta della procedura B successiva.

(33)

Figura 2: Instagram: Avvio dei Job

Possiamo notare c’`e un periodo in cui 2 procedure sono entrambe attive, ma si trovano in fasi diverse: una di raccolta, l’altra di elaborazione. In questo modo ogni istante `e coperto da una procedura di raccolta attiva.

Ogni ora si avvia un’ulteriore procedura che legge i csv precedentemente creati e crea un unico csv per ogni hashtag contentente tutti i dati raccolti senza duplicati. La procedura si occupa anche di caricare su Hadoop i json raccolti nell’ultima ora e il csv senza duplicati di ogni hashtag.

Stessa attenzione sugli hashtag ha influenzato anche il monitoraggio su Instagram. Anche in questo caso la lista degli hashtag `e stata aggiornata attorno a Maggio, con l’aggiunta di #fendiorchidea, e a Luglio con l’aggiunta di #fendiss16 e #fendifw16.

(34)

3.3.6 Contenuto del json e del csv di Instagram

Info contenute nel json: • Elenco hashtag

• Locazione (spesso assente)

• Commenti: per ognuno data creazione, testo e info sull’utente (username, id, immagine del profilo)

• Data di pubblicazione • Link diretto del post

• Likes: per ognuno info sull’utente (username, id, immagine del profilo) • Immagine: dimensione (originale e ridotta) e url

• Utenti taggati nella foto: per ognuno dati dell’utente (username, id, immagine del profilo) e posizione del tag nella foto

• Testo completo del post

• Tipologia di post (es. immagine) • Id del post

• Dati dell’utente che ha pubblicato il post: id, username, immagine del profilo Info contenute nel csv:

• data formattata • id

• link del post

• data pubblicazione (timestamp) • locatione • testo • lista hashtag • num. commenti • commenti • num. likes • likes

• num. utenti in foto • utenti in foto

(35)

3.4 Social Network: Facebook

Facebook originariamente è stato progettato da e per gli studenti dell’Università di Harvard. La sua fama si diffuse tanto velocemente da essere presto aperto anche agli studenti di altre università americane, ed in breve a chiunque nel mondo dichiarasse più di 13 anni di età.

Da allora il successo di Facebook è stato un crescendo: nel giugno 2013, secondo la Alexa Internet Inc. è diventato il sito più visitato al mondo, superando addirittura Google. Facebook ha cambiato profondamente molti aspetti legati alla socializzazio-ne e all’interaziosocializzazio-ne tra individui sul piano privato, ma anche (e di conseguenza) sul piano economico e commerciale.

Nel marzo 2015 Facebook ha superato 1,4 miliardi di utenti registrati, confer-mandosi come il pi`u diffuso social network ad oggi utilizzato.

3.4.1 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

(36)

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 è stato deprecato: è ancora supportato nella v2.0, ma viene reso pubblico che non sarà più 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à più 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).

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

(37)

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.

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

(38)

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 è stato necessario perché, al momento in cui è iniziata la fase di raccolta, Facebook forniva agli sviluppatori una serie molto limitata di AP I, all’interno delle quali non si è 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à, potenzialmente utili anche al nostro scopo. Nonostante questo aggiornamento è stato deciso di non andare a modificare la procedura sopra descritta, che rimane comunque del tutto corretta, soprattutto perchè il termine della raccolta dati era ormai prossimo (precedentemente fissato alla fine di Luglio).

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’autenticaschedula-zione 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.

(39)

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 è ritenuto più 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) è molto diverso sui diversi social, perciò, 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.

(40)

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.

4.1.1 Blog: Gruppo A

Come accennato nel paragrafo precedente, l’assenza di hashtag nel blog limita molto sia nelle quantit`a, sia nella tipologia di analisi effettuabili.

Il mining in questo caso si occupa dell’esplorazione dei dati osservando i post dal punto di vista temporale (giorno e ora di pubblicazione), ma anche analizzandoli per origine, alla ricerca dei blog pi`u attivi e di quelli che pi`u si occupano del marchio Fendi.

4.1.1.1 Distribuzione per origine

Osservando la distribuzione del numero di post pubblicati da ogni blog si nota subito la predominanza di 3 fonti:

• Fashion Magazine • Contatto News • Vogue

(41)

Figura 4: Blog, primo gruppo: Distribuzione dei post per fonte

Come potevamo prevedere l’attivit`a maggiore cade sui giornali web piuttosto che sui blog: essi infatti si occupano di molti argomenti ed hanno, quindi, una frequenza di pubblicazione molto maggiore rispetto ai blog.

L’interesse del marchio sull’attività in generale del giornale/blog è però limitato. Ciò che ha maggior rilevanza sono le pubblicazioni di post che riguardano diretta-mente F endi: per far questo, non potendoci basare sulle Association Rules, abbiamo suddiviso i post a seconda che la parola Fendi appaia o meno nel titolo o nel testo del post.

La cardinalit`a dei gruppi, come atteso, `e notevolmente diversa dalla precedente (ricordiamo che si tratta di un campione di dati):

Tutti Gruppo 0 (nonFendi) Gruppo 1 (Fendi)

4469 4430 39 (<1%)

Ci concentriamo sul Gruppo 1: Fendi e osserviamo come sono distribuiti i post:

Figura 5: Blog, primo gruppo: Distribuzione dei post del Gruppo 1: Fendi per fonte

Come prima osservazione notiamo che gi`a `e diverso il numero di blog: da 13 scendiamo a 9. Questo dato non sorprende: stiamo cercando informazioni riguardo