Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Department of software engineering

Diplomová práce

Customer Intelligence v kontextu Big Data Bc. Martin Tříska

Vedoucí práce: Ing. Tomáš Bruckner, Ph.D.

22. května 2013

Poděkování Chtěl bych poděkovat všem, kteří mi jakkoli pomohli při tvorbě mé diplomové práce, ať již morálně, či radou. Jmenovitě bych pak chtěl velice poděkovat svému vedoucímu, panu Tomáši Brucknerovi, za jeho trpělivost a obrovskou ochotu a Kláře Kokoškové za její právnické rady.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.

V Praze dne 22. května 2013

.....................

České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Martin Tříska. Všechna práva vyhrazena. ○ Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Tříska, Martin. Customer Intelligence v kontextu Big Data. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract This thesis analyzes possibilities of implementing Big Data analytics solution on unstructured data with a goal to better understand customer, his needs and wishes, especially with a focus to organization’s products and services. This is called Customer Intelligence. Thesis firstly analyzes the current situation around Big Data analytics and then types of information from/about customers, which are currently available in both public and internal information sources. Thesis further identifies their possible added value, important characteristics and structure, same as the methods of gathering (mining) them. The analytical part of this thesis deals with the legal and moral aspect of Big Data analytics within the Czech republic. The practical part of the thesis proposes a design of the Big Data analytics concept built around IBM Content Analytics tool including the design of the components, which had to be developed for this particular solution. The proposed solution is then implemented. Benefits of the Big Data analytics are then demonstrated using the solution on data gathered from public and internal sources to discover customer churn, complains, topics of interest and more. Keywords Big Data, Customer Intelligence, Unstructured data, Social media, Data mining

ix

Abstrakt Práce se zabývá možností analýzy velkého množství nestrukturovaných dat (zapojením Big Data) s cílem vytěžit z nich informace, které by organizaci pomohly lépe poznat zákazníka, jeho zájmy, a to hlavně ve vztahu k organizaci jako takové, jejím produktům či službám, které nabízí. Souhrnně se tato problematika označuje jako Customer Intelligence. Práce nejprve analyzuje současný stav Big Data a následně pak strukturu a klíčové charakteristiky veřejně i interně dostupných informací o klientech, s potenciálem zvýšit Customer Intelligence. Analytická část práce také řeší právní a morální aspekt analytiky nestrukturovaných dat především v rámci legislativy České republiky. Praktická část práce pak popisuje návrh technického řešení konceptu analytiky nestrukturovaných dat pomocí zvoleného nástroje IBM Content Analytics spolu s komponentami, které bylo nutné vyvinout. Navrhované řešení je následně implementováno a jsou na něm následně demonstrovány přínosy Big Data analytics na příkladu nalezení zákazníků, kteří chtějí odejít, jejich stížností, identifikace témat, o kterých se baví, a další. Klíčová slova Big Data, Customer Intelligence, Nestrukturovaná data, Sociální média, Vytěžování dat

x

Obsah Úvod Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Big 1.1 1.2 1.3

Data Co jsou Big Data? . . . . . . . . . . . . . . . . . . . . . . . Základní charakteristiky (3+1 V) . . . . . . . . . . . . . . . Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 5 7 7 9 13

2 Analýza rozsahu a struktury informačních zdrojů 17 2.1 Veřejné zdroje . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Interní zdroje . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3 Právní a morální aspekt Big Data 35 3.1 Zpracování veřejně dostupných informací . . . . . . . . . . . 36 3.2 (De) Anonymizace dat . . . . . . . . . . . . . . . . . . . . . 41 3.3 Poznání vs. vytváření skutečnosti . . . . . . . . . . . . . . . 44 4 Customer Intelligence 47 4.1 Typy dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 Příklady využití . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Návrh řešení 5.1 Výběr analytické technologie . 5.2 Architektura řešení . . . . . . 5.3 Výběr datových zdrojů . . . . 5.4 Párování uživatelských profilů xi

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

51 51 55 57 58

5.5

Shrnutí úkolů praktické části . . . . . . . . . . . . . . . . . .

59

6 Praktická část 61 6.1 Získávání dat . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.2 Analýza a zpracování dat . . . . . . . . . . . . . . . . . . . . 74 7 Výsledky řešení 85 7.1 Analýza získaných dat expertem . . . . . . . . . . . . . . . . 85 7.2 Analýza dat laikem na přepážce . . . . . . . . . . . . . . . . 92 Závěr 95 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Diskuze výsledků . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Doporučení pro další práci . . . . . . . . . . . . . . . . . . . . . . 98 Literatura

99

A Obsah CD

103

xii

Seznam obrázků 1.1 1.2

Rozdíl Business Intelligence a Big Data Analytics . . . . . . . . Vizualizace principu Map & Reduce algoritmů . . . . . . . . . .

8 14

2.1 2.2 2.3

Vizualizace výchozího nastavení bezpečnosti na sociální cebook v čase . . . . . . . . . . . . . . . . . . . . . . . Vzorová struktura článku ze serveru iDNES.cz . . . . . Vzorová struktura diskuze ze serveru iDNES.cz . . . .

Fa. . . . . . . . .

19 28 29

5.1 5.2

Příklad sentiment analýzy vybraných mediálních webů . . . . . Návrh architektury analytického řešení nestrukturovaných dat .

53 56

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13

Ukázka nastavení parsovacího XML souboru pro iDNES.cz . . Digram získání dat z Facebooku . . . . . . . . . . . . . . . . . . Princip získání dat z Twitteru . . . . . . . . . . . . . . . . . . . Grafické rozhraní aplikace Crawler Manager . . . . . . . . . . . Nastavení spojení s ICA REST API . . . . . . . . . . . . . . . . Ukázka spuštěného Twitter crawleru . . . . . . . . . . . . . . . Ukázka spuštěného Facebook crawleru . . . . . . . . . . . . . . Aktivita českých bank na sociální síti Facebook . . . . . . . . . Nastavení metadat dokumentů v nástroji ICA . . . . . . . . . . Úvodní strana analytické aplikace pro koncového uživatele . . . Přehledový pohled v analytické aplikace pro koncového uživatele Pokročilý pohled v analytické aplikace pro koncového uživatele . Možnosti exportu v aplikaci Customer Intelligence . . . . . . . .

62 64 69 71 71 72 73 74 75 78 79 80 83

7.1 7.2

Přehled dokumentů získaných z vybraných mediálních webů . . Přehled dokumentů získaných z vybraných bankovních profilů sítě Facebook . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

xiii

sítí . . . . . .

86

7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14

Přehled aktivity na vybraných bankovních profilech sítě Facebook v čase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Přehled stuktury příspěvků na vybraných bankovních profilech sítě Facebook v čase . . . . . . . . . . . . . . . . . . . . . . . . Příklad nalezené stížnosti - nefunkční karta . . . . . . . . . . . Sentiment získaných informačních zdrojů . . . . . . . . . . . . . Sentiment získaných informačních zdrojů - detail pro e15.cz na negativní výrazy . . . . . . . . . . . . . . . . . . . . . . . . . . Sentiment získaných informačních zdrojů - detail pro e15.cz na pozitivní výrazy . . . . . . . . . . . . . . . . . . . . . . . . . . . Přehled diskutovaných služeb . . . . . . . . . . . . . . . . . . . Sentiment bankovních služeb . . . . . . . . . . . . . . . . . . . . Vyhledávání klientů, kteří chtějí odejít od organizace . . . . . . Příklad uživatele, který chce opustit mBank . . . . . . . . . . . Přehled aktivity klienta pro pracovnici přepážky v bance . . . . Podrobný detail aktivity klienta pro pracovnici přepážky v bance

87 87 88 89 89 90 91 91 91 92 93 94

A.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . 103

xiv

Úvod Tato kapitola popisuje důvody výběru tématu, obecný úvod do problematiky, stejně jako cíle celého projektu.

Motivace Data is the new oil [1]. Věta, která zaujala mou pozornost natolik, že svým způsobem zapříčinila mou volbu tématu "Customer intelligence v kontextu Big Data". Co tato věta opravdu říká, je fakt, že informace a data obecně jsou a budou stále důležitější komponentou úspěchu všech organizací na trhu. Jednou z hlavních výzev businessu, která navíc vyrostla doslova před očima za poslední dekádu, je potřeba dostat ty správné informace na požádání co nejrychleji a zároveň co nejjednodušeji na správné místo, správné osobě a ve správný čas. Množství dat, která jako společnost každým dnem generujeme a se kterými se musíme potýkat je přitom zcela nepředstavitelné. Přiblíženo řečí čísel: ∙ Každý den je odesláno více než 144,8 miliard emailů [2]. ∙ Každou minutu na server Youtube přibude 72 hodin videa [3]. ∙ Každou minutu vyhledávač Google zpracuje přes 2 miliony vyhledávacích dotazů. ∙ Každou sekundu generuje urychlovač částic v CERNu 40 terabajtů dat. ∙ Teleskop, který bude dokončen v roce 2024, vygeneruje za den více dat, než nyní obsahuje celý Internet [4]. 1

Úvod Pro orientaci v této záplavě informací jsou již delší dobu využívány různé analytické nástroje s cílem usnadnit rozhodování, zrychlit procesy, zviditelnit určité extrémní hodnoty v datech a podobně. Tyto nástroje se souhrnně označují jako Business Intelligence a umí pracovat prakticky výhradně s takzvanými strukturovanými daty (jako jsou například data uložená v databázových systémech) a se záplavou nových druhů dat, nestrukturovaných informací, si neumí poradit. Druhou, a s první velice úzce svázanou, výzvou businessu je jeho nikdy nekončící potřeba dokonale porozumět zákazníkovi a dlouhodobě nabízet produkty a služby, o které opravdu jeví zájem a které uspokojují jeho potřeby. Zároveň je potřeba s daným zákazníkem budovat vztah. Toto se ovšem snadněji řekne, než provede. Různé organizace pracují se zákazníky různými způsoby. Některé se neobtěžují zkoumat zájmy svých klientů a rozesílají hromadné unifikované nabídky na adresy, které získali marketingovou kampaní, případně které nakoupili z databáze uživatelů třetí strany. Jiné organizace o svých klientech sbírají data pomocí různých věrnostních karet či zákaznických klubů (z čehož lze snadno zjistit, jaké produkty si uživatel kupuje), další pak stále prosazují osobní kontakt a přímou diskuzi se zákazníkem na téma, co si přeje a jak mu daná organizace může vyjít vstříc. Byla-li v oblasti Customer Intelligence prováděna nějaká analytická práce nad daty zákazníků, byla většinou právě v úrovni zkoumání jeho nákupních zvyklostí, analýzy produktů, které si nejčastěji kupuje, segmentací do určitých pevně stanovených kategorií a podobně. Pokročilejší analytika pak na základě takto zjištěných výsledků predikovala jeho příštího nákupu, na který mu mohla být dopředu poskytnuta sleva nebo speciální nabídka. Podobný model celou řadu let postačoval, neboť stejně nebyly jiné, pokročilejší (a cenově dostupné) metody. I kdyby se organizace v té době chtěly zapojit do vytváření různých behaviorálních analýz, či dokonale poznat a pochopit zákazníka z všech možných úhlů, nebylo by to možné, neboť prostě neexistovaly dostupné zdroje informací a zákazník by sám takovéto informace dobrovolně a zadarmo neposkytnul. Řešení obou těchto výzev vyžaduje zapojení principů a technologií, které tu doposud nebyly a které de facto vytváří celé nové odvětví Big Analytics, jinak řečeno pokročilé analytiky obrovského množství různých dat s důrazem na data nestrukturovaná (především tedy v textové podobě). Využívání těchto pokročilých analytických metod pro lepší pochopení a poznání nejenom vlastního businessu, zákazníka či dodavatelů, ale i vztahů mezi subjekty na trhu či libovolných aspektů relevantních k tržnímu segmentu, ve kterém daná organizace podniká, je v současné době prakticky na po2

Motivace čátku a jejich implementací lze získat velice silnou konkurenční výhodou. Tento stav ovšem nemusí trvat příliš dlouho a velice rychle se blíží doba, kdy budou tyto praktiky nutností pro přežití na silně konkurenčním globálním trhu. Organizace, která zaspí dobu, pak bude mít velice těžkou pozici dohnat ostatní hráče na trhu, přičemž se jí to ani nemusí podařit. Big Data jsou velký pojem dnešní doby, kvůli kterému vznikají zcela nové pracovní pozice [5], nové technologie [6], ale hlavně tento pojem mění přemýšlení lidí nad tím, co vlastně data jsou, co se z nich dá získat a jak tyto informace využít pro další růst organizace. Big Data přitom nejsou produkt nebo aplikace, kterou lze koupit, implementovat a hned používat, je to platforma, filozofie, celý nový způsob uvažování. K pokročilé analýze dat je ovšem logicky potřeba dostatečné množství dat v dostatečné kvalitě. Jinak řečeno, v datech musí být zajímavé informace, které z nich lze vytěžit. V kontextu Customer Intelligence jsou tak zapotřebí data, ze kterých by bylo možné vytěžit názory klientů na určité produkty, jejich stížnosti, náměty a další zajímavé informace. Zásadním přínosem v této oblasti, z pohledu konzumenta dat, byl a stále je dramatický rozvoj sociálních sítí, které se staly prakticky přes noc novým standardem mezilidské komunikace. Uživatelé moderních komunikačních prostředků (záměrně nepíši pouze počítačů či notebooků, neboť paralelně s obdobím masivní datové expanze se zcela razantně rozvíjel i trh s mobilními telefony, tablety a jim podobnými zařízeními, takže dnes je možné být online prakticky na jakémkoli médiu počínaje ledničkou po automobily) si rychle zvykli na tento snadný, efektivní a pro mnohé i velice zábavný způsob komunikace a rychle mu propadli. Dnes má jenom sociální síť Facebook více než jednu miliardu aktivních uživatelů měsíčně [7], z čehož je 3 849 900 z České republiky [8]. To je více než 50% české online populace. Tito uživatelé sdílejí pomocí svých profilů prakticky veškeré informace o svém životě, svých přátelích či zvycích, ale co je pro organizace nejdůležitější, jsou více než ochotní sdílet svá přání i své poznámky či výtky k produktům či službám, které daná organizace poskytuje. Tyto informace mají obrovskou moc a ještě větší přidanou hodnotu. Mohou způsobit spoustu škody, stejně jako mohou mít naprosto zásadní přínos. Záleží jenom na tom, jak se daná organizace zachová a jestli tuto hozenou rukavici zvedne a nabízenou příležitost správně využije. Facebookem a sociálními sítěmi ovšem tato datová exploze zdaleka nekončí. Moderní člověk využívá i celou řadu jiných komunikačních kanálů. 3

Úvod Komunikuje pomocí emailů, posílá sms, přispívá na Twitter, nahrává své fotky i s komentáři na Flickr a dělá celou řadu dalších činností, které o něm a jeho chování nechávají prakticky nesmazatelnou veřejnou (a pro organizace pracující přímo s daty klientů také interní) stopu. A je to právě tato stopa a její potenciální business využití k bližšímu poznání klienta pomocí pokročilých analytických metod nestrukturovaných dat, která stojí na úplném počátku mé práce.

4

Cíle práce

Cíle práce Analytická část 1. Analyzovat možnosti využití Big Data v businessu včetně konkrétních příkladů. 2. Analyzovat rozsah a strukturu veřejně dostupných informací na vybraných sociálních sítích. Navrhnout způsob jejich získání a ten podrobněji rozebrat. 3. Analyzovat rozsah a strukturu běžně dostupných interních zdrojů informací o klientech. Navrhnout způsob jejich získání a propojení s veřejnými daty. 4. Analyzovat právní a morální aspekt spojený se zpracováním Big Data. Navrhnout režim fungování v mezích zákona. 5. Vybrat vhodný nástroj pro pokročilou analýzu nestrukturovaných dat a nastudovat jej. 6. Navrhnout koncept řešení problému analýzy získaných dat s využitím zvoleného nástroje.

Praktická část 1. Nastavit/připravit zvolený nástroj pro pokročilou analýzu nestrukturovaných dat. 2. Získat data z vybraných sociálních sítí a vybraných mediálních webů. 3. Navrhnout a implementovat aplikaci pro práci s analytickým nástrojem pro koncového (nevyškoleného) uživatele. 4. Demonstrovat možnosti Customer Intelligence v Big Data na získaných datech. a) Nalézt zákazníka/y, který vyjadřuje přání odejít od organizace. b) Nalézt zákazníka/y se stížností. c) Analyzovat náladu příspěvků na určité téma (název produktu, služby či konkurence) nebo celých zdrojů dat. d) Identifikovat nejčastěji diskutovaná témata. e) Identifikovat příspěvky od konkrétního autora napříč všemi daty.

5

Kapitola

Big Data Tato kapitola představuje koncept Big Data. Součástí kapitoly je jak teoretické představení celé myšlenky a její definice, tak představení technologií, které se na zvládnutí Big Data využívají, a jejich základních principů při zpracování těchto dat.

1.1

Co jsou Big Data?

Big Data technologies describe a new generation of technologies and architectures, designed to economically extract value from very large volumes of a wide variety of data, by enabling high velocity capture, discovery and/or analysis [9]. Najít přesnou a hlavně jednotnou definici Big Data je prakticky nemožné. Tento fakt sám o sobě hodně naznačuje i celkovou nejednotnost konceptu jako takového, který je vše, jen ne formalizovaný či jakkoli jinak unifikovaný. Přesto je nutné pro potřeby této práce Big Data představit, včetně technologií, které k tomuto tématu nerozlučně patří. Definice v úvodu kapitoly naznačuje, že Big Data je soubor technologií, které mají za cíl správu a analýzu velkého množství převážně nestrukturovaných dat pro získání výsledků, které by šly zpeněžit. Takový popis nicméně úplně přesně nevystihuje jeden důležitý aspekt celého konceptu. Big data are high volume, high velocity, and/or high variety information assets that require new forms of processing to enable enhanced decision making, insight discovery and process optimization [10].

7

1

1. Big Data Za Big Data se tedy považují taková data, která nelze ukládat ani zpracovávat tradičními technologiemi [11]. Tato data jsou natolik kapacitně náročná, že je nelze uložit na jeden disk, a je tedy nutná distribuce na více paměťových médií. Zároveň se o Big Data často mluví jako o věčných datech, neboť teoreticky není potřeba žádná data mazat, pouze přidávat nová, a zpřesňovat tak výsledky. Co je jednou v datech zachyceno, zůstane v nich navždy. Naprosto klíčový je tak požadavek rozšířitelnosti tohoto úložného prostoru za chodu a dle potřeby (teoreticky až do nekonečna). Výpočty nad těmito daty se pak musí provádět distribuovaně. Koncept Big Data mění i samotný postup výpočtů, kdy se již nepřesouvají data na jedno místo kvůli výpočtu, ale výpočet se pak pomocí speciálních algoritmů Map & Reduce distribuuje blíže k datům. Výsledku se pak dosáhne postupným redukováním mezivýsledků. Právě paralelní zpracování a přístup k informacím umožňuje řešení postaveném na tomto principu mnohem vyšší rychlost a robustnost oproti standardním systémům, na kterých vznikají úzká hrdla při přístupech k paměťovému médiu a podobně. Rozdíl mezi tímto přístupem a běžnou Business Intelligence znázorňuje následující tabulka 1.1.

Obrázek 1.1: Rozdíl Business Intelligence a Big Data Analytics Druhým důležitým benefitem Big Data konceptu je fakt, že celé řešení lze vystavět pouze s využitím komoditního hardware bez nutnosti zapojovat drahá proprietární hardware řešení či servery. Příkladem může být společnost Google či Facebook, kteří mají svá datová centra sestavena z relativně levných počítačů zapojených v obrovském počtu paralelně, což jim dodává 8

1.2. Základní charakteristiky (3+1 V) potřebný výkon. Při výpadku jednoho uzlu jej lze snadno nahradit jiným, který převezme jeho práci. Hlavním rozdílem oproti běžným analytickým přístupům je nicméně v samotném přístupu při pokládání dotazů. Big Data, tím, že uchovávají a procházejí opravdu všechny dostupné informace v jejich původní podobě bez ohledu na formát, umožňují pokládat prakticky jakékoli otázky, a to i takové, které v době pořízení dat ještě nebyly ani známé, či nikdo nevěděl, že je bude jednoho dne potřeba klást. To je úplný opak tradiční rigidní databázové struktury, která svou pevně definovanou strukturou (schématem) z principu omezuje množinu dotazů. Chce-li se uživatel na takto uložená data podívat novým způsobem, z jiného úhlu, se kterým nebylo počítáno již při původním návrhu databáze, má většinou smůlu, případně se musí struktura databáze upravit a data do ní zpětně překonvertovat. Big Data nicméně nemění nic na obecných principech analytické práce, pouze v některých jejích aspektech podstatně rozšiřuje možnosti. ∙ Využití všech dostupných dat pro vytvoření modelu (dříve pouze vzorek). ∙ Kombinace více analytických modelů a technik s cílem zlepšit a zpřesnit výsledek. ∙ Samoučící algoritmy, které se v uzavřené smyčce učí nově získané informace, a nadále tak zpřesňují své výsledky. ∙ Využití prediktivních modelů prakticky v reálném čase.

1.2

Základní charakteristiky (3+1 V)

Ačkoli ohledně přesné definice Big Data panují stále dohady, ustálily se obecně některé charakteristiky, které mají všechna Big Data společná a které je odlišují od těch "běžných", zvladatelných dat. Většina zdrojů uvádí charakteristiky Volume, tedy množství dat, Velocity, tedy rychlost, jakou data přibývají, a v neposlední řadě Variety, tedy různou podobu a formát dat. K těmto třem základním charakteristikám (3V) společnost IBM identifikovala ještě jednu, Veracity, charakteristiku, která řeší především úplnost a důvěryhodnost zpracovávaných dat. Další charakteristiky mohou postupně přibývat, což dokládá, že i samotný proces poznání Big Data je ještě stále na začátku. 9

1. Big Data

1.2.1

Volume - Objem

Charakteristika objemu reprezentuje celkové množství dostupných dat. To může být tvořeno historickými záznamy zákazníka, všemi jeho transakcemi, logy jeho aktivit, daty ze sociálních sítí a webu obecně nebo všemi zmíněnými plus dalšími zdroji dohromady. Nesmíme zapomenou na fakt, že velké procento tohoto objemu je pouze šum, tedy neužitečné informace, které nepřinášejí žádnou reálnou hodnotu a které potenciálně mohou zkreslit výsledky. To mohou být různé technické provozní informace logované přístroji, ze kterých nelze nic vyčíst, a podobně. Typický dosavadní přístup při analytické práci nad daty byl pomocí vzorkovacích algoritmů vybrat určitou reprezentativní podmnožinu dat a na ní testovat určité hypotézy, či dělat statistiky. Z takto získaných výsledků byla často odvozována konkrétní doporučení (jaký produkt si zákazník příště koupí a podobně). Klíčovým bodem v tomto standardním procesu je přitom již samotný výběr vzorku, což je velice složitá operace. Téměř každé vzorkování totiž zavede určitou chybu, či zkreslení, které může ovlivnit (a velice pravděpodobně opravdu ovlivní) výsledek. Rozdíl přístupu Big Data v této oblasti je právě v možnosti zpracovávat všechna data bez ohledu na jejich množství a být si tak jistý, že výsledek je opravdu nejlepší možný a odpovídá skutečné situaci. Tato charakteristika nicméně klade na platformu Big Data vysoké požadavky na poměr ceny a efektivity ukládání dat, jejich bezpečnosti, ale primárně rychlosti provádění jednotlivých operací (algoritmů). Jelikož například nebylo možné efektivně využít dosavadní technologie ukládání dat, vznikl čistě pro potřeby zpracování Big Data zcela nový souborový systém Hadoop (který vychází z původního Google File Systemu, viz dále), na jehož základě staví většina současných open source i proprietárních komerčních Big Data řešení. Je třeba zmínit, že charakteristika objemu je vysoce subjektivní a nelze přesně určit, jaké množství dat je již považováno za Big Data. Hranice mezi Big Data a normálním množstvím je tenká a neustále se pohybuje. Finální číslo se prakticky pro každou organizaci liší a dáno i tržním sektorem, ve kterém firma působí, či softwarovými a hardwarovými nástroji, které k jejich analýze využívá. Tato hranice se bude neustále vyvíjet a posouvat paralelně s rozvojem technologií a obecně možností analytických nástrojů. Co nelze standardně analyzovat dnes, může být za pár let možné i pomocí běžných SW produktů. Jinak řečeno data, která by se dala v minulosti kvalifikovat jako Big Data, nejsou Big Data dnes a co všeobecně považujeme jako Big Data v dnešní době, může být rozumný a poměrně lehce zvladatelný objem dat za pár let. Obecně se ovšem má za to, že Big Data jsou někde v rozmezí 10

1.2. Základní charakteristiky (3+1 V) od několika terabajtů po desítky petabajtů [12].

1.2.2

Velocity - Rychlost

Rychlostí je myšlena především celková doba od vytvoření nové informace přes její získání, zpracování až k samotnému rozhodnutí. Aspekt rychlosti ke zpracování dat přibyl hlavně v posledních letech a s rozvojem technologií bude nabývat stále větší významu Již dnes by se nicméně bez tohoto atributu v určitých případech nešlo obejít, neboť některé druhy businessu (typicky automatizované systémy obchodování na burze a další) jsou nuceny zpracovávat informace takřka v reálném čase a musí se umět okamžitě rozhodnout o dalším kroku. Reálným příkladem může být situace, kdy operátor sleduje polohu mobilního telefonu podle jeho signálu, a jeho majitel, klient, právě prochází kolem obchodu se sportovními potřebami, na které mu prodejce (samozřejmě zprostředkovaně přes již zmiňovaného operátora) chce poskytnout slevu v případě, že okamžitě přijde do prodejny a něco koupí. V tuto chvíli jsou pouze dva možné scénáře. V prvním operátor stihne zachytit polohu uživatele (ideálně již, když se bude k prodejně blížit) a včas mu nabídku komunikovat, ve druhém pak operátor tuto aktivitu udělá až retrospektivně a nabídku bude komunikovat se zpožděním. Potenciální zákazník, který však dostane tuto nabídku pozdě se již ale do obchodu pravděpodobně nevrátí a příležitost prodat výrobek tak padá. Současné algoritmy pro automatické obchodování na burze pracují v řádu milisekund a uzavírají obchody za dobu kratší, než člověk stihne kliknout na myš. Milisekunda rozdílu při provedení příkazu v tomto případě znamená zisk nebo ztrátu a není daleko doba, kdy podobné principy budou platit i v obecném businessu [13].

1.2.3

Variety - Rozmanitost

Klíčovým rozdílem Big Data je především rozmanitost informací které skrze tuto platformu protékají a kterých se celý koncept obecně týká. Tradiční data, se kterými se při běžném provozu pracuje, mají pevně danou strukturu (obecně se označují pojmem strukturovaná). Typickým příkladem jsou data ukládaná do databázových struktur. Během posledních let se nicméně začal převládat obsah nestrukturovaný a především semistrukturovaný. Nestrukturovaný obsah může mít mnoho podob a jen těžko by jej šlo do detailu definovat. Do této kategorie nicméně spadá většina moderních formátů od obrazových či zvukových dat, příspěvků na sociálních sítích, blogů přes informace o geografické poloze, záznamy kliknutí na webech, data 11

1. Big Data dostupná na internetu a další). Všechny tyto formáty mají společný fakt, že nemají pevně daný řád. Často obsahují větší množství textové informace, která přitom nemusí být pouze ve formě srozumitelných vět, ale mohou to být různé logy ze zařízení, záznamy pohybu mobilních telefonů, různé signály, kódy a podobně. Právě logy jsou příkladem informací, které se často označují jako semi-strukturované. Semistrukturovaná data mohou mít v některé své části určitou strukturu (lze je předvídatelně číst), větší částí je ovšem nestrukturovaný text. U logu hardwarového zařízení může být například definováno, že výpis každé události začne unikátním identifikátorem zařízení, který má 8 znaků a je zakončen středníkem, bude následováno výpisem aktuálního data a pak bude následovat kód prováděné operace. Zbytek zprávy pak bude samotný nestrukturovaný výpis aplikace, jehož obsahem může být cokoli. Úkolem Big Data je všechny tyto informace vytěžit, sjednotit do podoby vhodné pro další zpracování (do jisté míry v nich jakousi, byť virtuální, strukturu vytvořit), data zpracovat a ideálně oddělit šum (nepoužitelné, či zbytečné údaje) od těch důležitých částí.

1.2.4

Veracity - Věrohodnost

Společnost IBM definovala ještě jednu Big Data charakteristiku, která vznikla především na základě zkušeností z praxe. Tato charakteristika je nicméně velice důležitá a její význam bude růst spolu rostoucím s množstvím dat. V tradičních databázových systémech bylo (a stále je) věnováno hodně pozornosti přípravě a předzpracování dat ještě, než vstoupí do samotného systému, a následně pak analýz. Business následně automaticky předpokládá, že ta data, která se do systému již dostala, jsou věrohodná, vyčištěná a kompletní, a že tedy závěrům z nich vydolovaných můžeme věřit. Připustíme-li v kontextu Big Data myšlenky zapojení dat z různých sociálních sítí, webových článků a jiných podobných zdrojů, je logické, že konzistence a důvěryhodnost těchto dat může z pohledu analytiků poklesnout. Ve skutečnosti dokonce dvě z výše zmíněných charakteristik Big Data - Rychlost 1.2.2 a Rozmanitost 1.2.3 doslova pracují proti věrohodnosti. Pokud totiž v reálném čase zpracováváme opravdu velké množství dat z různých zdrojů, není na jejich důkladné čistění nebo filtrování příliš času (krom jiného i z důvodu rychlosti hardware). Dopady záleží především na tom, jak daná organizace takto získaná data využívá a jaká rozhodnutí z nich chce vyvodit. Nemusí to nutně znamenat nevýhodu, je pouze potřeba si tuto skutečnost uvědomit. Je totiž nutné oddělit dva pojmy, které se často v souvislosti s Big Data mohou plést korelace a kauzalita. 12

1.3. Technologie Korelace znamená, že dvě sady informací spolu nějakou úzce souvisí, kdežto kauzalita je příčinná souvislost. Odhalit korelaci lze poměrně snadno pomocí matematického aparátu, na odhalení kauzality je ovšem potřeba rozumět kontextu. Big Data přitom slouží právě k odhalování korelací, stále ještě nerozumí kontextu. Příkladů, které tento zásadní rozdíl demonstrují, je celá řada. Například situace, kdy klient na sociální síť napíše, že od dané organizace odchází, nemusí nutně znamenat, že to opravdu udělá (výzkum chování osob na internetu s ohledem na jejich anonymitu a další aspekty je mimo rozsah této práce). Dalším příkladem zkreslení výstupů z dat může být situace, která nastala kolem hurikánu Sandy v USA na konci roku 2012 [14]. Mezi 27. řijnem a 1. listopadem 2012 o tomto hurikánu vzniklo více než 20 milionů tweetů na sociální síti Twitter. Jejich zpětná analýza ukázala, že nejvíce jich pocházelo z Manhatannu (centra New Yorku), což by naznačovalo, že právě tato lokalita byla nejvíce postižena. Skutečný důvod je nicméně mnohem přízemnější. Více tweetů z dané oblasti přišlo, protože místní obyvatelstvo má více mobilních telefonů a připojení k internetu než mnohem více postižené venkovské oblasti, které se navíc potýkaly s výpadky proudu a mobilních sítí.

1.3

Technologie

Celý koncept Big Data by však nefungoval bez patřičného technologického zázemí, na který ovšem již nestačí tradiční nástroje. Možností zvládnutí Big Data je sice více, nejvýznamnější z nich je ovšem bezpochyby Hadoop a z něj odvozené nástroje.

1.3.1

Apache Hadoop

Apache Hadooop je opensource framework pro ukládání a zpracování dat bez ohledu na jejich formát [15]. Počátky technologie sahají až k firmě Google, která si pro potřeby svého vyhledávače vytvořila vlastní souborový systém Google File System (GFS) s vysokou podporou paralelizace zpracování dat [16]. Důležitým aspektem zde přitom byl princip zpracování dat pomocí modelu Map & Reduce algoritmů, který umožnil vysokorychlostí zpracování paralelních dat. Koncepty souborového systému Google převzali dva vývojáři společnosti Yahoo a vytvořili nástroj Hadoop, který pak zadarmo dali k dispozici veřejnosti jako open source a na kterém dnes stojí většina Big Data řešení. Zajímavostí je, že jméno Hadoop vzniklo podle jména plyšového slona syna jednoho z programátorů. Hadoop sestává z dvou klíčových komponent: 13

1. Big Data

Obrázek 1.2: Vizualizace principu Map & Reduce algoritmů

∙ Hadoop Distributed File System (HDFS) ∙ Map & Reduce 1.3.1.1

Map & Reduce

Princip Map & Reduce je prostý a je znázorněn diagramem 1.2. Velké úlohy (v tomto případě počítání frekvence slov ve vstupním textu) jsou rozděleny na menší úkoly (text rozdělen do jednotlivých vět), které jsou následně paralelně zpracovány jednotlivými procesory. Výsledky paralelního počtu jsou následně seřazeny a redukovány do výstupním množiny. Hadoop přijímá požadavky na jeden centrální (master) uzel a následně je distribuuje jednotlivým uzlům v clusteru funkcí MAP, která rozdělí vstupní požadavek na menší podproblémy pro jednotlivé instance. Uzel tuto funkci vyhodnotí (tato akce probíhá paralelně na všech uzlech, kterých může být teoreticky nekonečně mnoho), a vrátí výsledek master uzlu. Ten pak má na starosti agregaci takto získaných výsledků funkcí Reduce a navrácení výsledného subsetu dat uživateli. Funkce Map i Reduce se obvykle programují pomocí jazyka Java nebo C++. K ovládání Hadoop souborového systému tímto způsobem je tedy 14

1.3. Technologie potřeba poměrně vysoká technická znalost.

1.3.2

Reálné příklady Big Data

Přínosy a možnosti Big Data lze nejlépe demonstrovat na několika zajímavých příkladech reálného využití platformy. 1.3.2.1

Optimalizace hromadné dopravy v Africe

Za pomoci dat z mobilních sítí o pohybu mobilních telefonů obyvatel města lze vizualizovat a optimalizovat funkci hromadné dopravy ve městě Abidjan v Africe. Pohyb jednotlivých uživatelů (za současné aplikace rozličných podmínek, například, že je jich více pohromadě a jedou stejnou rychlostí stejným směrem, tedy pravděpodobně sdílí stejný dopravní prostředek) dokáže vykreslit jejich trasu. Množství těchto uživatelů pak znázorňuje vytíženost jednotlivých spojů, které lze podle potřeby posilovat, či přesměrovat klidnější částí města [17], [18]. 1.3.2.2

Projekt Narwal - Zvolení Barracka Obamy

Kadidát na amerického prezidenta, Barrack Obama, jako první v historii zapojil při své volební kampani Big Data řešení [19] a spekuluje se, že právě i díky tomu celou kampaň nakonec vyhrál, a stal se tak prezidentem USA. Jeho tým datových specialistů sbíral data o všech voličích ze všech dostupných informačních zdrojů, sociálních sítí, emailů, diskuzí s voliči, sbíral poznámky od lidí z terénu, porovnával lokality, ve kterých lidé bydlí, zjišťoval jejich potřeby, připravoval speciální na míru šité kampaně přesně podle toho, co daní voliči měli rádi (například, jaké mediální hvězdy mají vystoupit na jakém meetingu podle jejich popularity v dané oblasti). Tento příklad názorně ukazuje, jak velký vliv lze získat pouhou analýzou dostupných dat. 1.3.2.3

China Telecom

Zajímavým příkladem z pohledu objemu zpracovávaných dat je pak implementace Big Data řešení pro největšího mobilního operátora na světě, China Telecom [20]. Tato firma má více než 600 milionů klientů rozdělených mezi 31 samostatných poboček. Data generovaná klienty i samotným provozem sítě za rok 2012 dosáhla kolosálních rozměrů. Podpůrné systémy pro služby vygenerovaly 8000 TB, data primárně nasbíraná a určená pro pozdější business analýzu 7000 TB, log detailních informací o hovorech všech zákazníků 16 TB a záznamy pohybu všech zařízení podle jejich signálu generují pravidelně více než 1 TB denně. Tradiční centralizovaná řešení sestavená z so15

1. Big Data fistikovaných a drahých serverů byla nahrazena levnější cloud computing variantou založenou na třech datových centrech postavených na kombinaci lacinějšího hardware a tradičních Big Data technologiích, jako Hadoop a MapReduce framework pro distribuci a kolekci výpočtů nad daty. Všechna tato data jsou nyn přístupná k analýze, reportům a jakémukoli dalšímu využití. Značně se také zkrátila doba předzpracování dat, neboť je nyní možné ukládat je přesně v tom formátu, v jakém vznikla, což by předtím nebylo možné.

16

Kapitola

Analýza rozsahu a struktury informačních zdrojů Big Data, jak popisuje předchozí kapitola, se mohou sestávat z prakticky neomezeného množství informací různých druhů a původu. Customer Intelligence nicméně tuto variabilitu trochu limituje a usměrňuje pohled pouze na ty druhy zdrojů informací, ze kterých se lze dozvědět více o zákazníkovi. Každá organizace, která přichází do styku s koncovým klientem, o něm vede celou řadu záznamů. Od obecných informací, jako jméno, adresa či telefon, přes seznam produktů, které mu dodává, jeho platební morálku, případně všechny dotazy, které kdy položil pomocí emailu, sms, telefonu či jiného komunikačního média. Struktura těchto interních informací je více či méně rigidní, nicméně v zásadně velice podobná napříč různými organizacemi a hlavně velice strukturovaná. S rozvojem využívání internetu, sociálních sítí, blogů a diskuzních fór ovšem přibyl ještě další důležitý zdroj informací o tom, co klienti opravdu chtějí, zdroj veřejně dostupných informací, se kterým ovšem málokdo umí pracovat. To je zapříčiněno z části také tím, že se obecně moc neví, jaké informace by využíváním těchto zdrojů organizace vůbec mohly získat. Popsat strukturu všech těchto nových dat z webu z principu není možné, neboť je velice variabilní a liší se server or serveru. V rámci potřeb své práce se chci nicméně blíže věnovat vybraným zdrojům. V této kapitole přiblížím strukturu interních a externích dostupných informací, které mohou obsahovat informace o zákaznících, a které tak spadají do kontextu Customer Intelligence. U vybraných pak přiblížím metodu jejich získání a zpracování. 17

2

2. Analýza rozsahu a struktury informačních zdrojů

2.1

Veřejné zdroje

Kromě dostupných interních informací, které má každá organizace o svých vlastních klientech, se bitva o zákazníka bude v nadcházející době odehrávat především ve veřejném prostoru, tedy hlavně na webu. Ten je v současné době tvořen, kromě informačních portálů a diskuzních fór, především sociálními sítěmi. Pro potřeby své diplomové práce jsem zvolil tři největší zástupce těchto sítí, které jsou v rámci České republiky značně rozšířené a na kterých uživatelé (stávající i potenciální klienti) zveřejňují informace, jež by mohly být relevantní k businessu dané organizace. Tato sekce popisuje, jak jsou informace na těchto sítích organizovány a hlavně jak lze tato data získat pro další zpracování analytickými nástroji.

2.1.1

Facebook

Sociální síť Facebook je bezpochyby největší podobnou komunitní sítí na světě a je vysoce oblíbená i v rámci České republiky. Její zahrnutí do datových zdrojů potřebných pro tuto práci je tedy prakticky nutností. Než ovšem tato data využiji pro nějakou pokročilejší analýzu, je nejprve potřeba popsat, jaké informace a jakým způsobem lze z Facebooku vůbec získat. 2.1.1.1

Struktura dat

Všechny informace sdílené na sociální síti Facebook lze klasifikovat do tří základních struktur a tří základních forem, přičemž se každá liší svým významem a je potřeba s ní pracovat trochu jiným způsobem. profil Prvním struktura, se kterou se každý uživatel Facebooku okamžitě po registraci setká, je profil. Obsah profilové stránky Facebooku se nijak zvlášť neliší od podobných profilů jiných služeb a jeho primárním účelem je sjednocovat na jednom místě všechny informace o uživateli, všechny příspěvky, jejichž je autorem, příspěvky, ve kterých byl zmíněn a podobně. Uživatel má nad obsahem svého profilu plnou kontrolu, může skrývat příspěvky, které si nepřeje zobrazovat (přičemž skrytí příspěvku se nemusí vždy rovnat jeho smazání). Důležitým aspektem profilu, který je obzvláště důležitý v kontextu jeho následného využití v rámci Big Data analýzy, je jeho bezpečnostní nastavení. Když Facebook v roce 2005 začínal, bylo výchozím nastavením zabezpečení informací uživatelů zobrazování příspěvků, fotek a odkazů pouze jasně 18

2.1. Veřejné zdroje

Obrázek 2.1: Vizualizace výchozího nastavení bezpečnosti na sociální sítí Facebook v čase

definovanému okruhu přátel, případně širšímu okruhu přátel přátel. Postupem času se ovšem tato politika měnila až do stavu, který panuje dnes, kdy je výchozím stavem zobrazování informací všem uživatelům sociální sítě, případně rovnou všem uživatelům internetu. Ačkoli uživatel má vždy možnost toto nastavení změnit a informace skrýt, vyžaduje to od něj již akci navíc a spousta z nich tak raději nechá nastavenu onu výchozí sdílnost se světem. Výchozí nastavení má přitom zásadní vliv na konečnou volbu uživatele, jak nám ukazují jiné výzkumy, především z oblasti behaviorální ekonomie, jako například Posner [21] či Kahneman [22]. Na to Facebook samozřejmě spoléhá především z komerčních důvodů, neboť bez veřejně dostupných informací by nemohl tak kvalitně cílit reklamy, které jsou hlavním zdrojem příjmů, a je to vhodné i pro externí subjekty, které chtějí tato data vytěžovat. Nejlépe tento přerod bezpečnostní politiky, ale i současný stav, zobrazuje tato vizualizace 2.1. Jednotlivé vrstvy znázorňují různé publikum, kterým jsou dané sekce informací (ve sloupci) viditelné. První vrstvou jsou přímí přátelé, druhou vrstvu reprezentují přátelé přátel, třetí všichni ostatní uživatelé sitě Facebook a poslední pak celý zbytek internetu. Modrá barva pak reprezentuje výchozí nastavení "zobrazovat"pro každý nově založený profil. 19

2. Analýza rozsahu a struktury informačních zdrojů stránka Veřejná obdoba uživatelského profilu je struktura stránky. Tato struktura slouží především pro veřejné účely a je využívána hlavně firmami pro vlastní prezentaci na sociální síti, známými osobnostmi a podobně. Rozdílem, oproti uživatelskému profilu, je možnost sledovat obsah libovolné stránky bez nutnosti dotazovat se kohokoli na explicitní povolení. Dá-li stránka svým čtenářům dostatečná práva (respektive ponechá-li jim je, jelikož jsou dána všem automaticky ve výchozím nastavení), mohou na stránku přispívat své statusy, komentovat statusy ostatních uživatelů, případně jim dát like. Veškerý obsah stránek, stejně jako příspěvky jiných uživatelů na tyto stránky přidané jsou pak veřejně dostupné, není-li administrátorem stránky nastaveno jinak. skupina Chce-li uživatel komunikovat s vybranou skupinou jiných uživatelů, může založit vlastní skupinu, další důležitou strukturu Facebooku. V rámci skupiny pak mohou nezávisle komunikovat a veškeré informace jsou pak viditelné pouze členům. Sama skupina přitom může mít nastavena práva viditelnost na úrovni úplného skrytí až po veřejnou skupinu, do které se může přihlásit každý uživatel bez vědomí správce. status je základním formou informací sdílených na Facebooku. Chce-li uživatel sdělit nějakou informaci svým přátelům či odběratelům (což je zvláštní druh vztahu [23], jehož smysl je víceméně podobný akci follow [24], dostupnou na Twitteru), napíše ji ve formě statusu. Status má formu krátké zprávy, která má primárně textovou podobu. Uživatel může do statusu vložit i obrázek, video či libovolný odkaz na jinou webovou stránku. Do každého statusu ovšem může vložit maximálně jeden tento objekt. Chceli například sdílet video i obrázek, musí je rozdělit do dvou samostatných příspěvků. komentář Informace ve formě komentáře se vždy bez výjimky vztahuje k již existujícímu statusu, a nemůže tak existovat samostatně. Obsahem komentáře může být buď čistá textová informace, či odkaz na jiný webový server nebo video. Do komentáře není možné nahrát obrázek. like Like je nejjednodušší formou vyjádření názoru. Uživatel pouhým kliknutím vyjadřuje svůj souhlas/podporu/obdiv danému produktu, stránce, komentáři, názoru a podobně. Pro potřeby praktické části jsou důležité především ty struktury a formy, které jsou veřejně dostupné a které tedy mohou posloužit jako zdroj dat. 20

2.1. Veřejné zdroje Proto bude další pozornost zaměřena především na stránky a letmo i profily uživatelů. 2.1.1.2

Akvizice dat

Data ze sociální sítě Facebook lze získat poměrně přímým způsobem pomocí Facebook Graph API [25]. Toto programovatelné rozhraní umožní přístup prakticky ke všem údajům, které se na síti Facebook nachází, s tím, že konkrétní míra detailu získaných informací záleží na nastavení bezpečnosti daného zdroje a vztahu autora stahovací aplikace a cílového subjektu (což platí především u uživatelských profilů). Tím se dostáváme k samotné metodě získání těchto dat. Každý vývojář, který chce toto API použít, se nejprve musí na síti Facebook zaregistrovat a následně požádat o vytvoření "aplikace", což je termín, kterým Facebook označuje jakoukoli hru/aplikaci/externí objekt, který s API chce pracovat. Tato aplikace následně dostane přidělený svůj unikátní identifikační kód (App Id) a tajný unikátní identifikační kód (Secret App Id). Tyto dva údaje jsou klíčové pro jakoukoli práci s Facebook API a bez nich není žádné dolování dat možné. Ve chvíli, kdy uživatel/vývojář má oba klíče, může si z nich nechat vygenerovat tzv. access token, tedy přístupový klíč, který následně musí zahrnout do všech volání Facebook Graph API. Konkrétní proces procházení dostupných struktur a forem informací je popsán v praktické části 6.1.4.1. 2.1.1.3

Dostupné údaje

Pomocí implementace aplikačních rozhraní na dostupné veřejné zdroje (především tedy profily/stránky českých bank) jsem identifikoval informace, které jsou tímto způsobem získatelné, a které tedy lze využít v následné analýze. Jde o následující hodnoty:

21

2. Analýza rozsahu a struktury informačních zdrojů status id message author id author name unique link type link created time updated time # likes likes profiles # comments comments profiles picture name caption description link type

Unikátní ID příspěvku/komentáře v rámci sítě. Textový obsah příspěvku/komentáře. Unikátní ID autora příspěvku/komentáře. Jméno autora. Unikátní URL adresa na příspěvek. Typ příspěvku. Je-li příspěvek typu link, obsahuje URL. Čas vytvoření příspěvku. Čas poslední modifikace. Počet like příspěvku. Seznam všech lidí/profilů - autorů like. Počet komentářů příspěvku. Seznam všech profilů autorů komentářů. Pokud je typ picture, obsahuje URL obrázku. Pokud jde o typ "story", obsahuje název příspěvku. Pokud jde o typ "story", obsahuje podtitulek. Pokud jde o typ "story", obsahuje popis. Pokud je status odkaz, obsahuje jeho typ.

uživatel id name first name last name gender locale unique link username about category description founded # likes # mentions phone products website 22

Unikátní ID uživatele v rámci Facebooku. Celé jméno uživatele. Křestní jméno uživatele. Příjmení uživatele. Pohlaví uživatele. Řeč uživatele. Unikátní URL na profil uživatele ve tvaru. Uživatelské jméno uživatele, pokud si jej definoval. Informace o uživateli. Většinou u firemních profilů. Kategorie (odvětví) uživatele. Popis uživatele. Datum založení uživatele. Počet liků, které má uživatel. Počet zmínek o uživateli jinými uživateli. Telefonní kontakt na uživatele. Seznam produktů uživatele. Webová stránka uživatele.

2.1. Veřejné zdroje

2.1.2

Google+

Sociální síť Google+ je druhou největší světovou sociální sítí, a je tak přímým konkurentem Facebooku i v oblíbenosti mezi uživateli. Nejde ovšem o přesnou kopii Facebooku, síť nicméně kombinuje celou řadu jeho principů a přidává i funkce jiných sítí (například Twitteru). Tato sekce popisuje strukturu informací dostupných Google+ i jejich konkrétní formu, stejně jako metody získání těchto dat. 2.1.2.1

Struktura dat

kruh je základní strukturou sítě Google+ a je tím, co jej nejvíce odlišuje od ostatních sociálních sítí, primárně tedy od Facebooku. Základní myšlenka vzniku kruhů je jednoduchá - uživatel má sice více přátel/známým, ale nechová ke všem stejnou důvěru a pravděpodobně by uvítal možnost oddělit určitou skupinu přátel od jiné. K tomu přesně slouží kruhy. Každý uživatel může vytvořit libovolné množství kruhů a pozvat/přidat do nich libovolné množství ostatních Google+ uživatelů. Jedním okruhem mohou být kolegové z práce, druhým přátele ze školy a tak podobně. Při sdílení jakéhokoli přispěvku (aktivity, viz dále) si pak může vybrat, kterému kruhu bude daný příspěvek viditelný, případně jej samozřejmě zobrazit globálně všem. profil je velice obdobná struktura, jakou má Facebook. Každý uživatel má svůj unikátní profil, na kterém udržuje (pokud samozřejmě chce) informace o sobě, své fotografie, videa a další. Samotný obsah stránky je pak viditelný podle přidělených práv jednotlivým příspěvkům. Zajímavostí je, že Google+ dle výchozího nastavení poskytuje pomocí API více informací než Facebook, jako například zaměstnání uživatele, bydliště, seznam škol a tak dále. Vše lze samozřejmě explicitně omezit v nastavení profilu, jak jsem ale již zmínil v případě sociální sítě Facebook, vyžaduje to extra operaci, a mnoho uživatelů tak nechává vše přístupné. Zásadní informací ovšem je, že Google podmiňuje využívání této služby registrací pod skutečným jménem [26], což je velice přínosné z pohledu vytěžování dat a párování uživatelských účtů s reálnými klienty stránka je opět velice podobná strukturou i povahou informací stránce na Facebooku. Většinou využívaná organizacemi pro veřejnou prezentaci a komunikaci se zákazníky. Ti mají opět možnost na stránku přispívat, komentovat aktivity a další. 23

2. Analýza rozsahu a struktury informačních zdrojů komunita je využívána především pro sdružování lidí s podobnými zájmy, o kterých v rámci komunit diskutují. Obsah v komunitách je tedy obecnějšího charakteru než stránka, která se většinou týká pouze jedné konkrétní věci (firmy). aktivita je v kontextu sítě Google+ synonymum pro příspěvek. Chce-li uživatel sdílet jakoukoli informaci ať již textovou, obrázek, video či odkaz, výsledkem je vždy aktivita. Ta se od statusu na Facebooku zásadně liší tím, že může obsahovat více druhů informace, na rozdíl o statusu, který je pouze jednoho typu (buď pouze text, nebo pouze video, pouze fotografie a tak dále). Do aktivity tedy může uživatel například vložit video i obrázek dohromady. Na tuto skutečnost je potřeba vzít ohled při vytěžování těchto informací. 2.1.2.2

Akvizice dat

Obdobně jako u sítě Facebook i zde je dostupné API pro přímý přístup k veřejně dostupným údajům. Vývojář si nejprve musí vytvořit uživatelský účet (případně využít již existující účet na jiných službách Gogole, jako například Gmail, Youtube a podobně) a následně pak vytvořit aplikaci. Stejně jako na Facebooku mu tento krok vygeneruje unikátní klíč, který pak musí používat při volání API pro identifikaci. Google poskytuje ke svému aplikačnímu rozhraní knihovny pro většinu používaných programovacích jazyků pro snadnější manipulaci se službou Google+. Například seznam aktivit pro daného uživatele v Javě získáme zavoláním tohoto URI. plusService.activities().list(userId, "public"); Seznam komentářů pro danou aktivitu pak získáme zavoláním následujícího URI. plusService.comments().list(activityId); 2.1.2.3

Dostupné údaje

Oproti Facebooku lze ze sociální sítě dostat ve výchozím nastavení více informací o uživateli, což se pro potřeby vytěžování dat velice hodí. Konkrétně jde například o seznam škol, na kterých uživatel studoval, či seznam pracovních pozic a tak podobně. Následuje přehled všech údajů, které se dají pomocí API zjistit.

24

2.1. Veřejné zdroje aktivita id title published updated url author.id author.name verb object object.content object.originalContent object.URL object.replies object.plusoners object.resharers object.attachments type geocode address uživatel id name given name family name gender birthday currentLocation aboutMe relationshipStatus organizations org.name org.department org.title org.type org.startDate - endDate placesLived emails language ageRange

Unikátní ID aktivity. Titulek aktivity. Čas vytvoření aktivity. Čas poslední modifikace. Unikátní URL adresa aktivity. Unikátní ID autora příspěvku/komentáře. Jméno autora. Určuje, jestli byla aktivita vytvořena, či sdílena. Samotný obsah aktivity. HTML formátovaný obsah aktivity Text aktivity bez HTML formátování URL na přiložený zdroj (video,..) Komentáře aktivity Seznam profilů, kteří dali aktivitě +1 Seznam profilů, kteří sdíleli aktivitu Přiložené objekty. Typ příspěvku. Geografická poloha aktivity. Adresa aktivity.

Unikátní ID uživatele v rámci sítě. Celé jméno uživatele. Křestní jméno uživatele. Příjmení uživatele. Pohlaví uživatele. Datum narození. Poloha uživatele. Volný popis uživatele, jím vložený. Říká, zda je uživatel zadaný. Seznam zaměstnání/škol. Název organizace. Název oddělení/fakulty. Název pracovní pozice/oboru. Práce/škola. Od kdy do kdy byl v organizaci. Objekt s místy, kde uživatel bydlel/bydlí. Objekt s všemi emaily uživatele. Preferovaná řeč uživatele. Věk uživatele v rozmezí. 25

2. Analýza rozsahu a struktury informačních zdrojů

2.1.3

Twitter

Sociální síť Twitter je primárně určena pro okamžité sdílení myšlenek uživatelů se světem. Tato sekce popisuje strukturu dat dostupnou na této síti 2.1.3.1

Struktura dat

Struktura sítě Twitter je ve své podstatě velice plochá. Nejsou tu žádné skupiny, stránky ani jiné složitější seskupení uživatelů. Každý má pouze svůj profil, na který umisťuje své tweety. tweet neboli příspěvek, je jediným způsobem sdílení informací na této síti. Každý tweet je omezen 140ti znaky a toto omezení nelze nijak obejít. V rámci tohoto krátkého prostoru může každý uživatel kromě samotného textu zmiňovat určitá témata pomocí tzv. hashtagů, podle kterých se pak dá napříč všemi tweety vyhledávat. Týká-li se tak například tweet sportu, může jej uživatel označit #Sport, týká-li se politiky, může přidat tag #politika. Vyhledá-li si jiný uživatel právě tento tag politika, zobrazí se mu všechny tweety, u kterých byl tento tag uveden. Jeden tweet přitom může mít i více hash tagů 2.1.3.2

Akvizice dat

Twitter poskytuje ke svým službám API, pomocí kterého lze jednotlivé tweety sbírat. Důkladnější popis rozhraní (Twitter nabízí dva přístupy práce s API přičemž oba se značně liší) následuje v praktické části. Základní princip je nicméně shodný prakticky se všemi ostatními sociálními sítěmi. Chce-li vývojář pracovat s API Twitteru, musí si na něm nejprve vytvořit uživatelský účet a na tento účet registrovat aplikaci. Ta dostane přidělen unikátní kód, který pak používá v komunikaci s rozhraní pro ověření identity uživatele.

26

2.1. Veřejné zdroje 2.1.3.3

Dostupné údaje

tweet id text created_at source geo entities user retweet_count favorite_count uživatel id name screen_name location description created_at followers_count friends_count time_zone geo_enabled statuses_count

2.1.4

Unikátní ID tweetu. Obsah tweetu, max 140 znaků. Čas vytvoření tweetu. Zdroj tweetu. GEO souřadnice tweetu. Zajímavé objekty v tweetu. Autor tweetu. Počet retweetnutí (sdílení). Počet "like"tweetu.

Unikátní ID uživatele v rámci Twitteru. Celé jméno uživatele. Zobrazované jméno, může se lišit od skutečného. Poloha uživatele, pokud sdílí. Volný popis uživatele, jím vložený. Datum vytvoření uživatelského účtu. Počet uživatelů, kteří sledují daný profil. Počet uživatelů, přátel daného profilu. Časové pásmo uživatele. Flag jestli má uživatel zapnuté sdílení polohy. Počet tweetů od založení účtu.

Mediální servery

Kromě sociálních sítí lze celou řadu informací nalézt například na mediální webech. Na těch se kromě tradičních článků velice živě diskutuje a může to tak být potenciální zdroj vědomostí o klientech a jejich pohledu na danou organizaci. Problémem těchto serverů je, že nemají žádné unifikované API, a pokud je chceme využít, je potřeba z nich nejprve dostat dostupná data. Nelze příliš popisovat obecnou dostupnou strukturu, neboť se liší web od webu. Pro demonstraci lze nicméně popsat strukturu na jednom z nejznámějších mediálních serverů v České republice - iDNES.cz. 2.1.4.1

iDNES.cz

Tento server je velice populární a pravidelně se umisťuje na předních příčkách v různých anketách oblíbenosti uživatelů českého webu a podobně. 27

2. Analýza rozsahu a struktury informačních zdrojů Z pohledu vytěžování dat obsahuje dva typy příspěvků - články a diskuzní příspěvky.

články jsou publikovány pracovníky redakce iDNES.cz a mají prakticky stabilní strukturu (viz obrázek 2.2). Kromě titulku a samotného textu obsahují informace o datu a času vytvoření článku a jménu autora. Jiné podobné mediální servery u článků ještě například uvádějí počet like na sociální síti Facebook a podobně.

Obrázek 2.2: Vzorová struktura článku ze serveru iDNES.cz

diskuze je pak u většiny serverů velice podobná. Jednotlivé komentáře jsou řazeny do souvisejících vláken. U každého příspěvku je většinou uvedeno jméno autora, jeho identifikátor a samozřejmě také datum a čas přidání příspěvku. Na příkladu příspěvku z iDNES.cz (viz. obrázek 2.3) vidíme, že se často uvádí i počet pozitivních a negativních bodů (ekvivalent vyjádření souhlasu s funkcí like na Facebooku). Uživatel může nahrát svou fotografii, ta nás však v kontextu vytěžování textových nestrukturovaných dat příliš nezajímá. 28

2.2. Interní zdroje

Obrázek 2.3: Vzorová struktura diskuze ze serveru iDNES.cz

2.2

Interní zdroje

Interní zdroje jsou pro většinou organizací zásadním assetem a v podstatě z velké části tvoří jejich know how. O svých klientech si uchovávají všechny možné informace a v interních dokumentech lze dohledat prakticky celou jeho minulost. Celá řada takto archivovaných informací je ovšem nestrukturovaných a nebyl na ně brán zřetel. Tato kapitola rozkrývá tato data s cílem poukázat na možné informace, které by se v nich mohly skrývat a které by obohatily výstupy Customer Intelligence.

2.2.1

Emailová komunikace

Email je častým způsobem komunikace zákazníka s firmou, zejména pak kvůli jednoduchosti, relativně vysoké efektivitě a velice nízkým nákladům na odeslání, jelikož jediné, co je k odeslání potřeba, je emailový klient a připojení k internetu. Tato sekce popisuje informace obsažené v emailech a možnosti využití emailů v kontextu pokročilé analytiky. 2.2.1.1

Informace v emailech

Nejrelevantnějším přínosem emailů, v kontextu tématu této práce, je samotné textové tělo a samozřejmě předmět emailu. Ostatní atributy jsou poměrně strukturované (jako například emailová adresa). Z dotazu na pojištění na cesty se totiž například dá odvodit, že zákazník bude někam 29

2. Analýza rozsahu a struktury informačních zdrojů cestovat. Pokud se ptá na pojištění pro celou rodinu, je vysoce pravděpodobné, že nepojede sám. A ptá-li se na podobnou otázku již podruhé za krátký časový úsek, dá se usuzovat, že do zahraničí jezdí často. Pokud jako firma (pro snazší demonstraci se budu držet modelového příkladu banky) vím takovouto informaci, mohu kombinací s dalšími vstupy vybrat, či vytvořit pro daného klienta produkt na míru, například pravidelné pojištění na cesty, a přímo jej s touto nabídkou oslovit. Jelikož zákazník dlouhodobě projevuje o podobný produkt zájem, je tento přístup diametrálně odlišný od hromadného rozeslání nabídky všem klientům. Zákazník takto získá pocit, že je pro organizaci důležitý, a že opravdu rozumí jeho potřebám, není pouze jeden z davu. Bude také více nakloněn koupi produktu. Bez pokročilého analytického nástroje pro analýzu nestrukturovaných dat je však prakticky nemožné tyto klíčové informace z emailů dostat, pomineme-li možnost jejich manuálního zpracování/přečtení. To sice lze v omezené míře praktikovat, s rostoucím množstvím emailů ovšem časová náročnost tohoto přístupu prakticky zamezuje jeho reálnému nasazení. Při množství, které každý den průměrná banka dostává (viz [2], [27]), prostě není možné všechny tyto emaily přečíst a informace si zaznamenat do interních systémů. Automatizace v tomto kroku je zcela nezbytná. 2.2.1.2

Automatická klasifikace

Zmíněná efektivita komunikace pomocí emailu má své jasně dané hranice a ty se vzdalují s přibývajícím množstvím emailů ve schránce organizace. Zákazníkovi, který má dotaz nebo připomínku, by se mělo odpovědět co nejdříve, ideálně okamžitě, což ale v záplavě všech mailů často není možné. Velké organizace nejčastěji volí metodu automatické odpovědi ve stylu "Během X pracovních dní Vaši žádost vyřídíme", to již ale může být pozdě. Klient mnohdy nepotřebuje komplexní a kompletní radu, ale vystačil by si i s obecnější, nicméně tématu se týkající radou, která ho alespoň pro začátek nasměruje. Typickým příkladem v bankovním sektoru by mohl být například email s poptávkou na nějaký produkt (například pojištění či hypotéku). Místo automatické odpovědi (jako například text: "Děkujeme za Váš email, brzy se Vám ozveme) by mohl být uživateli automaticky odeslán email s odkazem na určitou sekci webu, ve které si poptávaný produkt může sám vyhledat. Poznat automatizovaně téma, kterého se email týká, ovšem není nic jednoduchého. Analytický nástroj musí podporovat takzvanou automatickou klasifikaci, což je proces, během kterého je vstupnímu textu přiřazena podle jeho určitých charakteristik kategorie/třída, na základě které je nadále s tímto dokumentem nakládáno. Klasifikační nástroj se pro správnou funkčnost musí nejdříve natréno30

2.2. Interní zdroje vat na určité množině trénovacích dat, u nichž je kategorie předem známá. V případě emailů je tedy potřeba mít určité množství textů předem připravených, manuálně jim nastavit kategorie (stížnost, dotaz, faktura,..) a nechat pak engine přečíst text a najít v nich ty, jež jsou svou strukturou, či výrazy v nich obsaženými, podobné určité kategorii. V emailech, které se budou týkat dotazu na produkt, se například mohou často opakovat konkrétní jména produktů dané firmy, slova "najít, dohledat"nebo prosté "dotaz", v emailech se stížností pak "stížnost, problém, nefunguje"a tak podobně. Přesnost samotné klasifikace samozřejmě záleží na celé řadě faktorů, na velikosti testovací množiny, na rozdílnosti jednotlivých textů a podobně. Pokud by byl rozdíl v několikastránkových emailech pouze v pár použitých výrazech, klasifikační engine snadno zařadí dokument do špatné kategorie. Téma automatické klasifikace, jejího nastavení a optimalizace přesnosti by vydalo na samostatnou diplomovou práci. 2.2.1.3

Pořízení dat

Emailová data jsou poměrně snadno dostupná z interních mailových serverů (typicky Exchange či Lotus Domino), případně pomocí standardních protokolů POP3 nebo IMAP. Integrace emailových serverů tedy nepředstavuje překážku.

2.2.2

Interní poznámky

Celá řada organizací si vede o svých klientech poznámky s vidinou, že se někdy v budoucnu budou hodit. Tato praxe je běžná hlavně u těch firem, které přichází do přímého kontaktu s klientem (opět jsou klasickým příkladem bankovní domy) a které mají s klientem důvěrnější vztah. Přijde-li klient na přepážku banky například s žádostí o půjčku, zeptá se ho nejspíš pracovnice mezi řečí i na to, k jakému účelu půjčku potřebuje, kolik peněz má již našetřeno, kolik bude celkově potřebovat a podobně. Je-li klient sdílný, zmíní se, že se chystá na dovolenou, nebo že si chce pořídit motocykl. Pracovnice přepážky si tyto informace poznamená do interní aplikace (často přímo do iterního CRM systému viz [28]). Takto získané poznámky nemusí mít samy o sobě vysokou přidanou hodnotu, nicméně jejich kombinací s informacemi získanými z ostatních zdrojů (ať interních, či externích) a zasazením informací do kontextu lze opět o něco přesněji dokreslit obraz klienta a lépe na něj cílit produkty či služby. Klient může mezi řečí zmínit, že by si rád pořídil nové auto (i když původně přišel kvůli splátce hypotéky). Jelikož banka vede i jeho účet a zná jeho interní záznamy (zůstatek na běžném účtu, platební historii a tak dále) 31

2. Analýza rozsahu a struktury informačních zdrojů může, pokud informaci o přání nového vozu včas zachytí, oslovit klienta se speciální na míru ušitou nabídkou půjčky na nákup nového automobilu.

2.2.2.1

Pořízení dat

V tomto kroku velice záleží na tom, kde a jak jsou poznámky skladovány. Ve velkém procentu případu to bude v nějaké databázi bez ohledu na způsob jejich pořízení (pomocí dedikované aplikace, CRM systému a dalších metod). Poznámky také mohou být ukládány na souborový systém. V obou případech nečiní jejich vytěžení či integrace s analytickým nástrojem žádné větší problémy a lze ji provést pomocí standardně dostupných technologických nástrojů.

2.2.3

Přepisy telefonních hovorů

Klienty často preferovaným způsobem komunikace s organizacemi je přímý telefonní kontakt. Běžnou praxí jsou tak například dedikované telefonní linky (ústředny) či hlasového automaty, pomocí kterých lze snadno a rychle vyřešit nejběžnější problémy. Pokročilejší dotazy (které nespadnou do připravených kategorií) bývají přesměrovány na operátory. Není asi tajemstvím, že i tento informační kanál je důkladně monitorován a právě hovory s operátory jsou často nahrávány pro jejich možné pozdější využití. K tomu je ovšem potřeba buď jednotlivé hovory poslechnout a analyzovat manuálně, což je extrémně náročné jak na čas, tak na lidské zdroje, nebo je hovory přepsat na text a ten pak analyzovat. Princip analýzy těchto přepisů je pak identický s analýzou například emailové komunikace - vždy jde o to z textu (v tomto případě tedy přepis rozhovoru) dostat zajímavé informace či témata, kterých by šlo businessově využít. Klíčovým úkolem u tohoto média je právě onen přepis zvukového záznamu na text, který se pak dále použije jako vstup analytickému nástroji. Nejdůležitějším prvkem při přepisu je přitom použitý engine a jeho přesnost přepisu řeči na text. V kontextu České republiky je pak klíčová podpora a správné rozeznání českého jazyka. V praxi jsem se setkal především s enginem Watson od společnosti IBM [29] a dále pak s produktem univerzity v Liberci, enginem Newton [30]. Měl jsem možnost obě řešení vyzkoušet a musím konstatovat, že pro český jazyk byl přepis pomocí Newton engine přesnější (až 94% [?]), pro angličtinu a další světové jazyky ovšem zcela jasně převládla síla a robustnost Watsona, s jeho téměř 100% přesností přepisu u anglického jazyka. 32

2.2. Interní zdroje 2.2.3.1

Pořízení dat

Výsledkem přepisu hovorů jsou textové soubory, případně speciálně formátované XML soubory, které umožňují odlišit jednotlivé věty volajícího a operátora. V každém případě lze tyto soubory importovat do analytického nástroje stejným způsobem jako jakékoli jiné dokumenty na souborovém systému. Jak již bylo řečeno výše, klíčovým okamžikem u tohoto druhu média tedy není samotný import dat, ale jejich přepis z hlasu na text. Kvalita tohoto přepisu i přepis samotný je nicméně mimo rámec mé diplomové práce. Pro potřeby praktické části používám již přepsané texty (byť falešné, přesto simulující reálný stav).

2.2.4

Další zdroje informací

Nelze se 100% přesností predikovat všechny informační kanály, které mají organizace dostupné, neboť se tato množina značně liší podle segmentu, ve kterém organizace podniká, její velikosti a tak dále. Relativně rozšířeným způsobem získávání informací jsou marketingové kampaně, od road show po dotazníky. Klienti mohou s firmou komunikovat pomocí sms, posílat dotazy na firemní diskuzní fórum (jaké má v České republice například banka mBank [31]). Důležitá je zejména schopnost propojit informace získané z těchto komunikační kanálů do jednoho konsolidovaného pohledu, neboť se z jednotlivých střípků dá dohromady poskládat věrný obraz klienta, na kterém se dá pak dále stavět. Z pohledu analytického nástroje je zcela lhostejné, odkud data původně pocházejí, pokud se dají importovat. Nemusí to tak nutně být pouze čistě textová data, ale rozmanité registry osob, domů a bytů (katastr nemovitostí), všechny možné PDF dokumenty, tabulky a tak dále. Možnosti v této oblasti jsou zcela otevřené.

33

Kapitola

Právní a morální aspekt Big Data "Rules are not necessarily sacred, principles are [32]." Jak plyne z textu předchozích kapitol, popisujících principy Big Data platformy, zajímavá data již existují. Z následujících kapitol pak vyplyne, že i technologie potřebné k jejich vytěžení jsou již realitou. Myšlenky zaobírající se pokročilou analýzou dat, jejich vzájemným spojováním, hledáním vzorců chování a následným využitím takto získaných informací k čistě business účelům, jako je například oslovení s nabídkou na míru, již nejsou science fiction, ale realitou dnešních dní. Ruku v ruce s tímto tématem ovšem musí zaznít i téma úzce související, a to jsou právní aspekty této oblasti a v neposlední řadě aspekty morální. Data pro samotnou analýzu, pokud samozřejmě nejde čistě o data interní, je potřeba někde získat, zpracovat a pravděpodobně následně uložit. Nasazením pokročilých algoritmů a výkonných systémů následně může v datech odhalit i věci, které raději měly zůstat ukryty a podobně. Nemusí přitom nutně jít o věci nelegální, zakázané či v rozporu s nějakými ustanoveními. Stačí i choulostivé či jinak citlivé informace, na které, i když to třeba žádný zákon výslovně nezakazuje, by již z morálního hlediska měly být brány ohledy. Mezi businessem, právem a morálkou je v této oblasti moderních informačních technologií hranice užší než kdekoli jinde, a je proto potřeba tuto problematiku prozkoumat podrobněji. Považuji za naprosto zásadní zahrnout tuto kapitolu do své práce i přesto, že nejsem vzdělán v oboru práva, a můj výklad zákonů je tak značně omezen. Z tohoto důvodu jsem navštívil několik akcí a konferencí s tématikou práva v Big Data, kde jsem své otázky diskutoval s právníky z oboru, příkladně s právníky firmy Bird & Bird, kteří se specializují na právo v oblasti informačních technologií. I přes tyto skutečnosti není následující 35

3

3. Právní a morální aspekt Big Data text nijak právně závazný a je možné, že jiný právník bude mít jiný výklad zmiňovaných zákonů.

3.1

Zpracování veřejně dostupných informací

Oblast zpracování veřejně dostupných informací je naprostou klíčovou pro budoucnost Big Data v šíři, jakou má práce popisuje. Představuje nicméně největší výzvu z právního pohledu, neboť jde do jisté míry o zásah do elektronického soukromí jednotlivce, a představuje tak velkou třecí plochu názorů. Kapitolu je potřeba uvést zjištěním, že oblast právního zajištění Big Data je v současné době regulačními orgány prakticky nedotčená a ještě nějaký čas bude trvat, než se možnostem a realitám Big Data všechny zákony, vyhlášky a směrnice přizpůsobí.

3.1.1

Legislativní rámec

Obsah Big Data je rozličný: od audiovizuálních záznamů, přes osobní či provozní a lokalizační údaje až po případná obchodní tajemství. Právní ošetření všech možných případů vyžaduje zahrnout do úvah větší množství legislativních nástrojů, které pokrývají jednotlivé oblasti, a dosáhnout řešení jejich kombinací. Zpracováním informací, jejich získáním, uchováváním a jakoukoli další prací s nimi se zabývají především následující zákony a právní dokumenty. Z nich jsem čerpal informace a na jejich základě jsem vedl diskuzi s oslovenými právníky. 1. Zákon č. 101/2000 Sb., o ochraně osobních údajů Nejdůležitější zákon z pohledu koncového uživatele (osoby aktivní ve veřejně dostupném prostoru webu), který zavádí pojmy jako osobní údaj, citlivý údaj, určuje režim nakládání s osobními údaji, sankce v případě porušení povinností stanových tímto zákonem, zavádí pojmy jako správce dat a další. Zákon je platný hlavně pro právnické osoby. Na data a informace získaná a analyzovaná pro potřeby mé diplomové práce se tento zákon nevztahuje. §3 odstavec 3 Tento zákon se nevztahuje na zpracování osobních údajů, které provádí fyzická osoba výlučně pro osobní potřebu. Na data zpracovávaná pro komerční účely již ovšem ano. 36

3.1. Zpracování veřejně dostupných informací 2. Zákon č. 480/2004 Sb. o některých službách informační společnosti Zákon definuje a upravuje práva a povinnosti při provozování informačních služeb (například emailu a dalších), vymezuje práva a odpovědnost provozovatele za obsah a zavádí dozor nad dodržováním těchto pravidel. 3. Zákon č. 127/2005 Sb., o elektronických komunikacích Zákon upravuje především činnost podnikatelů poskytujících veřejně dostupné služby elektronických komunikací (převážně operátorů) a správu geolokačních dat. Tento zákon je tedy důležitý ve chvíli, kdy by právnická osoba (firma) chtěla využívat polohu svých klientů pro své obchodní účely (nabídky na míru ve chvíli, kdy je klient v určité lokalitě atd.) Tohoto tématu se pak týká především Hlava V Ochrana údajů, služeb a sítí elektronických komunikací Díl 1 Ochrana osobních, provozních a lokalizačních údajů a důvěrnost komunikací § 87 - § 91 4. Zákon č. 121/2000 Sb., autorský zákon Pokud by bylo obsahem analyzovaných dat i nějaké autorské dílo (ať již textové, audiovizuální či jiné podoby), musel by být brán v potaz i tento zákon.

Je velice složité predikovat všechny situace, které mohou v kontextu Big Data nastat, a podle mého názoru i názoru mnou oslovených právníků si s tímto tématem neví zatím rady nejenom česká, ale ani zahraniční justice. Nikdo stále neví, kde přesně jsou hranice virtuálního prostoru a pomyslné absolutní svobody slova, projevu a s tím spojené svobody nakládat s informacemi dle libosti a kde je již reálný svět plný pravidel a zákonů. Příkladem může být soudní případ z Velké Británie, kdy byl muž vzat do vazby na základě svého příspěvku na sociální síti Facebook [33]. 90% dostupných dat na webu bylo vytvořeno během posledních 2 let [34] a státní správa, respektive zákony, na tuto situaci nebyly dostatečně dopředu připraveny. Zákony byly většinou psány v době, kdy nikdo netušil, co Big Data opravdu jsou, jinak řečeno, data ještě nebyla "big"a ani jejich postupná novelizace tuto situaci zatím příliš nevylepšila. Evropská unie i celý svět se snaží celé toto nově vznikající odvětví právně ukotvit a postihnout všechny eventuality, bude to ale 37

3. Právní a morální aspekt Big Data ještě nějaký čas trvat a výsledek určitě nebude mít podobu jednoduchého předpisu, který bude "pasovat"na vše. V současné době ovšem zákony neodrážejí současné potřeby a rychlý vývoj této oblasti.

3.1.2

Získání údajů

První a klíčovou otázkou ve chvíli, kdy se právnická osoba (organizace) chce pustit do vytěžování veřejně dostupných dat, je "Jak a kde tato data získat?" a následná pak "Jak s nimi můžu nakládat?". Data, o kterých je řeč, jsou například veřejně přístupná na webových stránkách, informačních portálech (jako příklad lze uvést informační portál iDNES.cz [35] , Novinky.cz [36] či IHNED.cz [37]) či sociálních sítích. Každý z těchto serverů má své provozní podmínky, se kterými musí uživatel (potenciální klient a autor příspěvků) většinou souhlasit ještě, než přidá svůj příspěvek do systému provozovatele. V rámci těchto podmínek si každý provozovatel určuje míru oprávnění, jak s daty získanými od uživatele může nakládat. Může to být pouze právo manipulovat s daty, ale stejně tak si může do svých podmínek vložit možnost poskytnout data třetí straně, či je jakkoli jinak modifikovat, upravovat, doplňovat a podobně. Tuto aktivitu upravuje hlavně Zákon č. 121/2000 Sb. HLAVA III - Zvláštní právo pořizovatele databáze §88 - §94, který zavádí důležitý pojem pořizovatele databáze (§89). Pořizovatel databáze je fyzická nebo právnická osoba, která na svou odpovědnost pořídí databázi, nebo pro kterou tak z jejího podnětu učiní jiná osoba [38]. Tato osoba navíc musí do vytvoření databáze vložit podstatný vklad (§88a), který musí být kvalitativně nebo kvantitativně významný. Nestačí tak tedy data odněkud pouze zkopírovat a získat tím práva pořizovatele. Splňuje-li osoba tyto podmínky, vztahují se na ni zvláštní podmínky pořizovatele databáze a v rámci §90 pak může uplatňovat následující práva [38]: §90 1. Pořizovatel databáze má právo na vytěžování nebo na zužitkování celého obsahu databáze nebo její kvalitativně nebo kvantitativně podstatné části a právo udělit jinému oprávnění k výkonu tohoto práva. 2. Vytěžováním podle odstavce 1 se rozumí trvalý nebo dočasný přepis celého obsahu databáze nebo jeho podstatné části na jiný podklad, a to jakýmikoli prostředky nebo jakýmkoli způsobem. 38

3.1. Zpracování veřejně dostupných informací 3. Zužitkováním podle odstavce 1 se rozumí jakýkoli způsob zpřístupnění veřejnosti celého obsahu databáze nebo jeho podstatné části rozšiřováním rozmnoženin, pronájmem, spojením on-line nebo jinými způsoby přenosu. 4. Půjčování originálu nebo rozmnoženiny (§16) databáze není vytěžování podle odstavce 2 ani zužitkování podle odstavce 3. 5. Opakované a systematické vytěžování nebo zužitkování nepodstatných částí obsahu databáze a jiné jednání, které není běžné, přiměřené a je na újmu oprávněným zájmům pořizovatele databáze, není dovoleno. 6. Právo pořizovatele databáze je převoditelné. V kontextu výše zmíněných informací lze za takovéhoto autora databáze považovat například i server iDNES.cz, který tedy může nákladat s veškerým svým obsahem, který mu uživatelé svěří, nebo který vytvoří. Tento obsah navíc může zpřístupnit veřejnosti. Z pohledu třetí strany, jež tento obsah chce získat a zpracovávat je důležitý především odstavec 6, tedy že právo pořizovatele je přenositelné (za podmínek, které zákon neupravuje, může to tedy být zadarmo, pod určitou licencí, za úplatu a podobně). Chceli k těmto datům přistupovat subjekt třetí strany, může se tedy s pořizovatelem databáze napřímo dohodnout. Ve chvíli, kdy data legálním způsobem od původního pořizovatele databáze subjekt získá, přenesou se na něj i všechna práva s daty spojená, a je tak jako fyzická či právnická osoba schopen provádět s nimi cokoli si přeje (opět ovšem v rámci platných zákonů). Může je libovolně modifikovat, doplňovat (například dohledávat a obohacovat informace k získaným klientským účtům s cílem zkompletovat profil zákazníka), propojovat s informacemi, které již má dostupné (například daty z interních systémů) a podobně. Zákon myslí i na možnost, kdy se třetí strana s původním pořizovatelem databáze domlouvat nechce a data bude využívat bez jeho vědomí. Takováto situace je upravena v rámci §91, má ovšem svá značná omezení. §91 Do práva pořizovatele databáze, která byla zpřístupněna jakýmkoli způsobem veřejnosti, nezasahuje oprávněný uživatel, který vytěžuje nebo zužitkovává kvalitativně nebo kvantitativně nepodstatné části obsahu databáze nebo její části, a to k jakémukoli účelu, za podmínky, že tento uživatel databázi užívá běžně a přiměřeně, nikoli systematicky či opakovaně, a bez újmy oprávněných zájmů pořizovatele databáze, a že nezpůsobuje újmu autorovi ani nositeli práv souvisejících s právem autorským k dílům nebo jiným 39

3. Právní a morální aspekt Big Data předmětům ochrany obsaženým v databázi. Možnosti využití jsou tak v tomto případě omezeny především spojenímkvalitativně nebo kvantitativně nepodstatné části obsahu databáze a dále pak rozsahem možné práce, kdy tento paragraf limituje frekvenci využívání takových dat na běžně a přiměřeně, nikoli systematicky či opakovaně. Co konkrétně tyto slova znamenají a jaké jsou hranice, lze těžko bez konkrétního příkladu popsat a bude tak asi vždy záležet na výkladu práva tou či onou stranou. Ideálním řešením v případě, kdy právnická osoba (firma) chce využívat data (byť volně veřejně dostupná) třetích stran, je tedy přímá dohoda s pořizovatelem databáze na rozsahu a podmínkách poskytnutí těchto dat.

3.1.3

Osobní & citlivé údaje

Ve chvíli, když už jsou data dostupná a připravená ke zpracování, je potřeba se zamyslet nad problémem ochrany osobních či citlivých údajů, které v datech mohou být. Co konkrétně v rámci legislativy České republiky osobní a citlivá data jsou, je upraveno v Zákoně č. 101/2000 Sb §4 a) osobním údajem je jakákoliv informace týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze subjekt údajů přímo či nepřímo identifikovat zejména na základě čísla, kódu nebo jednoho či více prvků, specifických pro jeho fyzickou, fyziologickou, psychickou, ekonomickou, kulturní nebo sociální identitu b) citlivým údajem je osobní údaj vypovídající o národnostním, rasovém nebo etnickém původu, politických postojích, členství v odborových organizacích, náboženství a filozofickém přesvědčení, odsouzení za trestný čin, zdravotním stavu a sexuálním životě subjektu údajů a genetický údaj subjektu údajů. Citlivým údajem je také biometrický údaj, který umožňuje přímou identifikaci nebo autentizaci subjektu údajů Pouhá přítomnost těchto údajů ve zpracovávaných datech může změnit způsob nakládání s těmito daty, neboť se na ně následně vztahují další regulace a ochrany. Osobní a citlivá data občanů Evropské unie například nemohou být uchovávána mimo její hranice a podobně. Kompletní analýza dopadů přítomnosti osobních či citlivých dat ve zpracovávaných informacích je nicméně nad možnosti a rozsah této práce, neboť ty se vždy odvíjí 40

3.2. (De) Anonymizace dat od konkrétního případu a jen velice těžko lze vypracovat obecný scénář. Ponechám tedy tuto problematiku jako případné navazující téma jiným studentům, ideálně právnických fakult.

3.1.4

Komerční užití získaných údajů

Získal-li jsem data/informace legální cestou v souladu s výši popsanými principy, nic mi nebrání využívat tato data ke svým komerčním aktivitám. Mohu nad nimi dělat analýzy, ze kterých budu například odhadovat preference zákazníka a na jejich základě mu pak připravit kampaně na míru či cokoli jiného si přeji.

3.2

(De) Anonymizace dat

"Data mohou být buď užitečná, nebo dokonale anonymní. Nikdy obojí [39]."Problematika anonymizace dat stojí v pomyslném procesu zpracování dat na úplném počátku. Organizace (správci dat) nechtějí své cenné informace pouze pasivně ukládat, ale chtějí z nich dostat co největší business hodnotu. Tato snaha zapříčiňuje, že svá data (příkladně klientská data banky, nemocničních zařízení a podobně) sdílí jiným subjektům, často třetím stranám, partnerům či i pouze interně v rámci stejné organizace s cílem obohatit svůj/jejich business zajímavými informacemi. Každému takovémuto sdílení informací často předchází důsledná anonymizace všech údajů, ze kterých by mohlo se dala zpětně identifikovat konkrétní osoba. To by totiž bylo nepřípustné nejenom eticky, ale ani právně (viz 3.1.3). Obecně lze rozdělit anonymizační metody do tří skupin podle toho, jak je anonymizace prováděna

3.2.1

Mazání dat

Při použití metody mazání jsou z dat vymazány ty informace, které jsou zákonem (ale i prostým rozumem administrátora dat) označeny jako klíčové atributy, podle nichž by bylo možné osobu identifikovat. V reáliích České republiky je takovým identifikátorem bezpochyby rodné číslo, které je pro každého unikátní, jméno a příjmení, adresa či telefonní číslo. Tato metoda je z pohledu bezpečnosti údajů subjektu v datech (tedy například klientů) jednoznačně nejlepší, neboť informace, které byly jednou vymazány, nejde nijak dopočítat nazpět. Provede-li se výmaz těchto atributů důkladně, je ovšem výsledný set dat prakticky nepoužitelný pro jakoukoli další formu analýzy nebo zpracování, neboť neobsahuje již prakticky nic zajímavého. 41

3. Právní a morální aspekt Big Data

3.2.2

Generalizace

Druhou metodou anonymizace dat je zobecnění záznamů do takové míry, aby se celkově snížila míra detailu informací, a subjekt v datech tak nešel rozpoznat. Prakticky to může být například nahrazení konkrétního PSČ názvem kraje, telefonního čísla názvem operátora, ponechání pouze prvních X číslic z rodného čísla a podobně. Tato metoda tedy ponechá všechna data, pouze je neposkytne v tak detailní formě jako originál. Tato metoda již ovšem nese svá rizika a je možné, že i přes důkladnou agregaci údajů budou data natolik unikátní, že bude i nadále možné identifikovat konkrétní subjekt. Takovým příkladem jsou hlavně geolokační data o poloze uživatelů, získaná z mobilních telefonů. Velice zajímavý výzkum prokázal, že běžný denní pohyb většiny lidí lze jednoznačně identifikovat i po důkladné generalizaci údajů [40].

3.2.3

Agregace

Poslední metoda se používá ve chvíli, kdy pro zkoumání nejsou potřeba konkrétní data, ale stačí přehledy a statistické souhrny. Místo detailního seznamu uživatelů z Prahy tak například poskytnu pouze informaci, že jich je určitý počet. Takto vysoká míra abstrakce ovšem vyhovuje pouze některým analytickým potřebám, konkrétnější výsledky z takto anonymizovaných dat nemohu očekávat.

3.2.4

Bezpečnost

Míru anonymizace reguluje v určitých případech sám stát, který tímto nástrojem brání práva občanů na ochranu osobních údajů. Platí nicméně důležité pravidlo, že žádná regulace nemůže zvýšit bezpečnost dat, aniž by zároveň nesnížila jejich kvalitu [39]. Konkrétní příklady ovšem již několikrát prokázaly, jak nedostatečnou úroveň zabezpečení osobních údajů běžně anonymizační techniky poskytují. I ze zdánlivě neosobních údajů lze často identifikovat subjekt připojením informací z jiných zdrojů, či pouhou kombinací s jinými parametry. Podobných případů bude jistě přibývat. 3.2.4.1

AmericanOnline (AOL) Research

V srpnu 2006 zveřejnila společnost AOL data set s 20 miliony anonymizovanými záznamy ze svého vyhledávače s cílem poskytnout vědecké komunitě data pro jejich výzkum. Během anonymizační fáze byly z vyhledávacích dotazů odstraněny všechny informace, které by umožnily určit konkrétní osobu (IP adresa, uživatelské jméno a další), místo nichž bylo pro každého 42

3.2. (De) Anonymizace dat uživatele zavedeno anonymizované, ale u všech jeho záznamů stejné identifikační číslo, aby šlo zkoumat chování jednotlivých uživatelů. Už samotné zveřejnění dat bylo provázeno velkou kritikou ze strany veřejné komunity, neboť data obsahovala značné množství citlivých údajů a kontroverzních vyhledávaných výrazů, byla prakticky oknem do mysli uživatelům AOL. Hlavní problém nicméně nastal, když se redaktorům New York Times za pouhých 6 dní po vydání dat podařilo na základě vyhledávaných výrazů (jména, lokality,..) identifikovat uživatele číslo 4417749 jako Thelmu Arnold ze státu Georgia [41]. 3.2.4.2

Identifikace osob podle PSČ

Revoluční studie o možnostech identifikace osob čistě podle jejich poštovního směrovacího čísla, pohlaví a data narození [42], stejně jako později i druhá potvrzující studie [43] na aktualizovaných datech ze sčítání lidí v USA potvrdily, že pouhou znalostí těchto tří údajů, které nejsou běžně společností chápány jako tajné či potenciálně nebezpečné, a které jsou tak často k nalezení na veřejných místech (krom jiného na sociálních sítích), lze dosáhnout až 87.1% přesnosti identifikace konkrétní osoby. 3.2.4.3

NetFlix Prize studie

Firma NetFlix nabízí svým klientům za pravidelný poplatek možnost sledovat nové filmy a seriály online. Po každém takovémto zhlédnutí vybízí uživatele, aby právě zhlédnuté dílo oznámkoval a na základě těchto hodnocení mu pak doporučí další film. Systém doporučení je základem jejich business modelu, a proto se tato firma rozhodla uspořádat veřejnou soutěž, v níž nabídla $1 000 000 tomu, kdo zásadním způsobem zlepší jejich stávající systém. Jako trénovací data poskytla historické anonymizované údaje o aktivitě svých uživatelů, seznamy i konkrétní hodnocení jednotlivých filmů a další. Těchto záznamů bylo celkem více než 100 000 000. Pouhé dva týdny po zveřejnění těchto dat se dvojici vědců podařilo zjistit, že k identifikaci konkrétní osoby v datech postačuje znát pouze pár údajů o jím udělěných hodnocení. Je-li například známo přesné hodnocení 6ti filmů (tedy že filmu X dal uživatel 5 hvězd, filmu Y 3 a tak dále), lze jej identifikovat s přeností 84%. Pokud navíc víme ještě přibližně čas, kdy tato hodnocení udělil, zvýší se přesnost identifikace až na 99% [44]. Povedlo se jim dokonce spárovat některé účty z poskytnutých s účty na webu IMDB, který slouží pro veřejné hodnocení filmů, a na základě takto 43

3. Právní a morální aspekt Big Data získaných informací odhalit i informace, které by mohly naznačit politické smýšlení subjektu, jeho náboženské přesvědčení či sexuální orientaci.

3.3

Poznání vs. vytváření skutečnosti

Zapojením moderních technologií a hlavně možností analyzovat všechna data získáme výsledky, kterých by lidská mysl sama nikdy nebyla schopna a které nám tak byly doposud skryty. Některé algoritmy, jež pro tyto účely používáme, jsou dokonce natolik komplexní, že jejich chodu již nikdo nerozumí a neumí je ani žádným způsobem ovlivnit, může pouze čekat na výsledek [13]. Tato kapitola zmiňuje některé problémy, které může tato situace vyvolat.

3.3.1

Přílišné poznání

Na příkladu amerického prodejního řetězce Target, který na základě analýzy nakupovaných položek svých zákaznic identifikoval ty, které jsou těhotné, aby jim následně posílal kupony na slevy na kojenecké zboží, a "vychoval"si tak z nich věrné zákaznice, lze demonstrovat, kam až může vést přílišné poznání klienta. Takové kupony totiž začal posílat i jisté mladé slečně, kterou algoritmus označil jako těhotnou. Její otec si nicméně přišel stěžovat, že takové označení je urážkou její cti, neboť je ještě příliš mladá na to, aby byla těhotná a navíc je věřící. O pár dní později se mu dcera nicméně přiznala, že pravdu těhotná je, a on se tak musel jít omluvit [45]. Zapojením Big Data, která o všech obsahují mnohem více informací a ve kterých je teoreticky uložena veškerá naše minulost, bude podobných příkladů jistě přibývat a to vznáší otázku určitých etických hranic v tom, co je ještě běžné a k podnikání nutné vědomí o zákazníkovi a co je již zásahem do soukromí. Pojišťovny by například mohly sledovat veškerou konverzaci lidí na sociálních sítích a podle aktivit, které rádi dělají (sport, dobrodružné a nebezpečné aktivity atd.), následně zvyšovat výši pojistného. Zaměstnavatel by mohl monitorovat, zda jeho zaměstnanec neporušuje na webu určitý etický kodex firmy, a případné prohřešky pak řešit rozvázáním pracovního poměru či jinou sankcí. Příkladů by bylo možné nalézt celou řadu. K této otázce ovšem zatím neexistuje komplexní odpověď, neboť hranice morálky má každý nastaveny jinde, a co může být pro někoho zásahem do soukromí, jinému vadit nemusí. Dle mého názoru záleží hodně na tom, jaký benefit bude mít ona větší odhalenost všech názorů a obsahu pro daného uživatele. Ve chvíli, kdy bude nějaká organizace sledovat polohu muže, aby 44

3.3. Poznání vs. vytváření skutečnosti mu mohla následně poslat slevový kupón na prací prášek či tampony, bude tento subjekt spíše naštvaný a bude organizaci vinit z obtěžování. Pokud ale organizace opravdu dokáže zjistit, že zvykem tohoto muže je v daný čas kupovat alkohol a pošle mu slevu na vybranou, jeho oblíbenou, značku, nemusí mu to přijít jako nepatřičné obtěžování a může být za takovou službu nakonec rád. Jsem toho názoru, že tyto řešení budou moci naplno fungovat paradoxně až ve chvíli, kdy jim svěříme ještě více osobních informací a charakteristik a kdy tak budou opravdu schopny predikovat, co, kdo a kdy chce. Otázkou zůstává, jestli to není krok směrem k situaci popsané v Orwellově románu 1984 [46].

3.3.2

Ovlivnění zákazníka

Na řadě internetových obchodů, ale i jiných, jim podobných služeb, již delší dobu fungují doporučovací systémy, které na základě historických nákupů či kliknutí uživatele zobrazí ty nabídky, jež se líbily ostatním uživatelům s podobným chováním. Tento princip je v pořádku do chvíle, než se zamyslíme nad jeho možným dopadem ovlivňování uživatele/zákazníka. Neslouží totiž pouze k tomu, že predikujeme jeho zájem, jistým způsobem jej přímo ovlivňujeme. Tyto modely jsou totiž většinou samoučící, a tak se i jeho volba se započítá do dalších zobrazení jiným, podobně se chovajícím uživatelům. Může se ovšem stát, že má organizace na počátku nepřesnou predikci a zobrazuje uživatelům produkty, které ve skutečnosti nechtějí. Tím, že je ale zobrazuje často a velice viditelně (posílá reklamy do emailů, sms a tak dále), uživatel nakonec podlehne a produkt koupí, což je následně započítáno jako úspěch predikčního modelu a tím více je daný produkt nabízen. Teoreticky tak byla vytvořena poptávka na základě mylných údajů. Tento problém je úzce svázán s výzkumem racionality spotřebitele a jeho výběru, čímž se zabývá především behaviorální ekonomie. Výsledky nicméně ukazují, že spotřebitel se nechová vždy zcela racionálně [22], jak předpokládá většina ekonomických modelů, a je tak potřeba počítat i s touto eventualitou jeho ovlivnění.

45

Kapitola

Customer Intelligence Základní otázkou Customer Intelligence v kontextu Big Data obecně je "Jaký druh informací o klientech Big Data obsahují a jak jej lze využít?"Je důležité mít data, ale ještě důležitější je vědět, co s nimi ve skutečnosti mohu dělat, jaké výstupy z nich lze očekávat a jak tyto výstupy mohou být využity v businessu. O této problematice pojednává následující kapitola.

4.1

Typy dat

Jeliož Big Data umožňují zahrnout do analytického procesu jakákoli data bez ohledu na formát, je potřeba upustit pouze od tradičních zdrojů a doslova myslet ve velkém. Jako příklad nových zdrojů informací poslouží následující seznam: ∙ Internetová data - clickstream, sociální média, webové diskuze, články. ∙ Primární výzkum - dotazníky, ankety, experimenty, pozorování. ∙ Sekundární výzkum - reporty, business data, data o konkurenci či trhu. ∙ Geolokační informace - GPS, mobilní data. ∙ Obrazová data - obraz, video, satelitní snímky, sledování. ∙ Data ze zařízení - senzory, telemetrie. 47

4

4. Customer Intelligence

4.2

Příklady využití

Již v předchozích kapitolách jsem rozebral možnosti využití geolokačních informací v reálném čase například k odeslání specializovaných a na míru šitých nabídek vázaných lokalitou a časem. Dalším zajímavým příkladem využití Big Data platformy může být sledování takzvaného "clickstreamu", tedy detailního záznamu pohybu myši například v elektronickém obchodě. Tato kapitola uvádí některé přiklady využití dat k bližšímu poznání zákazníka.

4.2.1

Elektronické obchodování

Elektronické obchody jsou obecně průkopníky v analýze svých zákazníků, neboť musí neustále vyvažovat svou nevýhodu oproti kamenným obchodům, které z principu mají přímou intrakci se zákazníkem a tak i větší sílu na ovlivnění jeho nákupního chování. E-shopy již dlouhou dobu analyzují nákupní aktivitu jednotlivých uživatelů a porovnávají ji s nákupy ostatních uživatelů s cílem predikovat produkt, který si zákazník koupí příště, či který by jej mohl zajímat. Tato metoda ovšem vychází až z nákupů, které zákazník provede a zaplatí, což je pro obchodníka často již příliš pozdě na to, aby mu doporučil jiný, vhodnější produkt. Zrod Big Data umožnil vznik nové metody, záznamu a analýze takzvaného clickstream [47], tedy pohybu a aktivity myši, kterou uživatel ovládá web. Aplikace uchovává přesné pohyby a polohu myši každý okamžik, který zákazník stráví na webu. Kromě pohybu samozřejmě zaznamenává položky, na něž se zákazník dívá, případně zboží, které dává do košíku, ale nakonec se rozmýšlí a z košíku maže. Analytická aplikace v pozadí musí takto získaná data porovnat se všemi historicky získanými daty všech klientů s podobným chováním (množství dat, která musí takový algoritmus projít ve velice krátkém čase je v tomto případě obrovské a roste v čase i s počtem uživatelu/zákazníků daného obchodu) a ideálně v reálném čase na webu zobrazit nabídku na míru daného klienta. Pokud například odstraní z košíku položku X, může mu aplikace nabídnout okamžitě slevu na položku Y, kterou si nakonec koupili ti uživatelé, kteří si chtěli koupit položku X a navštívili stejné kategorie jako aktuální uživatel a navíc ohodnotili nákup kladně. Množství atributů vstupujících do tohoto rozhodovacího procesu může být (a zpravidla je) mnohem větší. Algoritmus může vzít do úvahy i aktuální denní dobu, počasí, aktuální důležité společenské události, aktivitu daného uživatele na sociálních sítích, témata, o kterých se nejčastěji baví, a podobně. Fantazii se v tomto případě meze nekladou, technologie toto již umí. 48

4.2. Příklady využití

4.2.2

Zdravotnictví

Dalším naprosto klasickým Big Data problémem je zdravotnictví, které je jako takové je prakticky celé založené hlavně na informacích a z nich odvozených řešeních. Klient (v tomto případě pacient) přichází s nějakou nemocí a snaží se popsat příznak, co nejlépe umí, aby jeho ošetřující lékař mohl správně identifikovat nemoc a předepsat vhodnou léčbu. Řada nemocí ovšem není banální a jejich příznaky se často kryjí. I zdánlivě nesouvisející "anomálie"může mít na konečnou diagnózu vliv a pacient si to ani nemusí uvědomovat. Zapojením Big Data technologií do tohoto procesu je možné na základě zadaných příznaků, pacientovy historie, dat z pacientových zdravotnických zařízení (tepoměr, kardiostimulátor,..) i všech dalších relevantních okolností porovnat daný případ se všemi případy, které kdy byly diagnostikovány, potenciálně v celém světě (což by ale vyžadovalo integraci jednotlivých zdravotnických systémů, což je zcela jiné téma), a zpřesnit tak lékařovo rozhodnutí. Tato metoda by teoreticky zcela omezila chyby při diagnózách. Lékař by stále nicméně byl ten, kdo by řekl poslední slovo, nástroj by mu pouze poskytl ucelený seznam možností.

4.2.3

Vyšetřování

Posledních příkladem, který zde uvedu, je využití Big Data pro vyšetřování. V kontextu dnešního businessu jde především o vyšetřování různého podvodného jednání. Typicky se může jednat o pojistné podvody [48], snahy podvést bankovní instituce při kreditních operacích a podobně. Bezpečnostní složky na druhou stranu mohou využít Big Data k analýze chování podezřelých osob, detekci hrozeb jako terorismus, zvláštních vzorců chování a podobně. Osoba se například může skrývat pod různými identitami, nicméně její styl psaní zpráv na webu, výrazy, které používá, či délka vět zůstane identická, a pokročilým analytickým nástrojům tedy snad odhalitelná. A tak dále. Ve všech případech je způsob využití podobný. Aktuální data se porovnávají se všemi historickými záznamy. Čím více dostupných dat, tím je výsledek přesnější.

49

Kapitola

Návrh řešení Tato sekce popisuje návrh řešení praktické části mé diplomové práce. Informace v této části mají za cíl popsat architekturu celého řešení, jaké komponenty se použijí a jak na sebe budou navazovat. Technické detaily navrženého řešení budou následovat v dalších kapitolách.

5.1

Výběr analytické technologie

Pro potřeby demonstrace mého záměru zpřístupnění a hlavně agregace důležitých informací ze všech možných informačních zdrojů s nestrukturovanými daty o potřebách klienta či případně i jeho osobnosti bylo nejprve potřeba zvolit vhodnou technologii pro analýzu nestrukturovaných dat. Těchto technologií na trhu moc není, a proto je výběr poměrně omezen. Pro očekávaný výsledek totiž nástroj totiž musí splňovat celou řadu požadavků najednou. Cílem mé práce nicméně není porovnávat jednotlivě dostupné technologie, ani preferovat opensource řešení nad komerčními produkty, či naopak. Analytický nástroj je pro mě pouze pomůckou, která mi pomůže demonstrovat sílu celé myšlenky analytiky Big Data. Byl bych rád, aby se mnou navrhované řešení nesvazovalo pouze se zvolenou technologií, ale aby bylo od ní bylo v co největší míře abstrahováno. Následují požadavky na analytickou technologii.

5.1.1

Načítání dat

Tento požadavek je zcela logický, nicméně bývá často v analytických pracích opomíjen. Aby vůbec bylo možné nějakou analýzu provést, musí být dostupná data. Metody získávání dat z tradičních zdrojů dat jsou u všech produktů na trhu víceméně samozřejmostí. Je tak možné importovat data 51

5

5. Návrh řešení z běžných databázových systému, načíst dokumenty ze souborového systému (windows i linux) či různých proprietárních technologií, jejichž seznam se odvíjí od výrobce analytického nástroje. Zaráží však absence možnosti importu dat z médií moderního charakteru, především pak ze sociálních sítí, webových diskuzí a podobných nových komunikačních kanálů. Automatická podpora těchto zdrojů neexistuje prakticky u žádného systému a je často řešena spoluprácí s třetí stranou, která (samozřejmě za peníze) tato data zpřístupní pomocí nějaké své vlastní aplikace. Takový přístup si ovšem nemohu dovolit, a proto je nutné, aby vybraný nástroj umožňoval vložení dat i jinak než pomocí standardních crawlerů, tedy aby měl programovatelné rozrhaní (API), pomocí něhož by šlo vyvinout vlastní crawler pro sociální sítě a dokumenty do analytického nástroje dostat vlastními silami. Takovéto rozhraní může být podobu například JAVA api, ideálně by však mělo mít podporu webových služeb (WS [49], případně REST [50]), a nebylo tak závislé na použité technologii.

5.1.2

Extrakce textu

Veškerý analyzovaný text je automaticky zpracován pomocí engine pro zpracování přirozené řeči. Tento engine musí být schopný indexovat dokumenty podle slov, která obsahují a následně podle nich umožnit vyhledávání. Indexace bude probíhat nejenom na základě slovních druhů, ale uživatel by měl mít možnost definovat si své vlastní slovníky pojmů, které například daný jazyk nezná, či které dávají v kontextu analýzy smysl. Takovými slovy jsou typicky názvy produktů, konkurence a podobně. Na základě výstupů z tohoto kroku analýzy pak lze například zobrazit si podstatná jména (názvy produktů a další), která se napříč texty nejčastěji vyskytují, jaká přídavná jména (vlastnosti) s nimi uživatelé nejčastěji spojují, jaká slovesa (činnosti) a další. Tato funkce je úzce spjata s nutností podpory lokálního jazyka 5.1.5.

5.1.3

Pokročilá analýza podle pravidel & Metadata

Analýza textu pouze podle automatických pravidel a jazykových druhů by samozřejmě nebyla dostatečná. Mělo by být možné stanovit si vlastní pravidla, která se pak následně promítnou na cílových textech. Příkladem takového pravidla může být podmínka "Pokud se do dvou slov od jména produktu bude vyskytovat jméno produktu konkurence a zároveň to bude ve stejné větě, ve které již ovšem nebude zmíněn žádný jiný produkt, označ tento dokument větu metadatem XY". Možnost přidání vlastních metadat je nesmírně důležitá. Uživatel si může jako metadato zvolit prakticky libovolnou hodnotu, podle zdroje informací se metadata mohou značně lišit. 52

5.1. Výběr analytické technologie Sekce 2.1.1.3 naznačuje, jaká metadata jsem zvolil pro příspěvky z této sítě, sekce 2.1.2.3 pak popisuje metadata z Google+, která jsou jiná a tak dále. Podle těchto metadat (tedy dat o datech) se následně dá vyhledávat, filtrovat dokumenty na základě jejich obsahu a podobně.

5.1.4

Sentiment analýza

Sentiment analýza neboli analýza (pozitivního či negativního) vyznění věty je důležitou a dnes již i nedílnou součástí textové analýzy, a musí proto být přítomná i v použitém analytickém nástroji. Tato funkce v kombinaci s možností nastavit si vlastní pravidla umožňuje analytikovi zjistit, jak se v analyzovaných dokumentech píše o vybraných tématech, produktech, konkurenčních firmách, atd. Snadno tak lze zjistit, příjímá-li veřejnost nový produkt nebo marketingovou kampaň pozitivně, nebo negativně, případně jaká slova se nejčastěji v souvislosti s názvem našeho produktu vyskytují, když se o něm píše negativně a tak podobně. Tato zpětná vazba umožní organizaci zjistit včas případné nedostatky a napravit je dříve, než zákazník přejde ke konkurenci, nebo jinak projeví svou nespokojenost. Možnosti využití sentimentu jsou samozřejmě mnohem širší 5.1.

Obrázek 5.1: Příklad sentiment analýzy vybraných mediálních webů

5.1.5

Podpora českého jazyka

Naprosto klíčovým požadavkem, má-li se textová analýza naplno využívat i v rámci České republiky, je požadavek na podporu českého jazyka. Většina dostupných řešení se zaměřuje převážně na angličtinu a analýza dokumentů v českém jazyce pomocí těchto nástrojů dopadá přinejmenším tristně. Nástroj musí krom jiného umět rozlišit správně slovní druhy, skloňovat jednotlivá slova a další. Typický příklad je slovo "být". Sleduji-li toto slovo, logicky chci také sledovat všechny jeho další verze, které ale mají stejný význam - byli, jsme, byl. Analytický nástroj musí být schopen zjistit, že dvě slova vlastně znamenají to samé, a ve výsledku je spojit. K dosažení tohoto cíle existují dva základní přístupy. 53

5. Návrh řešení Ořezání na kořen slova Každý analyzovaný výraz se ořeže až na jeho kořen a ty se následně porovnávají. Jsou-li stejné kořeny, výrazy se označí jako identické. Tento přístup má ovšem celou řadu nevýhod. Nejlépe se to demonstruje na konkrétním příkladu. Výrazy žid a židlička mají společný kořen žid, ale přesto nejde o identická slova. Nástroj, který by využíval tento přístup by je ovšem spojil do jednoho z důvodu stejného kořene slova, a tím by tak zkreslil výsledky analýzy. Lemmatizace Lemmatizace oproti kořenové metodě pro každý výraz najde jeho základní tvar (u příkladu jsme by byl základní tvar být) a až tento tvar porovnává mezi sebou. Takovéto výsledky jsou pak mnohem přesnější.

5.1.6

Vybraná technologie

Pro realizaci svého záměru jsem po pečlivém zvažování zvolil technologii IBM Content Analytics, která je komerční aplikací a se kterou jsem se setkal během stáže ve firmě IBM Česká republika. Tento nástroj splňuje, až na malé výjimky, výše uvedené požadavky a přináší celou řadu další možností. Pro potřeby praktické části mé diplomové práce bylo nicméně potřeba si i tuto technologii trochu přizpůsobit a vyvinout určité komponenty, které nejsou standardně dostupné. Více o tomto je popsáno v následující sekci. Produkt IBM Content Analytics je navržen ke zpracovávání textů v přirozeném jazyce způsobem, který pomůže vyhledávat a objevovat informace a rovněž umožnit uživateli provádět analýzu na nestrukturovaných datech ve stejné kvalitě a rozsahu, jaká je využívána u dat strukturovaných. Kromě vyjmenovaných základních funkcí umí IBM Content Analytics (dále jen ICA) zobrazit trendy jednotlivých údajů v čase, odhalit neobvyklé korelace či anomálie, zobrazovat vztahy mezi autory obsahu a další. S pomocí tohoto nástroje je možné vysvětlit výskyt událostí v datech, najít nové příležitosti pomocí agregace zpětné vazby zákazníka, dodavatelů a trhu, je možné sledovat i nekvantifikovatelné obchodní metrik s pomocí nastavitelných panelů dashboard, reportů a výkonnostních metrik a spousta dalšího. Přínosný je i způsob pohledu na data který tento nástroji přináší. Analýza probíhá pomocí takzvaných fazet (jinak řečeno kategorií kategorií), které umožňují postupně omezovat množinu dat (dokumentů) podle různých vlastností, jež analytika zajímají. Například lze nadefinovat fazetu cílů víkendových cest (pomocí vytvoření nového slovníku, viz dále), která 54

5.2. Architektura řešení bude obsahovat nejoblíbenější destinace, kam lidé o víkendech cestují. Taktéž můžete nadefinovat fazetu aktivit se seznamem typických činností, které během nich provádějí. S takto vytvořenými fazetami může analytik cestovního průmyslu zjistit například, které typy lidí (v závislosti na jejich věku, profesi, pohlaví a ostatních aspektech) mají sklon cestovat do jakých lokací, a dále umožňuje identifikovat aktivity, jimž se oddávají přes víkend. To vše samozřejmě nástroj extrahuje z nestrukturovaných dat na pozadí (příspěvků na webu, emailů). Popis všech možností nástroje ICA je mimo rozsah mé diplomové práce. Více lze zjistit z volně dostupných výukových materiálů [51], celá řada informací je dostupná pouze interně, či plynou z reálných zkušeností práce s tímto nástrojem.

5.2

Architektura řešení

Nejlépe lze vizualizovat navrhovanou architekturu celého analytického řešení pomocí diagramu 5.2. Data vstupují do systému pomocí crawlerů (na diagramu znázorněných komponentou C). Část analyzovaných zdrojů informací (databáze DB2 s "CRM"daty, souborový systém s přepisy telefonních hovorů a emaily od klientů) je podporována přímo zvoleným nástrojem ICA, a je tak potřeba jej pouze nakonfigurovat. Konfigurace spočívá především ve správném parsování a mapování vstupních dat na metadata dokumentu (CSV soubory určitého formátu, jména tabulek v databázi a jejich atributů a podobně). V případě web crawleru, který umí automatizovaně a systematicky procházet zadané domény a crawlovat veškerý obsah na nich nalezený, je potřeba pro každý zdroj nastavit speciální konfigurační soubor, pomocí něhož jsou z něj vydolovány pouze ty důležité atributy, které budeme potřebovat a které tak oddělí šum. Typ důležitých dat, která budu v rámci praktické části za webu crawlovat, podrobněji rozebírám v sekci 2.1.4.1. Druhou možností importu dat je nespoléhat se pouze na zdroje podporované automaticky nástrojem, ale vytvořit zcela vlastní crawler na míru, který bude data odesílat přímo do enginu ICA. Tento způsob bude nutné v mém praktickém řešení využít, neboť by jinak nebylo možné zahrnout do řešení data ze sociálních sítí. Vytvořím tedy vlastní crawler pro sociální sítě Facebook, Twitter a Google+, který bude umět data z těchto zdrojů překonvertovat přímo do ICA ve formátu, jenž umožní jejich další analýzu včetně zachování všech dostupných metadat popsaných v sekcích o síti Facebook 2.1.1.3, síti Google+ 2.1.2.3 a síti Twitter 2.1.3.3. 55

5. Návrh řešení

Obrázek 5.2: Návrh architektury analytického řešení nestrukturovaných dat

Po načtení dat se pak všechny dokumenty analyzují na základně mého nastavení nástroje. U všech se provede sentiment analýza a následně se naindexují podle připravených slovníků. Pro demonstraci možností Big Data analýzy nestrukturovaného textu postačí i vytvoření jednoduché slovníku, například se seznamem typických bankovních služeb, jako půjčka, hypotéka a další. V datech pak budu zkoumat, zda se o nich mluví, jak, kde a tak dále. Analyzované výstupy je pak zapotřebí odpovídajícím způsobem prezentovat. Nástroj ICA má vlastní grafické rozhraní (webovou aplikaci), která je ovšem poměrně komplexní, a vyhovuje tak především potřebám vyškoleného analytika, ne už laického uživatele, kterému ale chci výsledky také zpřístupnit. Vytvořím tedy vlastní webovou aplikaci jako endpoint pro uži56

5.3. Výběr datových zdrojů vatele, která umožní prezentaci vybraných výsledků i laikům. V diagramu je tato aplikace znázorněna komponentou U. Aplikace bude fungovat podobně jako vyhledávač Google a její využívání nebude vyžadovat žádné školení či pokročilé technické znalosti. Uživatel - lajk - přitom pravděpodobně vždy nestojí o podrobné pročítání analyzovaných dokumentů, ale vystačil by si i s jednoduchým dashboardem agregovaných výsledků. Z toho důvodu bude mít mnou vytvořená webová aplikace dva módy, na diagramu znázorněné komponentami Obecné a Pokročilé. Aplikace bude podporovat i export vybraných dokumentů, aby si i laický uživatel mohl zvolený subset uložit pro pozdější práci či jiné využití. Ten bude možný do formátu PDF a HTML (pro odeslání emailem). Stejnou funkcionalitu doprogramuji jako plugin i do samotného nástroje ICA, který tento export neumí (standardně podporuje pouze XML a CSV exporty).

5.3

Výběr datových zdrojů

Ze všech dostupných informačních zdrojů, které jsou volně přístupné a lze je tedy využít (přičemž je potřeba pamatovat i na zákonem stanovené podmínky), jsem vybral především takové, na nichž budou přínosy pokročilé analytiky nestrukturovaných dat nejvíce patrné. V reálné situaci by se jich zapojilo mnohem více, a nebylo by tak nutné vybírat pouze podmnožinu, pro demonstrační účely nicméně tato podmnožina postačí. Tato kapitola popisuje vybrané informační zdroje a důvody pro jejich zahrnutí.

5.3.1

Sociální sítě

Jako hlavní informační zdroje (s ohledem na cíle diplomové práce) byly vybrány sociální sítě Facebook, Google+, Twitter, a to na základě jejich masové rozšířenosti v ČR a množství informací, které se na nich nachází, viz 2.1. Z množiny všech uživatelských profilů a stránek, dostupných na těchto sítích, jsem vybral oficiální prezentace největších českých bankovních organizací, z nichž budou následně čerpána data. Tyto profily byly zvoleny především proto, že obsahují velké množství informací a zákaznické komunikace, a lze na nich tak snadno demonstrovat účel a možnosti analýzy nestrukturovaných dat.

5.3.2

Mediální a informační weby

Další důležitým zdrojem informací byly informační weby a jejich diskuzní fóra. Tyto komunikační prostředky jsou mezi internetovou komunitou velice 57

5. Návrh řešení oblíbené a obsahují velké množství informací. Z důvodu množství informací a jejich vysoké návštěvnosti jsem vybral weby e15.cz, iDNES.cz, iHned.cz, TN.cz, lidovky.cz, Tyden.cz a další.

5.3.3

Interní informace a data

Pro potřeby dokonalé demonstrace by bylo potřeba mít reálná data z organizace, která by šla následně propojit s veřejně dostupnými informacemi. Tato data ovšem k dispozici nemám a nepovažuji bohužel za reálné v plné míře všechna klientská data nasimulovat. Pro potřeby dema jsem proto použil pouze jednoduchou modelovou databázi, simulující CRM systém s daty o zákaznících. Do ní jsem vložil simulované poznámky o klientech (zachycené "jakoby"od přepážky) a přepisy telefonních hovorů. Po sesbírání všech dat z mnou definovaných zdrojů se nicméně ukázalo, že množství ostatních informací mnou simulované dokumenty naprosto zastínilo, a proto jsem jim nepřikládal v diskuzi výsledků velikou pozornost.

5.4

Párování uživatelských profilů

Klíčovým požadavkem pro úspěch celého konceptu analytiky interních i externích nestrukturovaných dat je správné spárování uživatelských účtů, respektive správné propojení identit uživatelů napříč různými informačními zdroji. Jak již bylo popsáno v předchozích kapitolách této práce, klient může s organizací komunikovat rozličnými komunikačními kanály a na každém z nich může vystupovat pod jiným účtem či jinou přezdívkou. Sociální sítě přinesly poměrně zásadní revoluci v registracích, neboť do té doby bylo poměrně běžné vystupovat na webu pod smyšlenou přezdívkou z důvodu anonymity. Síť Facebook má přímo ve svých pravidlech, že uživatelé musí používat své skutečné jméno [52], stejně jako sociální síť Google+, která toto pravidlo také vyžaduje [53]. I přes tyto podmínky ovšem stojí před organizací, která chce takovouto pokročilou analytickou práci provádět, úskalí párování těchto uživatelských účtů k reálným osobám a hlavně vůči vlastním zákazníkům. Pokud nebude organizace tohoto schopna, bude moci z dat vyčíst pouze obecné problémy, témata a přání uživatelů těchto sítí, nebude však schopna vytvořit personalizované služby na míru konkrétním jedincům. Pravdou zůstává, že v porovnání s výstupy dnešních běžně používaných technologií by byly ovšem i tyto obecné výstupy značným přínosem. Pro potřeby své demonstrace nicméně předpokládám, že párování uživatelských učtů napříč komunikačními kanály pomyslná organizace již vy58

5.5. Shrnutí úkolů praktické části řešila a dokáže jedince identifikovat a vztáhnout k němu všechny jeho aktivity. Reálně toho lze dosáhnout například vhodně zvolenou marketingovou kampaní, při níž bude stávajícím klientům nabídnuta například sleva na služby či nějaký bonus v případě, že organizaci sdělí své facebook či Google+ ID (unikátní přihlašovací jméno, pod kterým lze dohledat profil uživatele na této sociální síti), jméno či obdobnou proprietu jiné (současné nebo budoucí) sociální sítě či média. Toto spárování jsem v rámci své práce nasimuloval tabulku v databázi, která obsahuje pro každého uživatel jeho identifikátory. Vím tedy, že uživatel s facebook ID X vystupuje také na Google+ pod ID Y a podobně.

5.5 5.5.1

Shrnutí úkolů praktické části Získání dat

1. Nastavit crawlery nástroje IBM Content Analytics na databázi DB2 a importovat data z "falešného"CRM. 2. Nastavit crawlery nástroje IBM Content Analytics na souborový systém a importovat data z přepisů telefonních hovorů a emailů. 3. Vytvořit vlastní crawler pro sociální síť Facebook. 4. Vytvořit vlastní crawler pro sociální síť Google+. 5. Vytvořit vlastní crawler pro sociální síť Twitter. 6. Vytvořit konfigurační soubory pro vybrané mediální servery (iDNES.cz, iHNED.cz a další).

5.5.2

Zpracování a analýza dat

1. Nastavit nástroj IBM Content Analytics - kolekci dokumentů, parsovací a indexovací procesy, analytické rozhraní. 2. Vytvořit slovník služeb českých bank. 3. Doplnit/upravit nastavení sentimentu pro český jazyk.

5.5.3

Prezentace závěrů

1. Vytvořit vlastní aplikaci pro prezentaci výsledků analýzy. 59

5. Návrh řešení 2. Ve vytvořené aplikaci umožnit export vybraných dokumentů do PDF a HTML a stejnou. funkcionalitu naprogramovat i do nástroje IBM Content Analytics. 3. Vyhledat v datech informace definované cíli diplomové práce 4.

60

Kapitola

Praktická část Tato část obsahuje detaily praktické části práce, jejímž cílem je praktická demonstrace řešení Customer Intelligence za využití Big Data. Pomocí zvolené technologie budu analyzovat data, která bylo nejprve potřeba získat v dostatečné množství nejen z interních zdrojů (simulované prostředí organizace), ale také zdrojů veřejných, jako jsou sociální sítě, mediální servery. Pro prezentaci výstupů je pak nutné vytvořit webovou aplikaci, která bude agregovat analyzované výsledky a prokáže, že i tak komplikovanou problematiku, jakou analytika klientských nestrukturovaných dat bezpochyby je, lze vizualizovat přehledně a srozumitelně na jedné obrazovce tak, aby uživatel (laik simulovaný pracovnicí banky za přepážkou) okamžitě pochopil, co jsou hlavní témata a na co se zaměřit.

6.1

Získávání dat

Tato sekce popisuje proces získávání dat z vybraných zdrojů. Pro potřeby tohoto projektu bylo potřeba vytvořit komponenty, které by toto získávání dat umožnily.

6.1.1

Sociální sítě

Jako zdroj dat ze sociálních sítí byly pro potřeby této demonstrace zvoleni zástupci z řad těch nejpoužívanější - Facebook, Twitter a Google+. Tyto sítě jsou na území České republiky velice rozšířeny a uživatelé jsou zvyklí jejich prostřednictvím komunikovat nejenom mezi sebou, ale také směrem k organizacím. Tyto sítě také poskytují třetím stranám přístup k určitým informacím pomocí aplikačního rozhraní (API), a je tak možné je strojově procházet. Jelikož neexistuje veřejně dostupné řešení, které by bylo schopné 61

6

6. Praktická část zadarmo (pro účely této práce) crawlovat data z těchto sítí z mnou určených profilů (v případě sítě Facebook jsou to veřejné profily českých bank, v případě sítě Twitter pak tweety na předem definovaná témata s předem definovanými hash tagy a tak dále), bylo nutné si takový nástroj vytvořit. V rámci této kapitoly popíši principy především u sítě Facebook a Twitter, jelikož jsou principy u ostatních sítí (Google+) velice podobné. Pouze Twitter je odlišný svým API poskytujícím data v reálném čase. Přiložený kód aplikace je nicméně okomentovaný, a měl by tak pro pochopení principu postačovat.

6.1.2

Mediální weby

Načítání dat ze zvolených mediálních webů není možné provádět za pomoci žádného běžně dostupného API, a proto bylo nutné vymyslet jiný způsob. Jednou možností je získat informace z veřejného RSS feedu [54], což by ovšem znamenalo ochudit se o spoustu informací, včetně diskuzních příspěvků, které takto nabízeny nejsou. Jedinou možnou metodou tak zůstal takzvaný screen scraping. Smysl této metody spočívá v tom, že naprogramovaný robot (klientská aplikace) prochází zadanou doménu stránku po stránce do šířky, případně vynechává předem definované adresy (průchod doménou se dá omezit podle adresového prostoru), stáhne HTML obsah každé načtené webové stránky pomocí HTTP protokolu metodou GET a z takto získaného obsahu oddělí podle zadaného konfiguračního souboru ty informace, které mají nějakou hodnotu a lze je analyzovat. Zvolený nástroj ICA tento webový robot má, nicméně ten je potřeba zvlášť naučit každý mediální server, který má crawlovat procházel, neboť každý má zcela jinou HTML strukturu.

Obrázek 6.1: Ukázka nastavení parsovacího XML souboru pro iDNES.cz 62

6.1. Získávání dat V konfiguračním souboru jsou postupně vysekávány části HTML stránky podle tagů, které se v ní nacházejí a ze zbytku je parsován textový obsah 6.1. Pro každý web je potřeba nastavit tento konfigurační soubor jinak a postupem času tyto konfigurační soubory aktualizovat spolu s případnou změnou struktury takto procházeného webu. Crawlery na mediálních webech jsem nechal běžet několik dní nonstop a výsledky (množství dokumentů) lze vidět v závěru této práce. Nejde však o finální počty příspěvků/článků na těchto webech, pro potřeby mé demonstrace nicméně naprosto dostačující. S přibývajícím množstvím zdrojů dat samozřejmě poroste doba úplného přecrawlování.

6.1.3

Interní informace a data

Nebylo možné nasimulovat kompletně interní systém organizace, a proto od něj bylo abstrahováno vytvořením modelové databáze reprezentující interní CRM systém s daty o zákaznících. Z důvodu dobré kompatibility s vybraným analytickým nástrojem jsem zvolil databázový systém IBM DB2, v němž jsou data potřebná pro tento pokus uložena. Analytický nástroj IBM Content Analytics má crawler pro databázový stroj DB2 a nebylo tedy nutné pro získání těchto informací vyvíjet vlastní aplikaci. Všechny ostatní poznámky o klientech z "falešného CRM"a přepisy hovorů (falešné) byly uloženy na souborovém systému ve formátu CSV a byly do ICA importovány pomocí standardního crawleru souborového systému.

6.1.4

Facebook

Strukturou i popisem dat dostupných na síti Facebooku jsem se již zabýval v kapitole 2.1.1. Tato sekce pojednává o API Facebooku a samotném způsobu získání dat. 6.1.4.1

Open Graph API

Toto aplikační rozhraní je primárním způsobem vytěžování data ze sociální sítě Facebook. API je poměrně rozsáhlé [25] a jeho důkladnější popis je mimo rámec této práce. Důležitý je proces při získávání dat potřebných pro naši analýzu 6.2. Nejprve je potřeba registrovat svoji aplikaci na Facebooku, čímž získáme registrační klíč. Tento je podmínkou k získání přístupu k API (autorizace probíhá již výhradně pomocí oAuth). Z vygenerovaného aplikačního klíče a tajného aplikační klíče (AppId a Secret AppId) dostaneme po zavolání následující URI: 63

6. Praktická část

Obrázek 6.2: Digram získání dat z Facebooku

https://graph.facebook.com/oauth/access_token?client_id=APPID &client_secret=SECRETAPPID&grant_type=client_credentials access token, který od tohoto okamžiku musí být přítomný v URL každého dotazu na API Facebooku a tyto požadavky autorizuje. Pro každý definovaný feed (neboli stránku) je potřeba stáhnout všechny statusy, přičemž tyto jsou API vraceny postupně po virtuálních stránkách s maximálně 25ti příspěvky a případnými odkazy na další či předchozí stránku. Tato URL má následující podobu: https://graph.facebook.com/FEDDID/feed?access_token=ACCESS_TOKEN Pro každý takto získaný status pak pomocí následujícího volání API získáme uživatelský profil autora:

64

6.1. Získávání dat https://graph.facebook.com/AUTHOR_ID?access_token=ACCESS_TOKEN V případě, že status má nějaké komentáře, stáhneme i ty. Je-li jich víc než 25, jsou opět vrácená data stránkována a je potřeba je postupně všechna projít. https://graph.facebook.com/FEED_ID/comments?access_token=TOKEN Pro každý stažený komentář je opět potřeba stáhnout kompletní profil uživatele, stejně tak pro každý like u statusu či komentáře. Jedině tím zachytíme kompletní aktivitu uživatelů na daném feedu/stránce. https://graph.facebook.com/FEED_ID/likes?access_token=TOKEN Všechna takto získaná data je pak následně potřeba přetransformovat do podoby vhodné pro další analýzu, tedy do jednotlivých dokumentů, se kterými pak bude pracovat nástroj ICA. Vzniknou tři typy dokumentů status, komentář a profil. status Obsahem dokumentu typu status je samotný text, metadata jsou pak například počet like, počet komentářů, seznam autorů komentářů oddělených čárkou atd. komentář Obsahem dokumentu typu komentář je text komentáře. Tento dokument má jako jedno z metadat také ID původního statusu a jeho obsah, aby se i v této ploché struktuře zachovala návaznost jednotlivých vláken a aby na něj šlo případně později reagovat, a analytik tak neztratil kontext komentáře. Vláknovost těchto diskuzí ztěžuje analytickou práci a bylo by zapotřebí vymyslet nějaké lepší řešení pro podporu takovéto struktury. Architektura zvoleného analytického nástroje ovšem dovoluje pouze plochou dokumentovou strukturu. Pro potřeby demonstrace je tento způsob nicméně dostačující. profil Dokument typu profil nemá žádný textový obsah, pouze metadata o uživateli. Limity používání služby Facebook nelimituje své API technologicky, a je tak možné crawlovat veřejná data prakticky bez většího omezení. Limity se ovšem vztahují na data, která jsou pomocí API dostupná. Uživatel třetí strany tak například nemá přístup k datům uživatele, která sdílí na 65

6. Praktická část svém profilu, pokud jsou tyto data nastavena jako soukromá a uživatel není s cílovým subjektem "přítel". Jedním ze způsobů, jak toto obejít, je ovšem situace, kdy si uživatel, jehož data chci číst, přidá mnou vytvořenou aplikaci mezi důvěryhodné a přidělí jí práva přístupu ke svým osobním datům.

6.1.5

Twitter

Sociální síť Twitter poskytuje dva způsoby jak získávat tzv. tweety, tedy zprávy, které si uživatelé pomocí tohoto média posílají. Oba principy jsou fundamentálně zcela odlišné a každý z nich se hodí na něco jiného. Považuji za důležité je od sebe odlišit a zdůvodnit svou volbu. Další část této kapitoly popisuje proces získávání dat z této sítě pomocí mnou navržené aplikace, stejně jako zobrazuje výstup tohoto snažení. 6.1.5.1

Search API

Toto rozhraní je na ovládání ze strany vývojáře jednodušší než níže popisované Stream API. Vše, co k práci s tímto nástrojem potřebuje, je HTTP protokol a jeho metoda GET, jejíž pomocí získá obsah ze speciální REST adresy. Limity používání služby Limit počtu volání před tím, než je aplikace Twitterem odpojena, není pro toto rozhraní zveřejněn z důvodu, že by se jej vývojáři pokoušeli obcházet, nastavovali svoje crawlery tak, aby těsně splňovaly dané podmínky. Twitter sám považuje toto rozhraní jako dostačující pro většinu aplikací, ve kterých jeden uživatel vyhledává na této sociální sítí tweety pro vlastní potřebu a nezáleží mu až tak na kvantitě. V případě, že uživatel tento nepsaný limit překročí, dostane místo tweetu v odpovědi na své HTTP GET volání speciální zprávu, která obsahuje počet sekund, které musí daná aplikace vyčkat před dalším zavoláním služby. Bude-li aplikace tato varování ignorovat a snažit se agresivně získávat data z Twitteru bez přerušení, může být odpojena i na trvalo blokací zdrojové IP adresy. Zpoždění přijímaných dat Data získávána touto metodou jsou bez výjimky retrospektivní a jsou dostupná až ve chvíli, kdy zavolám příslušné rozhraní. Zpoždění tedy odpovídá prodlevě mezi jednotlivými voláními. Limity přijímaných dat ∙ Na jedno volání je uživatel schopen vrátit maximálně 100 výsledků, tweetů, přičemž s využitím stránkování (automatická funkce Search 66

6.1. Získávání dat API, která u každého volání vrací také odkaz na další virtuální stránku výsledků) lze na jeden dotaz získat až 15 těchto stránek, tedy maximálně 1500 tweetů. ∙ Větší problém představuje v případě tohoto rozhraní samotná kvalita dat. Známým nedostatkem, který v tomto rozhraní existuje pravděpodobně již od jeho vzniku, je nespolehlivost zobrazování unikátního identifikátoru (ID) uživatele = autora tweetu. Rozhraní náhodně vrací jinou hodnotu, a nedá se jí tak věřit. Toto představuje problém především ve chvíli, kdy chce cílová aplikace agregovat získaná data a zobrazit například počet tweetu pro jednotlivé autory a podobně. Takovéto výsledky pak mohou být nepřesné. ∙ Toto API umožňuje vrátit pouze tweety s ID vyšším než námi poskytnuté, což lze regulovat pomocí parametru "since ID".Toto je využíváno především pro získaní nových tweetů v případě opakovaného volání stejného dotazu. API bohužel často tento příkaz ignoruje a vrací i starší tweety, což si vynucuje kontrolu i na straně příjemce. 6.1.5.2

Stream API

Pomocí tohoto API se koncová aplikace napojí přímo na výstupní zdroj Twitteru, který do něj pak produkuje všechny tweety, jež odpovídají definovaných parametrům (klíčová slova, uživatelé či geolokalita tweetu, viz dále). Z popsaného plyne, že tato metoda vyžaduje, aby bylo spojení se serverem Twitteru trvalé a nepřerušované. V opačném případě přijde cílová aplikace o ty tweety, které na sociál síť přibyly ve chvíli, kdy zrovna "neposlouchal". V reálném nasazení je toto spojení udržováno po takovou dobu, po jakou je potřeba monitorovat daná slova či jiné parametry, může přitom jít o dny, měsíce, či dokonce roky. Spojení se navazuje na následující URL https://stream.twitter.com/1/statuses/filter.json Limity používání služby Důležitým rozdílem oproti Search API jsou limity aplikované na toto rozhraní. V tomto případě totiž neexistuje omezení na počet volání služby, neboť je spojení navázáno permanentně. Pro každé volání (tedy navázání spojení) je možné definovat několik parametrů, které mají vliv na výsledky vracené rozhraním. ∙ track umožnuje nastavit až 400 slov, tagů či jmen uživatelů, které chceme v tweetech fulltextově vyhledávat. U jmen uživatelů platí, že 67

6. Praktická část tímto filtrem projdou pouze, pokud jsou v tweetech tzv. zmínění, nevztahuje se tedy na autorství. ∙ follow umožňuje sledovat až 5000 různých uživatelů a vracet všechny tweety, které tito autoři nasdílí. Nevrací tedy tweety, ve nichž jsou uživatelé zmíněni, ale pouze ty, které sami vytvoří. ∙ location umožňuje definovat až 25 lokalit, ze nichž chceme sledovat tweetu. Lokalita není povinná u všech tweetů a je čistě na autorovi, jestli se rozhodne lokalitu zveřejnit, nebo ne. Je důležité zmínit, že všechny tyto atributy fungují současně, přesto nezávisle. Neexistuje tedy mezi nimi AND, ale OR. API tak vrátí všechny tweety, co odpovídají TRACK parametrům, a zároveň i všechny tweety z definované oblasti. Nevrátí tedy pouze tweety na hledaná témata z dané oblasti. Tento stupeň filtrace je případně potřeba provést v aplikaci. Zpoždění přijímaných dat Data získávaná pomocí Stream API lze považovat za realtime. Jediné zpoždění, ke němuž dochází, může být způsobeno momentální přetížeností sociální sítě Twitter, případně přenosové sítě jako takové. Oba druhy zpoždění jsou však v našem uvažování zanedbatelné. 6.1.5.3

Volba Twitter API

Pro účely tohoto projektu jsem si zvolil Stream API, tedy kontinuální tok tweetů na mnou určená témata. Hlavním důvodem byly lepší vlastnosti tohoto rozhraní, prakticky neexistující limit na sbíraná data, ale hlavně také větší relevance vzhledem k demonstrovanému záměru. Pokud by totiž jakákoli organizace opravdu chtěla implementovat technologii pro analýzu Twitteru, musela by nepochybně využít právě tohoto API. 6.1.5.4

Princip sběru dat pomocí Twitter Stream API

Pro sběr tweetů pomocí zvoleného STREAM API je potřeba navázat trvalé spojení se serverem Twitteru a definovat si výrazy, uživatelské účty nebo lokality, ze kterých chceme dostávat tweety [55]. Klientská aplikace se musí starat o toto spojení a poslouchat, jestli server neposílá tweet odpovídající zadným parametrům. Pokud ano, musí jej zpracovat a poslat na zpracování do analytického nástroje. V případě, že jsou vyhledávací podmínky definovány příliš široce a odpovídá jim příliš velké množství tweetů, nebudou doručeny všechny tweety. Twitter pro tuto situaci používá jednoduchou metriku postavenou na šíři 68

6.1. Získávání dat

Obrázek 6.3: Princip získání dat z Twitteru

aktuálního datového toku. Pokud zadané parametry odpovídají méně než 1% aktuálně celosvětově generovaných tweetů, budou doručeny všechny. V opačném případě Twitter doručí jenom některé a zároveň také zprávu s parameterem limit, jejíž hodnota určuje pravděpodobný počet tweetů, které nebudou doručeny. Jelikož toto API pracuje v reálném čase, nelze se k těmto tweetům již dostat, a jsou tak pro potřeby analytiky ztraceny.

6.1.6

Crawler Manager

Provedl jsem analýzu dostupných nástrojů a nakonec jsem se rozhodl, že pro potřeby sběru dat ze zadaných sociálních sítí vytvořím vlastní nástroj, neboť žádný jiný nevyhovoval mým podmínkám. Nástroj musí být zdarma dostupný, konfigurovatelný a navíc by měl mít možnost přímo posílat získané dokumenty do zvoleného analytického nástroje IBM Content Analytics. Navržené řešení jsem se nicméně snažil pojmout jako nástroj, který by měl být znovupoužitelný i pro jiné projekty a neměl být úzce svázán pouzena se zvolenou technologií IBM Content Analytics. Kromě exportu přímo do aplikace jsem tak rozhodl přidat možnost exportovat získané příspěvky také na souborový systém. Takto získaná data by šla vložit do jiných analytických nástrojů, případně s nimi dále pracovat. 69

6. Praktická část Rozhodl jsem se proto vytvořit samostatnou aplikaci a nazval ji "Crawler Manager". 6.1.6.1

Požadavky

∙ Vývoj v jazyku JAVA s důrazem na přenositelnost i na NIXové systémy, na kterých mohou analytické nástroje běžet. ∙ Konfigurovatelnost zdrojů bez nutnosti zasahovat do kódu s důrazem na znovupoužitelnost aplikace. ∙ Přehledné a intuitivní grafické rozhraní. ∙ Možnost přímého exportu dokumentů do nástroje IBM Content Analytics. ∙ Možnost přímého exportu dokumentů na souborový systém. ∙ Aplikace by měla podporovat vlákna z důvodu paralelního crawlování více zdrojů. Aplikaci Crawler Manager jsem navrhl a vytvořil s cílem zjednodušit získávání dat ze sociálních sítí pro jejich následnou analýzu. Aplikaci lze snadno rozšířit o další sociální sítě, což ovšem není součástí cílů práce. 6.1.6.2

Použité technologie

Aplikaci jsem vyvinul v jazyce Java. Pro grafické rozhraní jsem zvolil standardní Java GUI framework SWING. Pro komunikaci se servery jednotlivých služeb jsem zvolil opensource knihovnu Apache HTTP Components. V aplikaci se často opakovala potřeba převést vstupní JSON (Javascript Object Notation) na objekt, s nímž lze v Javě pracovat a následně jej na výstupu zase převést do podoby JSONu. K tomuto účelu jsem využil opensource knihovnu Google Gson, která mapuje vstupní JSON na statické Java třídy (obdboa Java Beans v J2EE) a naopak. 6.1.6.3

Uživatelské rozhraní

Při návrhu grafického rozhraní jsem se snažil o co největší jednoduchost a uživatelskou přívětivost 6.4. Uživatel by měl okamžitě pochopit, jaké parametry má nastavit a jak aplikaci ovládat. 70

6.1. Získávání dat

Obrázek 6.4: Grafické rozhraní aplikace Crawler Manager

V horní části aplikace má možnost uživatel nastavit parametry spojení s produktem IBM Content Analytics, respektive jeho REST API, které pro posílání nacrawlovaných dokumentů využívám 6.5.

Obrázek 6.5: Nastavení spojení s ICA REST API Pro každou sociální síť je zde pak dostupná jedna karta, která obsahuje všechna důležitá nastavení. Spuštění crawleru se provede kliknutím na zelené tlačítko start. V případě, že se vše správně nastaveno, objeví se v závislosti na zadaných parametrech výsledky v logu. Zároveň se tyto výsledky paralelně odesílají i do nástroje IBM Content Analytics, kde se indexují do kolekce dokumentů. K tomu také slouží mapovací tabulka, pomocí které je možné namapovat vstupní data na metadata dokumentu vkládaného do nástroje ICA. Uživatel má také možnost zvolit export na souborový systém a použít jej 71

6. Praktická část v jiném nástroji. Zároveň se spuštěním crawleru se také aktivuje počítadlo, které uživateli umožňuje zjistit, kolik dokumentů/tweetů/statusů již načetl, kolik bylo v rámci dané stránky (např. v případě Facebooku) nalezeno unikátních uživatelů (nezávisle na tom, jestli "pouze"dali like, komentovali, nebo přispěli statusem) a jak dlouho již crawler běží. Tyto informace lze pak samozřejmě zjistit i z nástroje ICA, toto počítadlo je zde pouze pro kontrolu a obecný přehled při crawlování. Výstup spuštěného Twitter crawleru například vypadá následovně. Zadány byly parametry track=bank,money,politics Na screenshotu jsem zakryl klíč aplikace

Obrázek 6.6: Ukázka spuštěného Twitter crawleru V případě sítě Facebook se pak nastavuje seznam unikátní identifikátorů feedů, tedy stránek, které se mají nacrawlovat. Nastavení exportu je podobné, včetně důležitého namapování na metadata dokumentu v ICA.

6.1.7

Prvotní analýza informací z veřejných zdrojů

V tuto chvíli jsou již nastavené externí crawlery, a vstupní data jsou tak připravena. Ještě než se spojí s interními daty v nástroji ICA (přepisy telefonních hovorů, interní poznámky a další), lze udělat prvotní zběžnou analýzu získaných dat. Pro demonstraci přikládám takovouto analýzu pro 72

6.1. Získávání dat

Obrázek 6.7: Ukázka spuštěného Facebook crawleru

sociální síť Facebook u vybraných uživatelských profilů. Jak jsem již zmínil v úvodu praktické části, jde o profily největších bankovních organizací v České republice. Samotný obecný přehled lze vidět na obrázku 6.8. Počet like vyjadřuje, kolik lidí (příznivců značky) vyjádřilo svou podporu značce pomocí tlačítka "like". Toto číslo samo o sobě ovšem nemá vysokou vypovídající hodnotu. Už z tohoto obecného grafu plyne, že například Česká spořitelna, ačkoli má na Facebooku méně like, má aktivnější uživatele, neboť více přispívají. Modrá barva v grafu vyjadřuje počet unikátních uživatelů v rámci stránky. Může jít o ty uživatele, kteří přispěli svým statusem na profil dané organizace, komentovali některý ze statusů či vyjádřili like. Obecně lze říci, že je to počet všech unikátních uživatelů, kteří byli na této stránce jakkoli aktivní. Analýzu informací na této úrovni nelze samozřejmě nazvat pokročilou. Stejně jako nám nijak nepomůže přiblížit samotný obsah dat, témata, o kterých se v nich hovoří, a další důležité informace. Je proto potřeba zapojit IBM Content Analytics. 73

6. Praktická část

Obrázek 6.8: Aktivita českých bank na sociální síti Facebook

6.2

Analýza a zpracování dat

Tato sekce popisuje nastavení analytické nástroje pro potřeby samotné analýzy. Samotný proces nastavení je poměrně zdlouhavý a považuji za zbytečné popisovat jej zde krok po kroku. Sekce se proto zaměřuje pouze na ty nejdůležitější části.

6.2.1

HW analytického stroje

Množství zpracovávaných dokumentů mi nedovolilo spustit celé řešení na svém počítači, a byl jsem tak nucen implementovat jej v cloudu. Virtuální stroj pak dostal přiděleno 8 procesorů Intel Xeon, 12 GB RAM a 200 GB diskového prostoru. Zkušenosti nicméně ukazují, že přidělená paměť pro množství 1.5 milionu dokumentů nedostačuje a při reálném použití by bylo potřeba paměť zvýšit. Hlavní zátěž serveru probíhá při indexování příchozích dokumentů. Analytická práce nad daty a vyhledávání již nepředstavuje velkou zátěž. 74

6.2. Analýza a zpracování dat

6.2.2

Nastavení nástroje ICA

Základním předpokladem pro analýzu dat v nástroji ICA je vytvoření analytické kolekce a nastavení všech jejích parametrů. Těmi nejdůležitějšími jsou metadata analyzovaných dokumentů, která musí být nastavena ještě než se spustí samotný proces crawlování, jinak by všechna metadata odesílaná mnou vytvořenou aplikací Crawler Manager byla ignorována a u dokumentů by byl ukládán pouze textový obsah a datum vytvoření. Pro síť Facebook vypadá například nastavení těchto metadat v administračním rozhraní nástroje ICA následovně 6.9.

Obrázek 6.9: Nastavení metadat dokumentů v nástroji ICA Je také potřeba nastavit tzv. fazety neboli pohledy na data, rozhodnout, která data se v nich mají zobrazovat, a připravit je pro následně vytvářené slovníky.

6.2.3

Příprava slovníků

Slovníky jsou důležitou součástí analytického procesu v nástroji ICA. Definováním vlastního slovníku může analytik zpřesnit své výstupy a zasadit je do kontextu. Vytvoří-li například slovník produktů organizace a slovník názvu firem konkurence, může pomocí nástroje ICA omezit kvantum všech analyzovaných dokumentů pouze na ty, které se týkají daného produktu (například se o něm diskutuje), přepnout pohled na jinou fazetu se slovníkem konkurence, nadále omezit (již omezený tématem produktu) výběr dokumentů na ty, kde se také diskutuje o vybrané konkurenční firmě, zjistit, o jaké se v souvislosti s produktem mluví nejčastěji, a mnoho dalšího. Pro demonstraci možností ICA jsem proto vytvořil jednoduchý slovník bankovních služeb, který jsem následně přidal do fazety Služby. Slovník obsahuje následující výrazy: 75

6. Praktická část ∙ hypotéka, ∙ půjčka, ∙ úvěr, ∙ splátka, ∙ účet, ∙ debetní karta, ∙ kreditní karta, ∙ visa, ∙ mastercard, ∙ poplatek, ∙ kontokorent. Bylo také potřeba nastavit, aby byly v analýze zahrnuty i všechny skloňované verze výše zmíněných slov, u slova splátka to tak budou i slova: splátku, splátky, splátkách, splatit, splatnost, splátkách, splátkou, splácet, splátek, splácení a tak dále.

6.2.4

Úprava sentimentu Českého jazyka

Český sentiment v produktu ICA prozatím není oficiální a byl vytvořen lokální pobočkou pro vlastní potřeby. Na tvorbě sentimentu jsem se také podílel. Sentiment je kontinuálně upravován a vylepšován na základě nalezených příkladů v datech. Je realizován pomocí rozsáhlých slovníků pozitivních výrazů, negativních výrazů, seznamu slov vyjmutých ze sentimentu a seznamu negací. Během práce na své ukázce jsem nalezl několik dalších výjimek a tyto seznamy upravil. Přesnost tohoto sentimentu v současné době nicméně ještě není 100%, pro potřeby mé demonstrace nicméně dostačuje.

6.2.5

Analytická aplikace pro laiky

Sekce popisuje návrh a vývoj webové aplikace pro koncového uživatele. Aplikace slouží jako jednotný vizualizační nástroj analyzovaných výsledků pro laickou veřejnost organizace, tedy ty pracovníky, kteří nebyli vyškoleni k práci se sofistikovaným nástrojem ICA, ale přesto chtějí získat výhody pokročilého nástroje pro analýzu nestrukturovaných dat. 76

6.2. Analýza a zpracování dat 6.2.5.1

Důvod

Jakkoli je nástroj IBM Content Analytics schopný sofistikovaně analyzovat vstupní dokumenty, indexovat je proti slovníkům a vytvořeným pravidlům nebo rozeznat sentiment jednotlivých vět či témat, pro prezentaci výsledků je jeho sofistikovanost spíše překážkou. Myšlenkou analytiky Big Data, kterou ve své práci zdůrazňuji, není pouze zjištění informací, ale také jejich prezentace koncovému uživateli v jednoduché, pro něj snadno stravitelné formě tak, aby okamžitě pochopil klíčové informace a mohl bez složitějšího přemýšlení jednat. Ovládání nástroje ICA nicméně vyžaduje proškolení uživatele a určitou míru zkušenosti. Rozhodl jsem se tedy, že pro demonstraci svého konceptu vytvořím vlastní webovou aplikaci, která bude prezentovat výstupy analýzy v takové podobě, jakou považuji za uživatelsky jednoduchou a přívětivou. Za cílový "modelový"objekt laického uživatele jsem zvolil pracovnici banky, která za přepážkou přijímá klienty a nemá příliš času každého z nich podrobně studovat a dohledávat všechnu jeho aktivitu. Přesto by ráda věděla, tzv. "s kým má tu čest"a co daného klienta pravděpodobně zajímá, případně jaké služby banky by jej mohly oslovit a co mu tedy může nabídnout. 6.2.5.2

Požadavky

Aby mnou navržená aplikace splňovala výše popsaná očekávání, musí splňovat některé požadavky ∙ Dostupnost bez nutnosti instalace, ideálně přes webový prohlížeč. Požadavek na ovladatelnost bez nutnosti instalace je dán tím, že uživatelé (zaměstnanci) by jinak aplikaci neradi využívali a nebyla by snadno přístupná na dnešních moderních komunikačních zařízeních, jako například tablety, mobilní telefony a podobně. ∙ Jednoduché, snadno ovladatelné a uživatelsky přívětivé uživatelské rozhraní. Podobně jako s nutností instalace i uživatelsky nepřívětivé rozhraní odrazuje koncového uživatele od využívání aplikaci, i kdyby byla její funkcionalita bez chyby. Uvědomuji si nicméně, že estetika je věcí subjektivní, a aplikace by tak měla být spíše střídmá. ∙ Možnost vyhledávat podrobný obsah dokumentů. Výsledné řešení bude mít tři úrovně analytického vhledu. Nejvyšším stupněm bude možnost analyzovat dokumenty přímo v nástroji ICA, 77

6. Praktická část která bude dostupná pouze pro vyškolené analytiky a pracovníky k tomuto úkol dedikované. Laický uživatel / zaměstnanec sedící na přepážce nicméně také potřebuje mít přístup k analyzovaným výsledkům, neboť je to právě on, kdo přichází do styku s koncovým klientem. Měl by mít možnost jak získat jednoduchý přehled o klientovi, tak dohledat v případě potřeby i konkrétní příspěvky (dokumenty). ∙ Možnost vyexportovat vybranou podmnožinu dokumentů jako PDF či email pro další zpracování. 6.2.5.3

Design

Z důvodu požadavků na dva možnost dvou rozdílných pohledů jsem rozhodl, že úvodní obrazovka bude mít formát, který je patrný z obrázku 6.10. Po spuštění aplikace dostane uživatel možnost vyhledat informaci pomocí analytického nebo pokročilého pohledu.

Obrázek 6.10: Úvodní strana analytické aplikace pro koncového uživatele Uživatel si zvolí požadovaný pohled najetím myši nad danou kostku. Analytický pohled mu zprostředkuje okamžitý přehled o vyhledávaném výrazu - ať již klientem (jeho ID), názvem produktu, nebo třeba jménem konkurenční firmy. Příklad výstupu analytického pohledu lze vidět na obrázku 6.11. Vyhledány byly dokumenty týkající se klienta s určitým ID. 78

6.2. Analýza a zpracování dat Koláčový graf ukazuje sentiment jeho příspěvků, kde zelená značí pozitivně laděné příspěvky, červená negativně laděné příspěvky a žlutá reprezentuje neutrální příspěvky. Dále vidíme o čem zvolený klient nejčastěji hovoři a co jej zajímá.

Obrázek 6.11: Přehledový pohled v analytické aplikace pro koncového uživatele V případě výběru Pokročilého vyhledávání dostane uživatel možnost vyhledávat přímo v dokumentech, již analyzovaných nástrojem ICA, a tak obohacených o sentiment či jiná definovaná metadat. Na obrázku 6.12 vidíme příklad výstupu pro zvoleného klienta, u které máme možnost vidět všechny jeho příspěvky napříč všemi sociálními sítěmi i interními dokumenty. Zeleně podtržené věty jsou pozitivně laděny, červené pak negativně. 6.2.5.4

Zvolené technologie

Aplikaci jsem původně chtěl napsat pouze v Javascriptu, HTML5 a CSS3 s využitím volání REST služeb na serveru, nicméně nakonec jsem své záměry upravil a vytvořil webovou aplikaci J2EE, která celá běží na webovém serveru GlassFish. Důvodů pro změnu bylo více, tím hlavním však bylo omezení Javascriptu při volání služeb na serveru. Všechny moderní prohlížeče totiž mají implemetovánu tzv. same origin policy, která zamezuje Javascriptu volat 79

6. Praktická část

Obrázek 6.12: Pokročilý pohled v analytické aplikace pro koncového uživatele

služby na jiné doméně, než ta, ze které pochází. Jelikož jsem chtěl, aby aplikace byla co možná nejmoderněji pojatá a využívala AJAX volání pro získání výsledků vyhledávání a následného vykreslení obsahu webu bez nutnosti znovu načíst stránku, byla možnost volat vlastní služby přímo z prohlížeče naprosto zásadní. Tuto bezpečností politiku sice lze obejít pomocí metody JSONP (volání webové služby s tím, že se výsledek vrátí jako callback funkce), to ovšem funguje pouze pro HTTP metodu GET. V aplikaci ale potřebuji i metodu POST (například pro odeslání vybraných dokumentů při exportu do PDF). Pro tu lze same origin policy obejít pouze triky s iFrame, to už mi ale nepřišlo dostatečně elegantní ani udržitelné, proto padla volba na J2EE. Webovou aplikaci (její face směrem k uživateli) J2EE tvoří 3 servlety index.jsp, advanced.jsp a overview.jsp, vše ostatní se v rámci těchto servletů mění dynamicky pomocí Javascriptu. Bylo také potřeby vytvořit si vlastní webové služby, které slouží jako proxy k REST API nástroje ICA a zároveň "předzpracovávají"výsledky do podoby konzumované samotnou webovou aplikací. Tímto krokem jsem chtěl minimalizovat zátěž klientského prohlížeče, který je tak pouhým "zobrazovátkem"dat nějaké větší logiky. Webové služby jsem realizoval jako REST pomocí opensource Java knihovny Jersey (JAX-RS). Popis jednotlivých 80

6.2. Analýza a zpracování dat REST zdrojů následuje. Pro potřeby exportu vybraných dokumentů do PDF jsem do řešení integroval opensource JAVA knihovnu Flying Saucer. Na straně klientské aplikace jsem využil, kromě již zmíněného Javascriptu, HTML5 a CSS3, hlavně toolkity D3js a Dojo. Hlavně D3 je skvělý nástroj pro manipulaci s Document Object Modelem webové aplikace, která je založená na datech, což je přesně tento případ. Pomocí D3 také generuji všechny vizualizace v mojí aplikaci, které vykresluji do SVG. Z tohoto důvodu je také aplikace funkční pouze v těch prohlížečích, které SVG podporují (starší verze Internet Exploreru například SVG nepodporují). 6.2.5.5

REST API

Pro potřeby této aplikace jsem potřeboval vytvořit na serveru webovou službu, jež bude komunikovat přímo s nástrojem ICA a připravovat informace přesně do takové podoby, kterou bude má aplikace bez další logiky konzumovat. GET /overview/sentiment Rozhraní pro zadaný výraz vrátí jednoduchý JSON objekt s počtem pozitivních, neutrálních a negativních dokumentů. Slouží jako zdroj pro pie chart webové aplikace. GET /overview/words Rozhraní pro zadaný výraz vrací obsah fazety "podstatná jména". Obsahuje tedy slova která se ve výsledných dokumentech nejčastěji vyskytují. GET /overview/count Rozhraní pro zadaný výraz vrací předpokládaný počet výsledků vyhledávání. GET /overview/sources Rozhraní pro zadaný výraz vrací hodnotu fazety "Zdroje". Obsahuje přehled zdrojů, ze kterých pochází informace pro zadaný výraz či od konkrétního autora a podobně. GET /overview/type Rozhraní pro zadaný výraz vrací hodnotu fazety "Typ". Obsahuje přehled typů informace pro zadaný výraz či autora - komentář, fotografie, článek, diskuze, a další. GET /advancedSearch Rozhraní pro zadaný výraz vrací hlavičky dokumentů včetně krátkého textu shrnutí. Druhým parametrem je počet těchto 81

6. Praktická část dokumentů - 10, 20, 100 až maximálně 3000, což je technologický limit nástroje ICA. POST /advanced/document/pdf Rozhraní vygeneruje PDF ze zaslaných dat. GET /advanced/document/pdf Rozhraní vrátí PDF pro zadanou unikátní URI. POST /advanced/document/email Rozhraní vygeneruje HTML email ze zaslaných dat. GET /advancedSearch/document Rozhraní pro zadané ID dokumentu vrátí skutečný a úplný obsah dokumentu. 6.2.5.6

Možnost exportu

Uživatel má možnost dokumenty, vybrané v pokročilém pohledu webové aplikace, exportovat do PDF nebo HTML, což se hodí pro případné odeslání pomocí emailu. Tuto možnost vidíme na obrázku 6.13. Výběr provádí uživatel kliknutím myši.

82

6.2. Analýza a zpracování dat

Obrázek 6.13: Možnosti exportu v aplikaci Customer Intelligence

83

Kapitola

Výsledky řešení V tomto bodě jsou již všechna data indexována v nástroji ICA. V návaznosti na cíle práce na nich chci demonstrovat možnosti Customer Intelligence a popsat myšlenkový proces takové analýzy. Není prostor popisovat zde všechny možné scénáře a z principu to ani není možné, neboť každý takový případ je velice úzce spjat s tím, co daná organizace potřebuje a jaké má očekávání. Volím proto obecné, přesto dle mého názoru velice relevantní business drivery: 1. Nalézt zákazníka/y, který vyjadřuje přání odejít od organizace. 2. Nalézt zákazníka/y se stížností. 3. Analyzovat náladu příspěvků z určitého zdroje a také od určitého klienta. 4. Identifikovat nejčastěji diskutovaná témata pro vybraného klienta. 5. Identifikovat příspěvky od konkrétního klienta napříč všemi daty.

7.1

Analýza získaných dat expertem

Nejprve je potřeba se podívat na získaný vzorek dat, z něhož bude analýza vycházet. Podařilo se mi nashromáždit 1 589 327 dokumentů (článků, statusů, příspěvků) z velkého množství zdrojů. Například obrázek 7.1 zobrazuje přehled množství informací z vybraných mediálních webů. Tato sekce uvádí příklad, jak by s nasbíranými daty mohl pracovat analytik vyškolený k práci s nástrojem. Věřím, že jednotlivá nastavení nástroje nejsou pro prezentaci konceptu až tak důležitá, uvádím proto pouze výstupy. 85

7

7. Výsledky řešení

Obrázek 7.1: Přehled dokumentů získaných z vybraných mediálních webů

Obrázek 7.2 pak zobrazuje frekvence příspěvků pro vybrané profily ze sociální sítě Facebook.

Obrázek 7.2: Přehled dokumentů získaných z vybraných bankovních profilů sítě Facebook Samotná čísla nejsou ovšem tak zajímavá jako to, co je za nimi skryto. Řekněme, že analytika zajímá aktivita na těchto vybraných profilech na Facebooku a chtěl by například vědět, kdy byly jednotlivé příspěvky na profily přidány 7.3. V případě, že by nalezl nějaké výkyvy, například rychlý nárůst aktivních uživatelů/zákazníků, mohl by dále pátrat čím byl způsoben - například nějakou úspěšnou marketingovou kampaní, plošnou slevou na produkt či cokoli podobného. Taková informace opět pomůže lépe poznat, co na zákazníky platí a co ne. Výstupy naznačují, že nárůst aktivity je poměrně lineární s menšími výkyvy, což nám žádné zásadní informace nepřineslo, podíváme se tedy na samotnou strukturu příspěvků, která je patrná z obrázku 7.4. Zobrazené grafy patří příspěvkům typu komentář (comment), status a odkaz (link). Výška sloupce v grafu značí celkové množství příspěvků v daném měsíci, barva sloupce významnost korelace vůči ostatním měsícům. 86

7.1. Analýza získaných dat expertem

Obrázek 7.3: Přehled aktivity na vybraných bankovních profilech sítě Facebook v čase

Obrázek 7.4: Přehled stuktury příspěvků na vybraných bankovních profilech sítě Facebook v čase

Tento pohled již prozrazuje, že v některých měsících byla korelace příspěvků určitého typu vůči ostatním vyšší (barva je oranžová, až červená), a stojí tak za to daný trend prozkoumat. Důvodem zvýšení počtu komentářů 87

7. Výsledky řešení může být například nefunkční služba (v kontextu bank například internetové bankovnictví) a s tím spojené stížnosti uživatelů. Pomocí nástroje ICA si tedy omezíme dokumenty pouze na ty z ledna 2012 a hned zjistíme, že důvodem byla nefunkčnost některých platebních karet, jak dokládá obrázek 7.5 s konkrétním příspěvkem klienta. Vidíme zároveň také negativní sentiment dané věty. Zároveň jsme tím našli příklad stížnosti zákazníka skryté v textu.

Obrázek 7.5: Příklad nalezené stížnosti - nefunkční karta Když už jsme narazili na sentiment, bylo by užitečné zobrazit si celkový sentiment jednotlivých zdrojů informací (obrázek 7.6). Tento pohled nám odkryje, které zdroje jsou negativní/pozitivní, což se opět velice hodí pro další podrobnější analýzu. Je-li zdroj vyloženě negativní (převládá u něj červená barva), lze dále zkoumat příčiny - o čem se v něm píše, kdo v něm píše, jak velká aktivita v něm probíhá. Je to důležité zejména ve chvíli, kdy se v daném zdroji píše přímo o dané organizaci. Negativní články mají negativní dopad na případné klienty tím více, čím větší dané médium je. 88

7.1. Analýza získaných dat expertem

Obrázek 7.6: Sentiment získaných informačních zdrojů

U každého zdroje si přitom můžeme zobrazit jednotlivé dokumenty a podrobněji zkoumat jaké výrazy se v nich používají a kde je sentiment negativní (červená barva) 7.7 či pozitivní (zelená barva) 7.8.

Obrázek 7.7: Sentiment získaných informačních zdrojů - detail pro e15.cz na negativní výrazy 89

7. Výsledky řešení

Obrázek 7.8: Sentiment získaných informačních zdrojů - detail pro e15.cz na pozitivní výrazy Abychom lépe poznali klienta, je dobré vědět, o jakých produktech/službách se mluví, což je patrné z pohledu 7.9. V tom nám pomůže analýza na základě slovníků, které jsem pro tuto demonstraci vytvořil a pomocí kterých se vstupní dokumenty indexují. Slovník služeb například odkryje, že se nejvíce diskutuje o účtech, poplatcích a hypotékách. Vím-li takovouto informaci, mohu jako banka připravit nějakou akci zaměřenou více na tyto oblasti, neboť klienti je pravděpodobně vyžadují a zajímají se o ně. Již to bylo zmíněno několikrát, ale zdůrazňuji ještě jednou, že toto je pouze demonstrace možností a rozhodně nepokrývám všechny možnosti technologie. Pokud bych chtěl například vědět, o jakých produktech se v dokumentech mluví, vytvořím další slovník se seznamem všech produktů. Pokud bych chtěl vědět, jestli se v datech nemluví o nějakých sportech, vytvořím slovník sportů a tak podobně. Pokud už takovýto slovník máme, můžeme si pak zobrazit u jednotlivých bankovních služeb i sentiment, tedy jak se o nich mluví. Z obrázku 7.10 je tak například patrné, že sentiment produktu "účet"je poměrně vyrovnaný. Úkolem analytika také nepochybně bude sledovat a identifikovat klienty, kteří si přejí odejít. Je spousta způsobů, jak takové příspěvky pomocí nástroje ICA najít, nejjednodušší je ovšem použít vyhledávacího engine. Nástroj automaticky počítá, kolik výsledků bude pravděpodobně dostupných pro vyhledávaný výraz (tedy že například pro výraz "odcházím"vrátí 100 dokumentů, jak je patrné z obrázkuu 7.11), a pak například identifikovat 90

7.1. Analýza získaných dat expertem

Obrázek 7.9: Přehled diskutovaných služeb

Obrázek 7.10: Sentiment bankovních služeb

konkrétního klienta, v tomto případě pana Miloslava Klímu, který na profilu AirBank vyjadřuje touhu opustit mBank. Tento příspěvek je pak vidět na obrázku 7.12.

Obrázek 7.11: Vyhledávání klientů, kteří chtějí odejít od organizace

91

7. Výsledky řešení

Obrázek 7.12: Příklad uživatele, který chce opustit mBank

7.2

Analýza dat laikem na přepážce

Analytická práce nad získanými daty sice může přinést zajímavé výsledky a vyústit například v návrh marketingové kampaně na míru, je ovšem dostupná pouze vybraným vyškoleným analytikům. Práce s nástrojem IBM Content Analytics není triviální a ve velké organizaci, jakými banky dozajista jsou, není možné vyškolit na jeho ovládání všechny zaměstnance, nemluvě o časté licenční politice podobných nástrojů, které se limitují na počet aktivních uživatelů. Zahrnutí všech pracovníků by tedy celé řešení zbytečně prodražilo. Big Data a analytika má hlavní přínos jen tehdy, pokud bude ve správný čas na správném místě. A tímto místem, kde s klientem komunikuje nejčastěji, je přepážka banky. Pro demonstraci myšlenky jsem si vymyslel scénář, kdy klient přichází na přepážku z důvodu vyřízení nějaké pohledávky (která v tomto případě není důležitá). Pracovnice banky na přepážce má spuštěnou aplikaci Customer Intelligence (v reálné situaci by byla integrována například v interním CRM systému), do níž zadá klientovo unikátní ID (případně jakýkoli jiný identifikátor) a okamžitě bez dalšího hledání či nutné analytické práce uvidí, o jakých produktech/službách daný klient nejčastěji komunikuje (napříč emaily, weby, sociálními sítěmi,..), jaký tón má tato komunikace (tedy jestli jde o klienta spíše nespokojeného, či naopak spokojeného) a v neposlední řadě také uvidí přehled obecných témat, které klienta zajímají a o kterých se rád baví. Obrázek 7.13 představuje tento pohled. Seznam témat lze nalézt v pravé horní části. Takový pohled může například odkrýt, 92

7.2. Analýza dat laikem na přepážce že často zmiňuje sport, či dovolenou, a byl by tak vhodným kandidátem pro nabídku pojištění.

Obrázek 7.13: Přehled aktivity klienta pro pracovnici přepážky v bance Pokud pracovnice chce, může si samozřejmě zobrazit detaily všech dokumentů, které jsou o daném klientovi dostupné, omezit si vyhledávání jednoduchými filtry podle zdrojů dat či časovým obdobím. Pokročilé rozhraní s všemi možnostmi nastavení je vidět na obrázku 7.14. Výsledky lze případně i exportovat - do PDF či do emailu. Tvorbou tohoto rozhraní jsem splnil všechny zbylé úkoly praktické části: Identifikovat sentiment napříč zdroji pro daného klienta, identifikovat seznam témat, o kterých hovoří a v neposlední řadě také zobrazit všechny příspěvky jednoho autora napříč všemi zdroji (podle ID autora).

93

7. Výsledky řešení

Obrázek 7.14: Podrobný detail aktivity klienta pro pracovnici přepážky v bance

94

Závěr Shrnutí Záplava dat, s níž se musíme dnes potýkat a jež bude i nadále růst, je faktem, se kterým se musíme naučit žít a vypořádat. Organizacím nabízejícím služby koncovým klientům data přinášejí jedinečnou možnost lépe poznat své zákazníky a nabídnout jim to, co opravdu chtějí, v čas i podobě, kterou vyžadují. Rozvoj moderních komunikačních prostředků, převážně tedy sociálních sítí, zapříčinil, že si klienti také začínají zvykat na možnost přímé komunikace s organizací, ať již jde o mladé start-upy, či tradiční banky. Všichni musí být na takovou eventualitu připraveni. Naprostá většina dat, o kterých mluvíme jako o Big Data, je přitom nestrukturovaná, často v podobě volně psaného textu, se kterým je potřeba umět pracovat zcela jinak, než tomu bylo doposud běžné. Cílem mé diplomové práce bylo, kromě jiného, ukázat, že jsou tyto technologie již plně připravené na takový úkol a že informace, které se v již dnes dostupných datech skrývají, opravdu mohou pomoci lépe poznat a pochopit zákazníka hlavně ve chvíli, kdy integrujeme dohromady všechny dostupné zdroje informací. Tento úkol se mi úspěšně podařilo splnit.

Diskuze výsledků Diskuzi jednotlivých výsledků bych rád navázal na konkrétní cíle své diplomové práce. 95

Závěr

Analytická část 1. Analyzovat možnosti využití Big Data v businessu včetně konkrétních příkladů. Tento cíl se mi podařilo úspěšně splnit pak v kapitolách 1 a 4. 2. Analyzovat rozsah a strukturu veřejně dostupných informací na vybraných sociálních sítích. Navrhnout způsob jejich získání a ten podrobněji rozebrat. Analyzoval jsem tři strukturu informací dostupných na třech největších sociálních sítích - Facebook, Google+ a Twitter 2, popsal jsem způsoby získání dat z těchto sítí a následně implementoval vlastní crawler, který tyto poznatky aplikoval do praxe. 3. Analyzovat rozsah a strukturu běžně dostupných interních zdrojů informací o klientech. Navrhnout způsob jejich získání a propojení s veřejnými daty. Analyzoval jsem strukturu i obsah běžně dostupných interních zdrojů a zároveň navrhl způsoby jejich využití v pokročilé analytice nestrukturovaných dat 2. 4. Analyzovat právní a morální aspekt spojený se zpracováním Big Data. Navrhnout režim fungování v mezích zákona. Úspěšně jsem nastudoval a rozebrat právní a morální aspekt analytiky veřejně i interně dostupných dat v rámci legislativy České republiky. Své názory jsem konzultoval s několika právníky zaměřenými převážně na IT právo 3. 5. Vybrat vhodný nástroj pro pokročilou analýzu nestrukturovaných dat a nastudovat jej. Prostudoval jsem možnosti dostupné na trhu a na základě parametrů zvolil analytický nástroj IBM Content Analytics 5.1.6, který jsem nastudoval, s jehož pomocí jsem navrhnul a následně implementoval řešení pokročilé analytiky nestrukturovaných dat. 96

Diskuze výsledků 6. Navrhnout koncept řešení problému analýzy získaných dat s využitím zvoleného nástroje. Viz výše.

Praktická část 1. Nastavit/připravit zvolený nástroj pro pokročilou analýzu nestrukturovaných dat. Podařilo se mi úspěšně nastavit všechny parametry zvoleného nástroje, nutné pro jeho správnou funkčnost. Vytvořil jsem slovníky pro demonstraci možností přizpůsobení analýz, vylepšil český sentiment a dovyvinul do nástroje pluginy, potřebné pro správný chod své demonstrace 6.2. 2. Získat data z vybraných sociálních sítí a vybraných mediálních webů. Úspěšně jsem navrhnul a implementoval nástroj pro získání dat ze zvolených externích zdrojů - sociálních sítí a mediálních webů - a takto získaná data jsem úspěšně importoval do zvoleného analytického nástroje 6.1.6. 3. Navrhnout a implementovat aplikaci pro práci s analytickým nástrojem pro koncového (nevyškoleného) uživatele. Úspěšně jsem navrhnul a implementoval aplikaci pro uživatele laika, pro práci s analyzovanými výstupy. Tohoto uživatele jsem pro potřeby své diplomové práce personifikoval do role pracovnice banky za přepážkou, která je v přímém kontaktu s klientem a která potřebuje jednoduše a rychle zjistit, jaký klient je a o co má zájem 6.2.5. 4. Demonstrovat možnosti Customer Intelligence v Big Data na získaných datech. V získaných datech jsem úspěšně nalezl následující informace: a) Nalézt zákazníka/y, který vyjadřuje přání odejít od organizace. Konkrétní příspěvek viz obrázek 7.12. b) Nalézt zákazníka/y se stížností. Konkrétní příspěvek viz obrázek 7.5. 97

Závěr c) Analyzovat náladu příspěvků na určité téma (název produktu, služby či konkurence) nebo celých zdrojů dat. Konkrétní příspěvek viz obrázek 7.6. d) Identifikovat nejčastěji diskutovaná témata. Konkrétní příspěvek viz obrázek 7.13. e) Identifikovat příspěvky od konkrétního autora napříč všemi daty. Konkrétní příspěvek viz obrázek 7.14. Vzhledem ke splnění všech cílů, které jsem si na počátku práce stanovil, považuji svou diplomovou práci za úspěšně zvládnutou a jsem přesvědčen, že jsem obecně prokázal business přínos konceptu pokročilé analytiky Big Data pro zvýšení Customer Intelligence.

Doporučení pro další práci V návaznosti na mou práci by bylo vhodné vyjádřit benefity analytiky Big Data i konkrétními čísly a pro vybranou organizaci celý business case spočítat. Do úvahy by se brala cena akvizice nového zákazníka, náklady na jeho retenci, potenciální benefity včasného odhalení jeho odchodu či pouhé nespokojenosti a tak dále. Dále považuji za vhodné více rozpracovat právní problematiku spojenou s Big Data, neboť v současné době toto téma není příliš pokryto, a poskytuje tak značný prostor pro zlepšení. Nástup Big Data právní otázky automaticky přinese a navazující práce by mohla teoreticky ještě s předstihem vyřešit problémy, které bude muset zanedlouho řešit celá řada organizací vytěžujících Big Data. Vhodným navázáním na mou práci by také mohl být vývoj crawlovací aplikace, která by mediálních serverech automaticky rozpoznávala text, a jednotlivá metadata (datum, autor a další) a usnadnila tak proces získávání informací.

98

Literatura [1] Michael Palmer. Data is the new oil. http://goo.gl/6Xqr4, 2006. [2] Radicati Team. Email statistics report, 2012-2016. Technical report, The Radicati Group, inc., 2012. [3] Youtube.com. Youtube press statistics. http://goo.gl/ABQX8. [4] Pete Pachal. Ibm’s big data challenge: A telescope that generates more data than the whole internet. http://goo.gl/2uyqk, April 2012. [5] IBM. What is data scientist. http://goo.gl/7xldO, 2013. [6] The Apache Software Foundation. What is apache hadoop? http: //goo.gl/T9m3q, 2013. [7] Donna Tam. Facebook by the numbers: 1.06 billion monthly active users. http://goo.gl/j8Vea, 2013. [8] SocialBakers.com. Czech republic facebook statistics. http://goo.gl/ qNC6A, 2013. [9] David Reinsel John Gantz. Extracting value from chaos. http://www.emc.com/collateral/analyst-reports/idcextracting-value-from-chaos-ar.pdf, June 2011. [10] Douglas Laney Mark A. Beyer. The importance of ’big data’: A definition. online, June 2012. [11] Danyel Fisher, Rob DeLine, Mary Czerwinski, and Steven Drucker. Interactions with big data analytics. interactions, 19(3):50–59, May 2012. 99

Literatura [12] Brad Brown Jacques Bughin Richard Dobbs Charles Roxburgh Angela Hung Byers James Manyika, Michael Chui. Big data: The next frontier for innovation, competition, and productivity. Technical report, McKinsey Global Institute, May 2012. [13] Kevin Slavin. How algorithms shape our world. http://goo.gl/ci5Lm, July 2011. [14] Kate Crawford. The hidden biases in big data. Harward Business Review, 2013. [15] Michael Minelli. Big data, big analytics : emerging business intelligence and analytic trends for today’s businesses. John Wiley and Sons, Hoboken, N.J, 2013. [16] Shun-Tak Leung Sanjay Ghemawat, Howard Gobioff. The google file system. Technical report, Google, 2003. [17] David Talbot. African bus routes redrawn using cell-phone data. MIT Technology Review, 2013. [18] IBM interní zdroje. nepublikováno veřejně. [19] Sasha Issenberg. Obama’s white whale. http://goo.gl/bX3EW, 2012. [20] Chao Deng, Ling Qian, Meng Xu, Yujian Du, Zhiguo Luo, and Shaoling Sun. Federated cloud-based big data platform in telecommunications. In Proceedings of the 2012 workshop on Cloud services, federation, and the 8th open cirrus summit, FederatedClouds ’12, pages 44–48, New York, NY, USA, 2012. ACM. [21] Richard A. Posner. Rational choice, behavioral economics, and the law. Stanford Law Review, 50(5):1551–1575, May 1998. Published by: Stanford Law Review. [22] Daniel Kahneman. Maps of bounded rationality: Psychology for behavioral economics. The American Economic Review, 93(5):1449–1475, December 2003. Published by: American Economic Association. [23] Zach Rait. Introducing the subscribe button. http://goo.gl/oEibb, 2011. [24] Twitter. Faqs about following. http://goo.gl/hMe8Y, 2013. [25] Facebook. Graph api. http://goo.gl/1bssB, Apil 2013. 100

Literatura [26] Google. Google+ page and profile names. http://goo.gl/eYG0n, 2013. [27] Quoc Hoang Sara Radicati, PhD. Email statistics report, 2011-2015. http://goo.gl/rW03g, May 2011. [28] Gartner. Definition - customer relationship management (crm). http: //goo.gl/3vrE5. [29] IBM. Ushering in a new era of computing. http://goo.gl/CAvhj. [30] Newton translation engine. http://goo.gl/m22u9. [31] mBank. Bankovní forum mbank. http://goo.gl/vQ4Nm. [32] Franklin D. Roosevelt. Speaks authorized edition of speeches. speech, August 1935. [33] CBS News ZACK WHITTAKER. U.k. man jailed over facebook status raises questions over free speech. http://goo.gl/rnEky, October 2012. [34] Paul Zikopoulos. Understanding big data : analytics for enterprise class Hadoop and streaming data. McGraw-Hill, New York, 2012. [35] iDNES.cz. idnes.cz. http://goo.gl/942LL. [36] Novinky.cz. Novinky.cz – nejčtenější zprávy na českém internetu. http://goo.gl/JvAAn. [37] IHNED.cz. Ihned.cz : Zpravodajský server hospodářských novin. http: //goo.gl/OJx7e. [38] Zákon 121/2000 sb. - o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). http://goo.gl/g24P0t, 2000. [39] Paul Ohm. Broken promises of privacy: Responding to the surprising failure of anonymization. UCLA Law Review, 57(9-12):1701, August 2009. [40] Michel Verleysen & Vincent D. Blondel Yves-Alexandre de Montjoye, César A. Hidalgo. Unique in the crowd: The privacy bounds of human mobility. Scientific Reports 3, (1376), March 2013. [41] TOM ZELLER Jr. MICHAEL BARBARO. A face is exposed for aol searcher no. 4417749. http://goo.gl/BsuG3, August 2006. 101

Literatura [42] Latanya Sweeney. Uniqueness of Simple Demographics in the U.S. Population, 2000. [43] Philippe Golle. Revisiting the uniqueness of simple demographics in the us population. In Proceedings of the 5th ACM workshop on Privacy in electronic society, WPES ’06, pages 77–80, 2006. [44] Arvind Narayanan and Vitaly Shmatikov. How to break anonymity of the netflix prize dataset. CoRR, abs/cs/0610105, 2006. [45] CHARLES DUHIGG. How companies learn your secrets. http:// goo.gl/q4jgD, February 2012. [46] George Orwell. 1984. Main Road Books, 2008. [47] Gartner. Definition - clickstream analysis. http://goo.gl/wCHyW. [48] Avivah Litan. Use big data analytics to solve fraud and security problems. Technical report, Gartner, March 2013. [49] W3C Working Group. Web services architecture. http://goo.gl/ JJc1z, February 2004. [50] Network Working Group Internet Engineering Task Force. The atom publishing protocol. http://goo.gl/SYtG7, October 2007. [51] Todd Leyba Josemina Magdalen Wei-Dong (Jackie) Zhu, Asako Iwai. IBM Content Analytics Version 2.2: Discovering Actionable Insight from Your Content. IBM Redbooks, May 2011. [52] Facebook. Zásady služby facebook pro jména a názvy. http://goo.gl/ LxdHd, 2013. [53] BBC News Alex Hudson. Why does google+ insist on having your real name? http://goo.gl/uknQ6, July 2011. [54] RSS Advisory Board. Rss 2.0 specification. http://goo.gl/4gijN, July 2003. [55] Twitter. The streaming apis. http://goo.gl/1kzPx, September 2013.

102

Příloha

Obsah CD

Obrázek A.1: Obsah přiloženého CD

103

A