UNIVERSITÀ DI PISA
Dipartimento di InformaticaLaurea Magistrale in Informatica per l'Economia e per l'Azienda (Business Informatics)
TESI DI LAUREA MAGISTRALE
UNA SOLUZIONE DI BUSINESS INTELLIGENCE PER IL
MONITORAGGIO E LA PIANIFICAZIONE DI CAMPAGNE WEB
ADVERTISING
Candidato
Lorenzo Policardo
Relatore
Prof. Nicola Ciaramela
Tutor Accademico
Sara Niccolini
Riassunto
Il digital marketing è ormai da tempo un settore sempre più consolidato e che sta vivendo ai giorni nostri una crescita inarrestabile. Le grandi opportunità offerte sono però bilanciate dall’enorme difficoltà nel rimanere competitivi in un mercato in cui si aprono continuamente canali nuovi ed opportunità inedite, sempre più potenti ma, allo stesso tempo, difficili da cogliere. La sola esperienza infatti non risulta sufficiente per l’analisi delle prestazioni ottenute e la pianificazione di nuove campagne sempre più diversificate e sofisticate.
Il lavoro che ha ispirato questa tesi è stato svolto presso Intarget S.r.l., agenzia web marketing leader nel mercato italiano, in grado di gestire l’intero flusso digitale della comunicazione di un’azienda. Il mio lavoro di tesi affronta la progettazione e la realizzazione di una soluzione di Business Intelligence per l’analisi, la narrazione e la pianificazione di campagne di web advertising in grado di fornire all’agenzia un vantaggio competitivo basato sulla qualità e la differenziazione del servizio offerto.
La tesi percorre e scala l’intera piramide della Business Intelligence iniziando dalle sue fondamenta. Infatti partendo dalla raccolta dei dati provenienti dalle piattaforme di advertising, questi vengono puliti ed integrati da un servizio ETL che provvede alla memorizzazione dei dati all'interno di un Data Warehouse, a cui si interfaccia un OLAP System. Una volta che i dati risultano storicizzati ed immagazzinati, essi vengono navigati dinamicamente attraverso un servizio di Data Visualization in grado di mostrare efficacemente ai clienti o agli utenti interni i risultati di campagna.
Una volta analizzato il passato, il mio sguardo si è rivolto al futuro ed alla possibilità di utilizzare i dati raccolti per la pianificazione delle future campagne, ciò è stato realizzato attraverso l’utilizzo di tecniche di Data Mining ed in particolare della regressione logistica.
In ogni fase del progetto saranno presentate sia le problematiche di ordine generale, sia i problemi riscontrati durante l'esperienza diretta con la realtà aziendale in un mercato dinamico in continua evoluzione.
L’obiettivo è stato quello di concepire, progettare e realizzare autonomamente un sistema di Business Intelligence che abbracciasse molte delle discipline affrontate durante i miei anni di studio per la risoluzione di un problema reale attraverso il confronto con professionalità aventi background differenti e non tecnici. È importante notare come questo progetto fin dal principio è stato concepito con una finalità pratica, con l’obiettivo di raggiungere nel minor tempo possibile ed in autonomia un risultato concreto da presentare all’agenzia e successivamente ai suoi clienti.
Indice
Capitolo 1 INTRODUZIONE ... 5
1.1 Presentazione del problema ... 5
1.2 Rassegna della letteratura ... 6
1.3 Contenuto della tesi ... 6
Capitolo 2 WEB ADVERTISING ... 8
2.1 Introduzione... 8
2.2 Trafficking e Placement ... 8
2.3 Terminologia del Web Advertising ... 10
2.4 Il processo di tracking in Intarget ... 11
Capitolo 3 LA SOLUZIONE DI BUSINESS INTELLIGENCE ... 14
3.1 Descrizione della situazione attuale ... 14
3.2 La soluzione proposta ... 15
Capitolo 4 PROGETTAZIONE DEL DATA WAREHOUSE ... 18
4.1 Cos'è un data warehouse ... 18
4.2 L’Analisi dei requisiti ... 19
4.3 Progettazione Concettuale ... 24
4.4 Progettazione logica ... 25
4.5 Progettazione Fisica ... 27
Capitolo 5 EXTRACT TRANSFORM LOAD ... 28
5.1 Il processo ETL ... 28 5.2 ETL Main ... 28 5.3 ExtractDCM ... 29 5.4 ExtractDBM ... 31 5.5 ExtractFB... 32 5.6 ExtractNielsen ... 33 5.7 ExtractYT ... 34 5.8 ExctractRT... 34 5.9 Sviluppi Futuri ... 38
6.1 Microsoft Power BI ... 39
6.2 Dashboard View ... 40
6.3 Reach & frequency ... 41
6.4 KPI Media ... 43
6.5 Consideration & Interest ... 44
6.6 Feedback ... 46
Capitolo 7 ANALISI DATA MINING PER LA PIANIFICAZIONE DI UNA NUOVA CAMPAGNA ... 47
7.1 Business Understanding ... 47
7.2 Data Understanding ... 48
7.2.1 Describe Data ... 48
7.2.2 Explore Data ... 49
7.3 Select Modeling technique: the Logistic Regression ... 53
7.3.1 I vantaggi della Regressione Logistica ... 55
7.5 Data Preparation ... 56
7.5.1 Select Data ... 56
7.5.2 Construct Data ... 61
7.6 Modeling ... 66
7.6.1 Generate Test Design ... 66
7.6.2 Build Model ... 67
7.7 Assess model ... 68
7.7.1 Likelihood ratio test ... 68
7.7.2 Pseudo R2 McFadden ... 69
7.7.3 LogLoss ... 70
7.8 Deploy: Pianificazione di una nuova campagna attraverso l’uso del modello... 73
7.9 Valutazione del servizio di Pianificazione ... 80
Conclusioni ... 82
Ringraziamenti ... 84
Capitolo 1
INTRODUZIONE
1.1 Presentazione del problema
Intarget da circa un anno propone alla propria clientela, la gestione delle attività web advertising attraverso l’Ad Server DoubleClick di Google. Il servizio DoubleClick Campaign Manager (DCM) è utilizzato per il caricamento e la gestione delle campagne di web advertising, inoltre DCM permette di registrare le statistiche di performance relative alla loro erogazione, ad esempio le impression, i click, la provenienza geografica, il tipo di sistema operativo/browser, il device ecc.
Intarget fornisce tale servizio ai clienti disposti ad investire budget considerevoli ed interessati a campagne con obiettivo di brand awareness, cioè l’incremento della notorietà del marchio ed il suo essere associato nella mente degli utenti a valori positivi. Tale tipologia di campagna si rivolge ad un mercato globale riguardante numerosi paesi ed utilizza un numero rilevante di canali digitali aventi differenti modalità di acquisto. Per capire il volume di questi dati, basti pensare che ogni cliente commissiona una decina di campagne l’anno della durata di qualche settimana e che ad ognuna di esse vengono associati centinaia di differenti posizionamenti.
L’agenzia al termine di una campagna provvede a scaricare da DCM i dati relativi al tracciamento delle campagne ed ad integrarli con altre informazioni provenienti da differenti fonti. Ciò si rende necessario poiché DCM prevede che trascorsi due anni dalla creazione di una campagna, i dati ad essa legati vengono definitivamente eliminati.
Il processo di storicizzazione dei dati viene effettuato “manualmente” attraverso la creazione di un unico foglio di calcolo in cui vengono registrate migliaia di righe relative a ciascun posizionamento, copiando ed incollando i valori dai diversi report d’origine.
È facile immaginare i limiti di questa soluzione a livello di tempo, affidabilità, alienazione umana oltre all’impossibilità tecnologica di mantenere alti volumi di dati in unico foglio di calcolo.
Inoltre applicando tale soluzione risulta impensabile riportare le statistiche temporali con dettaglio giornaliero ed improponibile poter fornire al cliente un monitoraggio completo giorno per giorno. In conclusione, l’agenzia ha la necessità di poter usufruire di un sistema in grado di storicizzare, integrare e rendere facilmente fruibili i dati relativi alle campagne web advertising. Inoltre presenta l’esigenza di presentare ai propri clienti delle proposte di pianificazione per le future campagne.
1.2 Rassegna della letteratura
Di seguito sono presentati i testi consultati per la stesura della tesi:
- Per la sezione relativa alla progettazione del data warehouse è stato fatto riferimento alle soluzioni presenti in Decision Support Database Essentials, [Albano, Ruggieri 16];
-Per la sezione relativa all’analisi di data mining è stato fatto riferimento alle nozioni teoriche presenti in Introduction to Data Mining, [Pang-Ning Tan 2006];
- Per le nozioni teoriche specifiche della regressione logistica è stato fatto riferimento agli appunti delle lezioni del corso Business intelligence e performance management, del professor Ciaramella dell’Università di Pisa [Ciaramella 2016] ed alla dispensa Regressione Multipla e Regressione Logistica: concetti introduttivi ed esempi, del professore Senese della Seconda Università di Napoli [Senese 2014];
- Per la realizzazione tecnica del modello di regressione logistica in linguaggio R, è stato fatto principalmente riferimento alle pagine web r-statistics.co Statistics 2016] e r-bloggers.com [R-Bloggers 2015].
1.3 Contenuto della tesi
Il lavoro svolto all'interno di Intarget si è focalizzato sullo sviluppo di una soluzione in grado di risolvere le questioni precedentemente descritte, esse risultano essere delle esemplari problematiche di Business Intelligence. Di seguito viene presentata l'organizzazione della tesi indicando, per ogni capitolo, il proprio contenuto.
- Il Capitolo 2 è una panoramica sul Web advertising, la descrizione del settore e delle terminologie, con un particolare riferimento alle piattaforme utilizzate per il monitoraggio delle campagne e alla gestione dei processi aziendali all’interno dell’agenzia Intarget.
- Nel Capitolo 3 viene illustrata la soluzione di Business Intelligence progettata e realizzata. Tale proposta è stata presentata fin dai primi giorni all’head Of Advertising in Intarget ed ha costituito il faro dell’intero lavoro di tesi svolto. Infatti i capitoli successivi sono composti dalle fasi che hanno portato alla sua realizzazione.
- Nel Capitolo 4 si presenta la fase di progettazione del data warehouse per il monitoraggio delle campagne awareness. L’analisi dei requisiti, la progettazione concettuale, la progettazione logica ed infine la realizzazione fisica del database attraverso tecnologie leader del mercato.
- Nel Capitolo 5 viene descritto lo sviluppo delle procedure di estrazione, trasformazione e caricamento dei dati, in inglese Extract Transform Load (ETL). Si delineano i punti salienti della implementazione, ponendo l'attenzione sulla descrizione delle problematiche riscontrate e di come queste siano state risolte. Infine una volta popolato il data warehouse si è proceduto alla
- Nel Capitolo 6 viene affrontata la fase di presentazione al cliente dei risultati di campagna attraverso un tool di Data Visualization in grado di interfacciarsi all’OLAP System e di mostrare attraverso una dashboard in modo immediato, dinamico ed accattivante la narrazione della campagna. Sarà presente un breve riferimento al feedback ricevuto da parte del cliente e dai vertici dell’agenzia.
- Nel Capitolo 7 lo sguardo viene rivolto al futuro ed alle tematiche di supporto alla pianificazione di nuove campagne. Dopo aver immagazzinato all’interno del data warehouse i dati relativi alle altre campagne awareness è stato realizzato un modello predittivo attraverso tecniche di Data Mining. In particolare è stato realizzato un modello di regressione logistica in grado di fornire dati certi fattori, la probabilità di atterraggio su una pagina prodotto da parte dell’utente.
La tesi termina con la descrizione degli obiettivi raggiunti, le conclusioni derivate dall'esito del lavoro svolto ed alcuni accenni sulle proposte per ulteriori sviluppi futuri.
Capitolo 2
WEB ADVERTISING
Il presente capitolo ha inizio con una breve introduzione al web advertising, prosegue illustrando quali piattaforme e tecnologie vengono utilizzate per la gestione di una campagna, descrivendo le metriche ed i KPI principali necessari per analizzare il suo andamento.
Nel corso del capitolo verrà fatto riferimento alla realtà di Intarget alle tecnologie utilizzate ed ai processi aziendali necessari per la creazione, il monitoraggio e la narrazione di una campagna di web advertising.
2.1 Introduzione
Il web advertising è un canale di comunicazione che sempre più aziende utilizzano per incrementare il numero dei propri clienti e promuovere i prodotti o i servizi offerti, sfruttando le enormi potenzialità offerte da Internet.
Il digital advertising si suddivide essenzialmente in display advertising (pubblicità su portali, social network, e-shopping) e search advertising (motori di ricerca).
Le campagne di tipo display vengono utilizzate spesso per aumentare la brand awareness, permettono infatti di raggiungere molti utenti e fanno leva sull’impatto visivo della comunicazione.
Spesso le campagne prevedono il remarketing: agli utenti che hanno già visitato il sito cliente o semplicemente visualizzato un banner viene riproposto il messaggio pubblicitario inducendoli a visitare a conoscere meglio il marchio.
Come già indicato il mio progetto fa riferimento al tracciamento ed ai risultati di campagne di tipo awareness.
2.2 Trafficking e Placement
Uno dei maggiori vantaggi del Web Advertising è la possibilità di raggiungere uno specifico target di utenti a cui rivolgere un messaggio di marketing personalizzato ed efficace. Un altro dei vantaggi principali della pubblicità su Internet è quello della tracciabilità dei risultati, ovvero la possibilità di verificare quasi in tempo reale l’effetto che essa ha sul pubblico.
Questo avviene grazie agli Ad Server che sono in grado di ospitare una campagna e tracciarla attraverso un unico strumento, anche se essa è erogata su più piattaforme competitor tra loro ed in diversi paesi.
Per posizionamento (Placement) si intende il luogo, il pubblico e la modalità con cui la creatività (banner) sarà visualizzata, quindi ad esempio in quale paese, sito, dispositivo, dimensione ecc. Esistono differenti soggetti che forniscono la possibilità di acquistare posizionamenti, tra questi: - I Publisher tradizionali: siti indipendenti aventi un numero considerevole di visitatori, essi
vendano i propri spazi direttamente all’agenzia solitamente attraverso una tipologia di acquisto detta Reservation Tradizionale (RT), in cui vengono stabiliti un prezzo ed un numero di booked impressions garantite.
- I Social Network (Facebook, Instagram): vendano i propri spazi attraverso una piattaforma proprietaria tramite un acquisto in RT oppure in Real Time Bidding (RTB) un metodo di acquisto che consente di intercettare e mostrare in tempo reale annunci pubblicitari a un target mirato e selezionato in specifici posizionamenti.
- YouTube, AdWords: offrono la possibilità di inserire i propri banner, annunci testuali di ricerca, video attraverso una piattaforma con modalità di acquisto di tipo RTB.
- DoubleClick Bid Manager (DBM): tale servizio è parte integrante dello stack Double Click e permette attraverso acquisti solitamente di tipo RTB l’acquisizione di spazi pubblicitari sui maggiori publisher internazionali.
L’insieme dei network sopra descritti sono tracciati attraverso Doubleclick Campaign Manager
(DCM) che ospita le creatività e fornisce le metriche riguardanti le prestazioni delle campagne.
In Figura 2.1 viene mostrato il funzionamento generale e semplificato di un AdServer, l’operazione illustrata ha un tempo di esecuzione dell’ordine dei millisecondi.
Le operazioni illustrate sono le seguenti:
1. L’utente approda sulla pagina del publisher
2. Il sito richiede all'Ad Server, l’advertisement da mostrare all’utente
3. L'Ad Server determina quale advertisement inviare al sito, il quale una volta ricevuto procede al caricamento in pagina
4. L’utente visualizza l’advertisement
Uno dei principali vantaggi dell’utilizzo di un Ad Server è la possibilità di ottenere i dati di performance relativi ad una campagna da un'unica fonte e di avere un unico modello di attribuzione delle conversioni.
Un modello di attribuzione è la regola o l'insieme di regole che determina il modo in cui le conversioni vengono attribuite ai media coinvolti nell’esperienza di navigazione di un utente.
Ad esempio un utente A potrebbe visualizzare un banner la prima volta sul sito Repubblica, dopo qualche giorno visualizzarlo sul sito Corriere e farvi click, in questo caso occorre determinare a quale publisher è ragionevole attribuire la conversione. Stabilire in unico luogo quale regola utilizzare per l’attribuzione di conversione è fondamentale per la coerenza dei dati.
Da notare invece come i dettagli relativi ai costi degli acquisti sono ottenibili esclusivamente dal network che ha fornito il servizio, ciò ha costituito una delle maggiori problematiche in fase di integrazione dei dati.
Il Web Trafficker è colui che si occupa di creare i tracciamenti, monitorare e fornire i report relativi alle campagne ospitate dall’Ad Server. Durante il tirocinio Intarget mi ha formato ed insegnato ad utilizzare DCM in sicurezza ed autonomia. Fin dai primi giorni sono stato affiancato ad un web trafficker esperto che mi ha illustrato teoricamente e nella pratica il funzionamento di DCM. Nei mesi di svolgimento del progetto ho creato, tracciato e monitorato un buon numero di campagne, ciò mi ha permesso di conoscere in profondità i processi da cui derivano le fonti dati utilizzate per lo svolgimento del progetto.
2.3 Terminologia del Web Advertising
Di seguito vengono riportati i principali termini utilizzati nel mondo del web advertising. La loro conoscenza risulta indispensabile per una miglior comprensione del progetto di tesi svolto.
Impression: indica il numero di volte che un banner viene visualizzato. Ad essere precisi, in realtà
indica il numero di volte che un banner viene scaricato sul dispositivo dell’utente, non viene garantito il fatto che sia stato caricato in un luogo visibile della pagina.
Active View: metrica di misurazione introdotta da Google, volta ad identificare le reali possibilità
che un ad sia visualizzato da parte dell’utente. Un banner è considerato visualizzato se risulta visibile almeno al 50% delle sue dimensioni in pixel per almeno 1 secondo.
eseguire l'autenticazione degli utenti, la tracciatura di sessioni di navigazione ecc. Da notare come i cookie siano associati al web client utilizzato e come essi siano soggetti ad una scadenza temporale, tali fattori rendono il cookie non direttamente associabile al singolo utente.
Reach misura il numero di visitatori che possono essere considerati come individui unici in un certo
lasso di tempo. Tale metrica in DCM viene misurata attraverso l’utilizzo dei cookie, altre piattaforme come Nielsen, riescono ad esser maggiormente precise sfruttando le informazioni che gli utenti inseriscono liberamente sui social network.
Conversion: misura il numero di conversioni ottenute. Per conversioni si intendono azioni che
l’utente effettua dopo l’atterraggio sulla pagina di destinazione. Vengono rilevate sul sito cliente attraverso tag inseriti all’interno della pagina web, nel mondo Double Click essi sono detti Floodlight. Le azioni tracciate possono essere ad esempio atterraggio alla pagina, richiesta di informazioni, acquisto, visione di prodotti ecc.
2.4 Il processo di tracking in Intarget
In questa sezione illustrerò brevemente il processo di tracciamento (tracking) di una generica campagna di web advertising svolta in agenzia.
Per una più facile comprensione del processo, la seguente tabella descrive le funzioni ed i compiti dei soggetti coinvolti nel processo.
Funzione Compiti
Media Planner
Studiare la migliore distribuzione degli investimenti pubblicitari sui differenti canali di comunicazione web. Pianificare gli spazi, valutando come, dove, quando e con quali budget intervenire in base al prodotto, al target ed al messaggio oggetto della campagna pubblicitaria.
Web Trafficker
Provvedere al tracking delle campagne ospitate sull’AdServer realizzando tag in grado di tracciare i dati statistici di ogni placement. Provvedere alla reportistica, integrazione ed al calcolo dei costi dei servizi di tracking erogati.
Tag Specialist
Studiare ed implementare il posizionamento di tag all’interno del sito cliente in grado di monitorare azioni specifiche da parte degli utenti.
Factory Ideare e realizzare le creatività grafiche, cioè i banner che saranno ospitati sull’AdServer
Tabella 2.1 Funzioni e compiti nel processo di Tracking
Il rispetto della procedura descritta è fondamentale per far sì che le date di partenza delle campagne concordate con il cliente siano rispettate, di seguito la descrizione sintetica del processo:
1) Realizzazione del Tagging Plan
Il Tagging Plan è un documento che stabilisce quali azioni di conversione dell’utente sul sito del cliente devono essere tracciate in base ai KPI di campagna. Ciò avviene attraverso l’implementazione di tag, detti floodlight, all’interno del sito del cliente. I floodlight tracceranno
DCM. Oltre a ciò il cookie dell’utente saranno mantenuti e riutilizzabili come audience per un certo periodo di tempo per attività di remarketing.
o Richiesta: Media Planner
o Owner: Planner/ Trafficker/ Tag Specialist
o Tempi: 1 settimana prima della partenza delle attività 2) Realizzazione Media Plan
Il Media Plan è un documento in cui sono descritti schematicamente gli spazi pubblicitari acquistati con riferimento al budget, alle stime di performance ed altre informazioni indispensabili al tracciamento, di seguito l’elenco completo:
- Publisher (es. Repubblica, DBM)
- Nome del Placement (es. HP Repubblica) - Formato (es.300x600)
- Budget
- Tipo di Acquisto (Cpm, Cpc, Cpv) - Stima Impression (acquisto Cpm o Cpv) - Stima Click (acquisto Cpc)
- Tipo Adserving (Redirect, impression+clic, clic) - Date d’inizio e fine
o Owner: Media Planner
o Tempi: 2 settimane prima della partenza della campagna 3) Stima dei costi DCM
Il media plan viene arricchito affiancando ad ogni posizionamento una stima dei costi del suo tracciamento, basata sulle stime di performance e su cosa è possibile tracciare (Impression e/o click)
o Owner: Trafficker
o Tempi: una volta che il media plan è stato completato 4) Specifiche tecniche formati
In un documento apposito da consegnare a Factory, vengono descritte le specifiche tecniche che le creatività devono rispettare, in base alla piattaforma su cui devono essere caricate.
o Owner: Trafficker
o Tempi: una volta che il media plan è stato completato 5) Consegna creatività
Il trafficker deve ricevere le creatività relative alla campagna, ciò è indispensabile se queste devono essere ospitate direttamente dall’AdServer.
o Owner --> Media Planner o Factory
o Modalità --> via mail, con specificata la rotazione e l'associazione se ci sono più creatività o Tempi --> 5 giorni prima della partenza della campagna
6) Realizzazione Trafficking sheet
La trafficking sheet è un documento in un cui per ogni riga viene specificato il nome del placement da inserire all’interno dell’Ad Server, le informazioni necessarie vengono ottenute dal Media Plan.
Questa fase è fondamentale infatti la struttura del naming è ciò che permetterà successivamente di dimensionare le misure e di poter navigare le statistiche di campagna.
o Owner: Trafficker
o Tempi: una volta che il media plan è stato completato 7) Comunicazione UTM e Landing Page
La trafficking sheet viene arricchita con delle stringe di codice UTM. Questo codice è necessario per avere un’integrazione con Google Anlaytics e deve essere inserito al momento della creazione dei placement nell’AdServer. Inoltre viene inserita la URL della pagina di destinazione su cui un utente deve atterrare una volta fatto click su un banner.
o Owner --> Planner
o Modalità --> da compilare nella trafficking sheet creata dal trafficker o Tempi --> 5 giorni prima della partenza della campagna
8) Eventuali Modifiche del piano o delle landing page
Non dovrebbe accadere ma non è raro che in prossimità dell’inizio della campagna o durante la sua erogazione, il cliente desideri modificare il proprio piano media. Questa informazione in possesso del Media Planner deve essere comunicata tempestivamente al Trafficker così che possa apportare le opportune modifiche.
o Owner --> Planner
Capitolo 3
LA SOLUZIONE DI BUSINESS
INTELLIGENCE
Il seguente capitolo illustra la soluzione di Business Intelligence proposta all’agenzia Intarget. Tale soluzione è stata ideata basandosi sui requisiti di monitoraggio e pianificazione dell’agenzia e costituisce il fulcro del mio progetto di tesi. La soluzione presentata è frutto delle conoscenze apprese durante i miei anni di studio, dalla contemporanea breve esperienza da sviluppatore e dal confronto con il relatore ed i vertici dell’agenzia.
3.1 Descrizione della situazione attuale
Intarget da circa un anno propone alla propria clientela la gestione degli spazi pubblicitari sul web attraverso l’Ad Server DoubleClick di Google. Tale attività comporta la gestione ed il monitoraggio di un volume significativo di dati. L’agenzia alla fine di ogni campagna provvede a scaricare da DCM i dati relativi al tracciamento delle campagne e ad integrarli con i dati di acquisto dei relativi placement ottenuti da differenti piattaforme. Questo lavoro viene effettuato “manualmente” attraverso la creazione di un unico foglio di calcolo in cui vengono registrate migliaia di righe relative a ciascun placement copiando ed incollando i valori dai diversi report d’origine.
Tra i limiti maggiormente evidenti di tale soluzione possiamo elencare:
- Un limite di tipo tecnologico dato dal fatto che un foglio di calcolo non è strutturato per mantenere milioni di righe
- Il tempo necessario per l’operazione di inserimento dei dati dalle diverse piattaforme
- L’alienazione umana di chi deve effettuare l’inserimento dei dati all’interno del foglio di calcolo - L’alto rischio di inaffidabilità ed inconsistenza nel tempo
- Lo scarso impatto ed i limiti estetici - Scarsa affidabilità, dinamicità e scalabilità
Tale attività risulta però vitale ai fini aziendali in quanto permette di monitorare le campagne in corso, di narrare i risultati ottenuti e di pianificare le nuove attività.
In un settore caratterizzato da un’elevata dinamicità e concorrenza, riuscire da parte dell’agenzia a proporre ai propri clienti un servizio di alta qualità che si differenzi rispetto ai propri competitor costituisce il più genuino dei vantaggi competitivi.
3.2 La soluzione proposta
Il problema sopra descritto risulta essere un esemplare problema di Business Intelligence.
La Business intelligence è infatti il processo di trasformazione di dati ed informazioni in conoscenza utile ai fini decisionali da parte dell’azienda.
Nei primi incontri con l’agenzia è stata quindi presentata la piramide della Business Intelligence illustrandone i livelli e le opportunità di cui Intarget potrebbe giovare nel realizzare tale progetto sia per i suoi processi interni sia per i rapporti con la clientela.
Il progetto di tesi percorre e scala l’intera piramide della Business Intelligence, mostrata in Figura 3.1. Infatti partendo dalla raccolta dei dati provenienti dalle piattaforme di advertising, questi vengono puliti ed integrati da un servizio ETL che provvede alla memorizzazione in un data
warehouse, a cui si interfaccia un OLAP System. Successivamente sarà possibile navigare i dati
attraverso servizi di Data Visulization in grado tramite una narrazione dinamica ed accattivante di illustrare con efficacia i risultati di campagna. Infine attraverso tecniche di data mining sarà possibile supportare la pianificazione delle nuove campagne prendendo decisioni non basate esclusivamente sull’esperienza umana ma su solidi metodi statistici.
In Figura 3.2 è possibile osservare una generica architettura di data warehousing cioè il processo attraverso cui i dati proveniente da differenti fonti vengono organizzati in un data warehouse (DW). I dati di origine sono costituiti spesso da data base operazionali (OLTP), essi vengono estratti, trasformati e caricati all’interno del DW attraverso l’utilizzo di un’applicazione ETL (Extract Transform Load). Una volta che i dati sono stati immagazzinati all’interno del DW, un OLAP System permette di svolgere efficacemente analisi multidimensionali. Successivamente è possibile estrarre i dati immagazzinati ed applicare su di essi tecniche di Data Mining, realizzare report statici oppure dashboard utilizzando tool di Data Visualizzation.
Figura 3.2 Data Warehousing Architecture
Partendo dall’architettura sopra descritta è stata studiata una possibile soluzione in riferimento al caso Intarget. La valutazione sulle tecnologie da impiegare si è basata comparando i costi ed benefici di ogni tecnologia, mettendo a confronto le possibilità presenti sul mercato con le esigenze ed i requisiti del progetto.
La scelta è infine ricaduta sull’utilizzo di buona parte dello stack Microsoft: - Data Warehouse: SQL Server 2017
- OLAP System: SQL Server Analysis Service (SSAS) - Data Visualization: Microsoft Power BI
Il modulo ETL è costituito da un’applicazione scritta in linguaggio C# in ambiente .NET. Tale scelta è dovuta principalmente alla possibilità di utilizzare l’Object-Relational Mapping (ORM) Linq, in grado di interfacciarsi facilmente a SQL Server 2017.
Figura 3.3 Data Warehousing Architecture for Intarget
Le fonti da cui vengono ottenuti i dati di origine sono le seguenti:
- DoubleClick Campaign Manager (DCM): costituisce la fonte principale da cui si ottengano i dati statistici relativi ai tracciamenti delle campagne.
- DoubleClick Bid Manager (DBM): fonte da cui si ottengo dati di costo e statistici - Facebook (FB): fonte da cui si ottengo dati di costo
- Youtube(AdW): fonte da cui si ottengono dati di costo e videoview
- Reservation Tradizionale (RT): documento in cui sono presenti i dettagli sulle reservation tradizionali.
Per le prime quattro fonti di dati è possibile ottenere i dati in maniera automatizzata, attraverso l’utilizzo di quattro differenti Application Programming Interface (API), integrabili all’interno dell’applicazione ETL. Una volta che i dati saranno immagazzinati all’interno del DW, questi potranno essere:
- Analizzati utilizzando tecniche di Data Mining, attraverso l’utilizzo di R o differenti tool di data mining
- Visualizzati attraverso report, realizzati utilizzando tabelle pivot Excel
- Esplorati dinamicamente attraverso dashboard, realizzate utilizzando il servizio Power BI Una volta presentata tale panoramica di progetto all’Head of Advertising ed al relatore di tesi entrambi hanno convenuto che l’obiettivo principale fosse riuscire ad arrivare il più celermente possibile alla fase di navigazione attraverso il servizio di Data Visualization. Infatti arrivare rapidamente ad un risultato tangibile e concreto avrebbe permesso di ottenere l’attenzione dei vertici dell’agenzia permettendo futuri sviluppi al progetto.Per permettere ciò è stato necessario semplificare la realizzazione dell’applicazione ETL posticipando l’utilizzo delle API. Le fonti di dati saranno in realtà costituite da file facilmente scaricabili attraverso ciascuna piattaforma, il codice leggerà, pulirà ed integrerà i dati provvedendo al loro caricamento sul DW.
Capitolo 4
PROGETTAZIONE DEL DATA
WAREHOUSE
Nel seguente capitolo viene presentata la progettazione del data warehouse per il monitoraggio delle campagne awareness. Nel primo breve paragrafo introduttivo viene descritto cosa è un data warehouse, le sue caratteristiche ed in generale la sua fase di progettazione. Verranno successivamente illustrate tutte le fasi di design: l’analisi dei requisiti, la progettazione concettuale, la progettazione logica ed infine la realizzazione fisica del database attraverso tecnologie Microsoft. Il riferimento bibliografico di questa fase è costituito principalmente dal volume Albano A., Decision Support Databases Essentials oltre alla documentazione ufficiale Microsoft relativa alle tecnologie utilizzate.
4.1 Cos'è un data warehouse
Un data warehouse è un database che costituisce le fondamenta di un sistema di supporto alle decisioni, cioè un sistema in grado di fornire informazioni chiare agli utenti, in modo che essi possano analizzare a differenti livelli di dettaglio una situazione e prendere facilmente le opportune decisioni sulle azioni da intraprendere. Un data warehouse è una raccolta di dati storici integrati, non volatile, organizzata per soggetti e finalizzata al recupero di informazioni di supporto ai processi decisionali. Esso presenta le seguenti caratteristiche:
- Orientato ai soggetti di interesse: i dati conservati in un data warehouse sono organizzati per tema, piuttosto che per applicazioni, come accade per i database operazionali. Questi ultimi infatti hanno lo scopo di ottimizzare l'elaborazione delle transazioni.
- Integrato: un data warehouse colleziona informazioni provenienti da diverse fonti e le integra tra loro mediante l'esecuzione di un dispendioso e ben studiato processo di caricamento e trasformazione dei dati che provenendo da differenti sorgenti potrebbero essere rappresentati in formati differenti o potrebbero contenere errori sintattici o semantici.
- Tempificato: mentre i database operazionali conservano solo i dati più recenti che descrivono una tipica entità, un data warehouse conserva dati storici con l'obiettivo di poter analizzare i cambiamenti nel tempo o il trend di un particolare evento.
- Statico: la modalità di interrogazione di un data warehouse è mirata all'estrazione di dati, non alla modifica dei dati conservati. Ciò implica che i dati siano consistenti nel tempo e periodicamente aggiornati con l'aggiunta dei dati più recenti.
- Supporto alle decisioni: dato che l'obiettivo ultimo è l'estrazione di informazioni significative ai fini decisionali, il design deve essere specificatamente realizzato al fine di ottenere la risposta alle query ritenute di interesse dagli utenti decisori finali.
I dati all’interno di un data warehouse sono strutturati tenendo presente il modo in cui gli utenti li utilizzano per il conseguimento dei propri scopi. Gli utenti hanno la necessità di analizzare collezioni di fatti che riguardano specifici eventi aziendali. Ogni fatto è caratterizzato da un insieme di misure che sono costituite da attributi numerici riguardanti una prestazione di un fenomeno aziendale. Gli utenti sono interessati ad analizzare le misure dei fatti secondo prospettive differenti di analisi attraverso diverse dimensioni. Le dimensioni forniscono un contesto al fatto supportando la possibilità di cogliere nuove opportunità. Gli utenti analizzano i fatti aziendali sulla base di una serie di indicatori (KPI), variabili quantitative calcolate con aggregazioni delle misure.
Seguendo il metodo riportato in [Albano 16] per la progettazione del data warehouse si cerca di procedere considerando sia i requisiti di analisi, cioè ciò che i clienti dell’agenzia ed i Media Planner intendono analizzare, sia i dati a disposizione ottenibili dalle diverse piattaforme di tracciamento. Illustro di seguito le fasi di progetto che saranno poi descritte maggiormente facendo riferimento al caso in esame.
- Analisi dei requisiti: si raccolgono e si definiscono con i richiedenti i requisiti delle analisi dei dati, di supporto alle decisioni, che si desiderano eseguire.
- Progettazione concettuale: viene definito un modello concettuale dei dati da analizzare. - Progettazione logica: il modello concettuale viene tradotto in un modello logico
- Progettazione fisica. Il modello logico viene configurato e realizzato su un database fisico. In questa fase possono essere definite strutture di memorizzazione (indici e viste materializzate) per agevolare le operazioni di analisi dei dati.
4.2 L’Analisi dei requisiti
La fase di analisi dei requisiti si suddivide in due sotto fasi principali: la Raccolta dei requisiti e la Specifica dei requisiti.
La prima fase riguarda la descrizione in linguaggio naturale dei requisiti, questi sono già stati in realtà trattati rapidamente nei capitoli precedenti. La seconda fase riporta i requisiti dell’analisi dei dati da parte degli utenti finali in maniera sintetica così che ciò possa essere utilizzato come base di partenza per la fase di progettazione concettuale.
Nel caso in esame la preesistenza di un semplice sistema integrato dei dati memorizzati in un unico foglio di calcolo in cui erano già strutturate dimensioni e misure, ha costituito una base da cui partire
Dal lato delle fonti invece, esse sono costituite principalmente da piattaforme attraverso cui le campagne vengono caricate e gestite. In particolare DCM come già descritto traccia le prestazioni relative ad un placement e fornisce tali dati attraverso un’interfaccia di reportistica. Tale sistema di reportistica si basa in realtà su fatti, dimensioni, metriche ed è evidente come esso si appoggi su un DW.
Da notare come le dimensioni già utilizzate nel foglio di calcolo preesiste sono derivanti dal naming assegnato ad ogni singolo placement. Ogni placement presenta infatti una struttura già precedentemente stabilita in agenzia, da cui è possibile ottenere tutte le dimensioni. Ciò ha permesso di procedere abbastanza celermente in questa fase attraverso incontri e confronti con l’Head of Advertising ed il Traffic Manager riguardanti sia le esigenze di analisi finali sia la possibilità fornite dalle differenti fonti dati. Tali considerazioni sono sinteticamente riportate nelle seguenti tabelle che costituiscono la Specifica dei requisiti:
- Tabella della specifica dei requisiti di analisi: in cui si formalizzano le analisi che si realizzeranno evidenziando le dimensioni, le misure e le metriche coinvolte.
- Tabella del fatto: in cui si descrive il fatto da modellare nel Data Warehouse. - Tabella delle dimensioni: in cui si descrivono le dimensioni di analisi del fatto.
- Tabella degli attributi dimensionali: in cui si descrivono gli attributi di ogni dimensione, è quindi presente una tabella per ogni dimensione.
- Tabella delle gerarchie dimensionali: in cui si descrivono le gerarchie delle tabelle dimensionali.
- Tabella delle dimensioni che cambiano: in cui si specifica quale strategia viene adottata per le slowly changing dimensions, cioè la politica di aggiornamento dei valori all’interno delle tabelle delle dimensioni in occasione di modifiche di contesto.
- Tabella delle misure del fatto: in cui si descrivono le misure del fatto.
Vengono ora riportate le tabelle sopra descritte relative al caso trattato. Tali tabelle sono state ricavate dai report già utilizzati dall’agenzia relativi ad analisi interne o presentazioni ai clienti. Di seguito si evidenziano le dimensioni, gli attributi e le misure utilizzate, in ogni requisito di analisi relativo al tracciamento dei placement.
N Requisito Dimensioni Misure Aggregazioni
1 Per la campagna x, il costo, le impression, i click, elencati per Sito
Campagna, Publisher
Cost, Impression, Click
Somma 2 Per il paese x, le video view 100%, il costo, elencati
per AdNetwork
Campagna, Publisher
VideoView100, Cost Somma 3 Per il formato x, il numero di conversioni,
impression, costo, elencati per device
Campagna, Sito, Advertisement
Conversion, Impression
Somma Tabella 4.1 Tabella della specifica dei requisiti di analisi
I report utilizzati dall’agenzia in passato non presentavano la dimensione temporale. Attraverso il confronto con l’Head Of Advertising abbiamo concordato come questa nuova dimensione risultasse utile per applicazioni future in grado così di cogliere gli andamenti temporali, è stato così deciso di aggiungerla.
Il fatto, la cui descrizione è mostrata in Tabella 4.2, è quindi costituito dall’evento giornaliero di tracciamento di un placement, questo livello di granularità permette di effettuare analisi ad un livello di dettaglio considerevole.
Descrizione Dimensioni Misure
Riga di tracciamento del servizio DCM riguardante un placement registrato per cui sono presenti dei dati statistici in riferimento ad una specifica giornata.
Campaign, Publisher, Advertisement, Date
Cost, Impression, Click, Conversion, VideoView ecc.
Tabella 4.2 Placement Tracking Fact
In Tabella 4.3 sono mostrate le dimensioni relative al fatto individuato.
Nome Descrizione Granularità
Campaign La campagna di riferimento, il paese, il cliente il settore di riferimento ecc La campagna in un dato paese per un cliente Publisher Il sito che ospita il placement, l’Adnetwork a cui appartiene, il metodo di
acquisto, la categoria
L’acquisto di uno spazio Advertisement Informazioni relative all’Ad le sue dimensioni, il device di rifermento, il sesso
di riferimento per la creatività ecc
L’ad associato al placement Date Dimensione temporale che identifica il giorno della registrazione delle
performance
Un giorno
Tabella 4.3 Descrizione delle Dimensioni
Per ogni dimensione è necessario avere degli attributi adeguati, attraverso i quali sia possibile aggregare i fatti ed ottenere valori significativi ed utili ai fini decisionali. Di seguito vengono descritti gli attributi per le dimensioni Campaign, Publisher, Advertisement.
Attributo Descrizione
Country Il paese di riferimento della campagna indicato in codice ISO, esempio: IT, UK, US ecc
Client Il nome del cliente esempio: Tagrutato
ClientSector Il settore di riferimento del cliente ad esempio: Faschion, Trasporti ecc.
CampaignName Il nome associato alla campagna
Tabella 4.4 Attributi Dimensione Campaign
Attributo Descrizione
Category Categoria di appartenenza del publisher: News, Faschion ecc Site Il sito su cui viene ospitato il placement esempio: Corriere
AdNetwork Spesso l’acquisto di spazio web non riguarda un sito ma un insieme di siti. Esempio: DBM, Condenast ecc
Buying La modalità di acquisto dello spazio: RTB, RT, PG ecc
Attributo Descrizione
BannerSize La dimensione del banner es. 728x90
Gender Il sesso a cui è rivolto il banner ad esempio potrebbe contenere una modella e quindi essere rivolto ad un pubblico femminile
Device Dispositivo su cui viene visualizzato il banner, es Desktop o Mobile
MediaType La tipologia di media, esempio Social, Display
PlacementSite Campo che dettaglia il posizionamento esatto del banner ad esempio HP indica che il banner è nell’HomePage
Tabella 4.6 Attributi Dimensione Advertiser
Le gerarchie dimensionali
Vengono ora descritte le relazioni fra gli attributi di una dimensione.
Dimensione Gerarchia Tipo di gerarichia
Date Day -> Month -> Year Bilanciata
Date Week -> Year Bilanciata
Campaign Client -> ClientSector Bilanciata
Tabella 4.7
Una gerarchia è detta bilanciata quando i suoi livelli sono in numero predefinito ed i valori che ne fanno parte sono sempre definiti.
In generale i valori degli attributi delle dimensioni possono cambiare nel tempo. Per ogni attributo soggetto a cambiamenti, occorre stabilire una strategia in fase di progettazione. In [Albano 16] vengono presentate quattro possibili strategie:
- Tipo 1, Riscrittura della storia: il valore di un attributo dimensionale che cambia viene trattato come un valore errato da sostituire con il nuovo valore. Questa risulta essere la soluzione più semplice che comporta però la perdita della storia.
- Tipo 2, Conservazione della storia): si desidera mantenere la storia dei valori. Un nuovo record viene inserito nella tabella delle dimensioni con una differente surrogate key. Questa rappresenta la soluzione più comune che va discapito dell'aumento dei dati della dimensione.
- Tipo 3, Conservazione di una o più versioni della storia: si vuole sia la storia dei valori che la data in cui avviene il cambiamento.
- Tipo 4, Dimensioni che cambiano frequentemente: gli attributi cambiano frequentemente e non vanno trattati con una delle soluzioni precedenti
Nel caso specifico nessun attributo è in generale soggetto a cambiamenti, infatti essi fotografano una determinata situazione non soggetta a mutamenti nel tempo. I valori degli attributi potrebbero cambiare solo a causa di un errato inserimento iniziale, in questo caso il valore verrebbe sostituito con quello nuovo non mantenendo la storia, quindi per tutti gli attributi sarà adottata una strategia di tipo 1.
Le misure
Le misure in esame sono quelle relative alla misurazione delle statistiche relative al tracciamento di un placement. In particolare la misurazione fa riferimento alle performance di un placement in un dato giorno. Le misure sono tutte additive, cioè è sempre possibile e risulta significativo aggregare i fatti e sommare le relative misure. Le misure sono costituite da tipici valori statistici ottenuti dalle relative piattaforme, non mi dilungherò nella loro descrizione essendo la conoscenza del loro significato non necessaria in questa fase.
La misura reach
La reach è una misura relativa al tracciamento di un placement che presenta per sua natura alcune particolarità. Essa misura il numero di cookie unici raggiunti ed è un valore di performance molto importante, esso presenta le seguenti caratteristiche:
- Non è additiva: infatti sommare la reach del paese x con la reach del paese y, non mi fornisce la reach dei due paesi. Infatti un utente raggiunto da entrambe le campagne per i due paesi, sarebbe conteggiato due volte. Notare che risulta non additiva qualunque sia la dimensione di riferimento considerata.
- DCM calcola la reach con riferimento a 42 giorni. Cioè il cookie di un utente raggiunto il primo giorno di campagna è considerato unico nella reach per i primi 42 giorni, al 43° giorno esso risulterà come un nuovo cookie. Da notare che una campagna può durare più di 42 giorni. - Ha una differente granularità rispetto al PlacmentTrackingFact. Infatti DCM fornisce il
calcolo della reach al massimo a livello di sito, non fornendo quindi tale dato alla granularità dai noi definita a livello di placement.
Di seguito si evidenziano le dimensioni, gli attributi e le misure utilizzate in ogni requisito di analisi relativo al tracciamento della misura reach.
N Requisito Dimensioni Misure Aggregazioni
1 Per la il sito x, l’impression reach per giorno Date, Publisher SiteImpressionReach 2 Dato il giorno x, il total reach per paese Campagna, Date CountryTotalReach
Tabella 4.8
Come si può notare in realtà la reach non è unica si differenzia in: - Impression reach
- Click Reach - Total Reach
Data la sua natura non additiva, per conoscere la reach a differenti livelli di dettaglio occorre ricorrere a differenti interrogazioni all’interfaccia di DCM. Ad esempio per conoscere la reach a livello di paese occorre impostare un apposito report e non sommare i dati relativi ai singoli siti per lo specifico paese. Date tutte le peculiarità della misura è stato deciso di realizzare un apposito fatto.
In realtà sarebbe necessario un fatto per ogni livello di dettaglio desiderato, ma di seguito riporterò il solo fatto reach a livello di sito.
Descrizione Dimensioni Misure
Riga di tracciamento del servizio DCM riguardante un sito registrato per cui sono presenti dei dati di rech
Campaign, Publisher, Date SiteImpressionReach, SiteClickReach, SiteTotalReach Tabella 4.9
Come è possibile osservare le dimensioni del fatto SiteReach sono le medesime del fatto PlacementTracking, tranne che per la dimensione Advertisement che non può essere presente data la natura della misura reach.
4.3 Progettazione Concettuale
I fatti, le dimensioni, gli attributi e le misure descritte nelle analisi dei dati suggeriscono come possibili schemi concettuali iniziali quelli mostrati di seguito.
Figura 4.2 SchemaConcettuale - TrackingSiteReachFact
Nella seguente tabella sono elencate le dimensioni individuate indicando in quali fatti vengono utilizzati, evidenziando quali informazioni sono in comune tra i due fatti. Questa osservazione permetterà di realizzare una rappresentazione unica di tali dimensioni così che esse possano essere condivise e possano essere realizzare analisi “cross-fact”.
Dimensione PlacementTrackingFact TrackingSiteReachFact
Campaign x x
Publisher x x
Advertisement
Date x x
Tabella 4.10
Da notare come questa fase sia stata facilitata dalla possibilità di avere già a livello concettuale un primitivo sistema di integrazione dati presente in agenzia. Non è stato infatti difficile capire quali fossero le misure e le dimensioni ritenute interessanti e quali quelle disponibili dato che questa fase era già stata in parte eseguita precedentemente attraverso l’inserimento dei dati all’interno del foglio di calcolo.
4.4 Progettazione logica
In questa fase si passa dagli schemi concettuali dei data mart allo schema relazionale del data warehouse.
Per ogni tabella dei fatti viene creata una tabella relazionale, con una chiave surrogata e le misure relative come attributi. Successivamente viene creata una tabella relazionale per ogni dimensione presente nello schema concettuale.
Anche queste tabelle contengono una chiave primaria surrogata e tutti gli attributi presenti nella rispettiva dimensione. Le dimensioni in comune sono rappresentate da un'unica tabella, vengono quindi relazionati fatti e dimensioni attraverso relazioni 1:N.
Nella figura 4.3, viene mostrato lo schema logico ottenuto.
Un attento lettore avrà osservato la presenza della tabella NielsenFact. Questa tabella è stata aggiunta in prossimità di un’importante riunione di resoconto campagna con il cliente. Era necessario infatti correlare tra loro i dati ottenuti dalle precedenti fonti con quelli acquisiti dalla piattaforma Nielsen. Per questione di sintesi in questo capitolo tale fatto non sarà descritto, per maggiori dettagli il lettore faccia riferimento al capitolo 6 in cui vengono descritti i dettagli dell’incontro ed i feedback ricevuti.
4.5 Progettazione Fisica
Il Data Warehouse è stato fisicamente realizzato come un database Microsoft SQL SERVER 2017, attraverso l’utilizzo di SQL Server Management Studio. Una volta realizzato il database, esso è stato utilizzato come origine dati per la realizzazione di un On-Line Analytical Processing (OLAP) System attraverso l’utilizzo di SQL SERVER ANALYSIS SERVICE (SSAS).Grazie all’implementazione del Cubo Multidimensionale è possibile ottenere risposte in tempi decisamente ridotti rispetto alle stesse operazioni effettuate su altre tipologie di database. In questa fase non è stato ritenuto necessario la definizione di ulteriori strutture di memorizzazione (indici e viste materializzate) per agevolare le operazioni di analisi dei dati.
Capitolo 5 EXTRACT TRANSFORM LOAD
Una volta conclusa la fase di analisi dei requisiti e di progettazione del data warehouse, si procede al popolamento del database con i dati delle campagne di web advertising. In questo capitolo si descrive la realizzazione delle fasi di estrazione, trasformazione e caricamento delle tabelle del data warehouse. Si presentano alcune delle problematiche riscontrate durante lo sviluppo del servizio software ETL e il modo in cui, tali problematiche sono state affrontate. Il capitolo si conclude con la descrizione dei possibili sviluppi futuri e miglioramenti possibili.
5.1 Il processo ETL
ETL, processo costituito da una serie di operazioni per ottenere i dati da fonti operative (fase di
estrazione), pulire e preparare tali dati (fase di trasformazione) per il loro effettivo caricamento nel data warehouse (fase di caricamento). In generale, prima che i dati siano memorizzati nel data warehouse, essi sono sottoposti a tre operazioni:
- Estrazione, estrazione dei dati dalle fonti operative, nel nostro caso le diverse piattaforme utilizzate per la realizzazione e la gestione di campagne di advertising.
- Trasformazione, i formati dei dati provenienti da differenti fonti vengono rielaborati eliminando così differenze semantiche o di sintassi.
- Caricamento, fase di caricamento dei dati all'interno delle tabelle che costituiscono il data warehouse.
Nel progetto presentato in questa tesi, le fasi di estrazione, trasformazione e caricamento vengono realizzate attraverso un servizio software scritto in linguaggio C# in ambiente .NET. Tale decisione è stata presa data la possibilità di utilizzare l’ORM Linq in grado di connettersi con facilità al data base SQL SERVER.
5.2 ETL Main
La funzione Main del programma richiama l’esecuzione dei singoli processi ETL. Infatti per ogni tipologia di dati da estrarre, pulire e memorizzare è stata realizzata una specifica funzione, di seguito elencate:
- ExtractDCM la funzione estrae dal file del report DCM i nomi dei placement da cui vengono ottenute le differenti dimensioni. Ad ogni placement sono associati valori relativi a metriche di
performance, ad esempio il numero di impressions, i click, le conversioni ecc. I dati vengono puliti ed inseriti coerentemente nelle tabelle dei fatti e delle dimensioni;
- ExctractDBM la funzione estrae dal report DBM i dati di costo relativi ai fatti inseriti;
- ExtractFB la funzione estrae dal report Facebook i dati di costo, le video view e le impression di remarketing relativi ai fatti precedentemente inseriti;
- ExtractNielsen la funzione estrae dal report Nielsen le impression On Target relativi ai fatti inseriti;
- ExtractYT la funzione estrae dal report YouTube le video view, il costo ed i click overlay relativi ai fatti inseriti;
- ExctractRT la funzione estrae dal un file contenente i dettagli dei contratti di reservation tradizionale e ridistribuisce sui fatti relativi i costi e le booked impression;
- ExtractReachDCM la funzione estrae dal report DCM i dati di reach, cioè il numero di utenti unici a livello di sito;
Risulta importante ai fini del funzionamento del programma che l’esecuzione della funzione
ExtractDCM avvenga per prima, in quanto le successive funzioni si basano sui dati relativi ai
tracciamenti DCM. Nei paragrafi successivi verranno descritti gli algoritmi sopra elencati.
5.3 ExtractDCM
Il seguente paragrafo descrive la procedura di estrazione, trasformazione e caricamento relativa ai dati ottenuti dai tracciamenti realizzati attraverso la piattaforma DCM (DoubleClick Campaign Manager). La funzione prende in ingresso i dati da un foglio di calcolo, essi vengono elaborati e caricati coerentemente all’interno del data warehouse. Il report ottenuto attraverso la piattaforma è costituito da una tabella contenente le seguenti colonne:
- Placement ID: id univoco all’interno della piattaforma DCM che si riferisce ad uno specifico placement;
- Placement: il nome del placement e da cui vengono estrapolate le differenti dimensioni; - Date: data relativa alla misurazione delle performance del placement;
- Campaign ID: id univoco all’interno della piattaforma DCM che si riferisce ad una specifica campagna;
- Site ID (DCM): id univoco all’interno della piattaforma DCM che si riferisce al sito su cui il placement è implementato;
- Site (DCM): nome del sito su cui il placement è implementato;
- Misure di Performance: valori relativi alle performance del placement ad esempio: Impressions, Clicks, Cost ecc.
Ogni riga del file è relativa alle performance registrate relative ad un singolo placement in una specifica data, l’algoritmo elabora le dimensioni contenute all’interno del nome del placement. Ad esempio dato il seguente nome:
UK_RTB_News_Condenast_GQ_desktop_woman_728x90_Campagna-2017_Ros_Display_rtb
Se non precedentemente presenti vengono estrapolate e caricate le seguenti dimensioni.
Campaign PK
Country Client ClientSector CampaignName CampaignName DCM
CampaignId DCM
123 UK Cliente Faschion Campagna-2017 01122017Cliente 230232
Tabella 5.1 Dimensione Campaign
Advertisement PK
BannerSize Gender Device MediaType PlacementSite CustomClient
456 728x90 woman Desktop Display Ros rtb
Tabella 5.2 Dimensione Advertisement
Publisher PK
Category SitePlacement Name
AdNetwork Buying Site DCMName
Site DCMId
789 News GQ Condenast RTB gq.uk 978721
Tabella 5.3 Dimensione Publisher
Una volta accertato che le dimensioni sono presenti all’interno del data warehouse, il programma crea ed inserisce il fatto, che viene legato alle dimensioni attraverso l’utilizzo di chiavi esterne.
Oltre alle dimensioni precedenti viene associata anche la dimensione date, attraverso l’utilizzo di una chiave esterna del tipo YYYYMMYY. Ad esempio se la misurazione si riferisce al 01/12/2017, al fatto viene associata la chiave 20171201 collegandolo così alla dimensione Date, tale informazione è ottenuta dalla colonna Date del report. La dimensione Date è stata precedentemente popolata attraverso l’utilizzo di uno script T-SQL, essa contiene attributi utili alla navigazione temporale dei fatti, nella Tabella 5.4 ne vengono mostrati alcuni.
DatePK FullDate Semester Quarter DayName MonthName
20171201 2017-12-01 SecondSemester Q4 Friday December
Tabella 5.4 Dimensione Date
Al termine dell’algoritmo risulterà inserito il seguente fatto, di cui vengono mostrati solo gli attributi chiavi esterne e categorici, oltre ad essi sono presenti le numerose metriche di performance relativi al placement in una certa data.
Placement TrackingPK PlacementId Placement Name Publisher FK Advertisement FK Campaign FK Date FK 12345 898989 UK…rtb 789 456 123 20171201
Tabella 5.5 Fact PlacementTracking
5.4 ExtractDBM
Il seguente paragrafo descrive la procedura di estrazione, trasformazione e caricamento relativa ai dati associati ai tracciamenti DCM, all’interno della piattaforma DBM (DoubleClick Bid Manager). La funzione prende in ingresso i dati da un foglio di calcolo, essi vengono elaborati e caricati coerentemente all’interno del data warehouse.
Il report d’ingresso è costituito da un foglio di calcolo contenente le seguenti colonne: - Data: data relativa alla misurazione delle performance del placement;
- Creatività: il nome del placement e da cui vengono estrapolate le differenti dimensioni; - ID posizionamento DCM: id univoco all’interno della piattaforma DCM che si riferisce ad
uno specifico placement;
- Sito: nome del sito su cui la creatività viene ospitata;
- ID sito: id univoco all’interno di DBM che si riferisce al sito su cui la creatività viene ospitata; - Costo: valore del costo dell’acquisto;
- Misure di Performance: valori relativi alle performance del placement ad esempio: Impressions, Clicks, ecc.
La colonna relativa alle performance risulta necessaria per alcuni particolari tracciamenti, relativi al caso di acquisti di più spazi su differenti siti attraverso DBM.
In questo caso per avere i dettagli di performance sui singoli siti esistono due alternative:
1. Realizzare un tracciamento DCM per singolo sito avente per adNetwork DMB e per site il singolo sito, questa operazione rende molto più lunga il processo di tracciamento DCM;
2. Realizzare un unico tracciamento DCM avente per AdNetworl DBM e per site All, questa operazione velocizza il processo di tracciamento di DCM, ma comporta la perdita delle performance di conversione tranne quella relativa all’atterraggio sulla pagina prodotto. Si ha quindi un trade-off tra la precisione del tracciamento ed il tempo necessario per la sua realizzazione. La scelta tra le due differenti alternative si basa sul numero di siti presi in considerazione, sull’importanza dell’acquisto a livello di budget e sul tempo a disposizione per la fase di tracciamento DCM. Di seguito una sintetica descrizione dell’algoritmo.
Il programma elabora ogni riga del file
- Controlla se sia già presente all’interno del data warehouse un fatto con id e data uguali ai valori delle colonne ID posizionamento DCM e Data.
o In caso negativo il programma termina senza apportare modifiche.
o In caso positivo, il programma controlla dal nome del placement se esso è un tracciamento del tipo DBM/All
▪ In caso positivo, il programma:
● Setta a zero i valori relativi al tracciamento DCM, tranne quelli relativi alle conversioni (eccetto la conversione product)
● Inserisce un nuovo fatto utilizzando le solite dimensione del tracciamento DCM, eccetto la dimensione Publisher, essa infatti sarà una differente dimensione avente valorizzato l’attributo SiteDBMName e SiteDBMId. Tale dimensione potrebbe essere già presente nel database, ed in questo caso sarà relazionata al fatto attraverso la sua chiave, oppure se non già presente creata ed inserita. Il nuovo fatto presenterà come performance quelle ottenute dal report DBM, inoltre sarà valorizzato il campo costo. Nella tabella 5.6 viene mostrata la nuova dimensione Publisher inserita.
Publisher PK
Category SitePlacement Name
AdNetwork Buying Site
DBMName
Site DBMId
101 News All DBM RTB Corriere.it 1092102
Tabella 5.6 Dimensione Publisher
▪ In caso negativo, il programma valorizzata la misura CostDBM, per il fatto individuato attraverso i valori delle colonne ID posizionamento DCM e Date
5.5 ExtractFB
Il seguente paragrafo descrive la procedura di estrazione, trasformazione e caricamento relativo ai dati associati ai tracciamenti DCM, all’interno della piattaforma di gestione campagne di Facebook ed Instagram.
- Data: data relativa alla misurazione delle performance del placement;
- Nome dell'inserzione: il nome del placement e da cui vengono estrapolate le differenti dimensioni, il suo primo campo deve essere costituito dall’ID del placement DCM;
- Importo: importo speso per la pubblicazione dell’inserzione;
- Impression: questa misura è utilizzata per i placement di remarketing le cui impression non sono tracciabili in DCM;
- VideoView 25%, 50%, 75%, 100% numero e soglia di visualizzazione relative alle inserzioni video;
Il programma elabora ogni riga del file. Controlla se sia già presente all’interno del data warehouse un fatto con Id uguale al valore Id all’interno del nome dell’inserzione e data uguale al valore nella colonna Data.
o In caso negativo il programma controlla se l’inserzione elaborata è di tipo remarketing (tale informazione è nel nome dell’inserzione)
▪ In caso positivo, viene inserito un nuovo fatto inserendo le misure di Impression, Cost e VideoView. (DCM potrebbe non aver mai registrato il fatto non potendone tracciare le impression);
▪ In caso Negativo, il programma termina;
o In caso positivo, il programma valorizza i campi Costo e VideoWiew, nel caso in cui l’inserzione è di tipo remarketing viene valorizzato anche il campo Impression.
Da notare che l’agenzia precedentemente non aveva previsto che l’id del placement DCM fosse inserito all’interno del nome dell’inserzione Facebook/Intagram, il processo prevedeva il solo mantenimento del nome del placement DCM. Ho però suggerito di inserire l’id DMC all’interno del nome inserzione nelle future campagne, tale informazione infatti essendo univoca garantisce la possibilità di associare correttamente le inserzioni Facebook/Instagram con i placement DCM.
5.6 ExtractNielsen
Il seguente paragrafo descrive la procedura di estrazione, trasformazione e caricamento relativa ai dati associati ai tracciamenti DCM, all’interno della piattaforma Nielsen.
Nielsen fornisce un servizio che se correttamente implementato, è in grado di dare informazioni socio-demografiche attendibili sugli utenti che visualizzano i banner della campagna. Il grande vantaggio di Nielsen è che le informazioni fornite non si basano esclusivamente su cookie, ma sulle informazioni che gli utenti rilasciano liberamente all’interno dei social network.
Il report d’ingresso è costituito da un foglio di calcolo contenente le seguenti colonne:
- Nome placement DCM: il nome del placement e da cui vengono estrapolate le differenti dimensioni, il suo primo campo deve essere costituito dall’ID del placement DCM;
- ImpressionOntarget: il numero di visualizzazione da parte degli utenti appartenenti al target di riferimento (ad esempio uomini 35-50 anni).
La funzione estrae dal report Nielsen le impression On Target relativi ai fatti memorizzati che vengono inserite in un'apposita tabella dei fatti. Anche in questo caso è stato suggerito l’inserimento dell’Id univoco DCM all’interno del nome dell’annuncio.
5.7 ExtractYT
Il seguente paragrafo descrive la procedura di estrazione, trasformazione e caricamento relativa ai dati associati ai tracciamenti DCM, all’interno della piattaforma di gestione delle campagne YouTube.
Il report d’ingresso è costituito da un foglio di calcolo contenente le seguenti colonne: - Data: data relativa alla misurazione delle performance del placement;
- Annuncio: il nome del placement e da cui vengono estrapolate le differenti dimensioni, il suo primo campo deve essere costituito dall’ID del placement DCM;
- Costo: importo speso per la pubblicazione dell’inserzione;
- Click OverLay: questa misura è utilizzata per gli annunci video overlay i cui click non sono tracciabili in DCM;
- Video View 25%, 50%, 75%, 100% numero di utenti che hanno visualizzato il video fino ad una certa soglia.
L’algoritmo per necessità di sintesi non sarà descritto nel dettaglio, in quanto il flusso del programma è analogo alla funzione ExtractFB a cui è possibile fare riferimento nel precedente paragrafo. Anche in questo caso è stato suggerito ai Media Planner l’inserimento dell’Id DCM univoco all’interno del nome dell’annuncio.
5.8 ExctractRT
Il seguente paragrafo descrive la procedura di ridistribuzione dei costi degli acquisti di tipo reservation tradizionale relativi ai tracciamenti DCM. I dati d’ingresso sono inseriti all’interno di un foglio di calcolo contenente le seguenti colonne:
- Lista delle dimensioni: Country, Buying, Category, AdNetwork, Site, Device, Gender, BannerSize, CampaignName, PlacementOnSite, mediaType, customClient, alcune delle quali
