Real-time KPI dashboard pro CFO: jak 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í ve 14:00, a aby mu někdo poslal alert dřív, než si toho všimne sales manager. Tenhle článek mluví o tom, jak postavit live KPI vrstvu nad existujícím stack (typicky PostgreSQL/MySQL + Stripe + GA4 + HubSpot nebo Salesforce) a kde leží hranice mezi „za týden" a „za měsíc".

Co reálně chce CFO vidět ráno

Empirická data ze cca 30 implementací v ČR: CFO se ráno dívá na 4-6 čísel, ne 40. Pro SaaS to je MRR, churn (30 dní), conversion z trialu, ARPU, aktivní uživatelé. Pro e-shop tržby dnes vs. yesterday, AOV, refund rate, attribution split (paid/organic/direct), cart abandonment. Pro multi-location retail per-store tržby s pořadím a delta vs. minulý týden. Klíčové: každé číslo má **delta + trend**, ne jen absolutní hodnotu — „412 800 Kč" nic neříká bez kontextu „+12 % vs minulý týden, baseline 380 000".

Co CFO **nechce**: 47 grafů na úvodní stránce, customizovatelné widgety, „explore" tlačítka. Chce list zafixovaných čísel, alert když se něco hne nestandardně, a možnost zeptat se konverzačně („proč jsou tržby v Brně dole?").

Architektura: stack, který reálně funguje

Pro středně velkou firmu (50-500 zaměstnanců): warehouse vrstva v BigQuery nebo Snowflake (5-20 GB dat, ne data lake na hokejovém hřišti), ETL přes Fivetran / Airbyte / vlastní Python jobs do dbt modelů, semantic layer (Cube nebo dbt metricflow) — definuje KPI jednou a používá se v BI i v NL query, a top vrstva pro vizualizaci a alerty. Žádný extra magický nástroj — proven stack, mnohokrát ověřený.

Důležité je oddělit „raw data" (PostgreSQL z aplikace, Stripe webhooks) od „business view" (dbt models s definovanými KPI). Bez tohoto oddělení každý nový dashboard tahá data z 5 různých sources, KPI se rozcházejí mezi týmy (sales vidí MRR jinak než finance), a začnete utrácet pondělky na sjednocování čísel místo na rozhodnutí.

Real-time vs near-real-time: co je realistické

Marketingové prezentace ukazují „real-time", ale realita je near-real-time. Stripe webhooks doletí pod 1 sekundu, PostgreSQL CDC pod 5-10 sekund, GA4 má inherent delay ~30-60 sekund. Aggregace v warehouse trvá 30-300 sekund podle objemu. Reálný update KPI je tedy 1-5 minut, ne „okamžitě". Pro CFO to je víc než stačí — v 8:30 vidí čísla z 8:25.

Pokud chcete sub-secondový refresh (operations dashboard, ne CFO), je to jiná architektura: Kafka + ClickHouse + materialized views. To stojí 5x víc a CFO to nepotřebuje.

Anomaly detection: kde leží reálný value

Klasický statický threshold („alert pokud tržby pod 300k") je špatný. Tržby v pondělí jsou jiné než v sobotu, v lednu jiné než v prosinci, na Černý pátek jiné než obvykle. AI baseline z 14-30 dnů per metric, který bere v úvahu day-of-week sezónnost, je rozdíl mezi „alert každý den" a „alert když fakt nastalo něco důležitého".

Druhá úroveň: anomaly korelace. Pokud klesly tržby AND vzrostly refundy AND zvýšila se latence checkoutu — to je jiný příběh než „jen klesly tržby". AI vrstva, která tyhle korelace najde a vysvětlí, ušetří CFO 30 minut detektivní práce každé ráno.

Natural-language query: kde funguje a kde ne

NL query („proč klesly tržby v Brně minulý týden?") funguje dobře, pokud máte solidní semantic layer (Cube, dbt) — AI ví, co je „tržby", co je „Brno", co je „minulý týden", a vrátí odpověď s grafem. Bez semantic vrstvy AI hádá a často špatně.

Kde NL query selhává: na otázky, na které neexistuje data odpověď ve vašem warehousu („jaká je naše market share?"). AI nemá vědět to, co nemá. Druhá oblast: agregace s subjektivními pojmy („jak se nám vede?"). „Vede" je relative. NL query je dobrá tam, kde je question parametrizovatelná do SQL. Pro „strategické" otázky je to spíš LLM chat s kontextem, ne dashboard.

Co se dá za týden, co za měsíc

• Za týden: napojit 2-3 zdroje (PostgreSQL + Stripe + GA4), vytáhnout 5-6 KPI, postavit jeden dashboard pro CFO. Bez AI vrstvy, jen čísla. Setup s konektorem (Fivetran trial nebo přímý SQL) jde rychle.
• Za 2-3 týdny: přidat dbt semantic layer (definované metriky), spárovat data napříč zdroji (zákazník v PostgreSQL = customer v Stripe = user v GA4), historical backfill 90-180 dnů.
• Za 4 týdny: anomaly detection (AI baseline per metric), Slack/Teams alerty s vysvětlením, daily exec briefing v inboxu.
• Za 6 týdnů: NL query (Cube + LLM), exec PDF exports, multi-role dashboardy (CFO vs. country manager vs. CEO).

Ceny a co je v balíčku

Reálný rozsah pro středně velkou firmu (50-500 lidí): implementace 89-199 tisíc Kč, provoz od 4 900 Kč/měs. Co je v ceně: konektory na 3-5 zdrojů, custom dashboard per role, anomaly detection + alerty, NL query, daily exec briefing. Co není v ceně: licence warehouse (BigQuery, Snowflake — typicky $50-200/měs podle volumeu), licence BI tool pokud používáte Metabase Cloud nebo Tableau, custom dashboardy nad rámec 3 rolí.

Na co si dát pozor

• Dodavatelé, kteří „nahradí váš ERP/CRM". Nepotřebujete to. Real-time dashboard sedí NAD existujícím stackem, ne místo něj.
• Nástroje s vlastním proprietary query languagem. Pokud kdokoliv jiný v týmu neumí, dashboard má jednoho údržbáře — a ten zítra odejde.
• Sales pitch o „AI insights without limits". AI doporučí to, co umí najít v datech, která jí dáte. Bez kvalitních dat nemá co najít.
• Pricing za uživatele („per seat"). U dashboardu pro CFO + 5 managerů to je OK, u firmy s 200 lidmi kteří občas mrknou na dashboard to vystřelí cenu.

Jak vám můžeme pomoct

Náš produkt AI Live Dashboard je přesně tahle vrstva: konektory na vaše zdroje, dbt semantic layer, custom dashboardy per role, anomaly detection s vysvětlením, NL query, daily briefing. Sedíme nad warehouse, který máte nebo postavíme (BigQuery/Snowflake je standard). Implementace 4-6 týdnů.