Podcast

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datatalk. Mým dnešním hostem je Roman Dušek, Head of Product ve společnosti Luigi's Box. Ahoj, Romane.
Ahoj, Jirko.

My se dnes s Romanem podíváme na to, jak funguje vyhledávání a doporučování produktů (recommendation) v e-commerce a kam se celý e-commerce trh ubírá, jaké jsou tam trendy, protože to je přesně oblast, kde Luigi's Box pomáhá a funguje. Každopádně pro ty, kdo o Luigi's Box slyšíte poprvé právě tady u nás v podcastu – Romane, mohl bys nám, než představíme tebe a tvou kariéru, představit i samotný Luigi's Box?

Určitě. Luigi's Box je technologická firma a v současnosti dodáváme vyhledávač asi třiapůl tisíce e-shopů v Evropě i někde ve světě. Kromě vyhledávače také poskytujeme doporučovací systémy (rekomendéry), produktové stránky a další služby. Naším cílem je, aby e-shopy lépe konvertovaly a více vydělávaly na uživatelích, kteří je navštěvují.

A to bude i naše téma, do toho se podíváme do detailů. Než se ale pustíme do samotného vyhledávání v e-commerce, máš v tom oboru velké zkušenosti. Mohl bys nám tedy povědět, jaká byla tvoje cesta, že jsi skončil jako Head of Product v Luigi's Box? Tvoje kariéra je velmi zajímavá a relevantní.

Tak taková stručná verze je, že jsem neustále pracoval s vyhledáváním v různých firmách. Kdybych začal úplně od začátku, tak jsem studoval aplikovanou informatiku na Masarykově univerzitě, kde jsem se poprvé setkal s programováním. Programoval jsem hlavně databázové systémy, tehdy bylo běžné řešit relační databáze. Asi ve čtvrtém nebo pátém ročníku jsem začal pracovat v prvních startupech, které byly zaměřené na data. Tam jsem se věnoval programování databází.

V jednom z těch startupů jsme vyvíjeli zajímavý produkt jménem UIR – univerzální informační robot. Ten by se dal dnes považovat za předchůdce dnešních velkých jazykových modelů (LLM), i když spíše jako slepá cesta, kterou bylo třeba prozkoumat, abychom pochopili, kudy cesta nevede.

O jakém roce se bavíme a v čem ta cesta nevedla?

Bylo to zhruba před 17–20 lety. Na Masarykově univerzitě byl například předmět „datové modelování“, kde jsme se učili vytvářet datové modely – to znamená analyzovat konkrétní doménu a znázornit ji diagramy s entitami, vazbami, atributy a podobně. Na základě těchto datových modelů vznikla firma, jejímž hlavním cílem bylo zachytit datové modely v systému.

Velkou nevýhodou tehdejších informačních systémů byla jejich rigidita – analýza se provedla, vytvořil se datový model, databázové schéma a na...

Programovalo se kolem toho nějaká funkcionalita a v momentu, kdy klient nebo zákazník chtěl udělat nějakou změnu, museli zase jít za nějakou společností a programátory. Potom se vymyšlely změnové požadavky a podobně, což bylo drahé a hlavně dlouhotrvající.

Myšlenka univerzálního informačního robota byla taková, že existuje datový model, který je vytvořený na úrovni aplikace. To znamená, že si můžu kdykoliv přidávat a měnit. Nebo vlastně nějaká schémata, to znamená, že můžu přidávat nové entity, vazby měnit a podobně. Aplikace nad tím pak uměla pokrýt libovolnou oblast a dotazovat se v přirozeném jazyce na danou doménu. Systém pak měl schopnost automaticky odpovídat.

To je vlastně něco podobného, kam se dnes blížíme s LLM modely. Jenže celý systém byl tehdy postavený na myšlenkách transparentní intensional logiky. Zpracování přirozeného jazyka spočívalo v tom, že jsme se snažili dělat syntaktickou analýzu jazyka, to znamená zjistit, co je předmět, přísudek a podobně, a propojit to s pojmy definovanými v systému. Dneska se ukazuje, že tato syntaktická cesta není správná a spíš se nyní ubíráme cestou LLM.

Na mě je fascinující, že tehdy vektorové databáze moc nefungovaly. Komplexy problém jste se snažili řešit v klasické relační databázi. Pamatuju si, jak jsem měl koupené svazky knih „Umělá inteligence 1, 2, 3, 4“ a pročítali jsme to. Vektorové věci a neuronové sítě tam byly zmíněny pouze jako experimentální, a od té doby se technologie posunuly obrovskou rychlostí.

V tom startupu, kde jsem pracoval jako databázový programátor, jsme programovali v hodně nezvyklém databázovém systému jménem Cache od firmy InterSystems. Ta americká firma má nad tímto systémem například běžící zdravotní systémy v Americe a Evropě, i když tam je méně známý, zatímco v Americe je to poměrně rozšířené.

Proč o tom mluvím? Před dvaceti lety bylo běžné, že pojem „databáze“ byl v podstatě synonymem pro relační databázi. Když se někdo bavil o databázích, měl na mysli relační databázi s SQL a uloženými procedurami. Mezi běžné patřily Oracle, MySQL, Postgres. Nic z toho ale nevyhovovalo potřebám našeho univerzálního informačního robota. Potřebovali jsme něco mnohem...

Bylo to o méně strukturovaných datech, a tak jsme hledali a právě jsme našli databázi Cache, která nabízela možnost vytváření nestrukturovaných nebo více rozměrných vektorů, které se nazývaly globály. Právě kvůli těmto vlastnostem jsme ji využili. V dnešní terminologii jde vlastně o NoSQL databázi, do které jsme si ukládali data ve stromových strukturách a pak jsme řešili, jak je procházet, jak to optimalizovat a podobně. Chápu, že tohle úplně nevyšlo – podle mě byl timing prostě špatný. Kdyby ten pitch deck oprášil dnes, jistě by našel investory, protože ta technologie je bezva.

Ještě během školy jsi tedy začal víc směřovat k startupové a budovatelské dráze, ale pak jsi skočil jinam. Nebyly to totiž naše startupy, spíše jsme tam byli něco jako zaměstnanci. Ale přičichli jsme k tomu startupovému prostředí – bylo nás tam asi patnáct programátorů a hodně nás to naučilo.

Jestli tenhle podcast poslouchá nějaký student, tak mám velké doporučení: nezůstávejte jen u pasivního přijímání znalostí, ale aktivně si je ověřujte, programujte, zkoušejte vymýšlet a realizovat své nápady. Myslím, že nás všechny, kdo jsme tam byli ve startupech, to hodně posunulo.

Tak co tě pak přimělo jít do Seznamu, který rozhodně startup není, ale je českou internetovou jedničkou? Čím tě tam nalákali? A tam tedy začal tvůj další profesní „search“?

Programování mě hodně bavilo, měl jsem menší startupy, které nebyly technologicky zaměřené, spíše na něco jiného. Byl jsem hodně na pomezí, jestli jít kariérou programátora, nebo někam blíž byznysu a podnikání. Pak jsem někde viděl inzerát, že Seznam hledá produktového manažera pro vyhledávání. Vyhledávání mi vždycky přišlo blízké, tak jsem se přihlásil, a ono to vyšlo. Nastoupil jsem přímo do oddělení fulltextového vyhledávání, kde jsem strávil hodně let.

Pracoval jsem tam sedm let a začínal jako produktový manažer. Měl jsem na starosti nejen fulltextové vyhledávání, ale i další úlohy. Například jsme tvořili našeptávač, který pomáhal uživatelům správně formulovat dotaz. To byl jeden z projektů, na kterých jsem se hodně podílel.

Dále jsme řešili vyhledávání v ostatních službách Seznamu, protože Seznam má spoustu vlastních služeb – Firmy, Mapy, Zboží a podobně. Když jsme vedli interní diskuze, bylo jasné, že vyhledávání není jen o odkazech na stránky třetích stran...

Ale je to hlavně o odpovídání, o přinášení informací konkrétnímu uživateli. Začali jsme daleko víc protěžovat to, že na některý dotaz je odkaz na fulltextový výsledek velice dobrou odpovědí, ale u některých jiných dotazů, například když zadám adresu nějakého místa, nebo název nějaké firmy, nebo když hledám třeba černobílé omalovánky, tak se nabízí ukázat jiné entity nebo jiné výsledky. Vlastně jsme tak vyjeli cestou bez míchání fulltextových výsledků s jinými zdroji, které jsme měli k dispozici, a tyto možnosti jsme pak hodně rozšiřovali.

Zeptám se: co vlastně znamenala role produktového manažera v kontextu Seznamu v letech 2010 až 2017, kdy jsi tam byl? Jak moc jsi musel být technický, protože jsi byl součástí vývojového týmu, a jaká byla tvá historická zkušenost? Jak moc jste dělali user research, kvalitativní část, a co to vlastně znamenalo být produktovým manažerem na Seznamu v těch letech?

Myslím si, že s odstupem času byla největší přidaná hodnota v tom, že jsem fungoval jako překladatel mezi dvěma světy. Jeden svět byl svět programátorů a vědců, druhý svět pak byl svět byznysu, který chtěl vydělávat peníze. V té době si tyto světy těžce rozuměly, dnes je to už lepší. Já jsem byl pro byznys ten technický člověk, programátor, který umí mluvit lidsky. A pro programátory jsem byl ten byznysmen, který rozumí světu byznysu. To je něco, co těžím dodnes ve všech firmách, kde působím. Dokážu vnímat požadavky trhu nebo byznys ownerů a umím dávkovat očekávání – co by mělo vzniknout, co je možné stihnout v určitém čase, aby to vůbec vzniklo.

Z pohledu technologií pak jde i o určování vize, kam se chceme vlastně podívat. Už si úplně přesně nepamatuju, kolik lidí jsme měli v týmu fulltextu, když jsem nastupoval, ale když jsem odcházel, byli to stovky lidí ve výzkumno-vývojovém oddělení, kteří byli schopni každý den odvést velké množství práce. A pokud měli jasnou roadmapu, plány a fokus, dokázali toho hodně. Takže přidaná hodnota produktové role je umět správně poukazovat na správné problémy, což byla i taková poučka jednoho mého kolegy z Seznamu, Štěpána Škroba, který vždy říkal, že je daleko lepší...

Je lepší řešit správný problém špatně než špatný problém dobře. Tímto zdravím Štěpána, který stále vlastně ve Seznamu je. Vždycky mi přišla tato poučka jako velice dobrá – soustředit se opravdu na ty největší výzvy, na ty největší problémy a na ty největší příležitosti, které tam jsou. Po Seznamu jsi šel do mall.cz v roce 2017, což už je zase trochu něco jiného. Seznam je i e-commerce částečně, určitě online, ale mall.cz je úplně e-shop. A teď příklad potenciálního zákazníka Lujgis – tam jsi šel řešit zase fulltextové vyhledávání.

Zase search, no... vlastně mě u Seznamu, nechci říct, že to úplně vadilo, ale je tam to, že uživatel fulltextového vyhledávání vlastně neplatí za službu. A je tam někdo jiný – inzerent, který biduje na určité klíčové slovo, a v momentě, kdy uživatel klikne na inzerát, Seznam tím vydělá peníze. Jsou tam tedy dva uživatelé – jeden, který službu používá, a druhý, který ji platí. Tohle je vlastně komplikující faktor při výrobě produktů pro takové služby, protože je tam navíc určitá komplexnost. Co jsem si chtěl vyzkoušet, bylo vytvářet službu, například vyhledávání pro e-shop nebo jinou službu, kde uživatel zároveň tu službu platí. To znamená jít do e-commerce. To byla přirozená linka, která mě lákala, protože tam se vše dělá proto, aby uživatel viděl správné produkty na správných pozicích a aby si je pak koupil. Proto jsem šel do e-commerce.

Jak tam vypadal tým a co jsi tam vlastně řešil?
Já jsem přišel do searchového týmu vlastně jako první, protože nikdo jiný tam nebyl. Měl jsem za úkol searchový tým založit. Kvalita vyhledávání v Mallu byla velice špatná. Pamatuju si první dotazy, které jsme tam zadávali. Například, když někdo zadal dotaz „elektrická trouba“, našel mu to „elektrickou kytaru“. Byl tam sice částečný shodný výraz „elektrická“, ale výsledek byl naprosto vzdálený tomu, co uživatel chtěl. Takže základní relevance byla velmi špatná a ještě jsme se nebavili o nějakém rankingu nebo o napojení na byznysové cíle. Potřebovali jsme hlavně zajistit, aby základní relevance fungovala dobře.

Tak jsme to dělali pozvolna a postupně vznikal realizační tým. V době největší slávy měl tým asi šest lidí – pět vývojářů a jednu administrátorku vyhledávání, Ivču. Ta nám pomáhala s některými věcmi, protože ne všechny věci je efektivní dělat programátorsky. Některé je lepší nastavit přímo v administraci, například synonyma nebo různé výjimky a customizace.

Podobně jsme všechno teď řešili. Měli jsme tam silný tým a dostali jsme se do takového stavu, že po několika letech, vlastně asi pěti letech, jsme vyřešili hlavní problémy toho vyhledávače. Myslím, že první tři roky trvalo, než jsme vyřešili ty klíčové problémy, jako například problém relevance a základní problém s rankingem, aby uspořádání produktů odpovídalo nějakému byznysovému pohledu, aby náš vyhledávač fungoval dobře a aby tyto služby byly efektivní. Navíc jsme tehdy měli ambice ten search engine dále rozšířit na další entity v rámci Mall Group.

Mall v tu dobu fungoval v několika zemích – Česko, Slovensko, Polsko, Slovinsko a Chorvatsko. Takže jsme pracovali na službě pro více jazyků, a to i pro jazyky, kterým nerozumíme, což byl velký rozdíl oproti Seznamu. Do skupiny patřily i další e-shopy, například Vivantis nebo Košík, takže jsme řešili, jestli nejsou nějaké synergie a jestli bychom nemohli stejný search engine použít i tam.

Nyní se dostáváme k Luigi's. Proč jste nepoužili Luigi's? Ještě předtím, rok předtím, než jsem šel do Luigi's, proběhla akvizice Mallu a Allegra, a začali jsme úzce spolupracovat s Allegro search týmem v Poznani. Byl to velmi zkušený tým, který vedl Adam, a pravidelně jsme tam jezdili na knowledge transfer. I když firmy vznikaly paralelně, základy a principy, na kterých byly postaveny, byly velmi podobné.

Takže ty jsi zažil Mall a Allegro, a podle toho, co říkáš, není to takový průšvih, jak se možná z českého trhu může jevit, že Allegro úplně nezvládlo sloučení s Mailem. Mě vždycky zajímal technický pohled, ten svět technologií, a byli jsme v úzkém kontaktu s Allegro search týmem, který měl zhruba 30 lidí, zatímco v Mallu jsme byli v technologickém týmu 6, takže byli pětkrát větší.

Spolupráce byla velmi dobrá a bylo vidět, že v některých oblastech jsou oni výrazně dál, například v některých machine learning oblastech. Naopak v jiných oblastech jsme byli zase my dál. Například jsme měli komponentu pro query understanding – tedy pro rozpoznávání záměru a významu dotazu. Dokázala rozdělit dotaz a určit, zda obsahuje kategorické či brandové složky, a podle toho se pak na míru přizpůsobit vyhledávání. Na tom jsme se aktivně zaměřovali.

No a zpátky k mému dotazu...

Proč tehdy už Luigi's Box existoval? Proč si místo budování týmu šesti lidí raději nekoupil hotové řešení? My jsme vlastně začali někdy v roce 2022 dostávat otázky od dodavatelů vyhledávání, předtím jsme tyto dotazy moc nedostávali. Ale někdy kolem let 2021–2022 jsme začali být oslovováni, jestli neplánujeme přejít na nějaké existující řešení.

Pro mě to bylo období, kdy jsem se poprvé setkal s týmem Luigi's Box na nějaké obchodní schůzce. Myslím, že to bylo během covidu, takže vše probíhalo na dálku, a my jsme se tam potkali a bavili o možnostech, jestli by se jejich řešení dalo použít, nebo ne. Zároveň jsme diskutovali i s jejich konkurencí.

Kdybychom toto rozhodování dělali v roce 2020, nebo ještě dřív – a já si přesně nepamatuji, jestli to bylo rok či dva dříve – ale kdybychom ho udělali někdy před pěti lety, kdy jsem nastupoval do MOLu, pak by se jednalo o velmi relevantní otázku: zda vůbec budovat vlastní tým, nebo použít řešení od třetí strany. Trvalo nám totiž tři roky, než jsme vytvořili řešení, které začalo fungovat.

Když se na to dívám z businessového pohledu, pokud bych mohl po podepsání smlouvy mít dané řešení okamžitě, tedy ne zítra, ale v dohledné době, ušetřil bych roky vývoje a značné náklady. Jak už zmiňoval kolega, měli jsme pět až šest lidí v realizačním týmu, což představuje vysoké personální náklady. To by určitě stálo za zvážení.

Předpokládám, že návratnost investice byla pozitivní, tedy že z tohoto zlepšení výkonu (upliftu) jste zaplatili tým, ale je to otázka time to delivery.

Je to zajímavé. A pojďme tedy k Luči. Když teď půjdu na internet a budu si chtít něco koupit, kde v tom máte prsty?

Začněme takhle: když jsem představoval Luči v medailonku, zmínil jsem, že v současnosti máme asi tři a půl tisíce nasazení – tedy stránek a e-shopů, které využívají naše služby. Kdybych měl jmenovat některé naše klienty – pokud nakupujete na Alze, Notínu, Dr. Max, Sportissimu, Planeo nebo dalších velkých e-shopech, při vyhledávání na těchto stránkách používáte naše služby.

Když tam napíšete „elektrická trouba“ a vyskočí vám kytara, buď vás znají moc dobře, nebo si můžete stěžovat Romanovi. Pokud to uděláte třeba na Muzikeru a zadáte „elektrická trouba“ a dostanete elektrickou kytaru, pak si myslím, že je to docela dobrý výsledek.

No, dobře, tohle jsou vaši klienti, ale co pro ně vlastně děláte? Co znamená být vaším klientem? My v současné době nabízíme e-shopům tři hlavní produkty. Prvním je vyhledávání – search bar – kde uživatel píše...

Někdo něco píše do vyhledávacího pole, objeví se mu nějaké našeptávané výsledky, tedy vlastně našeptávač, který tam funguje. V momentě, kdy ten dotaz poté potvrdí tlačítkem Enter nebo klikne na nějakou frázi v našemptávači, dostane se na stránku s výsledky hledání. Tam potom vidí tzv. facetovou navigaci. Celá tato interakce s vyhledáváním je to, co my dodáváme a co vidí uživatel.

Kromě toho je tu ale také něco, co uživatel nevidí, ale vidí to klient – a to je detailní analytika. Máme podrobnou analytiku, kde si klient může prohlížet, jaké dotazy jsou vyhledávané, jak dobře tyto dotazy fungují a jaké jsou největší problémy s těmito dotazy. Například dotazy, na které klient nemá žádné výsledky. Často se stává, že uživatelé přicházejí s očekáváním, že na daném e-shopu najdou určitý produkt, zadají dotaz, ale místo výsledků se jim zobrazí informace „bohužel, nic jsme nenašli“.

Tahle informace je ale velmi zajímavá pro byznysové týmy e-shopu, protože tyto „chybějící“ dotazy mohou otevřít příležitosti pro vytvoření nové kategorie, zavedení nového brandu nebo rozšíření sortimentu. Problémy mohou být různého charakteru. Například dotazy, které se sice shodují s kategoriemi, které e-shop nabízí, ale chybí jim konkrétní produkt. Nebo dotazy směřující na celou skupinu produktů či divizí, které e-shop ani nemá, ale uživatelé je očekávají.

Dám příklad z MOLu, kde jsme měli podobný report. Viděli jsme, že uživatelé hledají sortiment z oblasti farmacie, protože MOL se prezentoval jako komplexní prodejce a tvrdil, že má „všechno“. Lidé proto hledali i lékárenské produkty. My jsme však museli říct, že tyto produkty v sortimentu nemají. Z analytiky jsme ale viděli jasný signál – existuje poptávka po těchto produktech a pokud by se do nabídky zařadily, mohly by se velmi dobře prodávat.

U nás lze díky analytice sledovat také trendy v dotazech. Takže analyzujeme nejen dotazy bez výsledků, ale i ty s nízkou konverzí. To znamená, že uživatelé najdou, co hledají, ale například kvůli špatné dostupnosti (produkt není skladem, očekávaný termín doplnění za dva týdny) či nevýhodné ceně odejdou.

Máme na to reporty, které identifikují nízko konvertující dotazy, tedy takové, které mají vysokou návštěvnost, ale nízkou konverzi. Tyto dotazy stojí za podrobnější analýzu a případné optimalizace.

Jeden produkt je ten search, autocomplete nebo našeptávač, a k němu vlastně nějaká analytika. Potom máme další velký produkt, a to je doporučovač (recommender). To znamená, že máme opět nějaký e-shop, který má mnoho typů stránek – homepage, kategorické stránky, detail produktů, checkoutovou stránku. Na všech těchto stránkách se nabízí uživateli ukazovat produkty, které by ho mohly zajímat.

Každá stránka má nějakou specifickou vlastnost a hodí se na ni jiná strategie doporučování produktů. Například na homepage, která je pro mnoho lidí vstupní stránkou, bych očekával aktuálně trendující produkty na e-shopu. Případně tam můžou být produkty, na které se uživatel díval při poslední návštěvě, ale ještě je nekoupil a nedokončil nákup – tyto mu tam můžeme také ukázat, což bude dobře fungovat.

Naopak v detailu produktu se hodí zobrazovat alternativy daného produktu. Když se například podívám do sekce módy na tričko, rád bych viděl podobná trička či trička v jiných barvách. Je to celá řada strategií, co se tam dá nabídnout. U elektroproduktů mě mohou zajímat doplňky – například k mobilu si můžu koupit kryt nebo ochranné sklo.

Je zajímavá psychologie, jak nad tím přemýšlet, protože detail produktu je paradoxně nejčastější vstupní stránkou e-shopu. Většina lidí na e-shop nejde „předními dveřmi“ přes homepage, ale přichází z Googlu, Heureky, různých srovnávačů nebo Facebooku přímo na detail konkrétního produktu. Když se uživatel dostane na detail produktu, nastávají dvě možnosti: buď je to přesně ten produkt, který hledal, nebo ne. V případě, že to není přesně ten produkt, chybí doporučovač, který by mu ukázal alternativy, nebo doporučil další produkty, které by mohl koupit zároveň, aby mohl nakoupit vše na jednom místě.

To přesně pomáhají rozehrát rekomendery a zároveň k nim máme analytiku, která dokáže vyhodnocovat a říkat, jak jednotlivé pozice fungují. To znamená, zda je například rekomendační strategie na homepage dobrá, nebo zda by měla být nahrazena jinou strategií.

Když se zeptám, jestli je to všechno automatizované a statistické, nebo jestli je v tom i nějaká "chytristika"...

Homepage se využívá pro tyto tři strategie a přepíná se mezi těmi dvěma strategiemi. Jak řešíte ten problém s komplexitou? Chápu, že nějaké A/B testování výkonu jednotlivých produktů je jedna věc, ale to, co říkáš – to know-how o tom, jak využít homepage, jak se chová detail produktu, jak by to mělo vypadat v patičce nebo jinde – to je vaše know-how a chytré řešení zabudované do systému, které se mění dynamicky, přetrénováváním modelů, a je to úplně živé. Když se změní trh, tak se modely přetrénují. Nebo jak to funguje uvnitř?

My děláme velké množství A/B testů. V tom si myslím, že jsme dobří, protože máme tisíce jednotlivých stránek, na kterých máme nasazené naše služby, a jsme schopni provozovat opravdu velké množství A/B testů. Dokonce před nějakým rokem jsme spustili vlastní A/B testovací platformu, kterou využíváme na vyhledávání a připravujeme ji i pro jiné účely.

Tak abychom mohli dělat ještě větší objem A/B testů. Často klienti chtějí, aby u nich tyto testy probíhaly, protože je to jednoduchý způsob, jak zvýšit výkon jejich řešení. Když si udělám srovnání, kde jsme byli například na Mallu, tak tam jsme zvládali maximálně jeden A/B test za dva měsíce. Vždycky trvalo nějakou dobu připravit řešení, potom test běžel třeba měsíc a následovalo vyhodnocení. Navíc jsou i nevhodná období pro A/B testování, například letní prázdniny, Black Friday nebo přelom roku. Reálně jsme tak byli schopni odběhnout asi sedm A/B testů za rok, přičemž každý druhý nevyšel kvůli nějakým problémům a musel se restartovat, takže jsme měli třeba čtyři experimenty, které nás skutečně posunuly dál.

Když jsme začali spolupracovat s Luigi's Box, tak jedeme v úplně jiné dimenzi. I průzkum všech slepých uliček a možností je mnohem rychlejší. Máme všechny klienty rozdělené do různých průmyslových segmentů a každý segment se chová jinak. Máme například fashion segment, CIT (spotřební elektroniku), PET segment a další, podle sortimentu, který klienti nabízejí. Víme tedy, že chování uživatelů se v jednotlivých segmentech výrazně liší.

Pokud by to někoho více zajímalo, vydáváme pravidelnou ročenku, kde jsou tyto segmenty podrobně popsány. Kdo chce, může se podívat na náš web Luigi's Box, kde materiál najde. Ukazujeme tam například rozdíly v konverzních mírách pro jednotlivé průmyslové segmenty. Opravdu se to liší i v tom, jak se naše služba v každém segmentu používá. Nastavení a implementace těchto chytrých řešení je tedy...

Něco na základě zkušeností a dat, které máme s uživateli, když řeší daný průmysl. Přesně tak. Zároveň hodně těžíme z postojů našich klientů, protože díky nim máme silný vhled do byznysu a do toho, co se tam děje. Často vidíme komplexitu toho, co musí e-shopy zvládat a jakou hru vlastně potřebují uhrát.

Toto je důležité, protože nejde jen o to optimalizovat všechny e-shopy pro zvýšení třeba příjmů, ale víme, že tam vstupuje mnohem víc postojů a zájmů, které e-shopy musí řešit. Postoje a zájmy jsou například růst na dluh versus ziskovost. Nebo v případě Notina jde třeba o reklamní síť pro partnery, dále vstupují skladové zásoby a další faktory.

Každý e-shop má své byznysové cíle, většinou krátkodobé a dlouhodobé, a často řeší poměr mezi tím, jestli potřebují optimalizovat spíše na růst tržeb, nebo na profitabilitu, tedy zvýšení marže. To je základní rozdělení.

Pokud se podíváme detailněji, jde i o řízení skladových zásob. E-shopy často řeší například potřebu vyprodat část skladu, aby získaly hotovost (cash), kterou pak mohou využít jinde. Tím se také dotýkáme dalších cílů a dohod. Mnoho e-shopů má dohody s různými vendory o propagaci nebo o výpočtu marže. Ne každý sortiment se prodává tak, že za každý prodaný kus získám marži. Obchodní podmínky často bývají složitější.

Může jít například o objemové marže – prodávám produkt s minimální marží, ale po dosažení určitého množství prodaných kusů (například tisícátého) dostanu od vendora zpětný bonus. Když se na tyto úlohy podíváme technicky, automatizace, která by upřednostňovala produkty s vyšší marží, nemusí do tohoto zapadat. Marže na jeden produkt je nízká, ale až po prodeji tisíců kusů se marže zvyšuje. Je tedy důležité umět pracovat i s budoucí (potenciální) marží, nebo s nějakou ...

Jako prioritu. A může to být lokální, to znamená, že tato pravidla mohou být rozdílná pro různé divize, segmenty nebo kategorie. Když máte komplexnější firmu, která má celý tým lidí starajících se o sortiment, mohou být zájmy v jednotlivých divizích, segmentech a kategoriích odlišné.

Promiň, ještě se dostaneme k e-commerce. Ještě jeden produkt, Magneteda, abych nevynechal produktovou nabídku. Mluvil jsem o vyhledávání (search) a doporučování (rekomendaci). Třetí, který máme vytvořený a který používají naši klienti, je product listing, často označovaný jako PLP (product listing page) nebo category page, tedy stránka kategorie. To znamená, že když přijdu do kategorie, vidím produkty. Kromě produktů vidím také filtry, různé filtrační možnosti, fasety a nadkategorie.

Toto je něco, co známe ze všech e-shopů. Často jde o výpis z databáze s různými parametry. Je to jeden z nejstarších typů stránek na e-shopu a často je opomíjená, přestože na ni přichází třeba 50 % návštěvnosti. Lidé často začínají právě v těchto kategoriích.

Problém je, že kategorie nemají k dispozici nástroje, pomocí kterých by bylo možné naplňovat obchodní cíle. Konkrétně má e-shop kategoriální manažera, který řídí sortiment. Ten by chtěl například přesunout produkt z třetí pozice na první a věnovat mu více pozornosti. Rád by uspořádal produkty jinak nebo změnil strategii řazení v kategorii, případně upravil facetovou navigaci.

Kategorie manažer je expert v dané oblasti a ví, že například u knih nechceme podle značky (brand), jak je to běžné v elektronice, ale spíše podle autora knihy. Chtěl by si uspořádat parametry podle svých potřeb, určit, kolik se jich na první pohled zobrazí, a jaká bude jejich struktura.

Celá customizace facetové navigace, subkategorií (kategorií zobrazovaných nad produkty) je něco, co nabízíme. Když e-shop využívá naše PLP řešení, obvykle je to proto, že chce tyto úpravy provádět. Jeho systém to často nenabízí nebo jen omezeně. V takovém případě je potřeba vytvořit změnový požadavek, který se pak priorizuje, plánuje, analyzuje a po několika týdnech může být realizován, jakmile na to přijdou programátoři.

A to není to, co chce ten daný člověk v kategorii slyšet. Ten potřebuje jednoduchý systém, pomocí kterého si může dělat ty customizace podle toho, jak ten byznys běží. A zároveň má k dispozici analytiku, která mu říká například, které kategorie jsou problematické. To je přesně i to, o čem jsme si povídali u vyhledávání – které kategorie mají vysokou návštěvnost a přitom nemají konverze. To je velmi zajímavé, protože když jsme se...

Když jsme se o tom bavili, úplně jsem nechápal, proč máte produkty takto rozdělené. Pro mě je to prostě doporučování na různých úrovních, personalizace, prostě „poznej svého zákazníka“ a snaž se zvýšit marže nebo příjmy. Teď začínám chápat, že jsou to tři různé úlohy a produkty možná s jiným uživatelem na druhé straně, tak to chápu. Co mají společného? Je tam nějaká chytrost? Všichni vaši klienti, nebo u té produktové nabídky vidím, že je to víc frontendové, tedy umím si uspořádat svoji stránku, a u těch ostatních je to spíš datové doporučování. Co je tedy ta spojovací věc? Znáte uživatele a můžete nastavit strategii doporučování produktů?

Jednou z hlavních vlastností, kterou máme, je personalizace. Personalizaci používáme ve všech produktech jako sdílenou službu, to znamená, že víme, jaké jsou zájmy uživatele a co je jeho záměr. Máme krátkodobou personalizaci na úrovni relace (session) a dlouhodobou personalizaci. To samozřejmě ovlivňuje i kategorie – například u módy jsou krátké sessiony a uživatelé se často vrací, zatímco u elektroniky či drahých věcí použijeme historická data o uživateli. Do personalizace také vstupují různé atributy nebo entity, na které se zaměřujeme – například které kategorie jsou pro uživatele zajímavé, nebo jaké hodnoty atributů preferuje. V módě, pokud víme, že uživatel v obuvi nosí velikost 44, můžeme s touto informací pracovat. Stejně tak pracujeme s informací o citlivosti na cenu uživatele – například v některých kategoriích hledá spíš levnější produkty a v jiných zase prémiové. To je také něco, co do personalizace silně vstupuje.

Toto jsou věci, které jsou sdílené napříč produkty a které využíváme. A teď ještě k produktové stránce – přinášíme stejný zážitek, který dnes nabízíme ve vyhledávání, i do světa kategorií. To je hlavní výhoda našich kategoriálních stránek. To znamená, že například personalizujeme řazení na základě velkého množství signálů – pokud někdo potřebuje zohlednit marži (D&M marževost), popularitu nebo krátkodobou či dlouhodobou personalizaci, nebo cokoli jiného, všechny tyto nástroje má k dispozici. To se našim klientům velmi líbí, zároveň mají i stejné možnosti customizace...

Tosti – to znamená, že když potřebují upravit tu stránku, aby obsah stránky nebo produkty byly uspořádány jinak, mají tyto možnosti. No a pak je tam samozřejmě velká přidaná hodnota pro uživatele, protože když si vezmu sám sebe – přijdu na nějaký e-shop, který prodává například notebooky, a chci si koupit notebook – tak pro mě je často úplně jedno, jestli půjdu do menu, kde najdu nějakou podkategorii „notebooky“ a koukám se na výsledky, nebo jestli do vyhledávání napíšu „notebooky“. Z hlediska UX a jednotného uživatelského zážitku bychom měli dostat do stejného místa se stejnými nástroji. Nemělo by být tak, že vyhledávání mě pošle do výsledků hledání s jinými nástroji než kategorie.

Takže tím, co se snažíme docílit skrze portfolio, které nabízíme, je to, aby zážitek uživatele byl co možná nejvíc jednotný. Aby tam nebyl žádný předěl, kde by musel zákazník přemýšlet, že teď pokud chce využít například filtraci, musí jít po určité cestě v e-shopu.

Dává smysl, když jsi tady říkal, že vás používá Notino a Alza a vytvářejí si to vevnitř?

A tím pádem – kdybys byl teď v search týmu MOLu nebo Allegra, na co by ses zaměřil, aby pak mohl přijít Luďěk z Bos a všechno fungovalo? Kde je přidaná hodnota interního týmu, když ostatní funkce si mohu koupit od vás, od nějaké konkurence, tedy že už existují out-of-the-box řešení pro velmi komplexní věci a nemusím tři roky vyvíjet vlastní řešení?

Vidíme totiž trend u velkých společností, které se čím dál více učí některé věci outsourcovat, dokonce i ty, které dříve outsourcing odmítaly. Motivace je jasná – vývojové týmy nejsou levné, takže jde jednak o náklady a pak také o know-how. Je jedna věc naprogramovat vlastní AI nebo machine learning řešení, ale druhá věc je to ladit, zjistit slepé uličky a správné přístupy. To znamená řešení validovat v praxi, například pomocí A/B testů.

Zároveň je otázka, jestli mají e-shopy dostatečný výtlak, aby mohly provádět desítky, stovky A/B testů ročně, aby zjistily, co funguje a co ne a jestli konfigurace je správně nastavena.

Myslím, že díky tomu, že máte Notino a Alzu mezi klienty, je těžké argumentovat proti tomu, že pokud si tyhle firmy službu kupují, pro koho vlastně dává smysl stavět vlastní řešení od základu. Tedy pokud nejsou tak specifické a nemají extrémně specifické potřeby.

Ten tým spíš uplatnil datovou kvalitu a vstupy? Nebo je to spíš o pochopení byznysu, na kterou stranu mám ten přepínač—revenue versus marže—v daný moment přepnout? Je to o positioning a podobně? Kdybys byl dneska v situaci, že tě zase přemluví do Mallu a chtějí, abys řešil search, pravděpodobně bys vzal lidi s sebou, předpokládám. A čemu by ses věnoval ve volném čase?

Určitě by to byla datová kvalita. Ta je zásadní, stejně tak i množství informací, které jsme schopni dnes dodat do vyhledávače nebo vůbec do nástrojů pro product discovery. E-shopy dnes často disponují obrovským objemem dat, ale to, co skutečně potřebujeme, je, aby data byla aktuální, v dobré kvalitě a dostatečně rozsáhlá. Často je trend, že e-shopy rozšiřují svojí nabídku o sortiment třetích stran, a ne vždy se jim podaří udržet kvalitní obsah, správnou kategorizaci a klasifikaci parametrů.

Typicky jsme to viděli třeba v Mallu, konkrétně v fashion segmentu. Když jsme přebírali barevná schémata od dodavatelů módy, zjistili jsme, že v barevné facete bylo desítky až stovky nejrůznějších variant: modrá, modré, blue, blue-green a další. Nebylo to potřeba sjednotit a normalizovat, aby s tím šlo smysluplně pracovat. To je oblast kvality dat, a také jestli jsou k dispozici všechny relevantní parametry, které jsou důležité pro výběr produktu.

Druhou klíčovou věcí je hluboké pochopení byznysu, o který jde. Naše technologie dnes umí spoustu věcí přizpůsobit a dají se s ní dělat zajímavé věci, ale pořád je potřeba jasně vědět, co chceme dosáhnout a umět tybyznysové potřeby přetavit do podoby, kterou naše discovery nástroje dokážou dobře zpracovat.

Můj dojem je, že současným trendem je, že technologie se stále více komoditizují, ať už to jsou data, lidé nebo softwaroví inženýři. Přidaná hodnota tedy roste hlavně v porozumění byznysu, segmentu a celkově doménové znalosti.

Když se ještě vrátíme k Fujitsu Boxu, abychom to nějak uzavřeli: Když to vezmeme jako software, jak to běží, jak to funguje, na čem to stojí? Jako technologický podcast se ptám – spouštíte to on-premise, nebo jste cloudová firma?

Využíváme cloud, konkrétně AWS, což nám hodně pomáhá řešit naše potřeby. Pokud klient spustí velkou kampaň, dokážeme rychle navýšit prostředky na AWS, takže můžeme škálovat zdroje podle potřeby. To je zásadní hlavně při akcích jako Black Friday, kdy naši klienti startují kampaně s různým načasováním a tlakem na traffic.

Ak je něco výrazně větší, a z hlediska tech stacku, co máme, tak třeba ten search a některé další věci máme postavené vlastně nad Elasticsearch, potom hodně používáme Python, Javu, a také Ruby on Rails. To je pod kapotou, a navíc AWS. Jak to vlastně klienti konzumují? Funguje to tak, že je to API, a když teď napíšu na Alze vyhledávací dotaz, tak vy mi na to odpovídáte? Mají to nakešované, napočítané každý den, nebo jaká je tam logika?

Máme vlastně dva typy integrací, které nabízíme našim klientům – frontendovou a backendovou. Ta backendová znamená, že klient dotazuje přímo naše API, které má k dispozici. U frontendové integrace obsluhujeme celý ten frontend, což znamená, že uživatel s touto integrací má méně starostí a nemusí integraci řešit na své straně. My tam zajišťujeme také vykreslování na straně klienta. Oba typy integrace tedy fungují.

Teď jsem se hodně divil, že máte vlastní frontend. Pro mě bylo jasné, že napočítáváte data a posíláte je přes API headless, protože když jsi mluvil o produktech a analytikách, tak je pravděpodobné, že to konzumují i ve svých vlastních řešeních. Jak ale váš frontend vypadá? Proč je pro vás frontend důležitý, když je to součást datové infrastruktury klientů?

Pro nás, nebo vlastně jako součást našeho řešení, dodáváme celý analytický balík, který máme k dispozici. Klient se do něj přihlásí a vidí, co se děje s produkty, s vyhledáváním, s recommendery, s product listingem a podobně. Má tam možnost dělat jakoukoliv customizaci. Hlavní myšlenka je podobná tomu, jak funguje autonavigace – nastavím si cíl a autonavigace mě drží zaměřeného na cíl, ale zároveň mám kdykoliv možnost odbočit z trasy a udělat to, co potřebuji nebo považuji za vhodné. Není to tak, že si cíl nastavím a musím stoprocentně jet podle přednastavené trasy.

Stejný přístup máme i u customizace našeho řešení. Snažíme se maximálně automatizovat a udělat vše autonomní, protože většina klientů nechce věci nastavovat a očekává, že my jako technologická firma máme know-how a nastavíme jim to správně. Na druhou stranu však někteří klienti z různých důvodů chtějí nebo potřebují udělat customizace, které mohou jít i proti standardnímu napočítání, protože mají jiné cíle nebo představy, co potřebují udělat.

Pro takové případy potřebujeme docela robustní řešení. Produkcionalizace našeho řešení tedy není jen o tom, že někde dáme API a řekneme „to je všechno“, ale naopak je kolem toho spousta nástrojů, které umožňují klientům ovládat a přizpůsobovat řešení tak, aby měli lepší kontrolu.

Širší vhled vlastně do toho řešení.

Aby byli informovaní o nějakých novinkách, aby věděli, jak se tam zlepšení dějí a podobně. Takže si tam můžu zadat, že chci zvyšovat marže, ale potřebuji prodat hodně těchto tenisek například. Nebo, jak jsem tady třeba zmiňoval, jde o podporu těch A-B testů, což znamená možnost jednoduše na uživatelské úrovni si vyklikat, že chci spustit nějaký A-B test, který například nějakým způsobem ovlivňuje marži, a potom jednoduše vidět výsledek, který je snadno čitelný. To je vlastně jedna věc, která se týká frontendu.

A druhá věc je přímo u našich klientů, kterým dodáváme naše přehledové stránky s výsledky a podobně. To je pak taky nějaká frontendová knihovna, která tam běží. Vstupují do toho trendy, jako třeba sezónnost a další datové vstupy, což předpokládám, že je i počasí. A také – z jakých datových zdrojů vlastně vychází doporučení? Například když začne pršet v téhle oblasti, zda doporučovat deštníky, když to přeženu.

Co je na tom vlastně ještě nevyřešené? Chápu, že každá firma je specifická, takže každá to má nějak na míru a mění se to v čase. Jsou tam ještě nějaké trendy, které do vyhledávání a do celé téhle kategorie vstupují? Co se tam mění? Ono by se mohlo zdát, že vyhledávání je stabilizovaná a pevně daná oblast. Ty jsi s námi musel řešit sedm let, takže to už máš někde zaznamenané, ne?

Ale těch věcí, které se tam neustále mění, je celá řada. Hodně to ovlivňují změny na trhu. Když se podíváme, kam se celý trh vyvíjí a posouvá, tak dnes většina uživatelů používá mobilní zařízení, a to nejen k výběru, ale i k samotnému nákupu produktu. Před pár lety to ještě nebylo tak běžné – dřív se vybíralo na mobilu, ale produkt, například ledničku, jsme koupili až doma na desktopu. Dnes už to neplatí. Dnes se produkty vybírají i kupují přímo na mobilu a je zde silný tlak e-shopů, aby se celý proces výběru a nákupu co nejvíc zjednodušil.

To, co i my podporujeme a co je naším cílem, je, aby se veškeré nákupy realizovaly během první návštěvy – první session. To znamená, že když na e-shop přijde uživatel, který je rozhodnutý nakoupit, měl by v rámci první návštěvy vybrat produkty, vložit je do košíku a zaplatit. Takže cílem je, aby výběr produktů neodkládal na někdy jindy.

Jak jsem zmiňoval, změny v trendech jsou znát. Například vstupují segmenty, které dříve byly ryze offline. Za poslední roky to je hlavně segment potravin – online objednávání jídel z restaurací s dovozem, online supermarkety a podobně. To před pár lety nebylo zvykem, teď to už patří k normálu a uživatelské chování i zvyklosti se zásadně změnily.

U těchto klientů pak vidíme, že jejich zákazníci jsou zvyklí vlastně j…

Jako jeden den si to, nebo v nějaký moment, vyber si ty věci, vyklikej je, přidej do košíku a očekávej, že doručení proběhne ještě tentýž den. A je tam vlastně silná vazba na logistiku daného e-shopu. To znamená, že některé e-shopy, které prodávají běžný sortiment, mají často jeden centrální sklad, ze kterého pak rozesílají veškeré zboží.

Ale s čím se setkáváme čím dál častěji, je, že e-shopy mají více lokálních skladů, ze kterých mohou zboží dodávat rychleji. A teď vlastně přijdou za námi a ptají se: „Umíte to? Umíte využít informaci o tom, že uživatel je z nějaké oblasti, a vydávat zboží přímo z lokálního skladu?“ Tyto věci pak silně ovlivňují svět vyhledávání, respektive svět produktového vyhledávání (product discovery).

Já si to vysvětluju tak, že jsme rozmazlení tím, že už existuje doručení na další den, a konkurence je velká. Když to nemá jeden e-shop na skladě, může to mít ten druhý, a zákazníci už nejsou tak loajální. Takže pokud chcete, aby se zákazník soustředil právě na vás, musíte to zvládnout.

Co se týká současného datového trendu, jak do toho všeho vstupuje doba generativní AI a jazykové modely – týká se vás to? Z mého pohledu ve světě doporučování je to spíše statistika, tradiční machine learning a číselné modely než zpracování přirozeného jazyka?

Naše řešení jsou postavené právě na machine learningu. Všichni zakladatelé Luigi’s Box mají doktoráty z umělé inteligence a machine learningu, takže firma vznikla jako reakce na jejich hluboké ponoření v této oblasti. Machine learning je tedy v naší firmě opravdu hodně prosáklý.

Pokud se podívám na aktuální trendy, velmi nás zajímají velké jazykové modely (LLM). Klienti se nás často ptají, jak je používáme a jestli je vůbec využíváme. Dnes připravujeme čtvrtý nový produkt, který chceme brzy uvést na trh – shopping assistenta. Nejedná se úplně o chatbot, spíše o trochu jiný přístup.

Na trhu je dnes celá řada chatbotů, ale v podstatě jen zprostředkovávají komunikaci mezi uživatelem a LLM modelem, přičemž přidaná hodnota není příliš vysoká. Z mého pohledu také není silná ochota uživatelů k používání takových chatbotů. Je to jako s telefonem – když vám zavolá člověk, chcete si s ním povídat. Když však cítíte, že na druhé straně je robot, většinou jste k tomu skeptičtí.

100 % nestojíte, takže ji vlastně neřešíte. Naše myšlenka shopping assistenta je ale trochu jiná. To, co vlastně řešíme, je problém výběru produktů v určité kategorii. Představ si, že přijdeš do e-shopu a chceš si vybrat nějaký produkt — třeba piano nebo keyboard. Velmi záleží na tom, jestli jsi expert v dané kategorii, nebo ne.

Když jsi expert a znáš piana a keyboardy, je pro tebe úloha vybrat keyboard velmi jednoduchá. Znáš terminologii, názvosloví, víš, které značky jsou kvalitní, které naopak horší. Znáš cenové rozpětí a víš, jak jednotlivé atributy ovlivňují cenu. S výběrem ti tedy pomáhat nemusíte.

Když jsi expert, přijdeš do kategorie, podíváš se na faceted navigaci, na parametry, které tam jsou, klikáš, nastavuješ filtry, zadáš vyhledávání a vybereš si z několika produktů. Pro tebe je výběr otázkou sekund, desítek sekund nebo maximálně několika minut.

Horší je to, pokud nejsi expert a nerozumíš kategorii. Neznáš jazyk, kterým mluví jednotlivé parametry, nevíš, které jsou důležité, a které ne. Hledáš parfém pro svou ženu Valentýnu a musíš se v tom nějak orientovat. Máš dvě možnosti: buď se v kategorii nejprve zorientuješ, například koukneš na YouTube na nějakého rádce, který vysvětluje, co je dynamika u keyboardů, kolik kláves potřebuješ — zda 77, 67, 88 kláves, nebo jaké jiné parametry.

Nebo uděláš to, co většina lidí: odložíš nákup. Protože je to příliš složité a komplexní, řekneš si, dneska to dělat nebudu, někdy si to nastuduju. Nebo zavoláš někomu, kdo ti s tím pomůže, případně zajdeš do kamenné prodejny.

Tento problém chceme řešit: chceme uvést na trh řešení, které tě provede dialogem a na jeho konci ti ukáže jeden konkrétní produkt, který přesně odpovídá tvým potřebám. Řekneme ti: „Toto je ten produkt, ten si kup,“ případně nabídneme několik alternativ, které jsou také relevantní a které můžeš zvážit.

Při samotném dialogu, který vedeme spolu s uživatelem, se hodně opíráme ne o produktové otázky. Neptáme se například, kolik wattů má mít reproduktor v keyboardu, ani kolik kláves obsahuje. Místo toho se bavíme o potřebách uživatele, o jeho preferencích a postojích. Například se ptáme, zda bude chodit do základní umělecké školy se učit hrát, protože ...

Takže ano, vlastně potřebuješ něco, co má vlastnosti klasického keyboardu. To znamená třeba dynamickou klaviaturu. A trošku to vysvětlíme. Primárně jde o to ptát se na uživatelské otázky, na věci, na které ten keyboard umí odpovědět, a které uživatele provedou výběrem. Je to úplně stejné, jako když přijdete do klasického obchodu – prodavač vám klade přesně tyhle otázky.

Zkuste zajít třeba do Musiceru, my právě s Musicerem děláme pilotní projekt na toto téma. Proč zrovna keyboard? Protože jsem si myslel, že máš nějaké umělecké já a klavírní minulost. Ale to ne, to ne. Cerlika začala hrát na housle a vím, jak je problém vybrat nástroj, když o tom člověk moc neví. A proto jsme se rozhodli pro keyboardy a vedli jsme o tom diskuze právě s lidmi z Musiceru. Byli jsme i přímo v prodejnách, kde jsme se bavili, jak co nejvíce přiblížit myšlenku shopping asistenta k reálnému prodavači.

I když veškeré technologie na pozadí budou založené na machine learningu a především na LLM, snažíme se tímto technologiím co nejvíce ubírat na viditelnosti a u koncového uživatele vzbudit pocit, že komunikuje s reálným člověkem.

Co pro vás znamená uvést na trh čtvrtý produkt, který sice vychází ze stejné filozofie a datového základu, ale má zcela odlišnou produktovou propozici? Jako head of product jste si řekli: „Budeme dělat asistenta, paráda.“ Co se pak děje? Jak dlouho na tom pracujete? Kdy bude produkt venku?

My jsme vlastně v oblasti product discovery, kam spadají všechny produkty, které děláme. Když se na to podíváme z nadhledu, vidíme lego skládanku produktů, kde některé kostičky chybí. A právě shopping assistant tam chybí, protože dneska nemáme pokrytý use case, kdy přijde laik, který si neumí vybrat. Osobně věříme, že jde o poměrně velký segment, a proto do toho jdeme.

Současně vidíme ještě pár dalších kostiček, které dnes nemáme, a které budeme muset ještě dodat. Když se vrátím ke shopping asistentu, v tuto chvíli máme hotový prototyp, který chceme začít testovat, abychom získali nějaké obchodní výsledky.

Předpokládáme, že uživatelé a posluchači by si ho mohli zkusit někdy kolem poloviny roku 2025. Aby na to nezapomněli, doporučuji sledovat nás na LinkedInu – najděte si stránku Luigi’s Box, dejte „sledovat“, a budeme tam pravidelně informovat o novinkách.

Vlastně věci pouštíme. Pro mě je taky doporučení sledovat Luigi's Box. Já zase, tím že v e-commerce trochu znám, sleduju vás delší dobu. Překvapilo mě, kolik vás dneska je. Je vás přes sto, ne? Teďka je nás nějakých 111, myslím, když jsme se naposledy počítali. To je velmi brněnské číslo – 111, z toho by měl Onderka radost. Je nás 111 a jsme vlastně hodně rozkročení po Evropě, protože...

I tím, jak máme klienty nejenom na Slovensku a v Česku, ale hodně i v Polsku, v Německu, ve Spojeném království a podobně, tak i personální zastoupení vlastně kopíruje to, kde všude působíme. Takže hodně lidí je v Česku, na Slovensku, v Polsku, pak také teďka v Německu a dalších zemích. Přijde mi zajímavé, že firma s takhle úzkou doménou a propozicí takhle vyrostla. Jak se vám daří, jsem hrdý na to, že to děláte tady z Česka a že jdete do světa, takže držím moc palce.

Z Česka a ze Slovenska tedy. Tak z Česka, z Brna a ze Slovenska vám moc držím palce. Děkuju moc, Romane, že jste nás provedl trendy e-commerce trhu a vzal nás do toho, jak funguje search a product discovery. Držím moc palce.

Děkujeme a díky za pozvání. Děkujeme, že jste doposlouchali až sem. A díky také našim partnerům, členům Data Talk klubu. Jsou to intecs, Sazka, BizzTreat, Colours of Data, Revolt BI, GoodData, Keboola, Emark, Carl Data Company, DataMind, Notino a FLO.

A pokud chcete zůstat v obraze, co se týče české datové scény a globálních datových technologií, nezapomeňte se registrovat k odběru našeho týdenního newsletteru na datatalk.cz.

Nechť vás provází data.