Podcast

Ahoj všem, moje jméno je Barbara Hinerová.
Já se jmenuji Šimon Podhajský. A vítáme vás u dalšího dílu Data Talku.
Našimi dnešními hosty jsou Pavel Bulovský a Vojta Kůrka z firmy Meiro.
Ahoj kluci.
Čau, zdravíme.
Ahoj.

Tak se tedy dostaneme k Meiru a k tomu, co děláte, což je CDP.
Začneme u vás, vaší historie, toho, jak jste se dostali k datům a samozřejmě k Meiru.

Tak Pavle, začneme tedy tebou. Co děláš v Meiru a jak jsi se k tomu dostal?
V Meiru mám na starosti primárně produktovou strategii a taky trochu sedím u marketingu a obchodů.
Jako ve správném startupu nosím několik klobouků.

A ta moje cesta k tomu vedla hodně velkou obchůzkou.
Ten oblouk je dost velký.
Mám maturitu ze skládání ubrousků, hotelovou školu, takže tady, když poslouchám vaše rozhovory s klukama a holkama z Jaderky, připadám si dost neadekvátně.
Ale analytika a softwareové prostředí vůbec je mou vášní až posledních asi patnáct let života.
Trochu jsem prošel obchodními rolemi, dělal jsem víc business development a mám za sebou i úplné začátky Slevomatu a nějaké mediální internetové projekty.
Můj první technologický job byla obchodní pozice, která mě zavedla i do Asie v Social Bakers, kde jsme prodávali tehdy první verzi analytického produktu.

Takže za tou cestou je velký uhlíkový otisk?
Obrovský. Myslím, že to budu odčítat tím, že budu ještě hodně dlouho sázet stromy.

Dobře, a co jsi tedy dělal v Social Bakers? Pokračoval jsi v business developmentu a práci se zákazníky, že?
Přesně tak. Na úplném začátku Social Bakers jsme zjistili, že nám chodí dost leadů z Asie, o které se nikdo nechtěl starat, protože se k tomu nechtělo někomu vstávat brzy ráno. Tak jsem se tomu postavil a začal tam hodně cestovat.
Jak firma rostla a škálovala, otevřeli jsme pobočku v Singapuru, kam jsem hodně jezdit začal a stal se tam prvním člověkem, který ji zajišťoval.

V Singapuru jsem potkal Janu Žižkovou, se kterou jsme Meiro později založili, ještě o pár let později, ale vlastně jsme se potkali v Social Bakers.
Jana vedla globálně professional services tým, který dělal nadstavbové věci pro Social Bakers.
Když se firma reorganizovala, aby se více zaměřila na softwarový produkt, odešli jsme oba s tím, že vidíme prostor pro vlastní projekty.
Typicky jsme dělali datovou konzultaci, vizualizace, tradiční BI, konsolidace dat, reportingové nástroje pro marketéry, už pod vlastní firmou.
A tam jsme přivedli Vojtu, který byl náš první oficiální zaměstnanec.

Dobře, tímto byl míček přehozený na Vojtu.
Tak Vojto, jak ses dostal k datům a k Meiru? Máš také za sebou tak velký uhlíkový otisk, že sázíš stromy, nebo…?

(Text končí.)

Ta cesta byla o hodně kratší než Pavlova, taková přímočařejší, a ten carbon footprint tam mám teda hodně nižší, protože jsem vystudoval VUT v Brně, obor Aplikovaná informatika, a vlastně rok po tom, co jsem dokončil bakaláře, jsem pracoval ve Webnode jako datový analytik. Odtamtud jsem se rovnou přesunul za Pavlem a Janou na Bali. A ten karbonový footprint tam je opravdu malý, protože to byla moje první cesta letadlem. Do té doby jsem byl jen v kanceláři, nikdy jsem neletěl letadlem, nikde jsem nebyl, a najednou během jednoho měsíce jsem pustil byt, prodal auto, rozešel se s přítelkyní, udělal si pas, dal výpověď v práci a odletěl za Pavlem na Bali. Krásná, ale překotná cesta.

No to jo. A co tě přesvědčilo k tomu, abys učinil všechna tato rozhodnutí?

Facebookový post, kde byl na obrázku týpek se surfem.

Dobře, prosím vás, ještě mi to hoďte do nějakého časového rámce, o jakém roce se bavíme?

To bylo v roce 2015. No tak tohle bylo hodně cool – mít vily na Bali a podnikání z pláže.

To jsme všichni, digitální nomádi, a teď všichni chodíme ke stejnému chiropraktikovi, protože nás bolí záda od té doby.

Dobře, takže jsme tedy v roce 2015 na Bali se surfovým prknem a tam začíná cesta Meira, je to tak? Už jste měli nějaké zákazníky, byl to už produkt, nebo k tomu se dostaneme až za chvíli?

Jo, strávili jsme přibližně tři roky tím, že jsme dělali implementační projekty. Byli jsme například partnery Kevolli v Asii, což byla také hodně mladá firma, mnohem mladší než ji dnes všichni známe jako úspěšnou datovou platformu. Dělali jsme klasické reportingové projekty, bylo to zhruba před deseti lety, takže si představte dobu kolem maturity. Měli jsme zákazníky mezi našimi marketéry, protože jsme tenhle network už s Jenou měli vybudovaný, hodně jsme využívali network, který známe ještě z historie Social Bakers. Dělali jsme různá řešení od Austrálie po Hongkong v jihovýchodní Asii, celou oblast jsme měli pokrytou a měli jsme tam jednotky projektů.

Co bylo určující, bylo to, že jsme ztratili několik zajímavých příležitostí, které vždy měly nějakou specifikaci. Jeden případ byl třeba takový, že zákazník byl semi-governmental – nějaká vládní organizace v Austrálii, kde bylo jasně dané, že musí mít datovou rezidenci v Austrálii. To u SAS nástrojů, ke kterým jsme měli přístup, typicky v SAS podobě, bylo problematické. Tyto nástroje měly data většinou uložená jen v datacentru v Evropě nebo v Americe, a to bylo vše. Nemohli jsme jednoduše spustit službu v Austrálii, v jiném cloudu – to prostě neexistovalo. Tak jsme o několik takových příležitostí přišli, což nás vedlo k tomu, že…

Tady je opravený a upravený text pro lepší srozumitelnost a plynulost:

Potřebujeme mít nějaký vlastní nástroj. Asi jsme nad tím přemýšleli jako o produktu už dřív, ale minimálně ten interní nástroj, myslím, vzniká ve spoustě agentur, které se pak pouštějí do tvorby produktů. Takže tahle motivace, tyhle dveře se trochu otevřely, a v jeden moment za námi přišel náš nejstarší zákazník, řekl bych designový zákazník, a to byla Bank of Central Asia, BCA v Indonésii. Pro představu, je to banka, která má asi 35 milionů zákazníků.

My jsme pro ně tehdy dělali nějaké pěkné vizualizace marketingových dat, pracovali jsme s marketingovým týmem, který měli v jejich velkém headquarters. Oni pak přišli s tím, že někdo z vedení byl na konferenci a potřebují „single view of customer“, tedy jednotný pohled na zákazníka – bylo to tam jako určité heslo. Tak dostali zadání vytvořit právě ten single view of customer. My jsme k tomu udělali nějaký scoping a řekli si, že je to docela univerzální problém, se kterým je obtížné se vypořádat, hlavně co se týče datové integrace.

Potřebovalo vzniknout nové prostředí, protože se tu objevovala primárně orální data z webů a aplikací, která většinou do té doby fungovala jen přes Google Analytics, a to bylo prakticky všechno. Z toho vzniklo zadání, my jsme na tom začali pracovat a řekli jsme si, že by to mohla být logická nadstavba toho, co právě začínáme budovat.

O dva roky později, když Gartner vyhlásil Customer Data Platform (CDP) jako samostatnou kategorii, a já jsem o tom četl, přišel jsem do týmu a řekl jsem: „Hele, už vím, kdo jsme. Jsme CDP, Customer Data Platform.“ Na mě pak koukali, co jsem zač, co to za další buzzword je. Ale z toho nakonec vyplynulo, že se z toho opravdu vykristal standardní typ produktu, a dneska je CDP poměrně zavedená a známá kategorie.

V tomto procesu jsme začali narážet na limity těch nástrojů, které jsme dřív používali pro stávající zákazníky jako konzultační firma. Typicky šlo o datovou rezidenci, neschopnost spustit řešení kdekoliv. U té banky to bylo jasné – kromě místní regulace, která dnes už funguje ve všech asijských zemích s nějakou variantou GDPR a datové ochrany, museli splňovat také požadavky regulátora, které jsou zde obdobou ČNB. Museli mít jasná pravidla, jak data zpracovávat, data nesměla opustit zemi ani infrastrukturu banky. My jsme tehdy neznali nástroje, které by tyhle požadavky dokázaly splnit.

Druhá rovina byla ta, že většina datových platforem je opravdu nástrojem pro datové inženýry a analytiky, a bez znalosti SQL tam člověk nic neudělá.

My na to koukáme tak, že náš hlavní uživatel je byznysový člověk, marketér, který dělá kampaně, nebo člověk z týmu CRM, který komunikuje se zákazníky – a ten nemá technickou kapacitu na to, aby zvládal dataové nástroje vyžadující programování. Proto CDP jako nástroj by měl být…

Pokud chceš, mohu pokračovat dále nebo text ještě víc formálněji upravit.

Takovej prostě most mezi těma dvěma odděleníma, co nutně potřebuje mluvit s oběma, aby jsme v těch nástrojích té doby tohleto vůbec neviděli. Není běžné, že by si analytický nebo byznysový člověk chodil dělat query do datového skladu. To se prostě neděje a nikdy se to dít nebude. Uvědomění si tohohle vám hodně pomohla ta asijská provenience. Co dalšího jste si uvědomili díky tomu, že jste nezačínali stereotypně v Praze?

No, my jsme vlastně šli úplně opačným modelem, protože typicky ty velké technologické startupy, scale-upy, pocházejí spíš z Ameriky než z Evropy a často mají vývoj východně, když už jsou dost velké – v Indii, Vietnamu, ve velkých developerských centrech. A my jsme vlastně šli úplně opačnou cestou. Logika byla jednoduchá: žijeme v Asii, máme tady nějakou síť, kterou budujeme, která má byznysovou hodnotu, protože prostě potřebujeme zákazníky. Mám takovou tezi, že dělat dobrý produkt je dneska hodně jednoduchý, ale složitá je distribuce a prodej, teda najít zákazníka, ještě víc než dřív.

A my jsme šli takovou cestou, že jsme se podívali na to, co Gartner popsal jako CDP, a koukli jsme se, kde všichni vendory, kteří se do té kategorie přihlásili, jsou. Udělali jsme si takové vlaječky po světě a zjistili jsme, že 70 % z nich je v Americe, pár je v Evropě, jeden je v Indii a v jihovýchodní Asii, v Austrálii, nikdo nebo jenom jeden další. Takže jsme se zaměřili spíš na trhy, které jsou prázdné, kde nemusíme soupeřit třeba s Adobe nebo Salesforce, což děláme všude jinde. Proč tedy začít tam, kde to půjde s nejmenším odporem?

Zlomový bod, kdy jsme začali dělat ten produkt – CDP, byl kdy? Když si vzpomínám, byl to duben 2017. Seděli jsme na břehu řeky v Melbourne, na lavičce, bylo už takové podzimní počasí v Austrálii v dubnu, a tehdy jsme vymysleli jméno. Já si to úplně nepamatuju, moje časová osa začíná a končí tím, že jsme vyhráli Nagano, a od té doby ani před tím nevím nic.

No, tedy 2017, a přesně to bylo definované zákazníkem, který za námi přišel a říkal: „Potřebujeme udělat single view of customer,“ což prostě znamenalo, že přinesl byznysový use case. My jsme předtím jen dělali nějakou back-endovou aplikaci pro zpracování dat. Chyběl ten konkrétní use case, a tenhle zákazník nám ho přinesl. Byl to rozhodně zlomový moment.

Dobře, můžeš vysvětlit – začali jsme tady mluvit o Gartneru, o CDP a co to vlastně dnes znamená? Co to je?

No, CDP, tedy Customer Data Platform, je kategorie, která se jako všechny kategorie v marketingových a datových technologiích dost komplikují, protože všechno je dnes platforma, která se rozšiřuje. Dá se to jednoduchým jazykem popsat tak, že…

Zde je opravený a stylisticky upravený text:

Je známo, že CDP v podstatě kombinuje data o chování zákazníka. Můžete si to představit jako datový sklad, který je ale specializovaný na jediný objekt – zákazníka. Typicky se vůči těmto řešením musíme vymezovat tím, že nehodláme ve firmách nahrazovat datové sklady, protože tyto nástroje jsou designovány pro jiný use case.

Takže máme zákaznická data, která se typicky sbírají z behaviorálních zdrojů – hodně z webu a mobilních aplikací, kde dokážeme změřit každý klik uživatele. Dále jsou to veškeré marketingové kampaně, na které zákazníka cíleně oslovujeme, a sledujeme, jak na ně reaguje, případně nereaguje, protože vše poskytuje různé signály. Samozřejmě pak existují i nějaká transakční data nebo chování přímo v produktech.

Problém je, že si říkáme, že to může být jasný případ datové integrace – nějaké pipeline, které data nalijí do datového skladu, najdou jeden společný klíč v těch datech, vytvoří tabulku se zákazníky a dokážou je popsat. Ale je tam několik komplikací, které to značně ztěžují. Jednou z nich je fakt, že zákazník se v různých touchpointech firmy autentizuje nebo neautentizuje různými klíči. Můžete volat do call centra banky ze svého telefonu, do aplikace se přihlašujete na jiném zařízení přes uživatelské ID nebo e-mail, a na veřejném webu můžete být i bez přihlášení. Tohle jsou věci, které celý problém stěžují.

Jak se vám tedy daří tento problém řešit?

Děkuji za super otázku, která dobře zapadá do našeho tématu. Myslím, že se nám to daří řešit poměrně dobře. Možná to ale ještě trochu vztáhnu ke kategorii jako celku, protože se mi trochu vymkla původní otázka.

Kategorie CDP jako taková je totiž vícvrstevnatá a existují zde téměř dvě strany spektra. Na jedné straně jsou nástroje spíše zaměřené na marketingovou automatizaci, kterým se dnes často říká Customer Engagement Platforms (CEP). Tyto nástroje typicky dělají věci jako e-mailing v Evropě nebo notifikace a interakci v mobilních aplikacích například v Asii a na Středním východě.

Na druhé straně jsou nástroje zaměřené na real-time engagement, které však často bývají slabší v oblasti datové integrace. Tyto nástroje nejsou schopné přijímat data v libovolném formátu a vyžadují poměrně pečlivou přípravu dat před jejich zpracováním, což v našem případě není ideální.

Navíc dnes existují nástroje přímo postavené nad datovými sklady, například Snowflake, který říká: „CDP si dnes postavíte sami.“ Je to vlastně datový model nad datovým skladem, který si takto sestavíte a podle toho vám funguje.

Problém je, že takové řešení neřeší přístup koncových byznysových uživatelů – ti nemají přímý přístup do datového skladu a chybí jim jednoduché uživatelské rozhraní. Dá se říci, že tam má ten systém všechno, ale „chybí mu kola,“ tedy to, co by umožnilo byznysovým uživatelům s daty efektivně pracovat.

Pokud potřebujete text dále zjednodušit nebo zvýraznit určité části, rád pomohu.

Jasně, tady je opravený text s lepší gramatikou, interpunkcí a stylizací pro srozumitelnost:

Ano, ale chybí tam dveře. Tak to jsou takové ty jiné přístupy. My to řešíme spíš víc full stack přístupem, že máme v tom produktu dvě perzóny – díváme se na to, co tam dělá datový inženýr, analytik a co tam dělá ten byznysový uživatel, u kterého typicky předpokládáme, že vůbec neumí žádný programovací ani dotazovací jazyk na data. A nečekáme to od něj. To je správný předpoklad určitě.

Nicméně mluvíme tady o řešení, které je na konci toho procesu, ale zmínili jsme vznik v Asii a práci se zákaznickými daty, což je samo o sobě velmi rozdílné podle zemí, a vy to musíte nějakým způsobem řešit. Je to tak, že když jdu do Austrálie, musím si prostě nastudovat legislativu a zjistit, jaká všechna data tam musím zpracovávat. V Hongkongu je to zase něco jiného, v Singapuru něco dalšího, pak se vrátím zpátky domů a tady je zase ta GDPR apokalypsa.

Jak těžké bylo vlastně podchytit toto? Zdá se, že všechny ty různé legislativy jsou pro každou zemí jiné, ale z technického pohledu, jak se k těm datům chováme, jsou principy vlastně dost podobné, protože všichni hodně opisují od GDPR. To znamená právo být zapomenutý, právo dát souhlas ke zpracování dat, datová lokalizace, safe harbour – tyto principy se opakují velmi podobně. Takže když člověk je po tom compliance tou nejpřísnější metodologií, je to potom docela jednoduché.

Ale dostat se k tomu nejpřísnějšímu přístupu, hlavně co se týče lokalizace dat, je technicky docela složité, protože vznikají požadavky, abychom měli data ideálně u sebe nebo v nějakém cloudu, který je v dané zemi a provozovatelem daného cloudového providera. Začínáme být limitovaní technickou stránkou a kvůli roztříštěnosti cloudů, protože všechny ty cloudy mají hodně datacenter – v Americe je jedno, jestli je to US East nebo US West, v Evropě všichni hostují ve Frankfurtu, což je docela obvyklé.

Ale v Asii je to jiné – jednou se koukáme do Hongkongu, jindy do Singapuru, někdo chce data v Jakartě, jiný v Sydney. Už to začíná být zajímavější, protože jsou tam různý providery – například v Kazachstánu není žádný velký hyperscaler. To velmi ovlivňuje stavbu produktu a jeho architekturu, která musí být dostatečně obecná, aby se dala provozovat kdekoli.

Takže právo samo o sobě není tak velkou překážkou jako geografie. Přesně tak, myslím si, že právo je takové, jak všichni navzájem opisují – není moc co vymýšlet, stejně jako u webového trackingu, kde mají všichni skoro stejné SDK, jen se to teď trošku jinak jmenuje. Takže mi přijde, že to funguje podobně i u PDP (Personal Data Protection) – ať už v Singapuru, u objektů v Indonésii nebo u GDPR tady v Evropě. Je to pořád to samé, akorát se to jinak jmenuje.

Pokud chceš, můžu text upravit ještě víc do formálnější podoby nebo naopak neformálně. Dej vědět!

Zde je opravený a upravený text s lepší čitelností a interpunkcí:

Povinnosti tam jsou dost podobné. Nej přísnější je tady GDPR, nebo se Singapuru zase podařilo přidat něco navíc? Nejpřísnější je určitě GDPR, konkrétně v Německu pak ještě víc. Tam je regulace ještě trochu složitější. Myslím, že to není ani otázka legality, to je jenom jedna vrstva.

Myslím, že možná mě Vojta může doplnit, ale je to hodně i o technologickém vybavení. Typický zákazník v Asii vypadá hodně jinak než v Evropě, nebo než víme, že vypadá v Evropě. A je tam ještě dramatický rozdíl mezi tím, jak vypadá infrastrukturně či architektonicky zákazník třeba v Americe, kde je dneska prakticky všechno cloud first. My ale máme hodně implementací, které se dělají on-premise, například tady v Česku v jedné z největších bank, nebo také v Indonésii, kterou už Vojta zmiňoval.

Myslím, že stojí za to se podívat na detaily architektonického nastavení těch zákazníků, protože technologie tam často bývají výrazně starší, a my na to jako produkt musíme hodně myslet.

Jsem teď trochu zmatený, protože mluvíme zároveň o hyperscalerech a jejich datových centrech, ale i o on-premise instalacích. Znamená to, že děláte věci ve virtual private cloudech, nebo něco napůl? To je právě to, o čem jsem mluvil. Ze začátku jsme chtěli jít trochu proti proudu, mít nějaký buzzword bingo, unique selling proposition, být něčím jiní. Protože konkurovat ve stejném prostředí a s úplně stejnými funkcionalitami americké firmě prostě nemá smysl — na to nemáme ani zdroje, ani finance, ani nic jiného. Snažili jsme se tedy přinést na trh něco, co tam ještě nebylo, co jsme viděli, že chybí.

Je to složitý, ale klasická poučka je, že to děláte, protože jste nevěděli, že to bude složité — tedy navrhnout produkt tak, aby běžel skutečně kdekoliv. To znamená, ať už je to třeba indonéský cloud, respektive indonéské on-premise — tam jsme doslova přišli s USB flashdiskem, s docker imagery, připojili jsme je do serveru a tam jsme je nahráli.

Potřebujeme tedy, aby to fungovalo takto a zároveň jsme schopni deploynout do Google Cloudu, AWS, Azure, nebo kamkoliv jinam. Není to jednoduchý problém, že? Jak to teda máte vyřešené? Jaké jsou základy, principy, které umožňují to, že to běží jak s flashdiskem, tak v cloudu?

Disketou to úplně nepoběží, ale cokoli od flashdisku dál ano. Celý produkt jsme od začátku navrhovali tak, aby byl single instance — tedy jeden zákazník má celý vlastní stack a je to jeho. Toto je oddělené už na úrovni infrastruktury.

Kdybyste si vzali nějaký průměrný americký startup CDP, tak ten si vy…

Pokud chcete, mohu pokračovat případně s opravou i další části textu.

Opravený text:

Bere jeden velký cloud, vybere si buď Azure, AWS nebo GCP a začne to skládat jako puzzle z jejich vlastně manažovaných služeb. To znamená nějakou S3, nějaké BigQuery, Snowflake nebo něco pro udržení dat, nějaké SQS pro message queue a celé si to propojí jako pár drátků. Pěkný moderní data stack prostě. Jasně, funguje to a je to super rychlé na vývoj, ale člověk se už z toho cloudu potom nepohybuje. Už to nemá možnost vzít a takhle to nasadit na on-premise.

Takže my jsme museli tohle celé odstřihnout. Nepoužíváme jen jednu službu od těch velkých cloudů a celé jsme to postavili vlastně nad opensourcovými nástroji, které jsme poskládali dohromady tak, aby to fungovalo. To znamená, že už od začátku bylo srdcem celého toho stacku PostgreSQL, se kterou máme skvělé zkušenosti. Potom jsme měli trošku horší zkušenosti a pak zase dobré, ale od začátku to byl vlastně ten core.

Kolem toho jsme začali už v roce 2017, když jsme to začali vyvíjet, vše dělat v Dockeru. Ten měl tehdy ještě hodně much, ale ušel velkou cestu a v té době to bylo ještě hodně experimentální. Přineslo nám to ale možnost vzít si image a spustit je vlastně na jakémkoliv VPS. Celý kód je napsaný v kombinaci Pythonu a Go. Máme tam v kontejnerech zabalené RabbitMQ, nějaký Redis, webové servery, Nginx na servírování dat a celé to komunikujeme s PostgreSQL, která běží na pozadí.

Díky tomu, že jsme použili jen technologie, které umíme zavřít do kontejnerů a umíme je rozběhnout buď pomocí Docker Compose, nebo Kubernetes s nějakými úpravami, nám to umožnilo, že to můžeme nasadit prakticky kamkoliv. Jdeme tak daleko, že i na on-premise instance si dokážeme nainstalovat vlastní sběr logů – běží tam například Grafana s Lokim, který sbírá nejen logy, ale i telemetrii, a pomocí lokálního SMTP zasíláme alertovací e-maily, monitorujeme systém a podobně.

Opravdu tak dokážu vzít celou kompozici, celý produkt, nasadit ho na nějaký server a provozovat si to. To je asi náš největší argument.

Máme například na Filipínách jednu finanční instituci, která má instanci běžící bez přístupu k internetu. To znamená, že tam opravdu pošleme image, oni nám je zkontrolují, nahrají na server a tam – přes vzdálenou plochu v demilitarizované zóně – běží naše řešení a zpracovává data.

Zajímavé, fascinující, velmi fascinující. No, ale tam se potom docela blbě řeší nějaká údržba, když to máš úplně někde…

Rozhodně, je to složitější než kdyby byl nějaký výkladek, o kterém víme díky monitoringu. V běžné situaci to buď cloud vyřeší sám, nebo člověk prostě přes SSH přistoupí na server a něco opraví. My máme s ně…

Zde je opravený text s lepší srozumitelností, pravopisnou a gramatickou úpravou:

Kterými klienty přistupujeme i na on-premise řešení, buď pomocí nějaké webové platformy, vzdálené plochy nebo čehokoliv jiného. Ale máme i klienty, kteří to spravují úplně sami. My tomu trošku říkáme „indonéská vzdálená plocha“, protože máme v bance člověka, ke kterému nemáme přímý přístup na servery, protože jsou uvnitř banky. Takže tam máme vlastně kolegu z Indonésie, který v bance fyzicky sedí – myslím kolegu jako zaměstnance banky, ne našeho kolegu. Vždycky mu přes WhatsApp napíšeme příkaz, který má pustit, on ho spustí, vyfotí nám to telefonem a pošle zpátky ve WhatsAppu.

To zní skvěle. Jak se bráníte peklu mnoha verzí? Protože předpokládám, že všechny ty sestavy mají svoje vlastní verze a možná nechtějí aktualizovat to, co už funguje, ale i tak je musíte podporovat.

Super otázka. V podstatě máme jen jednu verzi produktu. Už jsme se v minulosti, před většími upgrady (Majorem), naučili, že dělat více verzí z téhož produktu a začít to verzovat různě, je cesta do pekla. Člověk už nikdy nic pořádně netestuje ani neupgraduje. Aplikace je napsaná tak, aby jádro (core) bylo vždy stejné pro všechny. Máme podobně jako Ubuntu nějaké LTS verze, k tomu minor a major verze. Díky tomu jsme schopni distribuovat aktualizace docela jednoduše. Ve výsledku je to úplná pohoda, protože vždycky, kde nemáme přístup, pošleme notifikaci přes WhatsApp s changelogem klientovi. Ten si to přečte, prověří image bezpečnostním scanem a jedním příkazem je schopný aktualizovat jen ty image, které potřebuje.

Cesta, jak jsme se dostali k tomu, že máme jen jednu verzi produktu, vede přes konfiguraci. Ať už mluvíme například o identity resolution – o kterém se budeme bavit ještě za chvíli –, či o jakémkoliv přizpůsobení produktu, vše se děje prostřednictvím konfigurace přímo v produktu, nastavováním pravidel, definicí atributů, které z dat získáváme, nastavováním destinací segmentů, journey canvasů a podobně. Máme tedy všude stejné jádro a mění se jen konfigurace pro konkrétního klienta, která se provádí z uživatelského rozhraní.

A co se týče byznysové stránky – chceme mít MRR (měsíční opakovaný příjem), tedy pravidelné platby každý měsíc. U tohoto modelu, kde nabízíme i možnosti on-premise, to není úplně jednoduché. Jak tedy funguje tato stránka?

Úplně stejně. Máme roční licence, předplatné – subscription. Oddělujeme hosting jako takový, resp. delivery model. Protože zákazník s on-premise řešením bude chtít pravděpodobně jiné SLA a podporu než zákazník, který nechce spravovat infrastrukturu a chce ji od nás kompletně.

To je jedna z velkých výhod – že toto umíme dobře oddělit. Když to zkusím shrnout do jedné věty: proč to…

Pokud chcete, mohu pomoci i s pokračováním či dalšími úpravami.

Zde je opravený text:

To, co tady děláme, je proto, že vsázíme na to, že celá ta oblast ochrany dat (data privacy) a podobné věci vlastně nejsou úplně o spotřebiteli samotném, ale spíš na to koukám z pohledu enterprise nebo mého stakeholdera, tedy toho, co chce CTO. Myslím si, že základní princip je, že řešení navrhujeme tak, abychom přinášeli workload přímo tam, kde jsou zákaznická data nebo data mého zákazníka, aby s nimi oni nemuseli nijak manipulovat, a my tak nevyváželi jejich data na infrastrukturu naší společnosti. Tohle je podle mě největší problém jak z pohledu compliance, tak bezpečnosti a kontroly jako takové.

Zažili jsme několik situací — nemůžu úplně detailně rozvádět, kdo byli vendory — ale byly i docela kuriózní momenty například u SaaS aplikací. Jeden klient, který měl opravdu velké množství dat na lokální středo-evropské poměry, používal SaaS nástroj, který byl však navržený pro zákazníky s daty třeba setinových velikostí. To nevadilo při samotném používání produktu, ale například při exportu dat už ano. Upload dat do produktu byl denně větší než maximální možný offload do jejich vlastního datového skladu, takže nikdy neměli možnost mít všechna svá data fyzicky na jednom místě – tedy dokud tento produkt používali. Data byla vlastně „zamčená“ v produktu, což vedlo k situaci, kterou nemůže schválit žádný data officer nebo bezpečnostní expert, pokud trochu zvažují rizika.

My si myslíme, že zákaznická data jsou u klientů tím nejcennějším, co je potřeba chránit a ze čeho těžit. Posílat je všem možným vendorům kam se jim chce není podle nás nejlepší strategie. A proto to děláme takhle.

Když už jsme u těch zákaznických dat, prošli jsme infrastrukturu, kde ta data jsou a na čem je založená. Možná se teď podíváme na datové zdroje od zákazníků, kteří ta data zpracovávají. Zkusím to popsat na typickém příkladu.

Třeba ta indonéská banka, kterou jsme tu zmínili. Je to klasická retailová banka, takže má běžné účty, k nimž zákazníci přistupují z několika zařízení, a spoustu produktů – kreditní karty, půjčky, spoření a podobně. Celkem má asi 25 různých portfolií těchto produktů. Banka má něco jako devět webových stránek – základní marketingovou stránku, kde zákazník vidí, co dostane k běžnému účtu či jinému produktu, a další stránky a aplikace, například program věrnostních bodů, kde si zákazník může přečíst, jak může body vyměnit za odměny spojené se službami banky, atd.

Pokud chceš, mohu celý text upravit i dále. Stačí říct.

Jasně, tady je opravený a trochu upravený text, aby byl srozumitelnější, plynulejší a formálnější:

Nějaký dárek nebo tak něco. No a pak jsou tam takové ty zabezpečené aplikace typu internetové bankovnictví, mobilní aplikace, do kterých se přihlašuje. Náš klient má nějakých 5–6 mobilních aplikací a asi 9 webů, které trackujeme. A to je první složitá věc – poznat zákazníka napříč všemi těmi kanály, zejména tam, kde se zákazník neautentikuje. To znamená na veřejných webech, které jsou obrovským zdrojem informací. Když například víte, že mám debetní kartu a základní účet, ale na webu už pravidelně sleduji nabídku kreditních karet, mohli byste mi ji v mobilní aplikaci nabídnout. Vidíte totiž, že tam jsem.

Je spousta našich zákazníků, se kterými začínáme pracovat, a zatím v tomhle směru vůbec nic nedělají, což znamená, že data jsou úplně odpojená – fungují v silu. Nikdo nepřemýšlí o tom, že by se dala nějak propojit. A to tam samozřejmě jsou i další systémy, například transakční systémy nebo CRM, které mají nějakou interpretaci dat. Často spolupracujeme s nástroji kampaní, jako jsou Salesforce, Marketing Studio, v Česku Smart Emailing, Gemelk a další platformy, na které lze poslat nějakou kampaň od zákazníka nebo na zákazníka. Tyto signály umíme skvěle využít.

Stejně tak callcentra, kde je spousta interakcí s klientem. V ideálním případě chcete všechna tato data dát na jedno místo.

Vy tam ještě doplňujete?
Ano, právě to kouzelné slovo „dát to na jedno místo“ představuje technickou výzvu, která je velmi zajímavá. Co Pavel vyjmenoval – weby, mobilní aplikace – tam je to ještě poměrně snadné. Hodí se SDK, data dostanete v hezkém formátu prostřednictvím nějakého collection endpointu, zpracujete je, obohatíte geolokací z IP adresy, poznáte zařízení, všechno v pohodě – dělají to skoro všichni.

Kde to začíná být zajímavé, je druhý level, tedy smart emailingy, mailkity a další platformy, které nám mohou odesílat webové události tak, abychom se v reálném čase dozvěděli, že někdo někomu poslal zprávu, dokázali na to zareagovat, nebo že někdo něco otevřel a podobně. To je stále relativně zvládnutelné integrační platformami.

Největší výzva ale začíná u takzvaných in-house systémů – typicky Microsoft SQL verze 2016, která ještě ani nepodporuje plně UTF, a v nichž mají dlouhou historii dat, ke kterým průběžně přidávají další. Nemají data v hezkém formátu a ID jsou často rozházená, nesourodá. Když se pak dostaneme k integraci těchto zdrojů, kde jsou nejdelší a nejhodnotnější data, je potřeba data předat do mixu a zároveň díky algoritmu pro řešení identity (Identity Resolution) poznat jednoho zákazníka napříč různými datovými zdroji, ať už jde o mobilní aplikaci, nebo jiné systémy.

Pokud chcete, mohu vám text upravit i stylisticky do konkrétního tónu nebo formy.

Jasně, tady je opravená a lehce upravená verze tvého textu pro lepší srozumitelnost a plynulost:

Jednoduchý mailkit, e-mailová adresa super, a najednou se objeví interní ID a nějaké číselníky. Začíná to být docela zábava vytvořit ten graf identifikátorů o zákazníkovi a správně pospojovat data ze všech zdrojů tak, aby byla relevantní a dalo se na ně nějakým způsobem navázat – například triggery na komunikaci, personalizaci stránky nebo cokoliv jiného. Jde vlastně o aktivaci těch dat a získání z nich hodnoty.

Chceš jít do hloubky, jak ten graf tvoříme? Identity resolution je jeden z hlavních pilířů CDP. Pokud se podíváme na definici CDP od CDP Institute, říkají, že CDP by mělo být schopné permanentně ukládat data, následně je rozpoznat díky identity resolution, uložit si jednotný identifikátor zákaznické entity a potom segmentovat a dělat další věci.

Identity resolution algoritmus je velmi zajímavý na implementaci, protože není složitý. Jako u všech věcí, na první pohled vypadá jednoduše, a právě proto například Snowflake nebo BigQuery – i když je někteří lidé označují jako CDP – ve skutečnosti těžko zvládnou vytvořit skutečné CDP. Problém identity resolution totiž vychází z dat generovaných lidmi a zároveň představuje grafový problém. To jsou dvě vlastnosti, které výrazně ovlivňují výkon a spolehlivost algoritmu.

Za prvé, jelikož jde o grafový algoritmus, spousta CDP vendorů – našich konkurentů – to řeší pomocí hard a soft ID. Například e-mailová adresa je brána jako hard ID – jedinečný identifikátor zákazníka. Ale člověk má často víc e-mailových adres, několik osobních i pracovních, a někdy si chce nakoupit pod jinou adresou, než osobní. Takhle to ale úplně nefunguje a neodráží to realitu.

Proto je potřeba vytvořit graf identifikátorů, který zapojí nejen e-mailové adresy, telefonní čísla, ale také interní CRM ID, user ID z interních systémů, first party cookies, ID z mobilních aplikací a podobně. Problém je, že ne všechny tyto identifikátory jsou stejně unikátní a stejně snadno identifikovatelné. Máme klienta, kde v jednom prohlížeči na prodejně prodejce nakupuje za zákazníky, takže first party cookie nemůže tyto objednávky spojit dohromady. To jsme také museli řešit.

Celkově jde tedy o graf identifikátorů, který musí mít pravidla jako whitelisting, blacklisting, frequency capping a priority jednotlivých identifikátorů. To všechno musíme do grafu zapojit.

Druhá, zajímavější věc na celém problému je škálovatelnost algoritmu. Není to jen o tom, že algoritmus přijme a zprocesuje pár událostí, ale…

Kdybys chtěl, můžu ti pomoci i s další částí textu nebo grafické znázornění toho problémového modelu, dej vědět!

Tady je opravený a upravený text:

Zpracovat jednu událost za sekundu, dejme tomu deset, je úplně jednoduché — tam Python nebo Píčko něco udělají a je to v pohodě. Ale když se bavíme o klientech, kteří mají třeba dva, tři, čtyři tisíce událostí za sekundu, začínají vznikat problémy.

Když si vezmeme například Notion — vím, že teď trochu uskakuju, ale vydržte — Notion, když si založíte účet a svůj workspace, vlastně obsluhuje půlku planety. A když si založím účet, Notion ví, že když tam pošlu nějaký request, uložím si nějakou tabulku nebo začnu psát článek, tak moje data z mého workspace mohou být fyzicky uložena na jednom konkrétním serveru. Těch serverů mají třeba 128, ale když přijdu jako přihlášený uživatel, vědí, že všechny moje requesty budou směřovat na ten jeden konkrétní server.

Teď se to pokusím přenést na problematiku Identity Resolution, kde, jak jsem říkal, data jsou generovaná lidmi. Když přijde událost, může obsahovat několik identifikátorů, například first-party cookie, e-mail, telefonní číslo a podobně. Může se stát, že mám anonymní historii na webu — například s čistým prohlížečem přijdu na web Heuréky a začnu tam něco vyhledávat. Dokud se nepřihlásím, což obvykle dělám až v posledním kroku nákupu, mám teda anonymní profil. Nemám žádný identifikátor, kterým bych to mohl propojit s Vojtou, kterého Heuréka už zná, protože tam pravidelně nakupuju. Tím vznikne anonymní profil. Až když se na konci objednávky přihlásím – například kvůli jednoduššímu uložení karty – potřebuju tyto dvě entity propojit, tedy merge je, sloučit do jedné. Nikdy ale předem nevím, které entity přesně to budou — dvě, tři, nebo třeba čtyři. Proto musím mít k dispozici celou databázi entit a musím řešit konflikty, protože události nemůžu zpracovávat úplně po jedné za sebou, ale chci je zpracovávat i paralelně, abych zvládl těch několik tisíc událostí za sekundu.

Když mám zpracování dvou, tří, čtyř eventů najednou a všechny zasahují do stejné entity, začíná to být opravdu velký problém.

Jak se tedy stalo, že tenhle komplexní grafový problém řešíte nad negrafovou databází?

Právě kvůli výkonnosti, kvůli operacím a kvůli vývoji. Ta výkonnost — i když se jedná o grafový problém, samotné grafy jsou relativně malé, graf identifikátorů má většinou jen desítky uzlů. To není obrovské množství dat a SQL s rekurzivními Common Table Expressions (CTE) je na to perfektně vybavený. Když si nastavím dobrý datový model, není problém to spočítat a uložit.

Co je skvělé na relačních databázích je, že mají velmi dobře vyřešený konkurenční přístup k řádkům, které reprezentují entity. Pracuje se zde s izolacemi transakcí, například v Postgresu máme read committed, repeatable read, serializable isolations a tak dále. Díky tomu nemusím vůbec opouštět relační databázi.

Pokud potřebujete ještě nějaké úpravy nebo zvýraznění, dejte vědět!

Opravený text:

Bázi můžu využít díky dekádám vývoje, kterými Postgres prošel, a můžu použít všechno, co oni mají. Můžu říct například: tady mám nějakou sadu queries, které vyhodnocují identitu, a když narazíš na konflikt, tak se s tím vypořádej. Implementovat distribuovaný systém je totiž věc, která vypadá jednoduše, ale je šíleně náročná. Proto jsme nechtěli implementovat vlastní distribuovaný systém, který by to nějakým způsobem dopočítal. Jsme tedy zavření v rámci Postgresu a necháváme jeho, ať za nás tu práci udělá a vyřeší konflikty.

Což mě připomíná, že vlastně už Postgres nepoužíváme. Jak se to stalo? Na začátku jsem říkal, že používáme Postgres jako databázi, ve které máme všechno. To byla pravda ještě před dvěma lety. Dnes je to zase pravda, ale jen jako možnost. Protože jsme zjistili, že Postgres je sice skvělý, ale začíná mít problém od určité velikosti. Když začneme škálovat až na miliardy řádků v databázi a terabyty dat, už to přestane stíhat.

Postgres umí škálovat jen do výšky, případně do šířky – to znamená, že lze použít read repliky, ale write node je pořád jen jeden. To je komplikované a zároveň udržovat high availability na Postgresu je strašně náročné, proto jsou manažované databáze. Místo toho jsme tedy zmigrovali na CockroachDB, která je skvělá, protože zvenku vypadá jako Postgres, ale je to distribuovaná databáze, která je masterless. Má zabudovanou high availability i vysokou spolehlivost, takže dokáže data replikovat. Máme klustery, které uchovávají desítky až stovky terabajtů dat a běží velmi dobře, v podstatě bez potřeby zásahů. Když nám třeba spadne jeden nebo dva servery z klastru, nic se neděje, opravíme je, připojí se zpátky a je to zero downtime, což je velká výhoda.

K tomu všemu jsme také předali OpenSearch, dříve Elasticsearch. Jen krátce k tomu: na začátku jsme Postgres používali na transakční payload, tedy přijde událost, upravím entitu, něco se zmerguje, někde se něco aktualizuje, něco dopočítá – to je v pohodě. Ale ve chvíli, kdy zákazník, jak říkal Pavel, třeba marketér, chce v uživatelském prostředí vytvořit segment a říct: „Dej mi všechny lidi, kteří byli na mém webu za posledních sedm dní z iPhonu, někdy mezi šestou a osmou večer,“ musíme projít všechny zákazníky a zkontrolovat právě tyto atributy – že tam byli několikrát v danou dobu z daného zařízení – a vybrat všechny, kteří to splňují.

Na takové analýzy je Postgres nevhodný, protože je to transakční databáze, ne analytická. Proto jsme udělali menší „výlet“ k jiné databázi… (pokračování chybí)

Opravený text:

Databáze, ten Postgres, to úplně nebude, tak jsme si říkali: „Hele, nebudeme chtít úplně tříštit tu technologii a radši půjdeme vlastně do něčeho podobného, ale sloupcově orientovaného, protože ty atributy máme uložené jako sloupce u těch entit.“ Takže jsme si vybrali MonetDB a tam jsme udělali – já jsem udělal chybu v tom, že jsme neprovedli dostatečně dobrou due diligence, to znamená, nepodívali jsme se na reference, kde to běží v produkci. Je to výborný projekt, ale je to projekt spíš studentský, akademický, myslím, že pochází ze zemí. A podle toho to taky vypadá – buggy se opravují jenom, když je semestr. Databáze, která ztrácí data, není úplně dobrá databáze, a já jsem tam jenom vygeneroval asi pět GitHub issues, kdy jsem to dokázal shodit, takže vlastně databáze přestala fungovat. Takže vlastně to byl ztracený rok mého spánku, kdy jsem se fakt nevyspal, nic nefungovalo, nic se nenapočítávalo.

A pak nám došla trpělivost, začali jsme se koukat znovu. A k našemu překvapení na to strašně dobře funguje vlastně Elasticsearch a jeho pozdější fork OpenSearch, protože i když to člověk má nějakým způsobem zakategorizované jako fulltextovou databázi, tak vlastně když z toho člověk odstraní ty fulltextové funkce, je to strašně dobrá databáze na vyhodnocování právě podmínek a získávání subsetu těch dokumentů z celého indexu. Takže vlastně ten Lucene invertovaný index je strašně rychlý na to.

Jsme díky tomu schopni, že data nejdřív napočítáme v Postgresu, respektive v CockroachDB, a potom si je v reálném čase zaindexujeme v Elastiku. Tam používáme operátory na podmínky, takže jsme schopni napočítat segmenty i na stovkách milionů entit během milisekund, a následně pak exportovat v řádu sekund až minut, kdy třeba exportujeme dva a půl tisíce segmentů nad databází stovek milionů entit denně u klientů. Takže nám to zjednodušilo práci.

Trochu to může znít tak, že u každého klienta instalujete takovou malou Snowflake, kterou máte namyšlenou sami, a to je hrozně složitý problém. Díky za tohle vysvětlení.

Ještě možná takový malý komentář, protože tady mluvíme o open source technologiích. Pokud nás poslouchá někdo, kdo staví produkty okolo těchto věcí a chce používat různé komponenty, které jsme zmínili – Cockroach, Elastic nebo i Docker – všichni v posledních dvanácti měsících výrazně mění licenční podmínky a tyto nástroje už nebudou úplně použitelné stejným způsobem do budoucna. Cockroach má zajímavost, že začíná částečně účtovat podle ročního obratu firmy, a jsou tam i jiné záludnosti. Takže pokud chcete na těchto technologiích stavět produkty, když tady posloucháte Vojtu, bacha na to.

Je to dvousečná zbraň, protože Cockroach začínal jako open source community verze a enterprise verze, přičemž stanovili docela zajímavé rozdělení funkcí. Zjistili, že to hodně lidí používá v komunitě a téměř nikdo v enterprise… [text končí]

Zde je opravený text s lepší srozumitelností a gramatikou:

Když měl docela dost financování od investorů, tak od určité verze už nemohou změny provádět retrospektivně, což je fajn. Ale zároveň od určité verze ruší komunitní verzi, takže vše bude placené, a proto už to není tak atraktivní. Na druhou stranu, před pár lety, myslím, že to bylo před čtyřmi lety, Elasticsearch upravil svou licenci, aby omezil přeprodávání Amazonem, který jejich službu hostoval a vydělával na tom obrovské peníze. Elasticsearch chtěl totiž postavit vlastní cloud. Proto změnili licenci, podobně jako teď dělá Kokroče. Ale před pár týdny Elasticsearch oznámil návrat k open source licenci. Takže je to takový cyklus, který si myslím bude pokračovat. Ale ten Kokroče mě mrzí.

Ano, nikdy nevíš, kdo chce vytáhnout jaké peníze, zvláště když jsou tam investoři.

Přesně tak. Dobře, to, co jsi říkal, zní jako velmi náročný problém, který zaměstná hodně lidí, aby technicky něco takového dokázali podchytit.

A my vlastně teď vůbec nevíme, kolik vás je v Meiru a kdo jste za lidi. Asi máte hodně databázových expertů a vývojářů?

Řekněte nám něco o složení týmu.

My to vlastně ani úplně nevíme, protože se to dost rychle mění. Nyní je nás kolem pětašedesáti. Jak jsme zmínili na začátku, začali jsme v Asii, kde jsme nechali obchodní tým. Tam jsem byl já s Janou a pár dalších lidí, kteří dělali zákaznické služby a prodeje. Po pár letech se Vojta přestěhoval zpátky do Brna, kde jsme založili vývojový tým, který je dnes pochopitelně distribuovaný mnohem víc. Takto jsme fungovali asi čtyři roky.

Tým má v podstatě tři základní části – zákaznické služby a prodej, implementační služby a vývoj.

Zákaznické služby a prodej nyní výrazně škálujeme, zejména v letošním roce. Jinak jsme celý sales dělali až do teď s minimální podporou, spíš my zakladatelé.

Implementační služby jsou u nás relativně malé, tvoří je typicky projekťáci, account manageři a techničtější account manageři. Vedle toho máme tým datových analytiků a inženýrů, kteří pomáhají zákazníkům konfigurovat a implementovat řešení. Tuto část ale v posledních letech moc neškálujeme, spíše se snažíme tyto kompetence předat partnerům.

Děláme produkt hodně partnersky orientovaný, vidíme v tom příležitost jak škálovat služby, tak distribuční kanály. Proto je důležité, aby externí člověk byl schopný produkt implementovat a nebylo potřeba žádné interní speciální know-how.

Poslední část týmu je vývojový tým, který vedl Vojta od začátku. Na jaře se k nám přidal Adam Sobotka jako CTO, můj bývalý kolega ze Socialbakers. Ten tým teď začíná pořádně formovat a dává mu péči, kterou potřebuje. Právě teď se dostáváme do další fáze…

Pokud chcete, mohu pokračovat v úpravách i na další části textu.

Tady je opravený text:

Lomového bodu, ale toho vývojového týmu je tam nás asi dneska 22, jestli to říkám správně? Já si myslím, že tak 17, co myslím. Je to možné. Říkáš to špatně. Říkáš to špatně, vždycky víc, vždycky víc. No, to jsem se právě chtěla zeptat i na ten přesun do Evropy, takže to se nevědělo, myslím, jestli zatím není spíš nějaká produktová připravenost, ale byla to teda cesta Pavla zpátky do domoviny. Je to tak, a vlastně my jsme to, když jsme se o tom s Janou bavili všechny ty roky předtím, tak jsme si říkali, že nechceme udělat tu chybu škálování do šířky ve smyslu nějakého geografického pokrytí moc brzo, protože nám přijde, že pak tam není takový dopad na ten trh a takový to, že říkáte, že jste nějakém trhu, ale ve finále tam prostě přijede obchodník na dva dny, třikrát za rok, tak to není úplně market presence. A my jsme tím, jak jsme malí, možná ještě stojí za to zmínit, že jsme vlastně celou Meyro financovali první roky čistě z vlastního provozního kapitálu, protože jsme vyšli z té službové, respektive konzultační agentury. A až teď, to se oznamovalo v lednu, jsme získali první investici, kterou jsme si pod velkým zvažováním vzali právě na to škálování enterprise obchodního týmu, protože tam už to prostě bez externích financí moc nejde. Ale ten růst se nám dařilo poměrně organicky do té doby, a tohle bylo přesně jedna z těch věcí, které jsme nechtěli udělat příliš brzo – jít příliš do šířky. Ono už takhle se dá říct, že nejsme úplně distribuovaný tým, ale tím, že jsme přes tyhle regiony, máme mezi sebou asi 6–8 časových pásem, podle toho, jestli je letní nebo zimní čas, tak je docela složité koordinovat firmu a udržet tam kulturu, když firma takhle roste a je hodně oddělená. Není to úplně efektivní a chápu, že se dneska ty velké firmy vracejí zpátky k mandatornímu office time od pondělí do pátku, protože ten full remote je asi kapitola sama o sobě, ale tohle je těžké.

Jak bys tu vaši kulturu popsal? Těžko, hrozně těžko se mi to popisuje, ale myslím, že co je asi trochu určující pro nás, je, že Jana – naše vlastně třetí zakladatelka spolu s Vojtou – je i CEO. Myslím si, že ne-li 50 %, tak alespoň 45 % lidí ve firmě jsou ženy. V těch 65 lidech máme něco kolem 20 národností, takže jsme takový multi-kulti tým, bez ironie, a je to super. Na druhou stranu to má samozřejmě své úskalí, protože lidi v každé kultuře jinak vyjadřují, mají jiný humor a učí se jinak. A tohle udržet napříč firmou, která ještě nemá infrastrukturu korporátu, je samozřejmě super těžké, a tam je milion věcí, které bychom mohli zlepšovat.

Má něco společného She Loves Data s tím, že většina nebo polovina týmu jsou ženy? No, trochu asi jo, protože to je velká aktivita, která…

Pokud budete chtít, mohu text dále upravit nebo zkrátit.

Tady je opravený a trochu upravený text pro lepší srozumitelnost a plynulost:

který se věnuje primárně Janě, samozřejmě. Takže She Loves Data, my jsme… nevím, kdo si tady úplně tu historii zná, protože moc lidí to asi nebude, ale my jsme si tehdy s holkama z Check It As udělali vedle nějakého Hecatonu jeden workshop.

Workshop, který původně sloužil jako onboarding do světa datové analytiky, aby si někdo mohl vyzkoušet napsat SQL příkaz a postavit nějaký dashboard. Byl určený typicky pro lidi, kteří nejsou moc technicky zaměření. V Asii se tenhle koncept strašně rychle rozšířil a začal intenzivně růst. She Loves Data je dneska obrovský projekt, je to fixní součást trhu, čistě komunitní projekt. Máme tam jednoho člověka na full-time. Je to super, protože spolupracujeme i s akademickými projekty v Singapuru s velkou univerzitou, a podporují nás různí partneři jako Snowflake, Teradata a další velké firmy. Děláme s nimi spoustu edukace nejen v oblasti hardskillů. A pro nás je to samozřejmě důležitá komunita, která je nám hodně blízká. Máme spoustu kolegyň ve firmě, které právě pocházejí z tohoto „poolu“ She Loves Data, protože se prostě přiblížily k organizaci.

Je to tak, rozhodně to hraje roli, ale neděláme to s tím hlavním záměrem, že She Loves Data je rekrutment. To byla jen taková odbočka, zajímavost, která se vrací právě k datům, proč jsme tu.

Chtěla bych se vás ještě zeptat, jak vnímáte AI, protože na to se musíme ptát každého a všechny to zajímá.

Přesně tak, je to mandatorní téma. Jo, za prvních patnáct-pětadvacet minut jsme ani jednou AI nezmínili, to je velký přešlap.

Já nechám Vojtu popsat technologickou stránku, já to spíš shrnu z hlediska produktové strategie a byznysu.

My si trochu myslíme, že hype kolem AI je fakt veliký a vývoj velmi rychlý, což znamená, že implementovat dnes nějaké části jako chatboty do relativně dospělého produktu, bez velké vize, kam to celé směřuje, je podle mě částečně takový gimmick. Většinou jsou tyto funkce periferií produktu.

Samozřejmě to sledujeme, sledujeme, co s tím dělá konkurence, a většinou to jsou takové gimmicky. Povídací chatboti, kteří vám řeknou, co je v datech nového, to možná na LinkedIn získá hodně lajků, ale nevím, jestli s tím v byznysu opravdu vyděláte peníze.

Spíš nás zajímá něco jiného. My na to koukáme trochu jinak. Myslím, že je vidět, že algoritmy se postupně komoditizují. Možná mi „AI skalní komunita“ odpustí, ale když vidíte, že si můžete za 20 dolarů koupit přístup k nejpokročilejším modelům na kreditku, tak je jasné, že přístup k těmto technologiím je již zdemokratizovaný.

A to mi říká, že rozdíl mezi firmami už nebude ve výběru modelu nebo v tom, jaký model používají, protože těch modelů je spousta na výběr…

Pokud máte zájem, mohu pokračovat s další částí textu či ještě upravit stylistiku.

Tady je opravený text, upravený pro lepší srozumitelnost a gramatiku:

Je spousta komerčně dostupných řešení, ale ten rozdíl v kvalitě těch implementací dělají ta data, kterými ty modely krmíš. To je zjevný z mého pohledu, ne? Jo, určitě. Stále se bavíme o tom, že modely jsou fajn a fungují, ale musíš do toho dát správná data, takže s tím budou všichni 100% souhlasit, a za to se nezaplatí zbytečně moc. To mě těší.

My to vlastně vidíme na tom, jak je středem našeho produktu zákaznický profil. Když to srovnáte s tradičním CRM, přijdete a uvidíte, že zákazník měl 3–4 objednávky za poslední dva roky, možná i jaké produkty si koupil, a pokud máte lepší CRM, tak tam například bude naintegrována zákaznická podpora, takže uvidíte, že měl dvě stížnosti. U těch modelů toho moc neuděláte, a pokud ano, potřebujete opravdu hodně zákazníků, abyste dokázali něco kvalitního vytvořit.

Když ale máte u zákazníka kompletní stopu všech jeho kliků s timestampem, které za 2–3 roky udělal – co nakoupil, co viděl, co naopak nekoupil – v těch datech je obrovské množství signálu. Proto si myslíme, že spíš chceme být interním datovým poskytovatelem pro datové týmy. Nechceme to pojmout vertikálně tak, že budeme mít všechny algoritmy světa zabudované přímo v produktu, ale chceme být těmi, kdo dodávají kvalitní data data science týmům, protože právě ty algoritmy by měly stavět interně, protože každý byznys má svá specifika.

Jsem vlastně hodně odpůrce black box algoritmů zabudovaných ve všech marketingových nástrojích, protože vidíme, že to jsou často takové… třeba Salesforce Einstein a podobné věci, které vytvářejí iluzi „citizen data scientist“. Máš pocit, že si tam nějak konfiguruješ algoritmus, ale ve výsledku je to stejný engine, který doporučuje produkty v online supermarketu i v eshopu s cyklistickým vybavením. To prostě nemůže fungovat, protože zákazník se v těchto případech nechová stejně a nemůže existovat jedna generická řešení.

Mám na to silný názor. Jak jsi zmínil, být providerem dat je opravdu důležité. Lidé si řeknou – jasně, připojím třeba Google Analytics, data se mi teď tahají do BigQuery, vezmu si je a hodím do nějakého generického GenAI, a na základě toho mi to něco doporučí. Ale tam úplně chybí podstatný krok, o kterém jsme mluvili – a to je identity resolution. I když metrika v Google Analytics nese název „users“, nejsou to uživatelé, ale zařízení. A to je obrovský rozdíl, protože my máme velmi transparentní přístup v… (text zde končí).

Pokud chceš, můžu ti pomoct s další částí.

Zde je opravený text:

K té identitě, kde si člověk může přijít na zákaznickou kartu, máme tam přímo vizualizovaný graf těch identifikátorů. S jistotou mohu říct, že například tento e-mail, telefonní číslo a tato kukina (cookie) patří dohromady, protože přišly ve stejném eventu, nebo protože uživatel vyplnil formulář či proklikl nějaký link z e-mailu. Najednou vidíme, že typicky na jednoho zákazníka jsme schopni napojit třeba čtyři až pět kukin z Google Analytics. To znamená, že tato data proplouvají celým datasetem.

Ať už s tím udělám cokoliv – remarketing, retargeting přímo v GMP, nebo když napojím data z Google Analytics do Google Ads a vytvořím tam segment – na první pohled se to zdá být ekvivalentní tomu, co děláme my. My také umíme na základě dat vytvořit segment a poslat ho do Google Ads, ale je zde zásadní kvalitativní rozdíl. Google Analytics to vyhodnocuje na úrovni jednoho prohlížeče, takže retargeting cíli pouze ten konkrétní prohlížeč.

My však, když zdetekujeme scénář, který uživatel nastaví v uživatelském prostředí, nepošleme jen tu jedinou kukinu, na které se transakce stala, ale všechny kukiny, které patří danému zákazníkovi. Takže to je skutečně zákaznická karta a zákaznické identifikátory. Na základě jednoho triggeru aktivujeme třeba pět zařízení, protože uživatel přišel z telefonu, potom z počítače doma, a potom třeba i z počítače v práci. Máme proto větší zásah, což vede k lepším metrikám jako je click-through rate, nižší náklady na jeden klik a lepší konverzní poměr.

To je vlastně jedno, ale nyní si to přeneste i do kvality výstupu algoritmů AI. Jaký je rozdíl mezi tím, když tam nasypu jen data z Google Analytics, versus když použiju pospojované identity z CDP platformy? Výstup algoritmu, i když bude stejný, bude diametrálně odlišný. I něco, co dnes dokážete dělat s generativní AI – což jste před pěti či sedmi lety třeba nemohli – ukazuje, že to umělé učení je vlastně jenom jedna část. Možná spíš jde o to správné propojení datové struktury tak, aby dávala smysl.

To nám pomáhá hlavně teď s vývojem produktu. Pro naše vývojáře to je skvělý případ použití. Když je totiž naučíme ptát se víc z pohledu šířky na problém… Já jsem například ze začátku dělával tu chybu, že jsem chodil s příliš konkrétním problémem. Vymezil jsem si přesnou hrací plochu a popsal problém. Už někdy jsem sám našel řešení díky klasickému rubber duck programmingu, ale někdy jsem problém popsal a AI mi nabídla řešení nebo kus kódu. Poslední dobou si ale začínám všímat, že když čl…

Pokud chcete, mohu pokračovat a dokončit i poslední větu podle vašeho zadání.

Ověk trošku ustoupí o krok zpátky a jenom popíše v kontextu ten problém a třeba přidá i nějakou datovou strukturu, takže dokáže také přemýšlet tím kontextem a nabídnout mnohem více řešení, třeba i „out of the box“. Proto jsme museli naše vývojáře trochu dotlačit k tomu, aby uvažovali nad tím, jak používají umělou inteligenci.

Co se týče produktu, jsme v tom opatrnější, protože jsou skvělé případy použití, například když Ford — myslím, že to byl Ford — si „hodil čet…“ na stránky a nějaký prompt engineer řekl: „Tak, vezmu si z Bexís a tady mám Ford za jeden dolar.“ Podobně Air Canada, kde chatbot refundoval nějaký lístek. To znamená, že dávat přílišnou autonomii algoritmu zatím není dobrý nápad.

Vím, že konkurence používá AI k generování obsahu a vytváří personalizovaný obsah pro každého zákazníka, ale to vyžaduje velmi dobré guardrails a limity. I my o tom uvažujeme, ale není až tak důležité personalizovat text, spíše jde o personalizaci produktů.

Do uživatelského rozhraní možná AI zavádíme, máme klasické asistenty, ale jak říkal Pavel, jsou to spíš gimmicky, které pomáhají s designem banneru na web, takže to není nic světoborného.

Kam se já jako head of R&D oficiálně posunuji, je aplikace stejné myšlenky, kterou máme se svými vývojáři, tedy používat AI na zákaznická data. Jde o to jít proti proudu konkurence, která využívá AI k výběru kanálu, generování obsahu a doporučování zvlášť.

My se teď na to díváme z větší dálky a pracujeme na pilotním projektu, kde chceme posbírat všechna dostupná data a atributy o zákazníkovi — typicky máme kolem 300 až 500 různých atributů vypočítaných z dat — a k tomu přidáme seznam všech kampaní, které máme na aktivačních platformách (push notifikace, e-maily, SMS, WhatsApp, web, in-app zprávy, retargetingové reklamy atd.).

Cílem je popsat, co má zákazník k dispozici (my myslíme našeho zákazníka) a poskytnout AI data o zákazníkovi s tím, že zjistíme, jaká je nejlepší strategie, jak tohoto člověka dotlačit k cíli, který si definujeme.

To znamená nedělat to na jednotlivých malých … [text končí].

Tady je opravený text:

V kousíčkách – tady mi udělej obsah, tady nějaký trigger, tady vyber nějaký kanál, ale opravdu nechat tu AI, aby se na to strategicky podívala za zákazníka a vybrala ten nejlepší další krok. Je tohle problém, na který teď hledáte šikovného datového specialistu? Děkujeme za nahrávku.

My do toho technologického týmu aktuálně nehledáme, protože jsme od začátku roku měli velkou podporu při náborech, kdy jsme tým výrazně škálovali. Teď jsme dokončili poměrně agresivní rekrutment a teď spíš potřebujeme tým zefektivnit a konsolidovat, takže teď nehledáme nové lidi do týmu. Nicméně spíš najímáme na byznysové straně, protože máme pocit, že jsme za ty roky vybudovali velmi solidní a zajímavý produkt, který má skvělé výsledky, a potřebujeme ho více dostat na trh. Data science proto teď není naší velkou prioritou, což asi může být důvod, proč všichni pořád najímají inženýry.

Ještě bych chtěla říct, že pokud hledáte datové specialisty, tak jste asi ve špatném podcastu.

Některé zákazníky jsme už zmínili, hlavně BCA, což byl pro nás definující zákazník z hlediska dalšího vývoje, ale určitě jich máme mnohem víc. Můžete zmínit nějaké zákazníky a typické use cases, které řešíte?

Máme tři hlavní kategorie. První je bankovnictví a finanční služby. Jeden z našich novějších zákazníků v Česku, na kterého jsme velmi pyšní, je skupina Direct, což je pojišťovna a několik dalších automobilových firem, kde je problém složitější, protože zákazník může vstupovat do styku s několika různými firmami najednou. To nás těší, protože v takovém prostředí jsme skutečně užiteční.

Samozřejmě bankovnictví a finanční služby jsou naší základní doménou. CDP (Customer Data Platform) má velké uplatnění v retailu, typicky v e-commerce, ale naše aplikace jsou spíše v komplikovanějších prostředích. Jeden zákazník, který s námi vytváří nový revenue stream, je australská lékárenská síť Chemist Warehouse, kde působíme jako decisioning engine nad všemi událostmi okolo zákazníka.

První use case tam je, že oni interně prodávají reklamu a mají stovky, vysoký stovky mikrosegmentů reklamních, které prodávají svým dodavatelům pro kampaně na sociálních sítích a programatické reklamě. V podstatě se chovají jako mediální společnost a je to skvělé, protože retailista tím rozšiřuje své revenue streamy. Je to fantastické.

Co máme rádi jako zákazníka v Česku, je třeba turistický segment, kde znáte značky jako Fischer nebo Exim. Pomáháme jim s aktivací dat v call centrech a identifikací zákazníků na webu, kteří tam jenom chodí a koukají, ale typicky by nakoupili offline. Víme, že když je prodá call centrum, mají lepší marži, takže…

Pokud chcete, mohu pokračovat dále nebo text ještě upravit podle potřeby.

Jestli se tam snažíme lidi tímhle způsobem přesměrovat, anebo jestli tam děláme vysokou výtěžnost třeba na zlepšení e-mailových kampaní, což je samozřejmě důležité pro klienta, který má typický obchodní cyklus, kdy zákazník nakupuje jednou za rok nebo jednou za dva roky. Tak tam je schopnost reaktivace zákazníka úplně stěžejní. To znamená, že tyto věci nám jdou docela dobře.

Zároveň mám jako oblíbeného klienta Dirturistik, protože to není jenom o byznysu přes několik značek a zemí, ale je to i technologická výzva. Mají totiž několik různých datových skladů s daty v různých formátech, takže je potřeba všechno přinést na jedno místo, potom pomocí identity resolution dát data dohromady a efektivně je využít. To je krásná výzva.

Ale to všechno zní jako velcí zákazníci. Vy jste zmiňovali, že jste zaměřeni primárně na enterprise. Existuje nějaký případ, kdy dokážete fungovat i pro menší zákazníky? Nebo jak přesně vypadá hranice, kdy už to funguje a kdy ne?

Hele, není to tolik o tržbách, což se často považuje za klíčové, ale spíš o datové zralosti firmy. Když to zjednoduším, tak na českém trhu například zákazník, který má interně nějaký datový sklad (typicky Keboola), už vlastně ukazuje, že přemýšlí o datech a ideálně je má v jednom Snowflake datovém skladu. Pak je naše implementace nad tím hodně jednoduchá a to nám říká, že pravděpodobně dosáhneme úspěchu.

Máš určitě pravdu, že jdeme z vrchu k velkým firmám, ale produktově se snažíme zamířit i do menších segmentů. Aktuálně to děláme přes partnery, kteří jsou schopní prodat menší licenci našemu produktu menší firmě a zároveň ji obsloužit. Je to takový kombinovaný, manažovaný servisní a business model.

To se nám docela daří a prostřednictvím těchto partnerů oslovujeme i menší firmy, ne přímo, ale přes ně, kteří kolem toho staví silný byznys. Takže ano, jdeme tímto směrem, ale rozhodně to není rychlá cesta pro nás. Vlastně není nic naší cestou rychlé.

No, máte rádi komplikované věci, to už jsme se dneska dozvěděli. Jsou nějaké další komplikace, na které se těšíte do budoucna? Co vás čeká a co byste vyzdvihli?

No, stojíme na zajímavém místě, protože ten produkt děláme už 7–8 let, jestli ne déle. Mám pocit, že technologie zastarávají stále rychleji a technologický dluh vzniká mnohem rychleji s tím poměrně rychlým vývojem.

Takže se vlastně díváme na to, jak bude vypadat další dekáda pro náš produkt. Nedávno jsem poslouchal skvělý rozhovor s jedním hlavním vývojářem z GoodData, který to popisoval. Myslím, že to bylo v CZ podcastu, jestli to…

Ne bylo tady u vás, tak popisoval vlastně překlopení toho produktu do druhé verze, která se stavěla úplně paralelně. A nás pravděpodobně čeká něco podobného s tím, že koukáme na to, aby to bylo poplatné nějakým aktuálním trendům. A ty aktuální trendy pro nás jsou mnohem větší přiblížení se nějakým těm cloudovým tržištím, což znamená Hyperscaler Marketplaces, tak aby nás ten zákazník dokázal nakoupit přímo jako v Google a v AWS v Marketplace, protože vlastně si myslíme, že to je něco, na čem jsme úplně zaspali, protože my ten předpoklad máme od samého začátku, ale vlastně jsme k tomu nikdy ten business nenapřeli. A tohle samozřejmě znamená hodně pro produkt, jak ho budeme vyvíjet dál, na co se potřebujeme soustředit. No, tak budeme držet palce, ať se na Hyperscaler Marketplace brzo dostanete, a děkujeme za rozhovor.
Děkujeme.
My děkujeme za pozvání. Ahoj.
Díky, ahoj.

Impex, Saská, Bystreet, Colors of Data, Revolt BI, Good Data, Keboola, Emark, Karl Data Company, Datamind, Notino a Flo. A pokud chcete zůstat v obraze, co se české datové scény a globálních datových technologií týče, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz. Nechť vás provází data.