Guest post: Proč Enterprise Data Hackathon?

Spousta lidí se mě ptá, proč jsme se do toho pustili a přes půl roku jsme se zasekli na tom, že běháme jak trotli po firmách, vymejšlíme jak to udělat, aby to security povolila, jak přesvědčit vedení ve firmách, že je to super nápad a že se musí změnit a inovovat, jinak zemřou, a že prostě nejsme v Silicon Valley, aby mohli mít tisíc nejchytřejších lidí z dané oblasti na světě, a že se to prostě musí dělat jinak…že se musí otevřít a crowd sourcovat…

Pravdou je, že nás to baví. Baví nás to proto, že vidíme v každodenní práci Kebooly, jak data mění lidi a firmy, jak Demokratizace dat pomáhá posouvat firmy dopředu a vydělávat peníze. Vždycky se snažíme, aby každý dolar, který klient utratí, se mu několikanásobně vrátil, a to v době řádu týdnů a ne roků. No, a tím, že děláme s daty, je naše práce krásně viditelná a měřitelná. Čísla nelžou.

Začátkem roku jsme s Keboolou chodili do velkých, klasických firem, částečně proto, že jsme chtěli, a částečně i díky mému předchozímu angažmá s netmailem a Google Cloudem, kde prostě již nějaké kontakty byly a lidi data zajímala.

Zjistili jsme fakt zajímavou věc. Zjistili jsme, že i když ve velkých firmách pracují šampóni, co mají boty z krokodýlí kůže, kapesníček sladěnej s košilkou a jsou bezvadně vyfitkovaní (ano, takoví lidé fakt existují a vím, z pohledu z vnitra těch firem je těžké si to představit. Ale kdyby bylo třeba, juknětě na Václava a je to prostě tam :)), tak to prostě nejsou ti samí manažeři, jako byli před deseti lety. Kupodivu to jsou super vzdělaní lidé, s obrovskou praxí v zahraničí, kteří fakt chtějí ve svých firmách dělat super věci a být na ně hrdí. Jen prostě mají občas problém to vrcholnému managementu ukázat. Moje teorie je, že je to tím, že nemají parťáky na straně dodavatelů. Každý dodavatel, když vleze do obří firmy, se posere, přestane být sám sebou a začne se podřizovat systému, o kterém si myslí, “že tak je.”

My jsme začali do těch firem chodit proto, že jsme chtěli. Nic nás nenutilo. Zajímali nás prostě ty lidi a jejich problémy. Necpali jsme jim “zázračný model, který teď vyřeší všechny problémy” a jen za mrzkých 30MKč.

Naopak, snažili jsme se, a snažíme, pochopit, jak operují a co je trápí. Zároveň si validovat naši teorii Demokratizace dat a demystifikovat BI. Myslíme si, že je to prosté. Každý má mít svá data neustále k dispozici a moci si sám, levně a hned odpovídat na datové dotazy. Třeba tak, že když chci vědět, jakej produkt mám naložit do kontejneru, který zítra vyplouvá z Šanghaje, a je tam jedna volná paleta, tak se sám podívám na trendy v reklamě, objednávky v kategoriích, četnost stížností a počet vratek. Spočítám si skutečnou hodnotu produktu a během 5 minut odpovím.

No prostě, viděli jsme úplně stejné lidi, kteří čtou stejné weby jako my či vy a kteří chtějí inovovat a chápou, že jedinou cestou je to vytáhnout ven a “olizovat si mozky” s ostatníma. 

A tak jsme se s nima spojili a uvidíme. 

Celý je to jeden velkej experiment a já upřímně obdivuji ty naše parťáky ve firmách. Jak ty, kterým se to podařilo a prošlapali celou korporátní byrokracií, tak i ty, kteří se fakt snažili, ale prostě se to zatím neseběhlo ve správný čas:)

No, a když jsme měli přislíbená data, tak teprve začalo hračkářství.  “Já bych si chtěl vyzkoušet forecast.io.” ”No, tak jim napiš, ne?” hmm…a oni odpověděli, že ano. Zajímavé…a co když zkusíme API x…to už je velký hráč…ANO…pak se samo ozvalo HP, a že nám půjčí Verticu a Autonomy. No, a tady nám teda vážně vzrostlo drzé čelo a řekli jsme si, že když už, tak už, a šli jsme za SAS a SAPem a pár dalšíma obříma enterprise hráčema a ukázalo se, že vlastně všichni chtěj a připraví nám Cloudové instance na víkend.

Takže SUPER !!!!

Jukněte na webík http://enterprise.hackathon.bi  a přijďte se zapojit 17.10. a uvidíme, jaká to bude sranda.

Jo a followujte nas  @hackathonBI 

Cus :)

Pavel

Informace na dosah ruky - Pebble Watch

Komplikované dashboardy za dvojitým přihlášením a trojitým firewallem přestávají být cool. Naši zákazníci potřebují podstatné informace doslova na dosah ruky - a to nesplňuje ani report v iPadu. 

Na startu naší vlastní "wearables" mánie jsme zvolili hodinky Pebble.

Proč?

Každý má svoje "jedno číslo", které mu napovídá, jak se mu daří. Obchodníka může motivovat, kolik si vydělal na provizích a jak si stojí oproti svému týmu, CEO bude chtít znát ukazatele od CFO, apod. Nemusí nic dělat, jen se podívá na hodinky...

Jak to funguje?

Do mobilu si nainstalujete Pebble aplikaci (Android, iOS) a v ní si nainstalujete "Keboola Stats" do které zadáte token, který vám vygeneruje náš "Pebble Writer" - ten bude v UI za chvilku.

Co to umí?

Aktuálně to umí každých pár vteřin v hodinkách aktualizovat libovolné číslo, které je dneska zanesené na dashboardu, který může ukazovat 2 čísla a jejich změnu v %. Například: kolik mám obrat od dnešní půlnoci do teď (aktuální přesné číslo) a o kolik % je to jiné oproti obratu včera za stejné období + kolik mám objednávek za dnešek a změna vůči včerejšku:

Obrat 123.000,- Kč (+7%)
Objednávky 600 ks (-12%)

Spočítat takhle umíme téměř cokoliv na co máme data (v tuhle chvíli se umíme napojit na 33 datových zdrojů + máme API pro příjem dat, která k nám posílá zákazník). Rychlost aktualizace čísel v hodinkách je nastavená na 1x/30 vteřin. Spolehlivě můžeme jít tak na 1x/10 sec, pak už to přestává dávat smysl - zpoždění v mobilní síti a čas potřebný pro načtení nových dat a spočítání metrik pro dashboard v hodinkách.

Teď ještě dostat to samé na hodinky od LG, Samsungu a Motoroly. Celý stack, od sběru, analýzy dat a API už máme, zbejvá frontend :-)

Kdo by si to chtěl vyzkoušet, máme jedny červený Pebble hodinky na půjčení - kdo má vlastní, může do toho naskočit hned. Samozřejmě musí mít data v Keboola Connection (data umíme vytahat i z existujících GoodData projektů!).

Credits: Tomáš Kačur za to že to celé postavil, Martin Karásek že během asi 45 sec vyšvihl ikonky do Pebble Store.

P.S. Pebble aplikace v telefonu (napsaná v JS) a aplikace v hodinkách (napsaná v Vanilla C) je jako OpenSource k dispozici v našem GitHubu. Backend vrací na metodu stats tohle (dokumentace API bude asap v Apiary.io):

{
    "heading": "Revenue",
    "title1": "Today",
    "percent1": "10",
    "number1": "123.4",
    "title2": "Week",
    "percent2": "20",
    "number2": "245",
    "changed": "2014-07-08T13:44:22+0200"
}

Další úspěch Kebooly - energetika a analýza dat v cloudu

Když jsem před 5ti lety začal obcházet místní trh a prodávat “pomůžu vám vyznat se v datech”, narážel jsem na nepochopení, strach z cloudu a lobby různých interních sil mých potenciálních zákazníků. Za těch pár let ušli Češi velkou cestu a nám se otevřely dveře do spousty firem, o kterých se mi dřív mohlo jen zdát. 

Loni v říjnu jsem popsal 8 důvodů, proč se firmy bojí cloudu. Myslím, že ve světle našeho nového klienta získá jakýkoliv argument "proč nezpracovávat data v cloudu” spíš jasnější obrysy výmluvy, protože plácnutí si s MND posunulo Cloud BI v ČR daleko do vod “offline korporátního businessu”.

MND (Moravské naftové doly) jsou největší těžební společností ropy a zemního plynu v České republice s více jak stoletou tradicí. Zároveň nabízí druhou největší skladovací kapacitu plynu v ČR.

27.1.2014 vstoupila MND a.s. na trh prodeje plynu domácnostem a o 4 měsíce později jsme jim po úspěšném “proof of concept” projektu zapli do produkčního prostředí analytiku dat, kterou pro ně zajišťuje úderné kombo Keboola Connection s "analytickým modulem” od GoodData.com. Celý projekt byl na BI svět neskutečně svižně - v našem paymo.biz má natrackováno 70 hodin - čili necelé 2 týdny práce. Lví podíl na takové rychlosti má samozřejmě skvělá příprava od lidí v MND a.s., kteří vědí, co chtějí, umí se perfektně ptát a jejich interní IT je hyper-kompetentní sehraná parta.

Z pohledu laika je pro mě business MND zhmotněný do fascinace zásobníky plynu a automatizovanými “hnízdy” na Moravě, kde jsem před dvěma lety překonal pud sebezáchovy a skrz plot s výhružnými cedulemi udělal jednu fotku.

Jak nás MND používá?


Srdcem celé analytiky v MND je náš produkt "Keboola Connection", což je kombinace datového skladu v cloudu a přidružených služeb, které umožňují data čistit, obohacovat (rozpoznávat v datech lokality a dotahovat k nim předpověď počasí nebo třeba odhadovat další nákup existujícího zákazníka) a různě auditovat, a nebo třeba posílat do dalších služeb. Součástí Keboola Connection je zároveň nativní napojení na GoodData.com, která pro nás slouží jako takový analytický modul. Máme tendenci říkat, že jsme “Fedex na data” - kdekoliv je vyzvedneme a kamkoliv je doručíme. Po cestě s nimi navíc umíme udělat různá kouzla.

Aby vůbec mohl podobný projekt vzniknout, bylo hlavní podmínkou MND, že jejich analytický tým zůstane samostatný a nebude se muset na nás spoléhat. Cílem pak bylo integrovat dohromady různé zdroje dat a umožnit nad výsledkem sledovat efektivitu přímého prodeje plynu domácnostem skrz dealerskou síť. Pro tyhle účely aktivně vysáváme pomocí Google Analytics extraktoru data o chování lidí na webu mnd.cz a od interního IT dostáváme (pomocí našich open source klientů) data z interního informačního systému přímo na naše Storage API + k nám třetí partner obdobnou cestou posílá data z call centra, kde se řeší telesales a customer support.

Nad těmito daty běží různé sady transformací a matematických detekcí, které tvoří podklady pro analytiku akvizičního funnelu (aka “monitoring prodeje služeb”) a jak je ovlivňovaný pohybem lidí na webu. Zkoumá se nad tím kvalita a výkony dealerské sítě (sales analytika) + následná funkčnost call centra (jak dlouho s kým mluví, o kolik hovorů přijdou, protože zákazník dlouho čekal, atd.) a jeho vliv na celý business proces.

Co bude dál?


Věřím, že BI v oblasti sledování kvality prodeje zafunguje skvěle a analytici v MND začnou pracovat nad dalšími druhy dat - analýza těžby si o to úplně říká. 

Možná i díky nám - nejefektivnější cestě jak analyzovat vlastní data z mnoha různorodých zdrojů - zůstane MND jedním z nejlevnějších dodavatelů plynu pro domácnosti, jaký na trhu dneska je (mrkněte sami: https://www.mnd.cz/plynzprvniruky/kalkulacka#vypocet)! 

Držte jim i nám palce!

P.S. Credits: Tomáš Netrval a Martin Matějka

Jak hlídáme útratu v našem Amazon AWS účtu?

Dlouhodobě jsem řešil, jak se dívat na náklady v Amazon AWS. Před lety jsme platili pár dolarů, pak stovek a dneska se nám měsíční účet pohybuje mezi 80.000 až 120.000,- Kč (a trend nepříjemně roste). Mimo jiné jsme si na to zařizovali dedikovanou platební kartu, protože když jsem odklikával na ČSOB kartě limit 150kKč pro platby na internetu, začlo mi pak bejt nepříjemný její číslo strkat kamkoliv jinam.

Za poslední dobu Amazon v “billingu” udělal poměrně pokrok, ale pořád to není to co bych chtěl. Platí, že nemají žádnou motivaci vás upozornit na zbytečně běžící služby (ze kterých jim padají $$) a rozhodně moc nepomáhají s optimalizací účtu. 

Pak jsem náhodou objevil službu Cloudability z Portlandu. Je skvělá! 

Platíme $49/měsíčně (cena je odvozená od útraty na AWS) a hned po prvním zapnutí jsem objevil různé zapomenuté Elastic IP adresy, neběžící LoadBallancery a (to bolelo nejvíc) pár velkých EBS s Provisioned IO, které se nepoužívaly. Spolehlivě jsem si povypínáním těhle AWS služeb ušetřil na 2~3 měsíce provozu Cloudability :-)

Jak to funguje?

Amazon umí logovat detaily o využití infrastruktury do S3 bucketu. Zapíná se to v sekci Billing > Preferences:


Data jsou poměrně pěkně čitelná:


ale scházel jim “nástroj” na míru. 

Kromě kvanta pěkně připravených pohledů na útratu, umí Cloudability dělat ad-hoc reporty až tří dimenzí a tří metrik (zamazal jsem hostname a jména klientů)


a posílat denní reporty s útratou:


Na ty koukám letmo na mobilu a hned je mažu. Jediné co sleduju je, zda tam není nějaký šílený skok (používáme SPOT instance s vysokým "bidem" a může se nám to poměrne snadno to stát).

Kdyby tohle měl Petr O. od svého providera, nemusel by se s nima hádat o meloun za konektivitu (k hacklýmu serveru jeho zákazníka, který měl blbej tarif na přenesený data)


... protože by si "průseru" všiml ihned.

Používáte-li AWS, určitě Cloudability zkuste, stojí to za investované úsilí!

Už je to 3 roky, Keboolo...

Před 3 lety nám Michael Gear podepsal první smlouvu na nákup platformy...

Téměř přesně rok předtím jsem na dovolené na Šumavě po večerech tlačil svoje první data do GoodData. Ou, jak to bolelo! :) Takhle jsem zformuloval do emailu první dojem:

Vlastně mě dneska překvapuje jak jsem intuitivně “trefil” důležitý aspekty z týhle zkušenosti. Vzpomínám si, jak to bylo silný. 

Tehdá jsme pro První multimediální v Keboole dělali zakázkovej vývoj a denně se prali s jejich (později EtNetera) projekťákama. Fér je říct, že to s náma taky asi neměli snadný a utrpení to mohlo bejt na obě strany. Do GoodData jsem teda zákonitě nahrával exporty z Atlassian JIRA. Tohle byly jedny z mých prvních reportů vůbec. Po tom UI se mi docela stejská :)

Když už jsem u toho vzpomínání, tak jsem si vylovil fotku našeho prvního “vlastního” kanclu. Byla to jedna místnost v paláci Lucerna za 12.000,- Kč měsíčně, kterou jsme měli v kanceláři WIA spol. s r.o. Jsem moc vděčný za vstřícnost s jakou nám lidi z wia.cz se vším pomáhali. Bylo to super období - takovej správnej boj o přežití. Díky, Filipe!

2011

Ten první kontrakt s GoodData jsme podepsali pro Centrum Holdings a de-facto celý rok 2011 v tom sami sebe hledali. Těší mě, že tam úplně původní GoodData projekt funguje dodnes na stejném datovém modelu. 

V polovině roku 2011 jsme vykopli první certifikovanou aplikaci (Facebook Insights data). Pokud mě pamět neklame, byli jsme první non-GoodData firma, kdo něco takového udělal. Uzavření smlouvy a domluvení $$ na prodej téhle analytické apky bylo dost peklo - a tady masivně nastupuje na scénu Milan Veverka, můj dnešní společník a parťák, bez kterého bysme dneska asi leštili okna těm EtNetera projekťákům :-) 

Koncem roku 2011 konečně dejiny leštiček CDček dojdou tam, kam 2 roky předpovídám a Milan opouští svoje tehdejší zaměstnání (šéfkonstruktér a designer strojů, co leští CD/DVD/BR) a nastupuje do svýho basementu jako náš 1. fulltime člověk mimo ČR. Musel na tenhle krok mít hodně odvahy, respekt!

2012

V Praze máme 2 analytiky, 3.5 vývojáře a support kolem. V Kanadě je 1 člověk. BI dělá asi 24% našeho obratu. První commit Storage API do GitHubu! Na naší tiskárně se tisknou akcie Apiary.io, Klára hraje “svědka” při jejich podepisování.

Koncem roku 2012 odjíždí do Kanady Ondra Hlaváček. Má pomáhat Milanovi. Zakládáme v Kanadě firmu a přijímáme první 2 místní zaměstnance. Nemáme moc peníze a plán je, že si je vyzkoušíme a jednoho z nich si necháme a druhého horšího budeme muset propustit. Adam a Cameron jsou ale megahustý borci a necháváme si je oba. Tou dobou máme na Tomášovi Trnkovi v Praze otestovaný draft prvních “Report Master” Keboola Academy projektů a díky nim bootujeme Adama i Camerona do GoodData ekosystému (rozuměj MAQL) de-facto za 14 dní. Adam v 1. měsíci u nás implementuje projekt pro Shazam, který končí velkým úspěchem a pro nás ziskem (= nedoplácíme na Adamovu vejplatu). Zároveň získáváme velkého zákazníka - bojí se, aby neinspiroval svojí konkurenci, proto nás tlačí k zákazu jmenovat ho v referencích (#trapáci) - který si nás nachází sám - posílá nám poptávku přes kontaktní formulář. Ten ale u nás pankáčů nikdo nečte. Takže nám od nich během 14 dnů přijdou do schránek 2 další urgence. Když je to ve fázi že nás prosí, abysme mu zavolali, přijde nám že asi nepůjde o indickej spam a voláme mu zpět - uf! Tohle je náš první projekt, který má šestimístný rozpočet v dolarech - začíná pro nás novej level hry. 

2013

V lednu máme plnohodnotný analytický týmy v Praze a Vancouveru, BI dělá 84% našeho obratu. Kolem GoodData věcí maká 6 analytiků a 5 programátorů (+ support kolem). 

V květnu v Kanadě nastupují další lidi. V Brně se přidává Odin. Je nás celkem asi 20 a BI dělá 100% našeho obratu. Po létě se Nailoš a Kachna přesouvají z White Rock kanclu do vlastního baráku v severním Vancouveru - izolujeme tak analytiky od programátorů (tady by se mohla GoodData od nás inspirovat - hodně věcí by to u nich prospělo) a získáváme trochu víc místa pro další lidi co tam nastupují. Koncem roku je jasné, že se do stávajícího kanclu nevejdeme - začíná nám první CAN stěhování, paralelně s tím nabíráme další lidi. Rok 2013 končíme dost spokojeně. 

Q1/2014 ve zkratce

Nastupují 3 další lidi (2 v ČR, 1 v CAN), odchází Vojta Roček, pouštíme se s Pavlem Doležalem do offline analytiky, zamilovávám se do nového datového zdroje (počítačové vidění), zapínáme další typ backendu (AWS Redshift) a Elasticsearch u nás hraje víc a víc rolí. GoodData oznamuje "Open Analytics Platform" (nechám si na separátní téma). 


Uf, budu si muset sepsat věci časem víc podrobnějc. Stalo se toho za tak krátkou dobu strašně moc... Mám pocit, že jsme loni byli úplný matlalové. Snad je to dobrý znamení! 



Data Hackathon v NODE5

Tak máme za sebou hackathon v Node5, zaměřený na data. S nápadem podobnou akci zorganizovat přišel Petr Ocásek a nás v Keboole nemusel vůbec přemlouvat - hned jsme byli pro. Cílem akce bylo dát dohromady lidi, kteří si chtějí zkusit různé technologie a v příjemném prostředí Node5 si jen tak pohrát.

Ze mě se stal samozvaný fundraiser - GoodData.com jsem nabídl, že mají unikátní šanci přispět hotovostí pěkně na dřevo a že jim za to nabízíme jen dobrej pocit a nulovou propagaci, protože by pak Lukáš Hudeček akci prohlásil za komerční a zničil nás nájemní hustosazbou Node5. Jarda Gergič z GoodData bez mrknutí oka otevřel peněženku a vysloužil si tím náš nehynoucí respekt. My jsme ještě přihodili 7k. Chvilku to vypadalo, že se za takovouhle datařskou akci postaví ještě StartupYard, ale nakonec z toho sešlo, asi protože budou daně nebo co a kluci teď šetří každou korunu :)

Pátek

V Node5 bylo natřískáno! FB event sliboval 85 lidí, nakonec dorazili všichni kromě Pavla Čurdy, který dal přednost gauč surfingu v Brně :)

Večer byl o prezentacích, jídle a networkingu. Telegraficky:

  • Jan Hřivňák z Futurelytics; nevím co říkal, protože jsem u toho usnul (den předtím jsme měli v Keboole náročnej mejdan :)
  • Štěpán Bechyňský ukazoval Excel a nějakej add-on, kterej mu vyhodil tunu errorů. Všichni se začali smát - to mě probudilo! Nakonec to rozběhl a vypadalo to docela super - data o měření hluku a vibracích na dálnici D11, zobrazený v mapě
  • já jsem měl říct něco o BigQuery, Redshiftu a Vertice. Myslím, že se potvrdilo, že nejsem lev salónů, zvlášť po mejdanech :)
  • Štěpán Bechyňský pak ještě ukazoval různý mikropočítače - vypadalo to dost surově hackersky 
  • Adam Herout z Click2Stream ukazoval možnosti počítačového vidění - jsem na baru, neodnáším si z toho nic > to mě trochu mrzí, vypadalo to super
  • Dva kluci z Ataccama.com tam pak ukazovali blejskavý sales prezentace svýho hadoop řešení; míň self-promo, chce se mi říct...

Zbytek pátku byl pak ve znamení skvělého jídla od Gazdinka a kecání s lidma. Vzhledem k mojí únavě z předchozího mejdanu jsem zaparkoval v pytli, kde mě našel Martin Podval a Štefan Pacinda

Pracují v HP na projektu, který umí simulovat pokročilé SOAP/REST/whatever systémy - takové hustoadvanced Apiary.io. Ještě s Ondrou Popelkou jsme spolu asi hodinu povídali o GoodData, HP, jejich projektu a Vertice. 

Sobota

Vyrážíme na 9:00 do Node5. Pavel a Ondra spí u mě (bydlím nově za rohem). Ráno je ve znamení vykopnutí skutečné práce. 

Kebooláci se rozdělují mezi “naše” svěřence - Click2Stream a Twisto. Začínám rychlovysvětlením, proč je pro ně GoodData super - nakonec před všema lidma, protože je o to docela zájem. Jdu na dřeň a atakuju interní programátory, co míchaj chartové knihovny a vlastní SQL dotazy na data. Ukazuju “report explain” a rozvoj MAQL na SQL + vypichuju API. Nevím jak se to chytlo, ale jsme na hackathonu, ne? :) Dotazy jsou jen k realtime datům - s tím se vypořádávám protidotazem, zda je potřeba z realtime měřiče teploty vody v reaktoru dělat Month-to-Date a drillovat do toho. Chvilku řešíme rozdíl mezi BI a reportingem. 

Twisto a Click2Stream se přesouvá do menší místnosti, kde se bavíme o business kritériích jejich projektů, povídáme o tom, jak se do GoodData data dostanou a co s nima bude nutné předem udělat. 

Na tuhle diskusi se nabalí další lidi a já začínám mít z celé akce moc příjemný pocit.

Twisto

Tým twisto má připravená data v docela dobré kvalitě a přináší si existující reporting. Tomáš Trnka celý GoodData projekt vykopne za 60 minut.

V tu chvíli do toho už kluci klikají o 106. Velmi rychle se koukají například na

  • dynamiku fakturací
  • upomínky po zákaznících
  • profit share s e-shopama
  • podíl zaplacených a nezaplacených faktur

... všechno pěkně filtrovatelné časem, typem zboží či skupinama zákazníků. Po obědě už běží domů, za ně hotovo (trochu škoda, mohli jsme kutit další věci).

Click2Stream

Tým Click2Stream do hackování dat nastoupil s vervou a velmi masivně. Všechny svoje firemní data otevřeli a pustili k nim každého kdo měl zájem. Odměnou jim za to byl tým, do kterého se přidal z venku například Adam Mika, Michal Procházka a Jan Panoch. Společně jsme pak drtili GoodData v asi osmičlenném seskupení - spolehlivě největší stolní hnízdo na celém hackathonu.

Celý den byl ve znamení validace dat, žhavých diskusí o rozdílu price vs total price nebo o referenční integritě dat na vstupu. Odměnou za vynaložené úsilí je seznam zlepšení do jejich produktu; například nemazat v DB kamery, které jsou vypnuté, protože jsou k nim v účetnictví historické transakce. 

Ke konci dne jsem se ještě bavil s klukama ze sinfin.cz, kteří dělali mapování pohybu po Node5 pomocí BT4 zařízení. Vypadá to super, hned mi hlava brousí k našim klientům - určitě spolu něco upečeme! 

Node5 jsme opouštěli lehce po 23:00. Petr Ocásek tam spí na gauči, aby ráno brzo otevřel holkám co dovezou snídani - respekt! Já si domů tentokrát přivádím Tomáše Trnku a 2 staroprameny. 

Alena z nás musí být nadšená :-))

Neděle

Před snídaní v Node5 je nutné se doma řádně nasnídat. Páreček od Dolejších a čerstvá vajíčka nám dělají základ na dopolední sprintování za počítačem. Několik prvních hodin to v Node5 vypadá, že náš tým Click2Stream+Keboola je jedinej, kdo přijde pracovat - ostatní osamělé hackery totálně válcujeme “na počet”. Kolem 11 se to ale dost srovnává a Node5 hučí jako v úle.

Dopoledne trávím laděním modelu a transformací. Tomáš Trnka obíhá stul a radí s MAQL metrikama a kurzama v Keboola Academy. C2S tým je ale bystrý jako nikdo jiný, v poledne jsou z nich ostřílený borci a do projektu sázejí pohledy na 

  • expirující plány v nejbližších 30 dnech
  • revenue share po streamovacích plánech
  • nárůst zákazníků
  • poměr orders vs refunds
  • % placených kamer co nemají zaplé automatické obnovení plánu
  • chargebacks
  • CLV zákazníka, apod

Dělá mi dobře, když vidím, jak jim to jde. 

Roman Staněk by měl radost - roste jim tu nová generace Haplíků /* internal joke */ :-)

Vyhlášení

Hlasovalo se v průběhu prezentací pomocí http://sli.do. Výsledky: 

  1. sinfin.cz a jejich bluetooth monitoring lidí - kluci rozmístili po Node5 BT4 beacony a sbírali pomocí dobrovolníků data o pohybu v prostoru. Výsledky jsou super! Trápí je usínání aplikace v iPhone, ale věřím že to zlomí (cc Lukáš Foldyna)
  2. daty.cz a vizualizace vazeb mezi firmama - Adam Kurzok nám ukázal, že kluci z Mitonu maj větší assety než kluci z Credo Ventures :-)
  3. Futurelytics a data o kriminalitě - celou sobotu je trápilo získání čistších dat než původně měli, pak je v Google BigQuery pročistili a upravili a na jejich instanci v AWS nad tím provedli K-means segmentaci. Výsledky dali do Excelu. Tomáš Trnka jim nabídl, že jim to hodí do GoodData, což využili a GoodData dashboard ukázali. Vypadalo to dost dobře!

Překvapením na závěr byl pak opět Tomáš Trnka, který si od kluků z Futurelytics vzal jejich data a vedle jejich GoodData projektu si udělal ještě druhý, na kterém nám prezentoval, že se dle údajů v datech rozhodně nevyplatí 

  • Braní rukojmích
  • Nedovolená výroba a držení radioaktivního a jaderného materiálu
  • Vojenské trestné činy
  • Výtržnictví - útoky na záchranáře

... jelikož jsou ve ~100% případů vyřešené

a naopak můžeme dost lehkovážně páchat

  • Krádeže leteckých zásilek
  • Sdělení nepravdivé informace, která může ohrozit bezpečnost nebo provoz vzdušného dopravního prostředku za letu
  • Padělání a pozměňování peněz
  • Manipulace s kurzem investičních nástrojů
  • Nesplnění oznamovací povinnosti v daňovém řízení

... jelikož jsou objasněné v ~0% případů

Na úplný závěr jsme (Kebooláci) dostali od Click2Stream prasečí nohu - epický! 

Díky moc, nebejt tam kamery, asi vás obejmu :)

Ende

Hackathon byl super! Rád bych poděkoval Petrovi Ocáskovi, že celé tohle dítko vymyslel a porodil. Jídlo od Gazdinka.cz, lidi co se tam sešli, prostor Node5, vymyšlené nápady - jedním dechem paráda. Na závěr jen doufám, že nejpozdějc do roka bude další kolo! :) 

Kdo dočetl až sem, tady jsou blogposty a fotky ostatních, pokud víte o dalších, pište do komentářů, prosím.


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.