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
Download

Customer intelligence v kontextu Big Data