Real-time KPI dashboard pro CFO: jak ho postavit nad PostgreSQL, Stripe a GA4

CFO nepotřebuje další dashboard. Potřebuje, aby čísla, na která se ráno dívá, byla v 8:30 stejně aktuální jako účetnictví odpoledne, a aby mu někdo dal vědět dřív, než si změny všimne obchod. Tento článek popisuje, jak postavit živou vrstvu KPI nad existujícími systémy (typicky PostgreSQL nebo MySQL, Stripe, GA4 a HubSpot nebo Salesforce) a kde je hranice mezi „za týden“ a „za měsíc“.

Ranní přehled obvykle stojí na 4–6 číslech, ne na 40. Pro SaaS to jsou MRR, churn za 30 dní, konverze ze zkušební verze, ARPU a aktivní uživatelé. Pro e-shop tržby dnes proti včerejšku, průměrná objednávka, podíl vratek, rozdělení podle zdroje návštěv (placené, organické, přímé) a opuštěné košíky. Pro síť prodejen tržby po prodejnách s pořadím a změnou proti minulému týdnu. Klíčové je, že každé číslo má změnu a trend, ne jen absolutní hodnotu: „412 800 Kč“ bez kontextu „+12 % proti minulému týdnu, obvykle 380 000 Kč“ nic neříká.

Co CFO nechce: 47 grafů na úvodní stránce, přizpůsobitelné widgety a tlačítka „prozkoumat“. Chce pevný seznam čísel, upozornění, když se něco nestandardně pohne, a možnost se zeptat: „proč jsou tržby v Brně dole?“

Pro středně velkou firmu (50–500 zaměstnanců): datový sklad v BigQuery nebo Snowflake (5–20 GB dat, ne datové jezero), přenos dat přes Fivetran, Airbyte nebo vlastní skripty v Pythonu do modelů v dbt, sémantická vrstva (Cube nebo dbt MetricFlow), která definuje KPI jednou pro dashboardy i pro dotazy v přirozeném jazyce, a nahoře vrstva pro vizualizace a upozornění. Žádný zázračný nástroj, jen osvědčený stack.

Důležité je oddělit surová data (PostgreSQL z aplikace, webhooky ze Stripe) od obchodního pohledu (modely v dbt s definovanými KPI). Bez toho každý nový dashboard tahá data z pěti různých zdrojů, KPI se mezi týmy rozcházejí (obchod vidí MRR jinak než finance) a pondělky se tráví sjednocováním čísel místo rozhodováním.

Prezentace slibují „real-time“, realita je téměř real-time. Webhooky ze Stripe dorazí do sekundy, změny z PostgreSQL (CDC) do několika sekund. U GA4 počítejte se zpožděním podle typu dat, u běžných reportů i v řádu hodin. Agregace ve skladu trvá desítky sekund až minuty podle objemu. Aktualizace KPI z transakčních dat je tedy v řádu minut, ne okamžitá. Pro CFO to bohatě stačí: v 8:30 vidí čísla z 8:25.

Pokud potřebujete obnovu v řádu sekund (provozní dashboard, ne pro CFO), je to jiná architektura: Kafka, ClickHouse a materializované pohledy. Je výrazně dražší a CFO ji obvykle nepotřebuje.

Pevný práh („upozorni, když tržby klesnou pod 300 tisíc“) nefunguje. Pondělí se liší od soboty, leden od prosince a Black Friday od běžného týdne. Model, který se učí z posledních 14–30 dnů a počítá s rozdílem mezi dny v týdnu, odliší „upozornění každý den“ od „upozornění, když se opravdu něco stalo“.

Druhá úroveň jsou souvislosti. Když klesnou tržby a zároveň vzrostou vratky a zpomalí se pokladna, je to jiný příběh než samotný pokles tržeb. Vrstva, která takové souvislosti najde a vysvětlí, ušetří CFO ranní pátrání.

Dotaz „proč klesly tržby v Brně minulý týden?“ funguje dobře, pokud máte solidní sémantickou vrstvu (Cube, dbt). AI ví, co jsou „tržby“, co je „Brno“ a co „minulý týden“, a vrátí odpověď s grafem. Bez sémantické vrstvy hádá, a často špatně.

Selhává u otázek, na které vaše data nemají odpověď („jaký máme podíl na trhu?“). Druhá slabina jsou vágní pojmy („jak se nám daří?“). Dotazy v přirozeném jazyce fungují tam, kde jde otázku převést na dotaz do databáze. Pro strategické otázky je vhodnější rozhovor s AI nad podklady než dashboard.

Orientační plán pro typický projekt:

• Za týden: napojit 2–3 zdroje (PostgreSQL, Stripe, GA4), vytáhnout 5–6 KPI a postavit jeden přehled pro CFO. Zatím bez AI, jen čísla.
• Za 2–3 týdny: přidat sémantickou vrstvu v dbt, propojit data napříč zdroji (zákazník v PostgreSQL = zákazník ve Stripe = uživatel v GA4) a doplnit historii za 90–180 dní.
• Za 4 týdny: detekce anomálií, upozornění do Slacku nebo Teams s vysvětlením a ranní souhrn e-mailem.
• Za 6 týdnů: dotazy v přirozeném jazyce, exporty do PDF a přehledy pro další role (CFO, country manager, CEO).

Orientační cena pro středně velkou firmu: implementace 89–199 tisíc Kč, provoz od 4 900 Kč měsíčně. V ceně jsou konektory na 3–5 zdrojů, přehledy pro jednotlivé role, detekce anomálií s upozorněním, dotazy v přirozeném jazyce a denní souhrn. V ceně nejsou licence datového skladu (BigQuery nebo Snowflake, typicky desítky až nízké stovky dolarů měsíčně podle objemu), licence BI nástroje (například Metabase Cloud nebo Tableau) a přehledy nad rámec tří rolí.

• Dodavatelé, kteří chtějí „nahradit váš ERP nebo CRM“: nepotřebujete to. Přehled patří nad stávající systémy, ne místo nich.
• Nástroje s vlastním dotazovacím jazykem: když ho v týmu umí jen jeden člověk, přehled má jediného správce, a ten může zítra odejít.
• Sliby typu „AI insights bez limitů“: AI najde jen to, co v datech je. Bez kvalitních dat nemá co najít.
• Cena za uživatele: pro CFO a pět manažerů v pořádku, u firmy s 200 lidmi, kteří se občas podívají, cena rychle vyroste.

Náš produkt AI Live Dashboard je právě tato vrstva: konektory na vaše zdroje, sémantická vrstva v dbt, přehledy pro jednotlivé role, detekce anomálií s vysvětlením, dotazy v přirozeném jazyce a denní souhrn. Běží nad datovým skladem, který máte, nebo ho postavíme (BigQuery nebo Snowflake).