Představte si nového kolegu, který je geniální na SQL, ale nikdy neslyšel, co ve vaší firmě znamená „konverze“. Odpoví vám rychle, sebejistě a pěkně naformátovaně. Jen nemusí odpovídat na tu otázku, kterou jste položili.
Přesně tak se chová AI konverzační agent nad datovým skladem. Pokud máte datový sklad v BigQuery (časté u e-shopů, které v něm mají i export dat z GA4), můžete agenta od července 2026 nasadit za odpoledne: konverzační analytika v BigQuery je dostupná veřejnosti. Jestli to bude dobrý nápad, nerozhodne model. Rozhodne to, co mu o vašich datech řeknete: jaké informace dostane v systémovém promptu a v popisech dat (co znamenají metriky, z čeho se počítají, čemu se vyhnout) a v jaké kondici data jsou, tedy jestli jsou vyčištěná, přehledně uspořádaná a zdokumentovaná.
V článku není žádný kód ani tutoriál. Jen to, co byste měli vědět, než k agentovi pustíte vaše markeťáky.
Shrnutí
- Konverzační analytika v BigQuery je od 1. července 2026 dostupná veřejnosti. Agent odpovídá na otázky přirozeným jazykem, ukazuje svůj postup včetně SQL a umí vícekrokovou analýzu.
- Agent čte to, co mu určíte: tabulky, pohledy (views) a uživatelské funkce. Přidáváte k nim popisy, pokyny a ověřené dotazy.
- Rozhoduje sémantická vrstva, ne model. Jeden zdroj pravdy pro metriky: definice, vlastník a granularita.
- Nejen GA4. Pokud máte v BigQuery i jiná data než GA4, může agent dotazy spouštět i nad nimi.
- Surový export z GA4 pro agenta nestačí. Je vnořený a denní tabulky se doplňují až tři dny zpětně. Vyplatí se ho zploštit, třeba hotovou knihovnou, a dotazy pouštět až nad zploštěnými daty.
- Začněte v malém. Pár certifikovaných metrik, ověřené dotazy a sada testovacích otázek.
- Hlídejte náklady a oprávnění. Agent dědí oprávnění BigQuery a velikost dotazu jde omezit.
Co umějí BigQuery agenti
Google tomuto modulu BigQuery říká Conversational Analytics (konverzační analytika) a agentům data agents. Vytvoříte agenta, vyberete mu zdroje znalostí (tabulky, pohledy a uživatelské funkce) a doplníte kontext: popisy tabulek a sloupců, pokyny, jak má data číst a dotazovat, slovník obchodních pojmů a ověřené dotazy (verified queries, dříve „golden queries“) pro konkrétní otázky.
Agent umí:
- vícekrokové analýzy v režimu „deep dive“, kde si sám sestaví plán vyšetřování,
- hledání příčin, předpovědi a odhalení anomálií pomocí funkcí AI.KEY_DRIVERS, AI.FORECAST a AI.DETECT_ANOMALIES,
- ukázat, jak k odpovědi došel: viditelné kroky úvahy včetně vygenerovaného SQL a citace zdrojů (tabulky, schéma, ověřené dotazy, pojmy ze slovníku),
- zeptat se zpět, když je dotaz vágní nebo nepřesný (tzv. gatekeeper rules), a pamatovat si obchodní pojmy.
Pracujete s ním v BigQuery Studiu, Data Canvasu, Gemini Enterprise, nebo ho napojíte do vlastní aplikace přes Conversational Analytics API. Tak jsme postavili i našeho analytického agenta pro firmy. Data zůstávají v BigQuery, takže platí vaše pravidla pro oprávnění a šifrování. Když všechny zdroje dat leží v EU, použije se unijní multiregionální endpoint, takže data v klidu i strojové zpracování zůstanou v EU.
Co je hotové a co zatím ne
| Funkce | Stav podle Googlu |
|---|---|
| Konverzační analytika v BigQuery a Conversational Analytics API | Dostupné veřejnosti (GA), BigQuery od 1. 7. 2026 |
| Ověřené dotazy, slovník pojmů a vlastní pokyny pro agenta | K dispozici v nastavení agenta |
| Měřitelné vyhodnocení kontextu v Knowledge Catalog | GA |
| BigQuery measures (metriky přímo v SQL) | Preview |
| Automatické vytváření popisů, slovníků a ověřených dotazů (Knowledge Catalog) | Preview |
| Agentní workflow (agenti běžící podle plánu) | Preview |
Preview znamená, že se funkce ještě může měnit a zatím na ní nestavte nic, co musí běžet beze změn.
Proč agent bez sémantické vrstvy chybuje
Model nevidí, co ve vaší firmě znamená „konverze“, „aktivní zákazník“ nebo „minulý měsíc“. Když dostane surové tabulky, hádá. A nejhorší na tom je, že hádá sebejistě: odpověď vypadá přesvědčivě, i když je špatně. Jedna chybná odpověď přitom stačí, aby analytik přestal agentovi věřit.
Typické chyby jsou dvě. První je špatná definice: agent počítá tržby z GA4, kdežto vedení čte tržby z objednávek, a čísla se liší. Druhá je nesoulad granularity: agent vynásobí metriky, které jsou na jiné úrovni detailu (objednávka, položka, relace), a výsledek nedává smysl.
Dobře to ukazuje zkušenost Anthropicu, který takhle automatizoval vlastní firemní analytiku. Podle jejich článku z června 2026 agent bez připravených pracovních postupů (skills) v jejich testech nepřekročil 21 % správných odpovědí. S nimi a se sémantickou vrstvou, do které se agent musí podívat jako první, se dostali na zhruba 95 %. Dvě další zjištění jsou pro každého, kdo agenta zavádí, ještě cennější:
- Automaticky vygenerované definice metrik nefungovaly. Pokus nechat sémantickou vrstvu napsat jazykový model nevyšel. Definice musí sepsat a schválit lidé.
- Přesnost bez údržby rychle klesá. Za jeden měsíc jim spadla z přibližně 95 % na 65 %, dokud údržbu kontextu nezačali brát jako běžnou inženýrskou práci.
Jde o čísla jedné firmy na jejích vlastních datech a testech, ne o obecné měřítko. Řád je ale výmluvný a stejnou zkušenost jsme slyšeli i na podzimním MeasureCampu: o přesnosti rozhoduje kontext, který agent o datech dostane.
BigQuery agenti jsou na začátku své cesty. Zatím nemusí odpovídat tak sofistikovaně a deterministicky jako konverzační agenti postavení na míru s povinnou sémantickou vrstvou. Zajímaví ale můžou být pro firmy, jejichž datový sklad už v BigQuery leží. Podrobnější dokumentace tabulek a jednotlivých sloupců v jejich popisech (descriptions) pomůže modelům se správnými výpočty. Sémantickou vrstvu to nenahradí, ale umí se jí to přiblížit, omezit halucinace modelu a zlepšit pochopení kontextu, na který se uživatel ptá.
Sémantická datová vrstva: co to je a jak se k ní postavit
Sémantická vrstva je překladač mezi byznysem a tabulkami. Říká, co znamená tržba, konverze nebo aktivní zákazník, z jaké tabulky se počítá, na jaké úrovni detailu (granularita) a kdo za ni odpovídá. Agent pak nevymýšlí SQL, ale mapuje otázku na definované metriky.
Není to hromada ověřených dotazů a není to jen popis sloupců. Je to jeden zdroj pravdy pro metriky a dimenze s vlastníkem. Takové metrice se říká certifikovaná.
Jak na ni, krok za krokem
- Vyberte malý počet metrik. Tržby, objednávky, náklady, ROAS, počet nových zákazníků. Pro začátek stačí pár, které se používají nejčastěji.
- U každé určete vlastníka. Člověka, který za definici odpovídá a rozhodne, když se mění.
- Popište ji celou: definici, vzorec, zdrojovou tabulku, granularitu a upozornění, kdy se liší od jiného zdroje (třeba tržby z e-shopu proti GA4).
- Nechte agenta číst zploštěné tabulky nebo pohledy (views), ne surový export. Marketéři GA4 export do BigQuery většinou znají. V surové, nezploštěné podobě je ale pro agenta prakticky nepoužitelný: parametry událostí jsou vnořené jako opakující se záznamy a denní tabulky se doplňují až tři dny po události. Zploštění, třeba hotovou knihovnou, nebo vrstva pohledů nad ním tuhle složitost schová. Stejně je to s ostatními firemními daty, třeba objednávkami nebo CRM: vyplatí se je pro agenta přeskládat do přehledných tabulek a pořádně popsat.
- Doplňte ověřené dotazy a slovník pojmů na otázky, které se opakují.
- Sestavte testovací sadu otázek se známou odpovědí a vyhodnocujte ji po každé změně kontextu.
- Určete, kdo metriky pravidelně přezkoumává. Bez toho vrstva zastará a agent začne odpovídat podle staré pravdy.
Čím ji udělat
Google tu staví na vlastních nástrojích. LookML v Looker je osvědčená sémantická vrstva, na které agent odpovídá podle centrálně schválených definic. BigQuery measures (zatím Preview) dávají obchodní logiku přímo do SQL. Knowledge Catalog pak sbírá metadata, slovníky a metriky na jednom místě, aby je agent mohl používat. Umí je i navrhnout automaticky, ale podle zkušenosti Anthropicu berte takový návrh jen jako podklad, který musí projít člověk. Podobnou roli mohou hrát i nástroje třetích stran. Nejdůležitější je ale rozhodnutí, co se ve firmě smí říkat „tržba“, ne volba nástroje.
Kdo si chce sémantickou vrstvu postavit sám a nezávisle na jednom dodavateli, má dnes několik open source možností:
- dbt MetricFlow (Apache 2.0): metriky popsané v YAML vedle dbt modelů, které engine přeloží do SQL pro různé databáze včetně BigQuery. Rozhraní pro BI nástroje jsou ale součástí placené dbt platformy.
- Cube Core (Apache 2.0): samostatný sémantický server s řízením přístupu, předpočítanými agregacemi a rozhraními SQL, REST a GraphQL, na které se dá napojit i AI agent.
- Boring Semantic Layer (MIT): lehká knihovna v Pythonu nad Ibisem, s volitelným MCP serverem pro AI agenty.
- Malloy (MIT): modelovací jazyk od autorů LookML, který definice metrik a vztahů překládá do SQL.
Přenositelnost mezi nástroji řeší Open Semantic Interchange (OSI), otevřená specifikace definic metrik od Snowflaku, dbt Labs, Cube a dalších, kterou v roce 2026 převzala nadace Apache Software Foundation jako projekt Apache Ossie. Projekty se rychle mění, a tak si licenci a stav ověřte, než na některém začnete stavět.
Kde se to nejčastěji pokazí
1. Agent čte data přímo ze skladu
Surové tabulky bez popisu agent nepochopí. Třeba export z GA4 je vnořený a doplňuje se až tři dny zpětně. Co udělat: dejte agentovi konkrétní tabulky, okomentujte je a přidejte k nim popisky sloupců.
2. Metrika nemá majitele
Když se čísla rozejdou, nikdo nerozhodne. Co udělat: ke každé metrice jméno člověka.
3. Agent nezná vaše pojmy
„Minulý měsíc“, „aktivní zákazník“ nebo „konverze“ znamená v každé firmě něco jiného. Agent si význam domyslí. Modely budou časem chytřejší a budou od nás potřebovat méně kontextu. Pokud ale chcete mít jistotu, že zareagují správně, a to v byznysu chcete, jasným instrukcím a mantinelům se nevyhnete. Co udělat: doplňte slovník pojmů a pokyny, jak je má agent chápat.
4. Nikdo ho netestoval
Bez otázek se známou odpovědí nepoznáte, jestli se agent po změně nezhoršil. Co udělat: sestavit testovací sadu a projít ji po každé úpravě.
5. Agent vidí víc, než by měl
Pozor na to, jaká práva agentovi v Google Cloudu a BigQuery udělíte. Obecně platí, že agent nepotřebuje tak široká práva jako běžný uživatel. Velikost jeho dotazů jde zastropovat a dotazy označit štítky, aby se dalo spočítat, co stojí. Co udělat: dát agentovi přístup jen k datům, která potřebuje, a nastavit limit dřív, než dostane přístup celý marketing.
Checklist: na co se zeptat dodavatele nebo analytika
Pokud zvažujete implementaci AI agenta pro konverzační analytiku, projděte si následující body. Technice rozumět nemusíte, stačí se správně zeptat. Když zazní „nevím“, vyplatí se to prověřit:
- Z čeho agent čte: ze surových tabulek, nebo z vyšší, vyčištěné a zdokumentované vrstvy datového skladu?
- Které metriky agent zná a kdo je u každé z nich vlastník?
- Jak agent ví, že se stejná metrika v různých zdrojích liší, třeba tržby v e-shopu a v analytice?
- Jaké ověřené dotazy a slovník pojmů má agent k dispozici?
- Máme sadu testovacích otázek se známými odpověďmi a kdy ji naposledy někdo spustil?
- Co agent vidí: zná oprávnění uživatele, který se ptá?
- Kolik může jeden dotaz stát a jak poznáme, kdo kolik utratil?
- Kde jsou zpracovaná data (EU endpoint) a co z toho říká smlouva?
Co jsme se naučili na vlastním agentovi
Nad Conversational Analytics API jsme si postavili vlastní aplikaci, AI datového analytika. Ladíme ji na agentovi nad syntetickými daty e-shopu se čtyřmi trhy a stovkami tisíc objednávek. Agent má popsané tabulky a sloupce, 19 ověřených dotazů a 14 obchodních pojmů ve slovníku. Co se ukázalo:
- Uživatel musí vidět, odkud číslo je. Každá odpověď u nás nese pečeť: zelenou „Certifikováno“, když agent spustil ověřený dotaz beze změny, oranžovou, když z něj jen vycházel a upravil ho. Na první pohled je tak jasné, kterému číslu věřit a které si ověřit v SQL.
- Nevinný pokyn umí rozbít ověřené dotazy. Když jsme agenta požádali, ať pojmenuje sloupce výsledku česky, přepsal kvůli tomu SQL. Odpověď pak už neodpovídala ověřenému dotazu. Do pokynů proto nepatří kosmetika, která mění dotaz.
- Tým potřebuje víc než okno chatu. Kolegové chtějí konverzace sdílet, opakovat je jako pravidelný ranní report a přidat k otázce vlastní kontext nebo pracovní postup. API na to přímo pole nemá, takže jsme to dostavěli v aplikaci.
- Náklady jsou malé, ale mají být vidět. V našem demu stojí jedna otázka v řádu haléřů. Každý dotaz má strop 25 GB zpracovaných dat a aplikace ukazuje odhad ceny u každé odpovědi i za celý tým.
Jak to děláme u klientů
AI agenta nad daty nezačínáme nasazením agenta. Začínáme daty. U e-shopů a firem, kde hrají velkou roli data z webu (GA4) a z kampaní, začínáme nejdříve datovou vrstvou a kvalitou měření. Pak v BigQuery postavíme základy datového skladu, ať už nad GA4, nebo nad firemními daty přímo z ERP či CRM. Teprve potom přichází agent, kterému popíšeme metriky, vlastníky a ověřené dotazy. Důvody shrnuje i náš článek Bez kvalitních dat žádná AI.
- Zmapujeme metriky, na které se ve firmě ptají, a kdo za ně odpovídá.
- Postavíme datový sklad s několika vrstvami pohledů na data.
- Popíšeme metriky včetně upozornění na rozdíly mezi zdroji.
- Nastavíme agenta, ověřené dotazy a limity nákladů a oprávnění.
- Otestujeme ho na sadě otázek se známou odpovědí, než ho dostanou uživatelé.
Je to pro vás? Test na 30 vteřin
| Do toho, pokud… | Počkejte, pokud… |
|---|---|
| Máte data v BigQuery a někdo s nimi umí pracovat | Data máte, ale nikdo jim nerozumí |
| Marketéři čekají na odpovědi od analytika celé dny | Ve firmě se neshodnete, co je tržba nebo konverze |
| Jste ochotní nejdřív sjednotit definice metrik | Nikdo nemá čas definice psát |
Pokud jste v pravém sloupci, začněte definicemi. Agent špatná data nespraví. Jen vás o nich přesvědčí rychleji.
Získejte konkurenční výhodu
Agenti jsou dostupní každému a rychle se zlepšují. Kdo je nasadí na dobře popsaná data, získá náskok. Kdo na surové tabulky, získá sebejistě špatná čísla. Vyžádejte si demo a projdeme, kde jsou vaše data teď.
Časté dotazy
Co jsou BigQuery datoví agenti?
Agenti, se kterými si o datech v BigQuery povídáte přirozeným jazykem. Vyberete jim tabulky, pohledy a funkce a doplníte kontext, pokyny a ověřené dotazy. Agent odpovídá textem, tabulkou nebo grafem a ukazuje, jak k odpovědi došel.
Je to už dostupné veřejnosti?
Konverzační analytika v BigQuery a Conversational Analytics API jsou podle Googlu dostupné veřejnosti (GA). Některé související funkce, třeba BigQuery measures nebo agentní workflow, jsou zatím v režimu Preview.
Jak připravit data z GA4 pro agentní analytiku?
Surový export z GA4 agentovi nedávejte. Je vnořený (parametry událostí jsou opakující se záznamy) a denní tabulky se doplňují až tři dny po události. Data je potřeba zploštit a začistit, například odfiltrovat interní a testovací provoz a sjednotit názvy událostí a parametrů. Pomůže hotová knihovna nebo vrstva pohledů nad exportem.
K jakým datům má mít agent přístup?
Až k vyšším, vyčištěným a zdokumentovaným vrstvám datového skladu, ne k surovým tabulkám. V nich jsou schválené definice metrik a popisy, podle kterých agent pozná, co a jak počítá.
Zůstanou data v EU?
Když všechny zdroje dat agenta leží v EU, Google použije unijní multiregionální endpoint a data v klidu i strojové zpracování zůstanou v EU. Konkrétní nastavení a smluvní stránku je ale potřeba ověřit pro váš projekt.
Kolik to stojí?
Samotné Conversational Analytics API Google podle dokumentace zatím neúčtuje. Platíte dotazy, které agent spustí v BigQuery, podle běžného ceníku BigQuery. Při rozumně připravených datech jde o haléře až koruny za otázku. Náklady jdou hlídat: velikost dotazu agenta lze omezit a dotazy označit štítky, podle kterých se dá vyčíst spotřeba. Ceník se může změnit, před nasazením ho ověřte.
Zdroje (čteno 7. 10., 10. 11. a 12. 11. 2026): Google Cloud: konverzační analytika v BigQuery, Google Cloud: zapnutí Conversational Analytics API, Google Cloud: Conversational analytics in BigQuery is now GA, Google Cloud: Conversational Analytics in Google Data Cloud in Q3 ’26, Google Cloud: Introducing the Google Cloud Knowledge Catalog, Anthropic: How Anthropic enables self-service data analytics with Claude, Nápověda Google Analytics: export do BigQuery, dbt Labs: open source MetricFlow.
