Krize BI dashboardů

Lidi se v datech nevyznali - tak si našli nástroje, jak si pomoct. Od roku 1958, kdy Hans Peter Luhn poprvé použil termín “Business Intelligence”, do konce 80 let celé odvětví pomalu kráčelo směr termínům jako jsou datové sklady, OLAP kostky, apod. V roce 1989 Howard Dresner definoval BI jako “koncepty a metodiky ke zlepšení business rozhodování postaveného na systémech pracujících s fakty”.

Od té doby BI zrálo jako víno až do dnešních dnů, kdy narazilo na strop a zažívá podle mě drobnou krizi.

Dashboard Krize

Krize je v zahlcení daty. Už né daty v surové podobě, ale daty, které jsou kategorizované a nějak matematicky upravené (reprezentované v podobě, kterou nazýváme “reporty"). 

Představte si, že máte velké množství dat. Víte že je v datech schováno spousta zajímavých informací - často vědomě přehlížených “long tailů” (long-tail je v obchodních datech definovaný jako množina velmi malých prodejů, které mohou společně zabrat tržní segment přesahující relativně malé množství bestsellerů). Takže vezmete nástroje, které vám data postahují na jedno místo, vyčistí, učešou a odprezentují - a začnete se na ně dívat (Keboola + GoodData). 

Časem ale přijdou 2 negativní efekty:
  1. rezignace / syndrom toustovače - v datech vidíte stále stejné informace. První týdny se v nich vrtáte, ale v čase upadá vaše pozornost spolu s tím, jak vám z dat (při pasivním používání) vycházejí věci, které jste se naučili odhadovat (Avast bude mít i zítra >200M uživatelů => tohle není informace, kterou potřebují denně připomínat). Pokud si pořídíte nový toustovač, jíte první týden jen tousty a pak jej dáte do skříně a tam na něj padá prach - něco podobného se vám může stát i v BI
  2. utopení / syndrom zavalení daty - při vhodném nástroji, který vám umožní zanořovat se do vašich dat, generujete jeden report za druhým - všude je přece něco zajímavého - a tak generujete reporty, až se v nich ztratíte

V momentě, kdy máte stovky reportů, selhává jakékoliv třídění, tagování nebo správné metodické pojmenovávání. Nastane efekt, kdy se v tom nikdo z vašich kolegů nevyzná a místo hledání dříve vyrobených reportů začnou lidi generovat od znovu nové a nové. Obchodní ředitel sice ví, že někde existuje report, který ukazuje "odhad marže na další 4 týdny podle předpokladů od sales manažerů”, ale najít ho je těžší než si ho znovu vyrobit (což je v případě GoodData enormě kvalitní znamení!).

Kudy z toho trh zkouší ven?

  • Použití přirozeného jazyka - Microsoft se ve svém “Power BI” snaží porozumět dotazům, podobně jako se ptáme vyhledávače. V takovém případě musí být přirozený jazyk napojený na sémantický model vedoucí k datům. Hezky se to ukazuje (viz odkaz na Power BI), ale dobře to vystihl Odin, můj kolega, který po přečtení jednoho takového článku reagoval:

"Precet jsem to a imho je to trosku bullshit, protoze clanky tohoto typu vychazi pravidelne od 50 let - s tim, ze zpracovani prirozeneho jazyka je ‘nadosah' :) Neboli nejlepsim obecnym vysledkem interaktivni prace s pocitacem (dotazovani se pocitace na neco) je zatim jazyk SQL, ktery puvodne mel byt tak jednoduchy, ze ho kazdy zvladne napsat jako vetu, a pak se ukazalo, ze realita (a tedy i prirozeny jazyk) je tak dementne slozita, ze ten jazyk je bohuzel taky dementne slozity a musis ho studovat 5 let, aby ses ho naucil poradne (stejne jako prirozeny jazyk).”

  • Použití vizuálního rozhraní mezi počítačem a člověkem - vidět je na příkladu BIRSTu. Je to krásně udělané marketingové video, ale jakmile se model dat (tedy vztahy mezi informacema) stane dostatečně složitým, přestane vizuální rozhraní fungovat - nerozumí co po něm chceme nebo se jeho ovládání tak zkomplikuje, že zmizí všechny jeho výhody.

Jak tomu pomůžeme my?

Je důležité nakombinovat od každého něco. Dál zůstane nejpodstatnější, aby mohl mít každý přístup k libovolné informaci kterou cítí že potřebuje (real-time validace hypotéz). Vedle toho musí stroje trochu pomoct s přehrabováním se ve výsledcích dat - abysme nemuseli generovat stovky pohledů na data s cílem najít “to ONO”.

V Keboole od léte 2013 připravujeme systém, který se tohle snaží vyřešit. Dneska je to téměř hotový soubor funkcí, které dokáží poznat typ dat (čas, IDčko, číslo, attribut, aj. - nazýváme to "data profiller"), vztahy v datech (pozná to třeba jak spojit google analytics a salesforce data) a následně provést spoustu testů, díky kterým se identifikují zajímavé momenty. Například je možné najít v datech zákazníky u kterých je zřejmá sezónost - na kterou je možné v předstihu upozornit - aniž by někdo musel přijít s nápadem něco takového provést. Náš systém v datech odhadne, kde je pospaný konkrétní zákazník a pokud u něj něco zajímavého najde, upozorní na to. Ideálně tak, že v GoodData vygeneruje report, který je automaticky filtrovaný na danou situaci. 

Pro typ dat “online transakce” máme sadu testů, které se snaží zajímavé momenty nalézt. Například test s pracovním názvem “WrongOrderTest” udělá histogramy všech kombinací faktů (typicky peněz) a attributů (produkty / lokality / měsíce / kategorie uživatelů / aj.). V nich pak zkontroluje, zda počty IDček (například objednávek) klesají shodně spolu se svojí hodnotou. Je-li nějaký attribut v nějaké kombinaci anomální, považuje to test za důvod k alarmu.


Na obrázku je pro konkrétní období a konkrétní produkt (nebo třeba skupinu uživatelů) nalezený nečekaný pokles profitu při konkrétním typu platby - tedy zvláštní chování. V případě, že vás nenapadne přesně takováhle kombinace reportu, nemáte prakticky šanci na tuhle situaci přijít, protože bude nejspíš schovaná v “long-tailu” dat a sama o sobě na vás nevyčouhne. Navíc o týden dřív/později se stejná anomálie nemusí vůbec opakovat - potřebujete tedy kontinuální detekci.

Můj cíl je, aby data která v Keboole držíme, byly periodicky testovány a jejim majitelům podobné zajímavé momenty předkládány formou materializovaného dashboardu v jejich GoodData projektech. Poslední co nám schází je definovat jak jednotlivé testy budeme konfigurovat - jejich síla je ve vzájemném provázání testů. Všechno ostatní - data profiller, testy, podpůrné R-kové funkce, API, backend servery, apod. je hotové. 

Tak kdo nemá co na práci, můžete nám držet ve finiši palce :-)

RFM segmentace

Pomalu končí vánoční nakupovací horečka a sčítají se příjmy. V lednu začnou všichni nahánět lidi na slevách (takže si doma budeme zase říkat, proč ty vánoce neslavíme o 3 týdny později :)

Já se dneska trochu zanořím do nejlacinější metody používané v marketingu - RFM segmentace - která se používá pro cílení při oslovování zákazníků. Vnímám to jako vhodné téma na leden, kdy bude každá objednávka drahá. Pokud RFM segmentaci neznáte nebo neděláte, čtěte dál. 


RFM segmentace není nic jiného než rozčlenění zákazníků do tří kategorií, podle:

  • doby od posledního nákupu (Recency)
  • počtu nákupů (Frequency) 
  • celkového objemu utracených peněz (Monetary)

Představte si, že máte 3 prádelní šňůry, jednu pro každou kategorii. Na Monetary šňůru pověsíte jména zákazníků vzestupně, podle útraty, na Frequency šňůru vzestupně podle počtu objednávek a na Recency šňůru dáte na jednu stranu ty zákazníky, co už dlouho nenakoupili a na druhou stranu naopaky ty, co nakoupili před chvilkou.

Pak si každou šňůru rozdělíte na dílky (segmenty), které očíslujete od jedničky směrem nahoru. Jednička znamená nejméně význaný segment (nízký obrat, málo nákupů nebo dlouhá doba od poslední objednávky - mrtvý zákazník). Jakmile to máte, začnete se na svoje zákazníky dívat optikou segmentů a jejich významů. Odteď zahodíme šňůry a všechno si vyneseme na kostku, která má na každé hraně vždy jednu kategorii:

Když se pak podíváte na jednu stěnu kostky, budete mít skupiny zákazníků, kteří vyhovují dvěma segmentům. Například zákazníky, co nakupují hodně často (Frequency), ale realizují nevýznamné objemy peněz (Monetary). Nebo zákazníky, kteří se významnou měrou podílejí na vašem obratu (Monetary), ale je to docela dlouho, kdy naposledy nakoupili (Recency).

Pohled na Recency/Frequency kategorii pak dělá takovou “heatmapu”:

Frequency 5 znamená “nakupuje hodně často” a Recency 5 znamená “nakoupil nedávno”. Cílem je mít k dispozici konkrétní seznam zákazníků, kteří jsou uvnitř každého čtverečku heatmapy + samozřejmě dobře rozumět specifiku daného segmentu. Existuje spousta pouček, jak se na jednotlivé segmenty koukat. Podobně jako u bostonské matice existují označení jako “Dojná kráva”, “Bídný pes”, apod. má RFM segmentace svoje klasifikační pojmy (loajální zákazníci, velký spendři, nový dojný krávy, …). Pro každý z těchto pojmů pak existuje přehršel rad, jak se chovat (těmhle popřej k narozeninám, na tyhle prď úplně, tyhle pozvem na golf, aj.). 

V RFM segmentaci je ohromné kouzlo - hlavně proto, jak je to celé (v dobrém slova smyslu) primitivní věc. Seřadit zákazníky na “šňůru” dovede každý, jedinou otázkou zůstane, jak se definují jednotlivé hranice mezi segmenty. 

Můžete na to použít věci jako je IBM® SPSS® Modeler, který vám vysype "machrovací" grafy, podobné tomuhle:

a nebo si to uděláte na koleně doma. Je pár věcí, které je dobré vzít v potaz, jinak budou výsledky RFM segmentace tristní, resp. nebude snadné vydělat jejím použitím peníze.

Významy R/F/M kategorií

Největší význam přikládejte zákazníkům podle doby od posledního nákupu (Recency), pak četnosti nákupů (Frequency) a teprve nakonec podle celkového obratu (Monetary). Je dobré přiřadit každému zákazníkovi zároveň nějaké jednoduché skóre, díky kterému budeme schopni plošně určit, který zákazník je nejhodnotnější, aniž se díváme na dimenze RFM. Jestliže máme v každé kategorii například 5 skupin, pak každému zákazníkovi můžeme přiřadit skóre od 1,1,1 do 5,5,5. Zákazník, který bude v kategorii Recency v segmentu 4, u Frequency v segmentu 2 a v Monetary 3, dostane skóre 4+2+3 = 9. Abysme neměli tisíce zákazníků oskórovaných pouze 125 hodnotama (počty kombinací při 5ti segmentech na každou kategorii), použijeme pro skórování ještě “váhy”. Váha bude jiná podle toho, zda je zákazník na spodní nebo horní hranici segmentu. Pokud bych měl Frequency segment pro zákazníky co nakoupili 5x až 8x, bude váha zvýhodňovat ty co nakoupili víckrát a diskriminovat ty co nakoupili méněkrát. Je vhodné, aby váha byla u Recency obecně větší než u Frequency a u Frequecy větší než u Monetary - tím se zároveň zvýhodňuje důležitější kategorie.  Vzoreček by mohl být takovýhle:

RFM Skóre Klienta = (Recency segment x Recency váha) + (Frequency segment x Frequency váha) + (Monetary segment x Monetary váha)

Seřazení všech klientů podle RFM Skóre nám pak umožní (obecně) ukázat na 20% nejhodnotnějších zákazníků.


Hranice segmentů 

Velkou otázkou tvorby RFM segmentace je jak definovat hranice jednotlivých segmentů (kdy je Recency 2 a kdy už 3). Konstatovat, že ten kdo nakoupil 6x je v jiném (méně hodnotném) segmentu než ten, kdo nakoupil 7x, není vždy úplně snadné. Můžete za sebe nechat rozhodnout robota, ale mozkové cvičení na tohle téma vám jedině prospěje a s RFM segmentací pak budete lépe pracovat. Navíc platí, že na to neexistuje správná odpověď (=automat to neudělá lépe než vy) a tak jediné co vám zbyde, je si to nakonec stejně otestovat. Nuže, více variant pro různé situace a následně praktické použití (direct mail, etc.) je jediná - i když trochu trnitá - cesta.

Správné segmenty by měly mít jisté charakteristiky:

  1. podobnost v rámci segmentu - neměli byste si později klást otázky, jestli daný typ mailu pošlete všem v rámci jednoho segmentu nebo jen části zákazníků.
  2. rozdílnost mezi segmenty - pokud se zákazníci v jednom segmentu podobají zákazníkům v jiném segmentu, je jeden ze segmentů zbytečný. Může se nám stát, že časem někde vypozorujeme velkou podobnost a segmenty se rozhodneme sloučit, nicméně by mezi nimi měl být od začátku jasný rozdíl.
  3. ověřitelnost v čase - segmenty budeme používat pro plánování kampaní a srovnávání výsledků v čase. Chceme být schopni srovnat výsledky jednoho segmentu mezi dvěma kampaněmi a/nebo v časovém odstupu. K tomu potřebujeme stabilní RFM strukturu - časté měnění hranic mezi segmentama je problém.
  4. dostatečná velikost - segment, ve kterém máme jednoho zákazníka je k ničemu. V každém segmentu by měl být vyvážený počet zákazníků, přičemž problém “3 extrémě silných (monetary) klientů” vyřešíme tím, že je prohlásíme za “příliš odlehlé” a vřadíme je do největšího segmentu (M5), ale hranice toho segmentu podle nich nekalibrujeme. Přesto se snažíme mít segmenty vzájemně co nejvíc shodné - toho docílíme laděním hranic.


Princip definice segmentů

  • Recency - vezmeme jednoduše datum poslední objednávky. Říká se, že “Recency” je nejsilnější určení toho, kdo nejspíše nakoupí. U toho kdo nakoupil tento týden, máme větší šanci na prodej, než u toho, kdo nakoupil před 1/2 rokem. Tenhle fakt je základním dogmatem direct marketingu a tady ho budu považovat za axiom a nebudu to obhajovat.
  • Frequency - stejně jako u doby od posledního nákupu, máme s frekvencí jistotu, že toho kdo nakoupil 3x zlomíme ke čtvrtému nákupu spíš, než prvokupce ke druhé objednávce. Pokud máte dost dat, nedává asi smysl použít celoživotní historii objednávek, protože to dává zbytečně velkou váhu aktivitě v dávné minulosti. Velmi staré objednávky nejsou dobrý indikátor budoucí aktivity. Doporučuju použít fixní okno směrem dozadu od poslední objednávky - třeba 3 roky transakcí. Pokud někdo naposledy objednal před rokem, podíváme se na jeho objednávky od teď 4 roky dozadu. Objednal-li někdo naposledy před 5 lety, podíváme se na 8 let dozadu.
  • Monetary - objem peněz je nejslabší ukazatel budoucí ochoty znovu objednat. Nepoužíváme celkovou hodnotu objednávek (CLV) - to příliš koreluje s jejich počtem. Lepší je použít průměrnou velikost objednávky ze všech objednávek, použitých ke spočítání Fequency kategorie. To nám z peněz udělá víc nezávislou proměnnou. Monetary ve svém malém dopadu na uskutečnění další objednávky mohou skvěle sloužit ke dvoum věcem:
    • zákazníky, kteří mají shodné Recency nebo Frequency rozdělíme tak, že ti s větším Monetary budou mít větší hodnotu
    • izolujeme zákazníky s příliš malou hodnotou - pokud by měl někdo “Monetary” ve výši ceny direct mailu, nebudeme ho asi chtít kontaktovat


Praktické nastavení

Není nezbytné mít ve všech dimenzích stejný počet segmentů. Naše segmentační “kostka” může být klidně kvádr o hranách Recency 5x, Frequency 5x a Monetary 3x. Pokud vám to nedává smysl, netlačte se do symetrických kategorií!

Pro Recency kategorii je dobré mít jemnější dělení pro čerstvé nákupy, zatímco zákazníci aktivní naposledy před 2 až 2.5 lety mohou být klidně v jednom společném segmentu. Sami si na začátku vymyslete hranice, přičemž zkuste vnímat, že Recency 1 a Frequency 1 je nový zákazník (koupil “nedávno” a celoživotně jen jednou). Kolik chcete, aby uběhlo času od prvonákupu, když takový segmentu budete oslovovat? 2 dny? Týden? Měsíc?

U Frequence je to podobné jako u Recency - nejnovější zákazníci vyžadují speciální zacházení, aby znovu nakoupili. Pokud přesvědčíte zákazníka s frekvencí 2, aby nakoupil znovu, máte ho nejspíš na doživotí. Zákazníci s frekvencí 3+ jsou vaše tvrdé jádro. Frekvence by tohle měla precizně rozlišovat.

Přesné nastavení Monetary je u každého úplně jiné - je třeba správné hranice hodně hledat. Pokud nemáte žádné lepší podněty, začněte s průměrnou objednávkou (Average Order Size  - AOS) a udělejte si 3 monetary segmenty: méně než polovina AOS, více než polovina a méně než 1.5 AOS a více než 1.5 AOS. Pokud je průměrná objednávka 450,- Kč, budete mít hranice (M1) 0,- Kč až 225,- Kč, (M2) 225,- Kč až 675,- Kč a (M3) 675,- Kč a více. Můžete si udělat ještě skupinu “pod 50,- Kč”, kam dáte extrémně nízké nákupy.


Vylepšování

  • “Co prodávám” - zákazníci kupující rozdílné druhy produktů (produktových linií) se chovají rozdílně. Je dobré udělat RFM segmentaci zvlášť pro každou produktovou linií vašeho katalogu a odděleně ji vyhodnocovat.
  • Druh zákazníka - zákazníci jsou z různých prostředí, firmy mají v ČR NACE kódy, v americe jsou na to SIC kódy
  • Velikost zákazníka - zákazníci různých velikostí se budou malinko jinak chovat - firma s 10 lidma nejspíš nemá oddělení procurmentu, takže se jí prodává snáze než firmě o 500+ zaměstnancích. Je dobré si s tím hrát. Můžete si na začátku rozdělit zákazníky do 2 skupin. Třeba 0 až 4 zaměstnanci a 5+ zaměstnanců - a sledovat pro tyhle dvě kategorie RFM segmentaci zvlášť. 

Pro zanořování se do dat je vhodné mít flexibilní systém, který umí data míchat a transformovat (Keboola Connection) a BI nástroj, díky kterému budete schopni segmenty kroutit, prohlížet, filtrovat a těžit - pro zjištění, zda se reakviziční kampaň na "chovatele zvířat za účelem výroby kožešin” (NACE kód 014920, 479 ekonomických subjektů v ČR) v segmentu (R2, F5, M3) vyplatila, už Excel nestačí a přichází GoodData. Doplňkový pohled přes vaší penetraci trhu a sledování toho, jak se chová saturovaný tržní segment, je už třešnička na dortu :)


Závěr

Statická RFM segmentace vám bude (skoro) k ničemu, desktopové programy typu SPSS vám sice udělají "kvalitní" segmentaci, na kterou ale nenapojíte dodatečné informace. Pokud navíc nerozumíte pravidlům, podle jakých byly jednotlivé segmenty definovány, nebudete nejspíš schopni výstupy správně zapojit do vaší marketingové strategie. Navíc věřím, že je třeba s nastavením experimentovat a nenechat si “to nastřelit automaticky” = pusťte se do toho s vervou a na vlastní triko, mozkové cvičení kolem definice segmentace byste neměli outsourcovat na dodavatele.

Pokud uděláte úkrok stranou a podíváte se na RFM segmentaci trochu z nadhledu, dá se to celé obalit spoustou buzzwordů typu "Predictive customer scoring", "Anti-churn detection", "Advanced segmentation", atd… 

Jednorázovou RFM segmentaci si snadno uděláte "doma na koleně", pokud ji ale chcete zapojit do všedního rozhodování, potřebujete ji mít součástí vašeho BI řešení. Kvalitní ukázka toho, jak jde obyčejné RFM nafouknout na "maximum", je Futurelytics.com - startup, který z mého pohledu utáhl pár lidí na vařenou nudli, nicméně jejich marketingová exekuce RFM segmentace je brilantní a za to jim určitě patří poklona. Jsem zvědavý, kolik startupů v “datovém” kole StartupYardu přijde s něčím podobným - je to za málo peněz hodně muziky :-)


Hezký povánoční segmentování!

BI kuchyně: Seznam.cz a jejich "data-archeologický" tým - část 2

A máme tu pokračování rozhovoru s Michalem Buzkem o tom, jak pomocí Keboola.com a GoodData.com zpracovávají v Seznamu data o svých obchodech. První část rozhovoru najdete zde.


Kvůli datům jsme ještě nikoho nevyhodili, odhaluje Michal Buzek zákulisí Business Intelligence v Seznamu

Minule jsme se v rozhovoru s hlavním analytikem Seznamu Michalem Buzkem dozvěděli, že se investice do datové analytiky mnohonásobně vrátila za pouhé tři měsíce.

Tentokrát se podíváme na to, jak GoodData mění fungování obchodních týmů, jak ovlivňuje chod firmy, a jak se bude rozvíjet práce s daty v Seznamu v nejbližší budoucnosti.


Dostáváte z GoodData odpovědi i nad rámec běžných reportů?

Co je běžné? To, že mají obchodníci mnohem lépe přečtené své klienty, je podle mě k nezaplacení. Dnes víme, že klient u nás sice investuje desetitisíce, ale za billboardy v tom samém období utrácí miliony. Kromě toho pracujeme se sezónností i s oslovováním podle oborů činnosti. Umíme také rozebrat portfolia obchodníků i obchodních týmů, a nacházet v nich klienty, kteří si zaslouží větší péči. To jsme mohli dělat (a občas dělali) i dříve, ale dnes je to nepoměrně rychlejší a snazší.

Myslím si, že klíčem není jeden všespasitelný report, který nám otevře oči, ale sada praktických reportů, které jsou vždy při ruce, a které pomáhají v každodenní práci.  

Jak se s tím obchodníci sžívají?

Párkrát jsem v Seznamu slyšel, že obchodník má obchodovat, ne se hrabat v tabulkách. Proto jsme reporty a grafy vyladili tak, aby byly pro obchodníky jasné a čitelné na první pohled. GoodData se díky tomu stala téměř každodenním nástrojem obchodníka před schůzkou s klientem. Zjistí v něm jeho mediální strategii, inzertní vývoj, zvyklosti a spoustu dalších dat.

Pomohla analytika i těm, u kterých bys to nečekal?

Někdo se v datech našel, jiný si k nim zatím hledá cestu. Ale letos jsem mezi obchodníky zaznamenal velký hlad po informacích. U některých jsem to opravdu nečekal. Těší mě, že GoodData není nástrojem jen pro vedení a vyšší management, ale že z něj dokáže čerpat užitečné informace i řadový zaměstnanec.  

Propustili jste už někoho na základě zjištěných dat?

Zatím ne, nebo o tom nevím :-) Musím ale říct, že obchodní projekt v GoodData umožňuje manažerům mnohem lépe kontrolovat své lidi.

Jak konkrétně?

Manažer například u každého klienta vidí objem nasmlouvané inzerce a počet návštěv obchodníka. Pokud klient uzavřel za poslední rok objednávky za 50 tisíc a obchodník u něj byl 15x, tak je asi něco špatně. Naopak je chyba, když u klienta s inzercí nad dva miliony vidíme v historii komunikace pouze jeden záznam. Buď je obchodník megaborec, nebo kašle na doplňování záznamů ze schůzky.

A využívají to manažeři, nebo o té možnosti jen ví?

Využívají. Pomocí podobných přehledů mohou se svými lidmi mluvit mnohem konkrétněji. Hned je vidět, kam chodí obchodník zbytečně a na co by se měl naopak soustředit. Nesmí se to samozřejmě přehánět, ale od manažerů na to slyším docela chválu.

Změnila datová analytika chod Seznamu?

Většina lidí z firmy dnes ví, že jediná správná a důležitá čísla jsou v GoodData. Top management tam má potřebné informace k řízení firmy, produktoví manažeři zde sledují KPI a plnění svých služeb, controlling zase náklady a výnosy, obchodní manažeři výkon svých týmů a klientů, PR oddělení statistiky ze sociálních sítí…

Obrací se na vás s požadavky na reporty i lidé z dalších oddělení?

Ano. Je skvělé, že v Seznamu funguje šeptanda – v posledním měsíci za mnou přišli třeba kluci z Skliku, manažer mobilní reklamy nebo plánovačka mediálního prostoru, kteří viděli u někoho jiného užitečné reporty v GoodData, a chtějí teď připravit své vlastní. Vidí, že jim to může v práci skutečně pomoci.

Kolik lidí u vás dnes používá GoodData?

Okolo 75, z toho něco málo přes 50 dělá obchod. Někteří manažeři ale připravují z GoodData podklady pro své lidi v XLS nebo PDF, takže s reporty ve finále pracuje ještě mnohem vice lidí.

Našly si výstupy z GoodData cestu i na porady?

Na poradách nejvyššího managementu jsou reporty z GoodData standardem už několik let. Sledují zde vývoj tržeb, nákladů, zisku, plnění ukazatelů vůči plánu a podobně. Na poradách obchodních týmů se zase řeší hlavně reporty s monitoringem inzerce, historií komunikace nebo inzertní výkony na konkrétních reklamních produktech. Pak se v Seznamu pravidelně setkávají i zástupci služeb, obchodu a marketingu, a sledují vlastní KPI.

Co pokládáš za největší přínos řešení GoodData/Keboola?

Přínosů jsem už zmínil spoustu, radši řeknu, co těší mě osobně. Největší radost mám, když vidím, že to lidé ve firmě skutečně používají, a že jsou doslova hotoví z dashboardů, které jsme jim připravili. Přitom jsou to často data, která v Seznamu byla i dříve, jen ne jednoduše zobrazená na jednom místě a s možností detailního zkoumání.

Máš nějaký oblíbený report?

V jednoduchosti je síla. U obchodníků nejvíc boduje tabulka nabitá užitečnými informacemi – v řádcích jsou klienti, ve sloupcích jejich ceníkové útraty na Seznamu a mimo Seznam. Jsou nadšení, když si jednoduchým klikem na částku ve sloupci zobrazí, kde přesně klient inzeroval, a co propagoval.

Já osobně mám rád záložku se dvěma vývojovými grafy. Levý ukazuje objem klientových investic do reklamy v ceníkových cenách z databáze monitoringu inzerce, pravý objem ve skutečných cenách z obchodního systému Seznamu.

V ukázce vidíte, že klient v roce 2013 čile inzeroval – ale ne na Seznamu. Díky datům jsme to odhalili a obchodníkovi se v říjnu podařilo vrátit Seznam do hry.  

A co dál? Máš nápady, kam to celé posouvat?

Mým cílem je pomoct vybudovat v Seznamu supervýkonné obchodní oddělení. Jak řekl kdysi náš obchodní ředitel – měli bychom posílat obchodníky za správnými klienty ve správný čas a se správnou nabídkou.

Jak tomu podle tebe pomohou data?

Chci, aby obchodník v GoodData viděl sám sebe, a bez dalšího filtrování i klienty, které má přednostně oslovit, protože u nich má větší šanci na obchod. Pomohlo by taky rozšíření o další datové zdroje a ještě podrobnější segmentace klientů. A důležité je i vzdělávání – teď připravujeme workshop pro obchodní manažery, aby dokázali pro řízení z GoodData vyždímat maximum informací.

Dokázal bys ještě fungovat bez GoodData a Keboola Connection?

Pokud bys mi nabídnul minimálně stejně vybavený nástroj za poloviční cenu, tak jo :-) Ale jsem realista. Kdyby bylo na trhu něco lepšího, už bych to věděl. Do dob Excelu, Accesu a sosání dat z databází bych se už ale vracet nechtěl.

Cítíš se díky datové analytice pro firmu přínosnějším?

To je strašně těžká otázka. Snažím se, aby to tak bylo. Přínos ale nezávisí jen na mně nebo na klucích, kteří na GoodData dělají se mnou. Důležitá je i podpora práce s daty u vedení obchodního oddělení i u celé firmy - jak se získané informace využijí v praxi. Myslím, že se nám daří stále vice lidí v Seznamu přesvědčovat o hodnotě dat. A tím snad roste i význam analytického oddělení.

Počkej, tak snadno mě neodbudeš - zvedla se i tvá hodnota na trhu práce?

Do CV si to určitě přidám, až bude potřeba :-) Byl jsem u úplného začátku implementace GoodData v Seznamu, jsem schopen v Keboola Connection připravovat datasety a stavět datový model. Nejsem žádná hvězda, ale nějaké zkušenosti jsem posbíral. I kdybych to už nepotřeboval, tak mě poslední roky s GoodData a Keboolou fakt bavily.

Šel bys do toho znovu?

Každopádně. Pokud někdy skončím v Seznamu a nějaká jiná firma bude chtít, abych se jim pohrabal v datech, tak to v Praze určitě vezmu přes Karlín.



Kohort Analýza

Empiricky jsem v minulém týdnu ověřil, že náhodný vzorek studentů na VŠ nezná tak super věc, jako jsou reporty s "Cohortama". Takže děcka:

Kohort Analýza není typ reportu ale spíš reportovací technika. Kohorta je skupina objektů, které sdílejí jednu společnou vlastnost. Je to velmi jednoduchá věc s velkým potenciálem, která jde dělat nad jednoduchou tabulkou. Cílem téhle analýzy je rozkrýt trendy právě přes dimenzi těch společných vlastností.

Mějme tabulku předplatného, kde je ID transakce (platba každý měsíc), ID předplatitele, Datum ve kterém předplatné vzniklo, Datum kdy jsme se se zákazníkem prvně potkali a cena kterou předplatné v daný měsíc stálo:

Je-li kohortou moment vzniku předplatného, můžeme si pak veškerý náš měsíční příjem "obarvit" měsícem vzniku předplatného. Tady je to vyjádřené v % - tedy kolik procent našeho obratu tvoří předplatitelé, které jsem získali v daném měsíci:

Vypadá to trochu jako hezká tapeta, ale když se podíváte na červen 2012, můžete vidět, kolik obratu nám dělají lidi, které jsme sehnali (zobchodovali) v březnu 2011.  

Tady je vidět jak to vypadá u služby SEOmoz (dnešní moz.com). Moz.com je služba placená měsíčně. Někdy kolem března 2009 se rozhodli dát novým lidem službu na 3 měsíce zadarmo. Reakcí na to byl ohromný zájem - a služba okamžitě zdvojnásobila svojí uživatelskou základnu. Jakmile akce skončila, polovina uživatelů zase odešla. Vypadalo to takhle:

Kohortou je tady, stejně jako v horním příkladu, měsíc registrace. Y-osa (vlevo) pak ukazuje počet uživatelů. 

Pokud se na to celé podíváme optikou peněz, dostaneme trochu jiný pohled:

Je krásně vidět, že nárůst uživatelů po dobu "akce" nevedl k žádnému zásadnímu zisku. Jakmile ale akce skončila, masivně se zvedl příjem služby - asi o $100k/měsíc. 

Rada na závěr: společný atribut může být téměř cokoliv, datum registrace, "tag" marketingové akce nebo nějaká jasně definovaná incentiva, kterou pro lidi děláme. Díky zobrazeným kohortám pak můžeme poměrně snadno získat povědomí, "co se nám vyplatí pro uživatele dělat". Pokud plocha toho modrého pruhu z posledního obrázku bude v čase větší než náklady na akviziční akci, vyhráli jsme. Známe-li navíc metriku CLV (client lifetime value), můžeme to celé zohlednit v souvislostech. Pak získáme odvahu k (drahým) akcím typu: "hej, pozveme kravaťáky na golf, oni si pak něco koupí".

Howg!


UPDATE 2013-12-10: Pavel Jašek v komentáři na facebooku doplňuje další info k CLV metrikám na své prezentaci na SlideShare

BI kuchyně: Seznam.cz a jejich "data-archeologický" tým - část 1.

Z kraje léta jsem s Michalem Buzkem dělal z Kanady po emailu rozhovor o tom, jaký je jeho pracovní svět. Než jsem to stihl punkově publikovat, vymklo se mi to z rukou. A tak teď představuju českou verzi rozhovoru po úpravě od Martina Brabce, jehož Obsahovou Agenturu jsme najali, aby nám pomohl s naším firemním blogem, kterým brzo začneme otravovat vaše životy :-) 


Investice do Business Intelligence se nám za tři měsíce vrátila desetinásobně, říká Michal Buzek, hlavní analytik Seznamu

Největší český internetový portál Seznam.cz vybudoval kromě vyhledávače konkurujícího Googlu také impérium prosperujících služeb – od vlastního e-mailu po inzertní weby a síť kontextové reklamy Sklik.

Jak využívá kolos o tisícovce zaměstnanců služby GoodData? A jak pomáhá zlepšovat výsledky obchodního týmu? To vše a mnoho dalšího najdete v dvoudílném rozhovoru s vedoucím analytiků Michalem Buzkem.


Jak to celé začalo?

Někdy kolem roku 2009 probíhalo v Seznamu výběrové řízení na Business Intelligence nástroj. Pavel Zima (tehdejší CEO Seznamu, dnes generální ředitel a místopředseda představenstva) tehdy přizval i GoodData. Já jsem byl v týmu, porovnával nabídky a dával doporučení vedení. Několikrát jsme se sešli se Zdeňkem Svobodou (spoluzakladatel GoodData), který nám předvedl, co to umí. Dostal od nás vzorek obchodních dat z Sauto.cz (inzertní web Seznamu zaměřený na prodej aut a motorek) a za pár dní už nám přinesl základní reporty včetně vizualizace.

Oproti licencovaným BI nástrojům to bylo strašně jednoduché a rychlé, pan Svoboda to navíc uměl i velmi přirozeně a nenásilně prodat.

Proč jste vlastně hledali Business Intelligence nástroj?

Potřebovali jsme se dostat z doby excelové, kdy si každý nosil na poradu vlastní report, pochopitelně s nestálou kvalitou dat. Také jsme tehdy měli asi čtyři obchodní systémy, účetní systém a elektronickou peněženku. Zkrátka, hledali jsme jednotný reportingový nástroj, ve kterém budeme mít všechna data s jednotnými metrikami.

A jak jste při tom narazili na Keboolu?

GoodData jsme používali už asi dva roky. Občas jsme požádali o úpravu datového modelu, ale do žádných větších věcí jsme se nepouštěli. Pak ale PR oddělení přišlo s tím, že GoodData umožňuje sledovat statistiky z firemních účtů na sociálních sítích. A protože nejlepší konektory na data z Facebooku a Twitteru dělala pro GoodData právě Keboola, objevili jste se na schůzce vy.

Jaký byl tvůj první dojem?

Konečně přišel někdo oblečený stejně jako lidi, které jsem potkával v Seznamu na chodbě. Žádní kravaťáci.

Začalo to tedy projektem pro vytěžení dat ze sociálních sítí?

Ano. Už předtím jsem chtěl v GoodData zkusit pár nových věcí. Rozšířit datové modely, více si hrát nad pohledy, o kterých jsem nevěděl, jestli pro ně nadchnu ještě někoho dalšího. Chtěl jsem taky zrychlit přidávání nových věcí, aniž bych musel oslovovat konzultanty z GoodData.

A do toho jste přišli vy, ukázali mi pár vychytávek jak vylepšit Dashboard v GoodData a pak i váš vlastní nástroj Keboola Connection. Nebudu kecat, taky se ke mně dostal post Tomáše Čupra (známý český podnikatel, zakladatel nejúspěšnější české variace na Groupon, Slevomat.cz, dnes CEO DámeJídlo.cz) o tom, jak jste mu změnili život :-)

Jak to pokračovalo?

V březnu 2013 jsme začali stavět nový projekt pro obchodní oddělení, kterým jsem chtěl dát obchodníkům zásadní důvod, proč používat GoodData. Už pár let jsme nakupovali data z monitoringu inzerce s útratami firem za velkoformátovou reklamu. Nijak zvlášť jsme ale jejich potenciál nevyužívali.

Nově jsme data z monitoringu v GoodData napojili na náš obchodní systém. Obchodníkům jsme tak dali do rukou jednoduchý nástroj, ve kterém si mohou o svém klientovi zjistit, kde a za co utrácí, v jakém období inzeruje nejvíce, a zda nezapomíná inzerovat i na Seznamu. Tím se posunul pohled na stávající nebo potenciální klienty ne o jeden, ale tak o pět levelů výš.

Bylo pro vás složité naučit se pracovat s Keboola Connection?

Ne, nemuseli jsme se nic extra učit. Datové transformace se  v Keboola Connection píšou v SQL, který náš tým ovládá. Já osobně jsem se do toho po pár týdnech docela dostal. Mojí oblíbenou hračkou je Sandbox, tréninkové prostředí, do kterého si posílám vstupní tabulky, a kde si ladím dotazy tak dlouho, dokud nevypadne odpovídající výsledek.

Co jste už zvládli vytvořit?

Náš obchod je docela velký a členitý, požadavky na přehledy v GoodData se tým od týmu liší. Jiné reporty chtějí lidé z Skliku, jiné tým specializovaný na velké klienty. Proto projekt pořád rozvíjíme, není to tak, že bychom jednou něco nastavili a měli pokoj. Ještě jsem ale nesetkal s požadavkem, který bychom pomocí Keboola Connection s GoodData nevyřešili. A to sbíráme podněty od kohokoliv.


A konkrétně?

V GoodData dnes máme několik projektů od sociálních sítí po sledování nákupního chování klientů. Ty například dělíme podle oborů, sledujeme jejich sezónnost z pohledu návštěvnosti kategorií na Firmy.cz (největší český katalog firem, patří pod Seznam.cz) a snažíme se je podle toho aktivně oslovovat. Obchodník si na svém dashboardu vybere kategorii, dostane se na report klientů, vidí jejich bonitu i útraty mimo Seznam. A přesně ví, koho a kdy oslovit. 

Jaká je na Keboola Connection a GoodData odezva v obchodním týmu?

Od obchodních manažerů, kteří díky tomu mají své lidi pod téměř 100% kontrolou, je zpětná vazba samozřejmě velmi pozitivní. Když od obchodního manažera s osmiletou praxí v Seznamu slyšíte, že si už svou práci neumí bez přehledů a informací z GoodData představit, tak se to poslouchá hezky.

Vyplácí se vám to finančně?

Po třech měsících běhu projektu jsem si prošel evidenci obchodních manažerů a očistil ji jen na peníze, o kterých 100% víme, že jsme je vydělali díky informacím z GoodData. Nemůžu říct přesná čísla, ale náklady na databázi a konzultace v řádu statisíců vyvážil více než pětimilionový výnos.

Takže vyplácí.

Jasně. GoodData navíc pomáhá peníze nejen vydělávat, ale i šetřit. Obchodník dnes může využívat svůj čas i energii jen tam, kde to má smysl. Neřídíme se už jen pocity, ale stále více daty. Vidíme přehledy nákladů do nejmenších detailů. Umíme najít příčiny nárůstů a přesně si zjistíme, co a jak nejvíc ovlivňuje výši zisku.

==========

Jak vypadají konkrétní reporty?  Kolik lidí v Seznamu dnes s daty vlastně pracuje? A už někoho z obchodníků kvůli podrobné analytice propustili? Pokračování rozhovoru s Michalem Buzkem najdete zde.
 

12.480 hodin práce

Zítra mám v GoodData ekosystému 4. narozeniny. 

Za tu dobu jsem stihl odpracovat přes 12.000 hodin práce, naučil se jinak o věcech přemýšlet, probděl nespočet nocí, trpěl komunikací přes mnoho časových pásem, poslal stovky supportních ticketů do GoodData a zpracoval desítky zákaznických projektů. Ale hlavně jsem poznal spoustu skvělých lidí a naučil se obrovské množství zajímavých věcí, který mě posunuly o notný kus dopředu. 

Přeju si, aby se mi dařilo Keboolu udržet stejně svěží, svobodnou a nadšenou. Aby se dál neevidovala docházka, přestala počítat dovolená, vývojáři se nehádali s analytikama, z poza oceánu lítalo míň Zendesk ticketů a klienti stále psali jen spokojené dopisy.


Nic z toho by ale nikdy nevzniklo, nemít doma trpělivou Alenu, nebýt lidí v GoodData, kteří nám nesmírně pomáhají, nebýt našich klientů, kteří nám důvěřují a hlavně nebýt skvělých lidí v Keboole, který mi pomáhají táhnout tuhle káru dál.  

Jsem vám všem za to moc vděčnej,

Díky!

Amazon Kinesis - jak nám cloud opět rozšířil možnosti

Amazon Kinesis je služba v rámci Amazon Web Services (AWS), která umožňuje zpracování jakýchkoliv dat v reálném čase. Aktuálně běží v neveřejném režimu a přístup k ní se schvaluje žádost po žádosti (moje žádost trvala asi 2 dny).


K čemu to je?

Zatím to zkoumám, ale nevypadá to jako něco moc revolučního. V podstatě jde o to, že Kinesis pro nás provozuje frontu na data, do které může padat cokoliv odkudkoliv a jakoukoliv rychlostí. My si musíme napsat aplikaci, která si z fronty data bere, něco s nima dělá a vrací je na výstupu (třeba zase do jiné Kinesis fronty). Kinesis samotný s psaním aplikací na zpracování dat nijak moc nepomáhá. K dispozici je SDK pro Kinesis - tedy obalené funkce typu GetNextRecords


A konkrétní příklady?

  • zpracování logů
  • analýza dat v reálném čase
  • odchycení a zpracování dat ze sociálních sítí
  • analýza finančních transakcí
  • gaming analytika
  • strojové účení


Kolik to stojí?

Kinesis se, stejně jako všechno ostatní v AWS, platí po hodině provozu za provozní jednotku (shard). Jeden shard zvládne přijímat data rychlostí 1MB/sekundu a odesílat rychlostí 2MB/sekundu. Aktuálním limitem na jeden vložený datový objekt je 50kB. Text tohohle blogpostu by jeden "shard" zvládl přijmout zhruba 500x/sekundu. Cena ze tenhle nejmenší "shard" je $0.015 za hodinu. Další a poslední cena je za vkládající operace. Jeden milion vložení (přijetí) datových objektů stojí $0.028. 

Když bych zůstal u objemu tohohle blogpostu a řekl, že má 3.5kB, pak kdyby chodil do Kinesis takovýhle text 300x/sekundu celý měsíc, stálo by to:

  • 1 shard = $11.16 / měsíc
  • vložení textu 500x/sekundu = 803.520.000 vložení za měsíc = $37,49 / měsíc (vložení = příjem jednoho blogpostu)


Suma sumárum

Největší přidanou hodnotou je tedy hlavně držení streamu dat, o který se nemusíme starat. Bude to možná poměrně konkurence pro Pusher. Pro Keboola Connection je to hlavně příležitost - de-facto na podobném principu dávno fungujeme a Kinesis nám může pomoct "zpevnit základy". 

Znovu se tedy potvrzuje to co jsem psal na konci staršího blogpostu - nejenom díky Kinesis si můžeme troufnout na náročnější projekty a cítit se v Cloudu silnější. 

K vidění na Kinesis zatím moc není, tady je promo video a odkazy na dokumentaci. Přikládám screenshoty z aktuální Management Console.

GoodData XAE - BI gamechanger

Z kraje léta spustila GoodData do ostrého provozu svůj nový analytický engine AQE (Algebraic Query Engine), který má oficiální produktové jméno GoodData XAE. XAE je ale určitě čínsky “podviživený kuře”, takže já zůstanu u AQE :-) Od prvního momentu je to pro mě věc s největší přidanou hodnotou - když mi to Miki ukazoval, zamiloval jsem se na první dobrou :-)

Úvod lehce ze široka

Každý systém, který má ambice vizualizovat data, potřebuje nějaký matematický aparát. Pokud jako vstup budu mít prodané položky a jména obchodníků a budu z toho chtít zjistit medián obratu obchodníka, musí nejprve někde na pozadí proběhnout sečtení všech prodaných položek v daném měsíci pro každého obchodníka a nad tímto výsledkem pak můžeme počítat medián. Levá tabulka je surový vstup, pravá je odvozená za pochodu a většinou si ani neuvědomujeme, že takové mezi výstupy vznikají. Nad tou pravou pak můžu počítat věci jako nejlepší obchodník měsíce, průměrný/“mediánový”, aj.:

Pokud nemám robustní analytický backend, nemůžu si dovolit dělat “co mě napadne”, ale musím uživatele svázat do nějakých předpřipravených “vertikálních” analýz (churn analýza zákazníků eshopu, RFM segmentace, kohorty předplatného, aj.). Vrtat se v datech je možné mnoha způsoby. Kromě GoodData, které tady chystám vyvrcholení :), máte na trhu BI nástroje jako Birst, Domo, Klipfolio, RJMetrics, Jaspersoft, Pentaho a mrtě dalších. Vypadají super! O některých z nich jsem se otřel dříve. Osamocený datový analytik pak ještě sáhne po Rku, SPSS, RapidMineru, Weku, aj. - ale to nejsou BI nástroje. 

Většina ze zmíněných BI nástrojů nemá propracovaný matematický aparát, takže vám umožní čísla sečíst, spočítat četnost prvků, zjistit maximum, minimum a průměr. Tady je to krásně vidět na promo videu RJMetrics.

Systémy jako je Domo.com nebo KlipFolio.com pak řeší problém absence matematického aparátu trochu trikem. Lidem nabízejí spoustu matematických funkcní - jak v excelu - které jdou ale aplikovat na jednotlivé tabulky, ale ne na celý datový model. Někdo si řekne, že je to jedno, ale opak je pravdou - tohle je prubířský kámen všeho kolem datové analytiky. Zkusím vysvětlit proč.

Hranice našeho pískoviště stojí na aplikaci zákona o zachování "business energie”: 

"pokud nedokážeme našemu zákazníkovi vydělat větší peníze než ho naše služby (a licence GoodData) stojí, nebude s náma spolupracovat"

Pokud vezmeme výpis faktur ze SAPu a nakreslíme graf “jak to roste”, poženou nás zákazníci jako sedláky u Chlumce. My potřebujeme trochu víc, potřebujeme dávat za pochodu jednotlivé datové dimenze do souvislostí (dimenze = tématický soubor dat, nejčastěji reprezentovaný jako tabulka dat - dimenze mezi sebou nemusí mít žádné jasně definované vazby; tabulku v analytickém projektu nazýváme datasetem). 

V momentě, kdy dáme jednotlivým dimenzím souvislosti, vznikne logický datový model. Logický model popisuje “business” souvislosti a často není shodný s technickým modelem, ve kterém ukládá data nějaký systém. Pokud má například Mironet e-shop, je databáze za tímto eshopem optimalizovaná pro potřeby e-shopu, nikoliv finanční, obchodní a/nebo subscription analytiky. Čím složitější je prostředí, jehož data se analyzují, tím méně podobností mají technické a analytické datové modely. Nízká (strukturální) podobnost zdrojových dat a dat, které potřebujeme k analýze, vyřazuje většinu GoodData konkurence. 

Dám příklad na našem interním projektu. Interní projekt jsem vybral proto, že obsahuje logický model, který potřebujeme používat sami pro sebe. Není to tedy uměle nafouklé “protože to zákazník zaplatí”.

Do GoodData nahráváme různé tabulky, které jsou spojené vazbama. Vazby definují logický model; logický model pak definuje “co jde s daty dělat". Náš interní projekt slouží k měření naší vlastní aktivity a spojuje data z českého účetnictví (Pohoda), kanadského účetnictví (QuickBooks), z vykazovací cloudové aplikace Paymo.biz a několik Google Drive dokumentů. V interním projektu máme 18 datasetů a 4 datumové dimenze.

Obecnější model vypadá takto a detailní model vypadá takto. Červeně jsem označil jméno klienta, černě jméno našeho analytika a modře odpracované hodiny. Chci tím ukázat, že jsou jednotlivé související informace v projektu bohatě rozprostřeny. Díky vazbám GoodData ví, co dohromady dává smysl.

Nad tímhle modelem stavíme dashboardy, ve kterých sledujeme, jak nám jde práce od ruky, srovnáváme mezi sebou měsíce, lidi, druhy práce, koukáme na náklady a výnosy, aj.

Cokoliv v tom našem dashboardu je přesně šité na míru naší potřebě. Nikdo nám nediktoval, jak se to bude chovat. Tahle volnost je pro nás kritická a jen díky ní dokážeme stavět nad GoodData cokoliv si zamaneme = je jen na naší schopnosti, jestli uspějeme a zákazník s náma bude spokojený. 

Trochu pastička na zákazníka je v tom, že podobný dashboard je možné na první pohled sestavit v ledasčem. Mám tady příklady dashboardů z KlipFolio. Jsou super, ale mají jedno podstatné “ale” - všechny vizuální komponenty jsou objekty, které načítají informace z předem připravených dat, které někdo designoval přesně pro účely toho dashboardu. Není možné to překroutit a začít třeba 2 čísla ze dvou podkladových tabulek podělit a sledovat jejich podíl v čase. A month-to-date toho podílu už vůbec ne. O situaci, kdy máte data, ve kterých jsou vazby “many to many”, nemá smysl vůbec mluvit. Velká výhoda těhle BI produktů (řikají si BI, ale BI to není) je v tom, že jsou líbivé a podbízivé. Člověk na startu neodhadne, že si kupuje křáp, který vlastně neumí o moc víc než jeho Excel.

Proč je trh zaplavený produkty, které hrají na maličkém hřišti se stěnama vylepenýma cool vizualizacema? Nevím, ale lidi jedou na vlně “Cool, BigData analytika!” a jsou hladový po čemkoliv co má podobu reportu. Tématická analytika se udělá za pár dní - transformace transakcí a počítání "Customer lifetime value" je snadná, dokud mi každý neřiká jak to chce mít podle sebe. 

"Nikdo na světě kromě GoodData nemá schopnost provozovat analytické projekty, které jsou 100% svobodné svojí podstatou (datovým modelem) a v těchto projektech nechat lidi dělat cokoliv chtějí, aniž by museli být low-level data analytici a/nebo programátoři. Bum!”

Jak to GoodData dělá?

V Excelu je každý zvyklý sečíst sloupeček “A” tím, že dá do libovolné buňky vzoreček “=SUM(A:A)”. V GoodData sečte sloupeček A tím, že napíše vzoreček “SELECT SUM(A)”. Jazyku kterým se v GoodData tyhle vzorečky píšou se říká MAQL - mnohodimenzionální analytický dotazovací jazyk (Multi-Dimension Analytical Query Language). Zní to děsivě, ale zatím to každéj dal, i Pavel Hacker má z Keboola Academy diplom na Report Mastera :-). Pokud se podíváte zpátky na ten můj datový model z našeho interního projektu, můžete si říct, že chcete průměrný počet hodin z jedné strany datového modelu, ale filtrovaný třeba typem úkonu, seskupený podle popisu projektů a jména klienta a to celé jen pro úkony, které proběhly o víkendu odpoledne. Všechny metriky budou vypadat jako “SELECT AVG(hours_entries) WHERE name(task) = úklid”. Multidimenzionalita toho jazyka je v tom, že neřešíte, v jaké dimenzi je jméno úkolu a v jakém je vztahu k počtu vykázaných hodin a nedejbože jménu klienta. GoodData, resp. vztahy v logickém modelu, který pro klienta navrhujeme my, za vás pořeší úplně všechno.

A teď jádro pudla: pokud vám připravím (denormalizovanou) tabulku do Excelu ve které to bude pěkně na zakázku sesypané dohromady, nebude to nikomu kdo tohle čte, dávat problém spočítat. Pokud vám dám data rozdělená podle dimenzí (a dimenze bude často jiný zdroj dat - jako jsou výstupy z našeho českého a kanadského účetnictví), bude to potřeba zpracovat mnohem složitějc (nejspíš začnete v SQL joinovat jako zuřivý). Jelikož se svět nedá popsat jednou tabulkou (teda asi dá - key value pair - ale nepůjde s ní moc pracovat), je pohled přes mnoho dimenzí tím podstatným. Bez něj je všechno jen takové to domácí počítáníčko :)

Kalibrace pozornosti: teď už byste pomalu mohli říct “wow”, protože pokud se vrtáte v datech, mohli byste mít vysokou míru afinity k popsané situaci :)

Jdeme do finále

Výroba dotazovacího jazyka je nejsložitější úkol, který v BI dneska můžete řešit. Není to o uložení velkých dat, není to o jejich zpracování, ani vykreslení grafů nebo příprava API, aby se dalo s váma perfektně spolupracovat. Dotazovací jazyk si nekoupíte ani za měsíc nenaprogramujete. 

Pokud bude jazyk složitej, nebude ho umět zákazník používat. Pokud bude jazyk hloupej, nebude s ním schopný dělat co chce. GoodData má jednoduchý jazyk na vyjádření jakkoliv složitých otázek směřovaných do dat a zároveň má aparát, kterým tento jazyk napasuje na jakkoliv složitý BI projekt (logický datový model). V případě GoodData je to právě MAQL/AQE - z mého pohledu je to tou jedinou věcí, která je na GoodData neopakovatelná. Kluci z Brna a Prahy - Tomáš Janoušek, David Kubečka a Tomáš Jirotka - navíc rozšířili AQE sadou matematických důkazů (složitá algebra), díky kterým je možné rychle testovat, že nové funkce v AQE platí pro jakékoliv druhy logických modelů. GoodData tak má jistotu, že překlady mezi (MAQL) metrikama a nějakým SQL na spodních databázích jsou správně. AQE tak pro běžného člověka překlene propast, která ho dělí od low-level scriptování. 

UPDATE 17.11.2013: MAQL je dotazovací jazyk, který je na základě logického modelu (LDM) překládaný pomocí MAQL interpretru (dříve QT - "Query Tree" engine) do stromu dotazů. Tyhle dotazy jsou vlastně definice "star joinů", ze kterých "Star Join Generator" (SJG) vyrábí podle fyzického datového modelu (PDM - leží pod LDM) vlastní SQL dotazy na DB backend. Celé to na začátku dal dohromady Michal Dovrtěl a Hynek Vychodil. Nová implementace AQE tohle všechno navíc položila na solidní matematický základ ROLAP algebry (podobá se relační algebře).

Po týdnech přemlouvání a úplatcích jsem vydyndal lehce cenzurované vzory dotazů, které AQE vyrábí z metrik, které jsem pro tenhle účel napsal. Tuším, že je to poprvé, kdy to někdo veřejně publikuje!

Pro srovnání jsem vzal datový model z Report Master kurzu v Keboola Academy a nad ním udělal report:

Graf mi na pravé Y ose ukazuje, kolik jsem udělal v Afgánistánu, Albánii, Alžíru a Americké Samoe kontraktů za posledních 13 měsíců. Na levé Y ose mi ukazuje modrou čárou, kolik mi přinesl průměrný obchodník a zelenou čárou mi ukazuje kolik byl medián obratu na obchodníka v daném měsíci (vstupy jsou de-facto shodné s ukázkovou tabulkou úplně na začátku).

Graf tedy obsahuje tři metriky (viz legenda pod grafem):

  • "# IDs” = SELECT COUNT(ID (Orders)) - spočítá počet prvků
  • “prumer na obchodnika” = SELECT AVG(obrat na obchodníka) - spočítá průměr z (pomocné) metriky počítající sumu obratu na obchodníka
  • “median na obchodnika” = SELECT MEDIAN(obrat na obchodníka) - spočítá medián z (pomocné) metriky počítající sumu obratu na obchodníka

a pomocná metrika

  • "obrat na obchodníka” = SELECT SUM(totalPrice (Orders)) BY employeeName (Employees) - spočítá hodnoty položek (nějaké prodeje) na úrovni obchodníka

Všechno je samovysvětlující, snad jedině “BY”, což mi definuje, že se mi peníze “totalPrice (Orders)” spočítají podle obchodníků a ne chaoticky mezi sebou. Troufám si tvrdit, že každý kdo je ochotný a bude se maličko snažit, se to naučí (ostatně to v Keboola Academy učíme jak na běžícím pásu). 

A teď to hlavní. AQE to přeloží na následující SQL:

S trochou nadsázky lze říct, že sestavení mého reportu je vlastně poměrně dost složité, ale mě to díky AQE vůbec netrápí. Platí-li hypotéza, že:

  1. pokud mi GoodData nevydělá balík peněz, tak ji nebudu používat
  2. balík peněz vydělám jen přesným používáním BI projektu, šitým na tělo
  3. BI šité na tělo je komplexní záležitost, kterou je možné obsloužit jen díky AQE

… pak je AQE základem úspěchu GoodData.

UPDATE 17.11.2013: jak to léta používám, vůbec mi nedošlo to zásadní - kontextovost MAQL metrik - úplně se mi to vrylo pod kůži a jinak si to neumím představit. Perfektně to pospal Hynek Vychodil v komentáři dole (nejde tu konkrétní komentář linkovat, tak tady je pro jistotu screenshot

Poznámka pod čarou: výše uvedené MAQL metriky jsou jednoduché příklady. Někdy je potřeba metriku postavit tak složitě, že je až nepředstavitelné, co se s daty musí na pozadí stát. Tady je příklad metriky z jednoho projektu, kde je analytika nad nestrukturovanými texty. Metrika počítá konverzační témata v aktuálním (zvoleném) období podle moderátorů:

Lukáš Křečan před časem blognul, že lidi jsou největší konkurenční výhoda GoodData. 

Lidi jsou základ, bez nich to určitě nejde a jsou to oni, kdo tvoří neopakovatelnou atmosféru ve které vznikají unikátní věci. Jeden za druhým jsou ale nahraditelní. Největší konkurenční výhoda GoodData (a zároveň zásadní duševní vlastnictví) je AQE. Pokud by ho neměla, musel by uživatel reporty klikat v sevřeném UI, které mu vezme tolik potřebnou flexibilitu. Bez AQE bude GoodData někde v partě mezi Tableau, Bime, Birst, aj. Stane se v zásadě nezajímavou a bude zhusta soupeřit s firmama, co si nad “Redshiftama" budou stavět vlastní UI.

AQE je pro GoodData neopakovatelná příležitost jak utéct konkurenci, která bude už jen ztrácet. Nikdo jiný dneska nedokáže implementovat novou funkci do produktu, kde mohou být libovolná data v libovolně rozměrech (dimenzích) a přitom si analyticky dokázat a otestovat správnost implementace. 

Hranice mezi falešnou představou že “ten cool dashboard je pro mě přínosný” a "opravdovým potenciálem vytěžitelným z dat", je velmi tenká... a jmenuje se customizace. Libovolný model pro libovolná data a nad ním libovolné výpočty. Může to kdokoliv nazvat jako extrém, ale bez schopnosti spočítat přes mnoho dimenzí přirozený logaritmus z podílu hodnot dvou období, do světa finanční analytiky díru neuděláte. AQE je gamechanger na poli BI a díky němu GoodData redefinuje pravidla hry. Dneska obecná odmocnina, zítra K-means... :)


Howg!


Trocha čísel z backendu

Kouk jsem se dneska na to, kolik dat držíme a zpracováváme v Keboola Connection. Nejsou to žádný ultra objemy, ale když si uvědomíme, že jsou to primárně čistý obchodní informace našich klientů (transakce a číselníky), je to docela dost. Nepočítám do toho náma vygenerovaný logy a eventy, popisující provozní parametry, ani zálohy a podobné věci. 

Vzal jsem v úvahu období od začátku minulého měsíce do včerejška, čísla jsou vždy agregovaná za jeden konkrétní nejaktivnější den:

  • Počet operací proti Storage API: 37.689
  • Objem přijatých dat: 26.5 GB
  • Objem odeslaných dat: 33.5 GB
  • Čas strávený obohacováním dat: 1.992.890 sec (23 dní!)

A ještě 3 celkové statistiky k dnešnímu dni:

  • Celkový objem držených (živých) dat: 1.3TB 
  • Počet všech řádků : 6 miliard
  • 5 nejčastějších chyb v API: 
    • nesedící struktura dat při importu od klienta
    • validace obsahu tabulky
    • nepovolený přístup
    • překročený počet povolených indexů
    • cílová tabulka nenalezena

A stupínek vítězů pro technologie, které se na tom podílí?

  1. místo určitě stále zastávají Amazon RDS (MySQL) servery
  2. místo nově zabral Amazon Redshift
  3. místo zabírají (měřeno přes palec) Google BigQuery, HP Vertica + R a Amazon CloudSeach

Minulý týden jsme ale měli "IT party" s Karlem Minaříkem a myslím, že Amazon CloudSearch brzo vystřídá ElasticSearch. V kostech cítím, že v tom leží budoucnost. Tlak na co největší rychlost a JSON všude kam se podíváš - trend je jasnej :-)

HR okénko:

Sháním někoho se zkušeností s AWS Data Pipeline a/nebo AWS SWF. Pokud nikdo takový neexistuje :), hledám nadšence, co si s tím pro Keboolu zaexperimentuje. Kontakt nejlépe v komentářích nebo emailem na petr@keboola.com.