Podcast

Dobrý den, moje jméno je Jirka Vešerek.

Ahoj, tady Karel Šmánek. Vítáme vás u dalšího dílu Data Talku. Dnes tu máme Zdeňka Hináka z Lifesportu. Ahoj, Zdeňku.

Ahoj, kluci.

Zdeněk je team leader Data Development Teamu. Je to druhý host, kterého tady máme z dat Lifesportu ve studiu. Budeme se se Zdeňkem bavit právě o Data Development Teamu a o tom, jak se mu vede v roli lídra. Také se hodně zaměříme na Google Stack a vizualizační vrstvy.

Tento tým má na starost zpracování dat, především ale doménově akvizici a chování uživatelů. To jsou témata, na která se můžete těšit.

Zdeňku, jak ses dostal do oboru a do Lifesportu? Jaká byla tvoje cesta?

Úplně od začátku to bylo tak, že v roce 2013 mě vzal Pavel Jašek do Dobrého Webu, kde jsme společně začali nasazovat měření uživatelům. Především Google Analytics. Časem to pak byl i Google Tag Manager. Přebral jsem školení Google Analytics, což byla a stále je moje srdcovka. I když jsem hlavně už uznal, že kvůli častým změnám to bylo nakonec trochu náročné, takže už jsem v tomto směru trochu mimo obor.

Dalším krokem bylo to, že mě vždycky bavilo radit klientům v oblasti řešení, se kterými pracovali. Agentura má omezené možnosti. Musí účtovat hodiny podle toho, kolik pro klienta zpracuje. Ale často jsem přemýšlel i v noci, co by pro ně bylo lepší, a říkal jsem si, že to takto není ideální. Čas mi nikdo neplatí a klienti to nechtějí dělat.

Tak jsem začal hledat, kde se dá něco vylepšit. Pak jsme se spolu bavili o tom, co vlastně Lifesport řeší. To bylo také období, kdy postupně přicházely nové Google Analytics, které jsme začali řešit.

Lifesport jako takový není obyčejný web, není to e-shop. Když to vezmu z hlediska průmyslu, je to blíže segmentu mobilních her, protože je to spíš eventová záležitost – je tam spousta přehledů zápasů, co se hrají, detaily zápasů, žebříčky, profily hráčů a podobně. Není to obyčejné procházení webem.

Navíc nově tam máme news, audio přehrávač i videoplayer. Produkujeme Lifesport video, což je už hodně věcí, které děláme.

Když tě zastavím, a když říkáš „Dobrý web“ — dnes jsou tady Sharepass, nově pro mladší posluchače. Za prvé, klobouk dolů, že to bylo asi dobré rozhodnutí jít tam. Mám pocit, že tam byla webová analytika na nějaké úrovni, že jste byli na vrcholu potravního řetězce.

Pak Bonami, ale pořád je to hodně e-commerce, hodně e-shopů. A teď mluvíš o specifickém Lifesportu. Co to pro tebe znamenalo, když jsi tam přešel? Bylo to business as usual? Nebo úplně přerámování tvého uvažování nad analytikou?

Určitě, protože jak říkáš, e-commerce z pohledu marketingu řeší hodně kampaně, náklady, jednoznačné transakce. Víš, kolik ti to vydělá a můžeš s tím začít docela dobře pracovat. Je to sice náročné, ale přímější cesta.

V Lifesportu máme business model založený na prodeji reklamy. To, co je podle mě na Lifesportu jedinečné, je, že jsme v 60 zemích světa, působíme celosvětově a můžeš sledovat, jak reagují lidé například v Africe nebo v Jižní Americe. Každý konzument je cílem, nechová se nějak jinak.

Pro mě to bylo velmi dobré vykročení z e-shopového světa. Daleko víc mě baví a zajímá zjišťovat chování uživatelů, jak se liší a co je na tom zajímavé.

Když se bavíme o technologii, tak se koukám, že vlastně od začátku to byla… Samozřejmě jsi skočil na Google produkty, ten Google se k tomu trochu váže, a předpokládám, že i technologie a firmy, kde jsi pracoval, byly vybírány podle toho.

Lifesport je jedna z těch firem, které běží na Google Cloudu, jestli se nepletu. Takže vlastně ta technologie ti dala směr?

Vybral sis ji podle toho, nebo ne?

Možná změním trochu otázku. Existují jiné technologie v marketingové analytice? Nebo je Google pořád primární a řešit cokoliv jiného nemá smysl, že jiných možností není? Že s tvojí specializací dávala smysl Google platforma pro marketingová a uživatelská data?

Určitě není jenom Google. Adobe a další hráči také jsou významní. Piwik například má placenou verzi, která jde přes hranice.

Nicméně pro mě Google produkty zůstávají stále velmi silné kvůli široké bázi uživatelů, kteří s nimi pracují.

K té otázce, jestli jsem si vybral Lifesport kvůli Google Cloudu jako takovému, o tom jsem při nástupu úplně neuvažoval. Když jsem se s kolegou Tondou bavil, říkal jsem, nemáte Google 360, ale existují AirQuick knihovny a můžeme stahovat data do BigQuery.

Organicky to dávalo smysl. Pojďme takto pracovat. To byly naše začátky v Lifesportu.

Nicméně vzhledem k milionům až miliardám eventů, které máme měsíčně, nestačilo to dělat s anti-samplingem nebo sledováním pár procent.

Naskočili jsme rovnou na vlnu, jakmile Google vydal GA4, šli jsme do toho rovnou.

Nevadilo nám, že je to beta, mění se schéma aniž by nás to odradilo, protože eventová analytika dávala smysl.

Ano, existují nástroje, které to řeší, ale my jsme zůstali u Google platformy a vyhovuje nám to.

Představme si, jak to v Lifesportu vypadalo v roce 2019, kdy tě kolega Tonda, kterého jsme tady také měli v podcastu, ulovil. Jak si to máme představit?

Už tehdy to byl velký skok ve škále počtu uživatelů. Lifesport je velmi rychle rostoucí firma. Jak to tam vypadalo, když jsi nastupoval?

V roce 2019 jsem nastoupil do Lifesportu, kde jsme se věnovali zpracování dat z Google Analytics.

Byli jsme tady vlastně dva – já a Tonda. On se zaměřoval na nasazování, já na zpracování dat, získávání dat do BigQuery a tvorbu výstupů.

Tehdy jsme si hodně hráli například s nástroji typu Crazy Egg na sledování heatmap.

Organizačně jsme spadali pod research and development a dost jsme spolupracovali s produktem, kam to směřovalo.

Mezi rokem 2019 a dneškem je ohromný skok.

Dnes už máme tým asi pěti lidí čistě v Data Developmentu a celkové BI má deset i více lidí.

Každý se specializuje na něco jiného. Máme tým, který se věnuje čistě revenue, a tým, který řeší jiný způsob aktivace dat než z pohledu uživatelské báze a marketingu.

To mi nahráváš, co tedy znamená Data Development Team? Jak to máte organizačně, co máte na starost a jak si to máme představit?

Každý den k nám přiteče několik terabajtů dat z Google Analytics, což je náš hlavní datový zdroj.

Nicméně máme také data z interní databáze, kde jsou informace o tom, jaké ID vidí uživatel na webu, zápas či event.

Samozřejmě máme data z různých reklamních nástrojů, spoustu z Google Search Console, to všechno získáváme.

Úkolem našeho Data Development Teamu je z té hromady dat, která jsou bezcenná, protože jsou to jen eventy, vytvořit datové martý, výstupy pro týmy zabývající se produktem a marketingem, které jsou naše klíčové týmy.

Likewise, rychle rostoucí tým zaměřený na obsah, tedy různá news sekce, video, audio.

To snažíme podporovat.

Možná nějaké specifikum našeho Data Development Teamu – když se řekne Data Development, možná si člověk představí spíše data inženýry nebo data inženýry analytics.

Řeší především transformaci dat, tvorbu pipeline a integrace nástrojů.

My ale uvažujeme trochu jinak.

Jak jsme rostli z dva lidí na víc, rozhodovali jsme se, jestli potřebujeme inženýrské kapacity nebo se zaměřit více na analýzu.

Chceme pochopit, co produkt a marketing potřebují a podle toho zpracovat data, aby to dávalo smysl a užitek.

Pro nás je prioritou doručit co nejrychleji smysluplný výsledek na to, na co se lidé ptají, a zároveň myslet trochu dopředu, co by je mohlo zajímat.

Tímto způsobem jsme tým postavili.

Máme jediného data inženýra, jehož úkolem není primárně získávání dat z nástrojů, ale spíše propojení přes API Google Cloudu.

Například teď řešíme projekt obohacování dat o audience v rámci GA4, pomocí importů dat nebo integraci nástrojů typu Tableau či R, aby bylo možné data používat.

Mohu to tedy reformulovat tak, že spousta firem staví velké datové sklady, konzolidují data a pak se snaží být vždy připraveny na všechno.

Vy ale začínáte od use case, zpracováváte data rychle, abyste měli výsledky.

Jak řešíte technologický dluh, protože předpokládám, že to je „to B“, které se musí řešit později?

Uvažovali jsme o tom.

Určitě technický dluh přichází, když chceš primárně vytvořit výstup, ale hlavně aby vznikl.

Touto cestou jsme prošli.

Osobně jsem trochu „policajt“ v tom, snažím se kluky brzdit.

Už máme vybudovanou architekturu, nejsme jen o tom, že máme hromadu dat a vybíráme, co je třeba.

Máme vrstvy: staging, transformace, analytická vrstva.

Postupně jsme si vyjasnili, co kde patří, takže jdeme těmito kroky dál.

Co se týče nástrojů, začali jsme využívat dataform.

Shadowované dotazy v BigQuery nejsou dostatečné pro smysluplné pipeline.

Dataform používám ještě od doby, než ho Google koupil, asi rok či dva předtím.

Rozhodnutí bylo jednoznačné.

Je to SQL v podstatě, lze jej rychle použít a má vestavěné testy.

Myslíme také na inženýrskou kvalitu, ale hlavně chceme být efektivní, abychom mohli s daty dobře pracovat.

Snažíte se mít co nejsnazší kód?

Přesně tak, abychom to zvládli zpracovat.

Nešlo nám o řešení na úrovni komplexního kódu.

Dnes umíme používat dataform, co potřebujeme, BigQuery navíc umožňuje různé rozšíření, takže se dá dělat opravdu hodně.

To je jedna část.

Druhá část je nástroj na získávání dat.

Začali jsme s Fivetranem, protože šlo jednoduše naklikat a fungovalo to dobře.

Pak nám ale ohlásili nový ceník, který pro nás při objemu dat hodně zdražil.

Naše volba pak byla DataDu, což je také česká firma, s kterou je dobrá a rychlá domluva.

Zdravíme Petra.

Zkoušeli vás už sponzorovat?

Dnes tě zastavím – zbytek týmu je pak víc analytický, zaměřený na konkrétní domény a interpretaci dat, méně na DevOps, jak by snad název napovídal?

Půjdu postupně.

Máme člena týmu, který se stará primárně o webový a app tracking, což je pro nás důležité.

Máme webové i nativní mobilní aplikace.

Pohled je relativně podobný, ale rozdíly mezi iOS, Androidem a webem jsou významné.

Tento člověk má na starost právě tuto oblast.

Dále máme člověka, který je hodně ponořený v datech v pipeline, rozumí kombinacím vnitřních dat, která jsou v datakor, kde jsou data o eventech a specifika napojení na další data.

Zároveň tento člověk úzce spolupracuje s produktem a přijímá ad hoc požadavky.

Díky dobré znalosti dat je schopen velmi rychle požadavky vyřídit.

Pak jsem tam já.

Nedávno přišel nový kolega, který se věnuje akvizici uživatelů a marketingu.

Ta oblast je mi nejbližší.

Používáme nástroje jako AppsFlyer pro aplikace.

Ale to už bychom se dostali do detailů.

Když se podíváme na organizační úroveň a nastavení takového týmu, pro koho je takové řešení vhodné a pro koho ne?

Lifesport je ve velmi unikátní situaci.

Týká se to škály, obchodního modelu, zejména škály.

Jak říkáš, máme mobilní aplikaci, která je podle mě nejpopulárnější česká mobilní aplikace na světě, pokud se nemýlím.

Má velké množství denních i týdenních uživatelů, takže škála je obrovská.

Dále je důležité, že používáte standardizovaný stack.

Nemusíte svádět boj s každým novým datovým zdrojem.

Neustále pracujete v podobných prostředích a zdokonaluje se tým.

Takže je to tím vysvětlením, proč dává smysl takový tým?

Nebo jste v historii měli jiné struktury?

Pokud byste učinili jiné rozhodnutí – měli více data inženýrů, třeba dvakrát či desetkrát více?

Škálování Google Cloudu je pro nás velmi jednoduché.

Škálování neřešíme, protože všechny použité nástroje jsou serverless, případně škáluje třetí strana.

Například DataDu a API konektory, s nimiž pracujeme.

Ano, když jim napíšeme na podporu ohledně problémů, rychle je řeší.

To je komfort, který v této spolupráci máme.

Co se týče BigQuery, nemusíme se starat o databázi.

Ta funguje, jak potřebujeme.

Řešíme však FinOps z pohledu nákladů na zpracování dotazů.

Co se týče technického dluhu, před třemi čtyřmi lety jsme vytvořili datový model, z něhož jsme začali čerpat surová data z Google Analytics.

Byly nějaké transformace, ale dotaz stál třeba i několik terabajtů.

Dnes je ten jeden z…

[rozhovor pokračuje]

Legů, o kterých se zmiňoval Petr Bublin, zpracoval skvělý refaktoring, v rámci kterého nás nyní stojí gigabajty dotazů na ta samá data, někdy i megabajty. A jde o to, přesně jak jsi říkal, dobře zná platformu, ví, co vyžaduje, jaké dotazy používáme, což jsme se časem dozvěděli, jak vlastně fungujeme.

To je možná odpověď, že my nejdřív uděláme ten výstup a zpětně potom vznikne technický dluh, nicméně snažíme se najít čas na to, abychom ten refaktoring provedli ve chvíli, kdy se něco opakuje, víme, že nám v tom leží peníze, a tak tam zasáhneme a upravíme to.

Myslím, že je to hodně souvislé s tím – to je moje další otázka. My jsme tady neřekli úplně, v jakém režimu vy fungujete, protože chápu, že teď máš nějakou historii v té webové analytice od roku 2013, což znamená, že bych předpokládal, že máš dost expertízy nejenom nástrojové, ale co se týče třeba těch use case’ů a podobně, že víš, pro co si jdeš, že tohle by měl být ten set reportů, které bychom měli využívat a tlačit.

A mě spíš zajímá, čekáte na požadavky z byznysu, anebo to aktivně tlačíte? Protože minimálně ty, nevím, jaký zbytek týmu tu expertízu máte, tak předpokládám, že je to tak, že vy analýzy děláte a tlačíte, fungujete jako konzultanti v rámci té skupiny, říkáte: „Tohle se má takhle využít,“ nebo jen čekáte většinou, nebo ne? Jen předpokládám, že je to nějaká kombinace. Jak prioritizujete kapacity?

Náročně. Popíšu to tak, že my existujeme…

Protože ty domény, které jsem popsal, jsou produkt, marketing a případně další části produktu. Pod produktem je tým, který řeší A/B testy, komunikaci e-mailu a podobně, pak je tam i tým, který řeší content. Takže když řeknu produkt, znamená to několik dalších oddělení.

Když to vezmu z plodu těchto týmů, tak když potřebují pracovat s daty, ptají se nás, my jim připravujeme výstupy, buď formou nějakých reportů, ale zároveň se snažíme mít pohromadě datamarty, ze kterých ty reporty čerpají data, abychom to dokázali efektivně předpoužívat.

To je jedna věc, ale je to tak, jak jsem říkal, každý z členů týmu má nějaký přesah do dané domény. Umíte například marketing, u Petra je to produkt, u Luba tech a případné věci týkající se news a technologické části.

Plánování probíhá tak, že se snažíme prioritizovat dotazy, které máme, sledujeme roadmapu, kam se produkt posunuje. Například v aktuálním období, kdy jsou velké sportovní události, se snažíme vyrolovat zajímavé novinky, a tam samozřejmě musíme myslet i na tracking, změny a dopady, které mají na celou pipeline.

To je tato část a každý se svou expertízou se snaží komunikovat v dané doméně a s těmi, kdo zadávají požadavky, konzultovat, proč je to pro ně důležité.

Oproti tomu stojí to, co my v development týmu chceme dělat — například refaktoring, sledování technického dluhu, nastavení datamartů, nastavení vrstev, aby přesně tak, jak říkáš, nevznikala samotná data, která zpětně nelze využít.

Tyto požadavky jdou někdy proti sobě. Nemám na to zcela návod, ale snažíme se o to tak, že jsme si řekli, že máme nějaké dlouhodobé projekty, které chceme v tomto roce dokončit, například upravit část pipeline, nastavit kontrolu kvality dat a podobně.

Některé dlouhodobé projekty vyplývají z potřeb domén, ale nikdo je řekne přímo, protože možná neví, že je potřebuje — jen my tušíme, že tudy vede cesta. Říkáme si, že tomu dáme 40 %, a 60 % si pak rozdělíme přibližně – 30 % na fokus přecházející z požadavků domén a dalších 30 % na věci, které nepředvídáme, protože vždy přijde něco nečekaného, nějaká změna.

Takto hrubě nastavujeme kapacity, které chceme čerpat. Každý týden máme meeting, kde si říkáme, jaké byly požadavky a co je v plánu. Každý z lidí samostatně dokáže přibližně posoudit, kde má kapacitu.

Já se pak snažím fungovat v roli facilitátora, kde když se dívám zhora, vidím, že člověk se sice snaží, jak může, ale už to přeteče někam jinam.

Snažím se komunikovat s lidmi z jednotlivých domén, vysvětlovat jim, že když někdo chce něco, ale někdo jiný podobné, může se to spojit do většího projektu, kde si řekneme, co je akutní a co se dá dělat společně.

Mám pocit, že jsme úplně ze stejných věcí debatovali neúmyslně nedávno i v NDOM.

Každopádně chtěl jsem se doptat — říkal jsi, že máš na starosti tým přibližně pěti lidí. Říkal jsi, že data dělá asi deset lidí.

To znamená, že existují domény, které jsou ještě mimo tvou přímou kontrolu. Jak to funguje s ohledem na to, že říkáte, že se snažíte dělat věci přímočaře, konsolidovat je do rozumné podoby, aby to bylo udržitelné a hlavně aby tam byl tah na branku?

Tah na branku se mi líbí, co se týče live sportu.

Ano, tah na branku je náš brand úplně.

Na druhou stranu jsou tam pravděpodobně i datové oblasti, které jsou někde úplně jinde.

Vím, že jsme se bavili o nějakých streamech, sportovních eventech a podobně, které možná mají málo společného s webovými daty.

Předpokládám, že tam mohou vznikat nějaká datová „sila“, že tam můžete mít například dvě datové platformy nebo používají odlišné technologie.

Jak jsi tedy s tímto pohledem kamarád s cross-týmy?

Myslím, že určitě dobře. Technologicky?

Naše snaha je vždy dát data, která zpracujeme, do BigQuery. To je alfa i omega.

V tuto chvíli, jak jsi říkal, jeden tým například řeší, jak plnit data v rámci datakoru, hodnotit, například jak se vyplatí tenis, stolní tenis, šipky atd. v různých zemích.

To jsou určitě jiná data než ta, která zpracováváme v rámci clickstreamu.

Nicméně jsme schopni tato data, protože jsou společná, s klíčovými ID, která jsou na jednom místě, dát ven jako dataset kompatibilní s informacemi, které pak zpracují kolegové například pro datakor a oni jsou schopni udělat analýzu.

Máme společná místa, snažíme se být flexibilní.

Nemáme absolutní povinnost pracovat jediným způsobem.

Může se stát, že některý tým zpracuje data trochu odlišně, ale pokud mají data spolupracovat, vznikne datamart, který sdílíme.

Samozřejmě jsou tam rezervy v dokumentaci, ale snažíme se o to, protože víme, že jsou to klíčová data, dát jim prioritu a více se s nimi bavit.

Již jsme malý tým, kde se spoustu věcí dokážeme vyjasnit přes Slack nebo osobní schůzku.

Na druhou stranu je potřeba zakotvit klíčové informace, například popisy metrik, aby při novém vytváření podmětů neměly vzniknout znovu.

Možná se podívejme na konkrétní domény.

Když jsi mluvil o rozdělení, že 40 % kapacity chcete mít na důležité a potřebné věci, které ostatní možná nevidí, aby byl v systému pořádek, co to jsou za projekty? Co do toho spadá? Co byla velká věc, kterou jste nedávno řešili?

Začnu tou nejdůležitější dlouhodobou věcí, kterou řešíme – data discovery a kvalita dat.

To řeší každý tým, který přichází do styku s daty.

Začalo to asi před dvěma lety, kdy jsme začali používat nástroj SelectStar, který slouží k dokumentaci dat a jejich sdílení napříč firmou.

Byla to myšlenka, že nám to pomůže lépe propojit data cross-týmy.

Letos jsme spolupráci ukončili.

Důvodem není, že by byl SelectStar špatný, ale záleží na našem fungování a rozvoji Google Cloudu.

Google Cloud nám výrazně napomáhá v tom, jak data sdílet a popisovat v BigQuery – například díky dataplexu.

Za poslední rok nestačím sledovat, co tam všechno je nového – Vertex AI, endpointy pro machine learning modely a podobně.

Tyto nástroje se snažíme využívat.

V Google Cloudu máme například datalineář přímo na úrovni BigQuery, což dobře doplňuje Dataform.

My jsme tedy řekli jako datový tým, že občas používáme SelectStar k dokumentaci metrik a jejich vzniku, nicméně v tuto chvíli většinu těchto věcí řešíme přímo v Google Cloudu.

Proto nám nedával smysl mít vedle další nástroj.

To je dlouhodobý rozvoj, hodně spojený s toolingem a kódem.

Pokud se podíváme na zbylé domény a těch 40 % dlouhodobých cílů, předpokládám, že jsou hodně spojeny s akvizicí a chováním uživatelů.

Co jsou ty velké věci, které řešíte?

Z velkého pohledu řešíme uživatele, akvizici uživatelů, jejich aktivitu a hodnotu.

Zadání prodeje mediálního prostoru není přímočará linka, nejsou zde přímé transakce, takže hledáme cesty, jak definovat hodnotu uživatele.

Řešíme segmentaci uživatelů podle akvizičních kanálů.

S tím souvisí například projekt, kdy nechci říct CDP, to je pro mě moc široký pojem.

Vzali jsme, co máme v BigQuery – ID uživatelů, ID registrovaného uživatele.

Když se přihlásí nebo registruje, máme spoustu first party dat, se kterými můžeme pracovat.

Google Analytics umožňuje import audiensí přes Firebase.

V Apexu jsme schopni využívat segmenty z Google Analytics k oslovení uživatelů třeba i notifikacemi.

To vypadá velmi zajímavě.

Říkám to, protože možnosti v našem objemu jsou trochu omezené.

Uživatelů jsou stovky milionů ID, a import přes API do GA by trval dlouho.

Proto v GA postupují vstříc a umožňují import přes CSV, což nyní zkoušíme.

Smyslem není postavit CDP, ale být schopen oslovovat určité audience našimi marketingovými komunikacemi.

Je to určitá spolupráce produktového týmu, marketingu a grow týmu, abychom byli schopni vybudovat analytics, držet nad tím ruku a řídit to.

Neřešíme jen technickou část, ale i identifikaci hodnotných uživatelů, jejich life cycle.

Získáváme uživatele na určitou dobu, někdy nejsou aktivní.

U nás hraje roli, zda se venku hraje sportová událost.

My sice neděláme sezonní kampaně pro televizi, ale když hraje Euro, víme, že lidé jsou aktivní.

Můžeme mediálně podpořit zájem obsahem, lidé hledají informace o zápasech a výsledcích, které poskytujeme.

Také oznamujeme sportovní události, očekáváme nárůst zájmu, oddělujeme aktivity, které děláme, a zjišťujeme, zda marketing přispěl k byznysovým výsledkům.

To jsou výzvy, kterým čelíme a které nás zajímají, a kterým postupně věnujeme pozornost.

Chtěl jsem se jen zeptat na CDP.

Říkal jsi, že je to zajímavé.

Ovšem krabicová řešení, jako je Exponea a podobná, vám podle všeho nesedí.

Mě by zajímalo, co z CDP je pro vás klíčové – zda je to analytika, což není standardně součástí, nebo spíš sjednocení identifikátorů uživatelů.

Předpokládám, že to je pro vás výzva.

Nebo je to marketingové oslovování uživatelů? To předpokládám má na starosti spíš produktový tým.

Chápu to správně?

Těžko říct.

Předtím bylo dělení, kdy část týmu se jmenovala Product Marketing, nyní Grow.

Tam řeší část týmu identifikaci uživatelů, poznávání, k jakému identifikátoru nebo zařízení patří.

Komunikovali jsme s různými dodavateli CDP systémů – Meiro, Exponea; měli jsme prezentace firem, které jsou postavené čistě na Google.

Vypadá to, že to funguje dobře a hezky.

Určitě by to pro nás mělo smysl, ale v našem objemu dat se většinou platí za počet požadavků (requests) a cenovky jsou velmi vysoké.

Pokud analyzujeme, že na tom umíme vydělat, například prodej kampaní v OX televizi, pro nás to zatím nedává smysl.

Řekli jsme si tedy, že to uděláme vlastními silami.

Začneme od nuly a posuneme se nějak dál.

To nás zajímá – jaký přínos nás čeká, jestli to vůbec má smysl dělat.

Vyvinuli jsme vlastní způsob identity resolution pro rozpoznání uživatelů.

Nástroje jsou sice lepší, ale potřebujeme začít něčím.

Důležité je, jak oslovit uživatele.

Fungujeme především na Google Ads, takže v reklamních systémech zatím nejsme limitováni.

Mailing a notifikace jsou tři klíčové kanály, které používáme a které jsme schopni odbavit v našem technologickém stacku.

Notifikace řešíme pomocí Firebase, emailing máme částečně vlastní řešení, které pracuje s audiensami v rámci nástrojů používaných pro druhý zmiňovaný kanál.

To že Google Ads obohacujeme daty, umíme také odbavit.

V rámci Datarů, které nabízejí reverzní ETL, zkoušíme další možnosti.

Nejde o reklamu na Dataru, ale to bylo zajímavé, protože Peťa Neme je asi jediný, kdo tento termín používá a je na něj velmi zapálený.

K datovému stacku se ještě dostaneme na konec.

Takže toto jsou naše úvahy a „chytristiky“ (vlastní nápady), když si říkáme, že jsme schopni mnohé věci sami zvládnout, máme vlastní segmenty a máme o uživatelích hodně informací.

Věcí, takže pojďme využít, co máme. Takže to je náš přístup a ano, když nám něco chybí, tak hledáme nějakou krabičku, která nám pomůže tu část vyřešit, ale to krabičkové řešení, které by dělalo vše, nám se moc v tuto chvíli nedává.

Já zopakuji to, co jsem říkal: podle mě jste velmi specifický klient, že nezoufáte si sem tam, proč nepracujete pro nějaký e-shop, kde máte skladové zásoby, next best action a takové věci. Vůbec ne. Mě to ale baví, to jsou hodně zajímavé výzvy, dovolil bych si říct.

Třeba jedna z věcí, které hodně řešíme, je, že jsou kampaně, které vedou na web, akorát že cílem té kampaně je instalace aplikace. Což je trochu výzva. My používáme AppsFlyer pro napojení dat z trafiku z webu do aplikace a dneska jsme zrovna měli mít školení, jak debagovat nativní aplikace a jaká všechna ID tam tečou, jak vlastně a zároveň, jak AppsFlyer debagovat, co tam má, jaké hodnoty ukládá pro akvizici, kterou identifikuje. Takže to jsou krásné výzvy a to mě baví na tom.

Jak těžké je vlastně dát ty věci dohromady, ten svět mobilních aplikací a ten webový svět? Jsou to ještě pořád dvě úplně odlišné domény s vlastními zákonitostmi a vlastní chytristikou, které se dohromady dávají těžko a draze, anebo už je tam nějaká spojitost, nějaká konsolidace?

Když se vzpomínám, když jsme začali dělat tu pipeline, tak první vzor pro nás, jak tu pipeline postavit podle tvého modelu, byl web. Řekli jsme si: OK, tak to replikujeme na ty aplikace. Vzniklo z toho trochu kočko-pes, protože na webu jsi schopný dát page type a víš jasně, co se zobrazí. Ale v aplikacích to nefunguje, tam máš různé obrazovky, které se překrývají, různé swipeování a kde se uživatel nachází. Tak jsme to nějak nalepili, aby to vypadalo, protože když to vezmeš, tak to v zásadě dělá to samé, dělá aplikace jako ten web. Ale chování uživatelů v aplikacích je úplně jiné.

A druhá věc je, že se to netýká jen aplikací a webu, ale iOS a Android. To jsou také dva úplně jiné světy. Jednak technologicky, protože když se bavíme s vývojáři, tak něco se dělá jinak v iOS, jinak v Androidu. A druhá věc je, že i návyky uživatelů na těch platformách se liší. Teď třeba, jak se posouvá iOS v rámci widgetů a Islandu, Dynamic a podobně, dávají přístup vývojářům a je na tobě, jak to zpracuješ. Takže každá platforma jde nějakým směrem a my na to reagujeme, protože i produkt na to reaguje – na iOS to funguje jinak, na Androidu jinak. A musíme prioritizovat, co smysluplně trackovat a co už ne. Takže to není procházka růžovou zahradou, ale jak jsem říkal, ta komplexita tě vlastně baví.

Jak moc je to založené na tom, že stojíte před whiteboardem a přemýšlíte, jak to uděláte? Protože mě to zní, že vytváříte něco úplně nového, co tady nebylo, není, že řešíte problém, který zase tolik firem na světě neřeší, že tam je nějaká matematika, nějaká chytristika.

Jak moc jsou to technické věci a jak moc analytické věci?

Za mě vždycky začínáme tím, že zjistíme, co vlastně potřebujeme zjistit. Docela možná někdy nejtěžší je pochopit zadavatele, co řeší a proč to řeší. Začínáme tím, že se bavíme o tom, co v datech už máme, co z toho jsme schopni zjistit a kde jsou nějaké mezery, kde nám to nestačí.

Jak jsem říkal, například v aplikacích často neměříme třeba swipeování nebo přecházení doprava, doleva, co má uživatel za možnosti. A občas přijde specifický dotaz v rámci produktu. Ale jsme schopni sáhnout právě do toho modulu ad hoc, udělat nějakou informaci a vidět, jestli je přínosná, nebo ne. Takže nejdříve se snažíme hodně protipovat.

Zjišťujeme, co se vlastně dá prakticky za data použít. Protože kolikrát můžeš mít spoustu přání – bylo by hezké vědět tohle. Ale když se nad tím zamyslíš, tak když tu informaci dostaneš, co s ní vlastně uděláš? To je naše primární úvaha nad tím, co má smysl měřit.

Uděláme v tu chvíli, co jsme schopní, dodáme a bavíme se, vlastně iterujeme dál. Bavíme se o tom, zda to stačí, nebo ne, kam to posunout dál, jestli je potřeba.

To mi zároveň odpovídáš na tu třetí kategorii. Říkal jsi, že 40 % věnujete dlouhodobému rozvoji platformy a vašeho fungování, 40 % jasným a dlouhodobým businessovým cílům a 30 % držíš na ad hoc řešení, což spadá do té škatulky.

Jak moc na vás padá věcí, jak moc mají uživatelé naučené, že si to dělají sami, a jaká je tam dynamika? Myslíš, kolik lidí je schopných self-service a kolik je na vás dotazů?

Jaký máte vztah k self-service? Nemyslím přímo ten buzzword, ale jak tohle rozvíjíte? Jak data-driven jsou v týmech? Když mluvíme o produktovém marketingu, tak tam jsou analytici. Předpokládám, že jim stačí datamart, reporty a nějaká discovery.

Ptá se také, jak to naráží na úzký profil dat, který tam máte. Typicky ten dotaz padá mimo, nebo se trefí?

Je pravda, že v rámci dat, která máme, jsme schopni odpovědět na většinu produktových marketingových dotazů, tam není problém. A vše, co má vztah k sportovním událostem a chování uživatelů, tam data jsou.

Druhá věc je, že máme dva typy datamartů: agregovaný datamart, kde nejsou uživatelská ID, což nám umožňuje rychle a levně odbavovat hodně dotazů typu, jak moc se používá nějaká funkce, jak lidé protékají nějakým flow a podobně.

Druhý typ jsou uživatelské datamarty, které děláme užší kvůli množství dat a zaměřujeme se na to, co se skutečně reálně bude používat.

Co se týče ad hoc dotazů, to je zajímavá kapitola, protože já se hodně snažím zaměřit na to, jak data uživatelům dodávat.

My využíváme Tableau jako platformu pro dodávání dat a existuje několik úrovní výstupů.

Pro produkt vznikla například řada reportů v Tableau, kde si uživatelé filtrací naklikají spoustu věcí a kombinací. Je potřeba pouze znalost dashboardu, aby si uživatelé nastavili, co potřebují, a vidí třeba metriky jako live zápasy, průměrný počet uživatelů při zápase a podobně. Tímto odbavíme hodně dotazů.

Pak jsou věci, které se týkají dat na úrovni uživatelských ID. Tam řešíme více ad hoc věci, například kampaně, chování uživatelů, retence, kohorty a podobně. Začínáme tam používat klasické Google Sheets, kde vytvoříme dotaz v krátkém období, dáme Google Sheet a lidé v marketingu si s tabulkami rádi hrají, takže s nimi dokážou data prozkoumat a zjistit, co jim vyhovuje.

Třetí oblast jsou výstupy typu dashboardů, které ukazují trendy a směr. Tam se snažíme být úzce zaměření, například když vedeme traffic, ukazujeme klíčové informace z různých kanálů, návštěvnost a také informace o událostech, které mohly mít vliv, například release a podobně.

To trvá dlouho, protože sjednotit se na tom, aby dashboard dával skutečně smysl a nebyl příliš hluboký analytický pohled, je náročné.

Je to práce, ale dává to hodnotu dlouhou dobu, protože se ten dashboard používá dlouhodobě.

Mě by spíše zajímalo, protože jsi zmínil, že veškeré dashboarding a Excel extrakty máte. Máte ambice ohledně uživatelů? Máte uživatele, kteří jsou „zblblí“ tou dobou a naučili se SQL a chtějí si opravdu sáhnout do BigQuery a věci si v self-service režimu opravdu vykvérirovat?

Určitě. Vím o lidech, kteří používají přímo BigQuery a jsou schopni si z tabulek vytáhnout, co potřebují. Je jich pár, ale i tak tam jsou.

Jak řešíte, aby BigQuery nezavařili, co se týče financí, limitů a podobných věcí? Koho pustíte do warehouse?

Jak jsem říkal, máme oddělení staging, transformation a analytics. V rámci projektu analytics jsou tři oddělené projekty. Do transformation pouštíme maximálně někoho z BI týmu, nikdo jiný tam nesmí. V analytics projektu jsou datasety obsahující datamarty. Tam pustíme lidi, ale ty datamarty nejsou velké, protože jsou většinou jednoučelové nebo nějaký výběr dat. Tam už…

Raději naučíte картерáky.

No, chci zmínit ještě jedno velké téma, slona v místnosti, který jsi řekl jen mimochodem. Když se podíváme na váš stack, jste hluboce v Google a v Google Cloudu.

Samozřejmě jste říkal, že specializovaná řešení v poslední době opouštíte, protože nástroje v Google Cloudu jako Dataplex rostou a daří se jim.

Na druhou stranu máte Tableau, což je…

Slovo do pranice.

To je zajímavé, tam cítím nějakou kontroverzi. Jak to, že máte Tableau a ne Looker? Jak to vzniklo a jak často dostáváš tuto otázku a musíš to vysvětlovat?

Tableau jsme začali používat velmi záhy, co jsme začali zpracovávat data z BigQuery. Důvod výběru? Ano, uvažovali jsme o Lookeru, ale v té době byl Looker ještě samostatnou firmou, ještě nebyl koupený Googlem. Takže to je trochu historická geneze.

Data Studio, respektive Looker Studio, používáme také. To hodně souvisí s BigQuery a je zdarma.

Co se týče Tableau a Lookeru, Tableau nás oslovilo z hlediska možnosti vytvoření vlastní šablony a vlastního způsobu komunikace dat. Nejsem Looker specialista, ale Looker má výhodu v tom, že si tam člověk může rychle naklikat něco jednoduchého.

Co se mi líbí na Lookeru, je ta semantická vrstva a LookML, což je snad i Google plánuje vypustit jako samostatný produkt, oddělený od vizualizací, který by se třeba dal napojit na Tableau. Na to jsem zvědavý.

Bariérou uvažování o přechodu z Tableau na Looker byla cena a přeučení na nový nástroj. Musel by být výrazný důvod, proč jít jinam. To je mimochodem důvod, proč ho někteří nepoužívají, i když je hezký.

Dnes s nástupem generativní AI, což je hezký buzzword, Google Looker integrace může pomáhat. Ale Tableau také poslouchá analytickou komunitu a chápe, jak ten svět práce s daty funguje.

Například Tableau Pulse, který jsem testoval, mě baví a může být způsob, jak přiblížit metriky uživatelům. Před generativní AI byla dotazování složitá, člověk musel přesně říct, co chce, a nedostával to, co skutečně potřeboval. Teď to vypadá, že to jde lépe.

Navíc governance nad daty je důležitá. Když chci dávat data lidem a bojím se, co budou dotazovat, Tableau jde v tomto směru správnou cestou. Těším se, že to bude funkční řešení.

Mám pocit, že ten důvod, proč bude Looker dávat semantickou vrstvu jako samostatný produkt, je právě generativní AI.

Bavil jsem se s Googlem a nejsem si jist, ale říkali, že by se mělo dotazovat přímo do semantického modelu a Looker by se mohl vynechat.

Cena je ale pravděpodobně stále problém.

Proto držíte Data Studio, když jsi zmínil, že Looker Studio máte ve stacku? Je to interní nástroj, kde prototypujete, a pak to jde do Tableau, nebo jaká je komplementarita těchto dvou?

Ano, nejčastější použití Looker Studia je pro distribuci většímu počtu uživatelů, kteří potřebují omezený pohled na data a víc nepotřebují. Například pro naše partnery po celém světě nebo redakce zpráv, které potřebují jednoduché informace a licence na Tableau by se jim nevyplatila. Proto používáme Looker Studio jako embedded analytics a distribuované řešení.

Můžeme se vrátit? Protože Jirka na to skočil od konce, ale posluchači nám stále dávají zpětnou vazbu, že je zajímají technické detaily. Můžeme zkusit popsat jednotlivé vrstvy odspodu, jak máte systém postavený? Myslím si, že by nás to zajímalo.

Zmínil jsi, že to začíná DataDoo. Proč jste zvolili DataDoo? Chápu, že jsi říkal, že cena byla lepší než u Fivetranu. Zkoušeli jste i něco jiného? A proč takovou technologii? Vlastně si nepsali vlastní konektory nebo CDP v Pouzovkách?

Na této úrovni jsme hledali partnera, který nám zajistí získávání dat bez starostí o DevOps okolo, škálování a všechno s tím spojené. Každé API jednou potřebuje aktualizaci a podobné věci, bez toho se to neobejde. Cena se nám vracela v tom, že nemusíme věnovat čas na to řešit. Rozhodli jsme se, že nebudeme budovat velký inženýrský a analytický tým.

Co se týče DataDoo a Fivetranu, ano, používali jsme různé nástroje. Jedním z důvodů, proč jsme začali používat Fivetran, bylo to, že ten měl v té době konektor na Google Search Console. Dnes už to není potřeba, ale tehdy to byla jediná možnost.

Při přechodu na DataDoo bylo omezení, že naše interní databáze nebyly přístupné zvenčí. Vyžadovali jsme reverzní SSH tunel, což ne každý nástroj umí. DataDoo nám to umožnil, takže to byl další bonus.

Za nás je užitečný support, na který je snadné si navyknout.

Ovládají vám kluci DataDoo na míru? To by asi mohli říct sami.

Co třeba funkce jako Iceberg, data travel a podobné nové formáty, které podporují? Využíváte je? A jak je máte postavené?

Jedničku přímo nemáme v transformační vrstvě, což je projekt transformation, kde řešíme získávání a přepracování surových dat ze stagingu a…

Řešíme tam náš datový model a způsob, jakým budeme data zpracovávat. Přiznám se, že my klasicky neřešíme úplně věci, jak jsi říkal, například time travel a tyto funkce, které přicházejí jako relativně novinka v současné době. Pro nás to úplně není zásadní změna, kvůli které bychom museli upravovat, jak to řešíme. Nicméně ano, existují tam možnosti vytváření snapshotů a podobné věci. Je to asi úroveň, kterou my jsme úplně neanalyzovali z hlediska možného dopadu.

Co nás aktuálně zajímá, je například pricing nebo rozdíly v priceingu v rámci dotazů při různých cenových modelech, se kterými Google přišel. To je trochu taková alchymie. Zatím se nám to pořád vyplácí, aktuálně to vypadá jako náš on-demand model.

Nově budeme spolupracovat s Mazhar Data, což je nástroj, který řeší datovou kvalitu, ale část řeší také infinops nad BigQuery, asi nad Google Cloudem jako takovým.

Ve chvíli, kdy jsi říkal, že vlastně máte už další vrstvu, která je transformovaná a kde řešíte – teď si nejsem jistý, kde přesně řešíte tu situaci, že když ti přijde delta, tak aby ses dostal ke konsolidované transakční tabulce – co přímo řešíte v té stage, tedy v té etapě?

To záleží na tom, jakým způsobem data získáváme. Třeba částečně je to řešené i v DataDoo, kde si nastavujeme, jakým způsobem se data uloží. Je to naše a záleží to podle zdroje dat, nemáme jednotné řešení. Reakce na to, jak zpracujeme data, už probíhá v transformační vrstvě.

Jasně, a v DataDoo, pokud se nepletu, tak tam dokonce řeší i změny schématu, že? To znamená, když se změní například API na zdroji…

Když tam máte nový atribut, který chcete z nějakého důvodu načítat, tak vám to zajistí, že se to automaticky zpropaguje i do BigQuery, je to tak?

Ano, určitě.

Super. A potom další vrstva – jakou tam máte modelovací techniku? Máte tam například snowflake, nebo data vault, co tam používáte? V kontextu toho, že jsi říkal, že se snažíte dělat věci hodně přímočaře, jak je vybudováno to jádro?

Tady se snažíme využívat primárně to, že zkombinujeme data, která máme z raw dat Google Analytics, a k nim obohacujeme data z ostatních databází. To jsou například informace o novinkách, kampaních, sportovních událostech. To jsou klíčové věci, které přidáváme, a výsledkem je jedna velká tabulka v transformační vrstvě.

Hodně používáme nesting, takže vlastně z hlediska úspory storage, protože ta tabulka má řádově desítky terabajtů, se snažíme být co nejefektivnější.

Co se týče kroků transformace, snažíme se mít co nejméně – většinou jsou to dva, tři kroky v rámci transformační vrstvy.

Tím nestingem myslíš zavedené komplexní datové struktury uvnitř jednoho pole, že?

Přesně tak. To nám zaručuje efektivitu. Před refactoringem jsme šli nejjednodušší cestou, kdy to byla obrovská široká tabulka, teď je to stále široká tabulka, ale s vnorenými strukturami. Vypadá to skoro jako dokumentová databáze.

Zvolili jsme no-cycle přístup raději než dekomponovaný model.

Beru, že tohle jsou nativní přístupy BigQuery, které v tomto objemu dat skutečně začnou být efektivní. Má to nevýhodu, že při tvorbě dotazů je potřeba trochu uvažovat, jak data například unnestovat, aby dotaz vrátil očekávaný výsledek.

Jasně. A potom, v závislosti na reportingových nástrojích, předpokládám, že data do nástrojů načítáte večer?

Jak kdy.

V analytics projektu máme martovou vrstvu, tam máme, jak jsi se ptal na star schema, snowflake atd., tak nakonec to je kombinace. Z části agregovaných dat je to vlastně ta jedna velká tabulka. BigQuery umožňuje používat HLL engine, který umožňuje počítat různé agregace přes dimenze, které v tabulce jsou vytvořeny, a z toho obsloužíme mnoho požadavků, které jsou předem známé.

Nevýhoda samozřejmě je, že když potřebujete novou dimenzi, není jednoduché ji tam přidat.

Pak jsou tu datamarty bez agregace na úrovni uživatelských ID a tam se snažíme o kombinaci faktových a dimenziálních tabulek. Je to takový hybridní přístup od každého něco, aby nedával smysl vytvářet normalizovanější strukturu.

BigQuery v tomhle funguje naprosto perfektně a umožňuje vytvořit širokou tabulku s určitým nestingem.

Nad datamartem je ještě vrstva, kde připravujeme data pro samotný výstup. Záleží na tom, jaký je výstup.

Pokud je výstup určený pro lidi, snažíme se to mít v rozumné struktuře bez komplikovaného nestingu, maximálně s jednoduchým joinem, což stačí.

Třeba konkrétně pro Tabulo je potřeba mít některé tabulky v „dlouhém“ formátu, takže připravujeme dataset.

Máme extrakty, kde se data stahují přímo na server Tabulo, ale některé věci jedeme live, protože pokud nejsou velké objemy dat, ale je potřeba často měnit dimenze a hodnoty, a nemáme to předem připravené, děláme to takto.

Historizace nějaká? Neřešíte ji? Myslíš situaci, kdy bychom potřebovali přeloadovat historická data – třeba SCR2 v jádru, nebo něco takového?

Někdy skutečně potřebujeme historii ukládat, ne vždycky.

Díky BigQuery a kapacitě jsme schopni celou historii uložit v jedné velké tabulce, kde může být i duplicitní informace, takže to až tak moc neřešíme.

V některých případech ano – například na úrovni uživatelů si ukládáme informace o změnách a o aktuálním stavu.

Takže zase volíme hybridní model tam, kde to potřebujeme, a tam, kde technologie umožňuje, jdeme normálním způsobem podle metodik.

Když jsme začínali s definovanými metodikami, tak je pravda, že byly napsané trochu na dobu, kdy bylo potřeba šetřit každým bajtem. Dnes už se musíme trochu posunout.

Jasně.

A úplně poslední dotaz, omlouvám se, že jsem tak dlouhý, ale máme v komunitě mnoho lidí, kteří milují Rebetéčko.

Ty jsi říkal, že používáte Dataform, já to beru jako konkurenci dbtčka, protože oba jsou do jisté míry open source.

Proč Dataform a ne dbt?

Úplně jednoduše.

Když jsem zkoušel první transformaci v dbtčku a první transformaci v Dataformu, tak Dataform mi byl hotový hned. A to byl primární důvod, proč jsme zvolili jeho.

Nebylo to tak, že bych dělali rozsáhlý výzkum a porovnávali plusy a mínusy.

Dataform se posunul velmi dobře i z hlediska práce s Gitem, má verzování, všechny tyto věci jsou implementované.

Ano, dbt má větší komunitu, je tam spousta pluginů, které vyhovují různým lidem.

Slyšel jsem překvapivě hodně názorů od lidí, kteří Dataform používali a zároveň dbt, a říkali, že kdyby Dataform tehdy znali, šli by raději Dataformem.

Takže to je zajímavé a je to druhý člověk, kdo mi to říká.

Určitě zajímavé.

Já jsem vám posledních 15 minut úplně nerozuměl, ale moc mě těší, že plníte přání našich posluchačů, kteří chtějí větší technický detail a hloubku.

Mám pocit, že na té technologické stránce jste to celkem hezky vyřešili – že to jedete v Google ekosystému, že jste hluboko v nástrojích, že jde hodně o finance a přizpůsobení stacku, protože s tolika uživateli a daty je potřeba, aby to příliš nestálo.

Co je tedy pro tebe ta zajímavá výzva?

Technologická výzva mi přijde celkem přímočará.

Zajímavé je pro mě řízení nákladů za dotazy a řízení businessové hodnoty.

Co tě nejvíc baví v Livesportu na analýze dat?

Proč neběháš po trhu a nepomáháš e-shopům?

Jak říká kolega, máme v podstatě jednoduchá data, výzva je v množství dat.

Máme 60 zemí, stovky jazyků, takže komplexita roste s počtem a různými pohledy.

Například když chceme analyzovat dotazy z Google Search Console, kterých je zhruba 18 milionů denně, kolega to pročistil na pět milionů unikátních dotazů.

Pomáhá nám interní AI tým, kterému jsme trochu zahltili API konektor kvůli množství dat.

Nyní hledáme kreativní řešení, jak zpracovat toto obrovské množství dat, jak to pročistit a zároveň zachovat automatizační nástroje, které nám pomáhají otevírat data.

To je jeden příklad.

Druhý je, že dříve bylo používání aplikace závislé na tom, zda se právě hrálo sportovní utkání.

Sportovní svět určoval chování uživatelů.

Díky tomu, že přidáváme obsah, audio a video, máme redakce a nedávno jsme otevřeli studio na nahrávání, vytvořili jsme nové možnosti.

To jsou věci, které mě velmi baví.

Všechny ty indické sporty, japonské sporty – to je pro nás nové, zajímavé.

Děkuji moc, že jsi byl u nás a povídal o datovém development týmu a o komplexitě řešení spojené s velkým množstvím jednoduchých dat.

Přeji ti, abyste nikdy nepřekročili hranici a vždy měli tah na branku.

Věřím, že se zde brzy znovu uvidíme s tebou nebo s některým členem tvého týmu, protože mám pocit, že v Livesportu děláte spoustu velmi pokročilých a unikátních datových věcí.

Díky moc, že jsi to s námi dnes sdílel.

Děkuji za pozvání, byl to příjemně strávený čas.

Díky moc.

A to je všechno.

Děkujeme, že jste poslouchali až sem.

Děkujeme také našim partnerům – Big Hub, Intex, Saska, Bystreet, Colors of Data, Revolt BI, Good Data, Kebule, E-Mark, Karl Data Company a Datamind.

Pokud vás zajímá více, navštivte naše stránky datatalk.cz a přihlaste se k odběru našeho newsletteru.