Presentation – Oggetti QlikSense

 Al fine di rendere i dati geografici coerenti tra loro, essi vengono presi entrambi dalla stessa sorgente secondo il criterio per cui se la city o la country e nulla su Sales Force, ma la stessa è presente sulla piattaforma, entrambi i campi cCity e Country sono presi dai dati della piattafoma. Questo metodo evita possibili incoerenze tra i dati geografici, che potrebbero emergere con l’utilizzo di due sorgenti diverse per City e Country.

 Creazione di alcuni campi di flag che identificano se per quella riga sono stati gestite le seguenti eccezioni sopra indicate, distinguendo quelle di carattere anagrafico da quelle di carattere geografico. Tali flag vengono poi utilizzati per agevolare i calcoli sull’app di Data Quality.

Le tabelle finali risultato di queste elaborazioni vengono poi storicizzate in dei qvd di secondo livello (uno per ciascuna tabella).

Figura 18. Data Model finale dell’app di Presentation

Il data model finale è pertanto costituito dalle seguenti tabelle:

- Platforms: tabella dei fatti principale: al suo interno contiene i dati di lettura di tutte le piattaforme, del website di Finance e delle mail aperte e cliccate. Per ciascun reader sono presenti anche i dati anagrafici. Tali dati non sono stati inseriti in una tabella apposita in quanto essi vengono presi dalla piattaforma o dall’anagrafica Sales Force in base al fatto che essi siano presenti o meno su quest’ultima

- Document Data: tabella di anagrafica contenente per ciascun documento, dati anagrafici come il nome, la società di appartenenza, la data di pubblicazione ecc. Si collega alla tabella dei fatti platform tramite il campo CMS, che identifica il documento in modo univoco.

- MappingCMS: tabella di anagrafica contenente per ciascun CMS l’elenco dei codici documento associati. Essendo state create le chiavi in base al CMS, tale tabella non risulta strettamente necessaria, ma dato che contiene poche righe, è stata lasciata per poter velocizzare eventuali controlli dei dati, dovuti ad esempio all’inserimento di

nuovi codici documento associati a dei CMS. Anche questa tabella è collegata alla tabella Platforms tramite il codice CMS.

- Google Analytics: tabella contenente i dati aggragati di Google Analytics in cui sono presenti specifici KPI non divisibili, per i quali risulta necessario mantenere il dato della tabella allo stato di aggregazione originario. Questa tabella viene utilizzata esclusivamente per il calcolo di tali KPI, infatti i dati di lettura di Google Analytics sono presenti anche all’interno della tabella Platforms, in modo da avere accesso allo stesso livello di aggregazione per tutte le piattaforme. La chiave di collegamento della tabella con la tabella Platforms è data dalla concatenazione dei seguenti campi:

 CMS

 Read Date

 Platform

 City

 Country

Tale chiave rappresenta il massimo livello di dettaglio a cui arriva la tabella Google Analytics, e permette quest’ultima di essere correttamente filtrata sull’interfaccia in base alle selezioni applicate dall’utente.

- Master Calendar: tabella contenente, per ciascuna data di laettura, gli attributi relativi alla settiman, mese e anno di appartenenza.

E’ utile notare che il modello dati finale si discosta parzialmente da quello ipotizzato inizialmente (rif. paragrafo 3.5.1); questo è dovuto al fatto che durante il progetto, una volta emerse tematiche come la gestione dei dati anagrafici, è risultato indispensabile provvedere trovare nuove soluzioni, che hanno portato a questi cambiamenti. La struttura di base però non è cambiata, ma risulta abbastanza fedele a quanto preventivato.

Una volta creato il modello dati è necessario passare alla progettazione degli oggetti Qlik Sense che verranno inseriti all’interno dell’ interfaccia web QlikSense (mashup). Tali oggetti, prendono spunto da quelli condivisi tramite mockup nelle prime fasi del progetto, anche se con parziali modifiche. Di seguito elenchiamo gli oggetti definitivi creati, suddivisi per pagina di appartenenza sul mashup:

HomePage

• Tabella dei KPI: tabella contenente tutti i KPI che saranno inseriti nella Homepage

Figura 19. Tabella contenente i KPI della HomePage

Le logiche di calcolo di tali KPI sono le seguenti:

 Reports published: conteggio distinto dei CMS

 Unique readers: conteggio distinto dei lettori esclusi quelli sconosciuti

 Countries reached: conteggio distinto degli Stati

 New readers: conteggio dei readers che hanno letto un solo documento una sola volta

• Grafico di Trend: andamento delle letture nel tempo. La dimensione utilizzata è una dimensione di drill che in base alla selezione permette di passare alla visualizzazione del numero di readers negli anni, mesi o giorni. Le misure calcolate sono il numero di letture e la cumeulata delle letture nel tempo:

 Total Reads:

count([Reader’s ID])

 Cumulated Reads:

RangeSum(above(column(1),0,RowNo()))

Figura 20. Grafico di trend

• Grafici a torta: identificano la suddivisione percentuale delle letture in base alle dimensioni Investor Type, Channel e Country. Dal conteggio vengono esclusi i valori delle dimensioni “Unknown” e il massimo numero di valori della dimensione visualizzabili sono 10, gli altri valori vengono inseriti in un unico valore denominato

“others”. Per ciascun grafico viene inserita la dimensione limitata ai primi 10 valori, mentre la misura è data dal conteggio delle letture.

 Total Reads Investor Type:

count({$<[Investor Type]-={‘Unknown’}>}[Reader’s ID])

 Total Reads Country:

count({$<[Reader Country]-={‘Unknown’}>}[Reader’s ID])

 Total Reads Channel:

Count([Reader’s ID])

Figura 21. Grafici a torna

Data Analysis

• Grafici a torta: identificano la suddivisione percentuale delle letture in base alle dimensioni Investor Type, Channel e Location. Dal conteggio vengono esclusi i valori delle dimensioni “Unknown” e il massimo numero di valori della dimensione visualizzabili sono 10, gli altri valori vengono inseriti in un unico valore denominato

“others”. Per ciascun grafico viene inserita la dimensione limitata ai primi 10 valori, mentre la misura è data dal conteggio delle letture. In altre parole vengono utilizzati gli stessi oggetti che erano presenti nella pagina Homepage. Questa duplicazione è dovuta al fatto che mentre la Homepage è una tabella di sommario delle analisi, Data Anlysis è una tabella di dettaglio in cui per analizzare meglio i dati è comodo avere gli stessi grafici senza necessità di cambiare di volta in volta pagina.

• Sankey Chart: grafici che identificano visivamente quali documenti sono visualizzati da certe tipologie di utente e in che quantità. Tale tipologia di grafico necessita di essere settato con almeno 2 dimensioni e una misura che nel nostro caso sono:

 Dimensione 1: Investor Type/ Institution/ Country: i grafici creati sono tre, ciascuno per ciascuna di queste dimensioni.Per evitare di avere troppe dimensioni poco influenti, che renderebbero poco leggibile il grafico, è stato deciso di settare al massimo 5 valori per ciascuna dimensione, che corrispondono ai 5 volori con più letture. Non essendo su questo grafico possibile settare questa impostazione, abbiamo creato delle dimensioni calcolate che seguono questa logica. Segue il calcolo dalla dimensione top 5

“Investor Type”:

if(GetPossibleCount([Investor Type]) >= 10, aggr(

if(rank(count({<[Investor Type]-={'Unknown'}>}[Reader's ID]),1,1)<=10,[Investor Type],null())

,[Investor Type]), [Investor Type])

Per le dimensioni Institution, Country il calcolo è identico, cambia solo il nome della dimensione su cui fare il calcolo

 Dimensione 2: Document Name: nome del documento oggetto di letture.

Anche qui per evitare di avere troppe dimensioni poco influenti, è stato deciso di settare al massimo i 5 documenti più letti:

if(GetPossibleCount([Document Name]) >= 10, aggr(

if(rank(count( [Reader's ID]),1,1)<=10[Document Name],null())

, [Document Name]), [Document Name])

 Misura: conteggio delle letture

count([Reader's ID])

In figura un esempio di Sankey chart per Investor Type:

Figura 22. Sankey chart

• Bar Chart: grafico che identifica quali sono i 5 documenti più letti e qual è il numero di letture ad essi associato. In questo caso dunque la dimensione inserita è il Document Name settato per i soli primi 5 in base alla misura, che è data dal conteggio delle letture:

count([Reader's ID])

Figura 23. Grafico a barre

• Tabella: identifica per ogni documento, il numero di letture percentuale di letture sul totale. La dimensione utilizzata pertanto è il Document Name, mentre le misure sono date dal conteggio delle letture e dal conteggio delle letture diviso il conteggio totale delle letture presenti in tabella.

 Reads: count([Reader's ID])

 % Reads: count(Reader's ID])/count(total [Reader's ID])

Figura 24. Tabella letture per documento

Data Analysis

• Tabella: identifica per ogni documento la sua data di pubblicazione. Inoltre la selezione dalla tabella di uno qualsiasi dei documenti apre la pagina web contenente il report del documento.

Figura 25. Tabella documenti pubblicati

• Grafico di Trend: permette di visualizzare l’andamento delle letture nel tempo.

Analogamente al grafico presente nella Homepage, anche qui la dimensione utilizzata è una dimensione di drill che in base alla selezione permette di passare alla visualizzazione del numero di letture negli anni, mesi o giorni.

La misura inserita è data dal seguente calcolo:

count([Reader's ID])

Figura 26. Grafico di trend per anno - mese

• Tabelle: contengono i KPI relativi al sito di Finance e delle mail aperte e cliccate. I KPI calcolati sono:

 Unique visitors: numero di lettori dei documenti presi da Google Analytics

sum ([# Users])

 Avg visit duration: media della misura “Avg Time On Page” della tabella Google Analytics

Avg ([Avg Time on Page])

 ResearchLink visitors: numero di letture avvenute tramite widget, calcolato in base alla somma della misura “Flag Widget” presa dalla tabella Google Analytics

Sum ([Flag Widget])

 E-mail opens: numero di mail aperte dai lettori, date dal conteggio delle righe della tabella platforms aventi il campo “Flag Type Date” = “Open”.

Count ({$<[Flag Type Date]={'Open'}>}[Flag Type Date])

 E-mail click throughs: numero di email in cui è stato aperto il link che rimanda al documento oggetto della mail, date dal conteggio delle righe della tabella platforms aventi il campo “Flag Type Date” = “Click”.

Count ({$<[Flag Type Date]={'Click'}>}[Flag Type Date])

Figura 27. Tabella contenete i KPI relativi al website

Figura 28. Tabella contenete i KPI relativi alle mail

Geo Analysis

• Mappa Geografica: creata su due livelli di densità, Country e City. Il livello country è un livello area con 100% trasparenza che consente lo zoom automatico sullo stato di appartenenza dei dati, qualora vengano applicati i filtri. La posizione della Country è individuata sulla mappa grazie al campo Geo.country_GeoInfo che contiene le coordinate dell’area geografica. Il livello city è un livello densità, in cui la coordinata della città è individuata dal campo Geo.city_GeoInfo che contiene la coordianta puntuale della città. Il peso e il raggio sono calcolati tramite il conteggio delle letture su ciascuna coordinata; essendo un livello densità con mappa di calore, maggiore sarà il valore della misura per una determinata coordinata o area, più rossa e grande sarà evidenziata la zona.

Figura 29. Mappa Geografica a densità

La figura seguente mostra come, grazie all’inserimento del livello area Country, selezionando una città come Londra, per la quale è associata una coordinata puntuale, lo zoom automatico non si riduce al singolo punto, che sarebbe visivamente poco significativo, ma permette di visualizzarlo ad un livello di zoom tale da vedere lo stato di appartenenza:

Figura 30. Mappa Geografica filtrata su una città

• Bar graph: grafici che permettono di vedere come le letture sono suddivise per

dimensione geografica, tipologia di investitore e piattaforma di lettura. I grafici creati nello specifico sono due, ciascuno con le seguenti dimensioni e misure:

 Continent, Country, City: dimensione drill down che cambia livello di aggragazione rispetto ai filtri applicati dall’utente. Di default è visibile la suddivisione per continente, ma se ad esempio si seleziona uno Stato, la dimensione cambia in automatico e diventa a livello di città

 Investor Type, Channel: ogni grafico possiede una di queste dimensioni, che lo differenzia dall’altro

 Reader City Geo: conteggio delle letture escludendo i dati che hanno città, stato e continente nulli. La formula implementata è la seguente:

count({$<[Reader City]-={'Unknown'}, [Reader

Continent]-={'unknown'}, [Reader Country]-={'Unknown'}>}[Reader's ID])

In figura il grafico settato per Channel, a livello di aggragazione geografica massimo (Continent):

Figura 31. Grafico a barre leture per continente

Readers Report

• Tabella: tabella contenente per Insititution, Institution Investor Type, City e Country, le seguenti misure:

 Website: conteggio delle letture avvenute sul sito di Finance

Count({$<Platform={'Edison Website'}, [Flag Type Date]={'Read'}>}[Reader's ID])

 E-mail opens: conteggio delle mail aperte dai lettori di ciascuna società

Count({$<[Flag Type Date]={'Open'}>}[Flag Type Date])

 E-mail click: conteggio delle mail nelle quali è stato cliccato l’url che porta al documento pubblicato sul web

Count({$<[Flag Type Date]={'Click'}>}[Flag Type Date])

 Institutional Platform: conteggio delle letture avvenute tramite le altre piattaforme

Count({$<Platform-={'Edison Website'}>}[Reader's ID])

 Reads: conteggio delle letture totali, comprensive di mail esclusivamente aperte

Count([Reader's ID])

Figura 32. Tabella di dettaglio letture per institution

Filters

• Caselle di elenco: costituiscono i filtri che saranno resi disponibili nell’interfaccia utente. Ogni filtro corrisponde ad una casella di elenco

Tutte le misure calcolate sono state create come master item, che verranno poi utilizzati all’interno del mashup.

L’app di presentation è inoltre messa a disposizione degli utenti come strumento di data quality, in quanto permette loro di fare controlli tra i dati di anagrafica ricevuti dalle piattaforme partners e i dati da loro censiti sull’ anagrafica Sales Force. Fare queste verifiche per loro è semplice grazie alle funzioni di self -service BI QlikSense, che permettono in modo facile e intuitivo di creare tabelle e grafici semplicemente trascinando oggetti, dimensioni e misure sul proprio foglio di lavoro dell’ App QlikSense.