Proč jsme postavili AI datového analytika (a jak ho dnes používají naši klienti)
Když klientům dodáme Dance, čistá data v BigQuery a hotové reporty, většinou máme pocit, že je hotovo. A z pohledu datové infrastruktury vlastně je. Data tečou, metriky sedí, dashboardy fungují. Jenže pak přijde úplně běžný dotaz z marketingu:
„Hele, můžeš se prosím podívat, jaký jsme měli minulý týden konverzní poměr na mobilech napříč trhy?"
Na první pohled nic složitého. Jenže odpověď stejně zabere klidně dvě hodiny. Někdo musí otevřít BI nástroj, najít správný report, případně dopsat SQL, zkontrolovat výsledek, exportovat ho a poslat odpověď zpátky.
A přesně takových dotazů chodí každý týden desítky. Tak vznikl Signals AI Analytik.
Představujeme Signals AI Analytika
Signals AI Analytik je AI agent, kterému se klient může zeptat na svá data přirozeným jazykem. A dostane odpověď. Někdy doplněnou o graf, někdy o tabulku, někdy prostě jako krátké shrnutí. Bez čekání na analytika, bez hledání v dashboardech, bez psaní SQL. Technicky je to konverzační agent nad LLM modelem, běžící jako Cloud Run služba přímo v GCP projektu klienta.
To je pro nás důležité: data neopouští klientovu infrastrukturu.
Agent si sám napíše SQL, spustí ho nad BigQuery, výsledek interpretuje a vrátí uživateli přes webové rozhraní. Historie konverzací se ukládá, takže se k dotazům dá vracet podobně jako v běžném chatu.
Proč to není jen další chatbot nad BigQuery
Model, který umí vygenerovat SQL, dnes není nic výjimečného. To už umí kdeco. Rozdíl mezi hezkým demem a nástrojem, který opravdu používá klient, je v kontextu.
A právě na tom jsme strávili nejvíc času.
Kontext, ve kterém agent funguje, je modulární. Co platí pro každý projekt postavený na Dance, dědíme. Co je specifické pro konkrétního klienta, jeho metriky, jeho byznys, jeho slovník, přidáváme nad to.
Agent tak ví, jaké tabulky má v BigQuery, co znamenají jednotlivé metriky, jaké atribuční modely používáme, jak se v daném byznysu počítá marže, jak se grupují kanály nebo v jaké měně jsou tržby.
Když přijde nový klient, nepřepisujeme celý prompt od nuly. Přidáme jeho kontext.
Díky tomu agent neodpovídá obecnými frázemi typu „v GA4 se obvykle…". Odpovídá ke konkrétním datům konkrétního klienta.
Co s tím klienti reálně dělají
Klienti tomu mezi sebou začali říkat „kecátko". A je vidět, na co ho používají.
V praxi vidíme tři typické způsoby použití.
1. Ad-hoc dotazy, na které není postavený dashboard
Většina dashboardů odpovídá na otázku co. Obrat, návštěvnost, konverzní poměr, výkon kanálů. To, co se reportuje pravidelně, má své místo a vizualizaci.
Jenže reálné dotazy z byznysu málokdy končí u co. Obvykle pokračují proč, o kolik, co kdyby. A na ty dashboard postavený není.
„Dodavatel nám zdraží vstupy o osm procent. O kolik máme zdražit, abychom udrželi objem prodejů na určité úrovni?"
„Jak si vede nová kolekce v poměru ke staré ve stejném období loni?"
„Který kanál v posledním měsíci nejvíc zlevnil a kde jsme díky tomu udělali největší zisk?"
Dřív tahle otázka šla na analytika a odpověď přišla za pár hodin, někdy další den. Teď ji manažer položí rovnou a má odpověď v řádu vteřin.
Žádný ticket. Žádné čekání. Žádné „až se k tomu dostanu".
2. Hloubková analýza s kontrolou nad SQL
Pro analytiky a datové specialisty jsme přidali SQL panel. Agent ukáže, jaký dotaz vygeneroval a spustil. Uživatel si ho může zkontrolovat, zkopírovat, upravit nebo použít dál ve vlastním projektu. Tohle je pro nás důležité. Nechceme černou skříňku, která jen sebevědomě vyplivne číslo. Chceme nástroj, kterému jde vidět pod ruce.
A právě v tomhle režimu vznikají ty zajímavější analýzy. Jeden z klientů takhle před pár týdny odhalil, že problém s klesající konverzí spočívá ve druhém kroku v průchodu funnelu. Klasický report mu řekl, že konverze klesla. Agent postupnými dotazy pomohl najít, kde přesně.
Tohle je práce, která dřív vyžadovala hodiny analytikova času. Teď je to konverzace.
3. Pravidelné rychlé checky
A pak je tu třetí použití, kterého si všímáme čím dál víc. Otázky, které dřív manažer často ani nepoložil. Ne proto, že by ho nezajímaly, ale protože věděl, že tím někomu přidá práci.
„Jak nám jdou nové kolekce?" „Proč nám spadla návštěvnost?" „Jak si vedou produkty ve slevě oproti zbytku sortimentu?"
Teď se zeptá rovnou.
A právě to podle nás mění způsob, jak týmy s daty pracují. Data nejsou jen v reportech, do kterých se někdo jednou týdně podívá. Jsou k dispozici ve chvíli, kdy člověka napadne otázka.
Jak to zapadá do zbytku Dance platformy
AI Analytik stojí na Dance, což je zásadní. Bez kvalitní datové vrstvy by AI agent generoval nesmysly s velkou jistotou. Což je horší, než kdyby negeneroval nic. Dance mu dává pevnou půdu pod nohama: konzistentní tabulky, jasně definované metriky, transparentní atribuci a propojené marketingové náklady. Na druhou stranu, Dance bez Data Analytika je skvělá infrastruktura, kterou naplno využije hlavně člověk, který umí SQL a má čas se v datech hrabat.
Data Analytik tuhle schopnost otevírá širšímu týmu. Od juniora v marketingu po obchodního ředitele. V podstatě self-service přístup k datům pro celý tým.
Proč o tom píšeme
Postavit AI agenta nad reálnými klientskými daty je úplně jiná disciplína než udělat pěkné demo.
Většina práce není v samotném modelu. Je v kontextu. V tom, jak agent rozumí datům konkrétního klienta. Jak se zachová, když dotaz nedává smysl. Jak řeší SQL chyby. A jak zajistíme, že data zůstávají v klientově projektu. Tohle jsou věci, které v tutoriálech moc často nenajdete.
Kdyby vás zajímalo něco konkrétně, ozvěte se.
Přečtěte si více
Datové inženýrství v AI době: zajímavá práce nikdy nebyla jen v transformacích
AI dnes dokáže napsat dbt nebo Dataform model rychleji, než si většina datových inženýrů stihne uvařit kafe v kuchyňce.
A píše ho čím dál tím lépe. Ne vždy dokonale, ne vždy produkčně, ale dost dobře na to, aby bylo jasné, že se práce dataře mění. Pokud byla hlavní hodnota datového inženýra v tom, že uměl rychle napsat SQL transformaci, tak se tahle výhoda bude už jen zmenšovat.
To ale neznamená, že datové inženýrství mizí. Spíš se konečně ukazuje, kde byla jeho největší hodnota celou dobu. Ne v samotném přesouvání dat z bodu A do bodu B. Ne v tom, že někdo umí napsat další LEFT JOIN. Ne v tom, že vytvoří další Gold tabulku. Ale v tom, že někdo rozumí, co ta data znamenají.
Proč jsme postavili Dance (a co všechno už dnes umí)
Když před pár lety Google Analytics 4 přinesly export do BigQuery i pro neplacené účty, byli jsme z toho nadšení. Exporty přes API našim klientům už dávno nestačily a 360 licence byly příliš drahé.
Už na několika prvních projektech se ale ukázalo, že stavět každému klientovi datový model na míru nedává smysl ekonomicky ani prakticky.
Řešili jsme v podstatě podobný problém jen z jiného konce. Jak správně zpracovat GA4 data? Jak je propojit s objednávkami? Jak z toho udělat něco, čemu bude klient opravdu rozumět?
Řekli jsme si, že to musí jít líp. A tak vznikl Dance.
