BI bez datového jezera

Většina startupových BI projektů začíná příliš brzy a příliš velkolepě.

Zakladatel položí jednoduchou otázku: „Vrací se uživatelé z tohoto kanálu po svém prvním spuštění?“ Odpovědí by měl být dotaz. Místo toho se z toho často stane projekt na vybudování platformy: propojit všechny zdroje, postavit sklad, definovat události, vyčistit identity, propojit dashboardy a čekat.

Tato práce má nakonec smysl. Ale pro malý tým to může být špatný první krok. Produktová databáze už ví většinu toho, co zakladatel potřebuje vědět. Ví, kdo se zaregistroval, kdo něco spustil, co použil, kolik to stálo, co selhalo a jestli se vrátil.

Skutečný problém není v tom, kde pravda žije. Jde o to, jak umožnit agentovi analyzovat tuto pravdu, aniž by se vystavila surová produkční databáze.

To je vzor, který používáme ve VM0: maskovaná, pouze pro čtení větev Neon, která našim agentům poskytuje dostatek pravdy pro BI, aniž by jim poskytla data, která by nikdy neměli vidět.

Problém zakladatele: otázky přicházejí dříve než datový tým

Firmy v rané fázi nemají nedostatek otázek. Mají nedostatek času.

Každý den chce tým zakladatelů vědět například:

• Změnil se včerejší provoz na skutečné uživatele?
• Které kanály registrace přivádějí lidi, kteří skutečně něco spustí?
• Vrací se uživatelé po prvním spuštění po 7 nebo 30 dnech?
• Které placené účty utichají?
• Která modelová trasa zvyšuje náklady?
• Zneužívají zkušební uživatelé výpočetní výkon před konverzí?
• Zlepšilo se nebo zhoršilo zdraví produktu od včerejška?

Žádná z těchto otázek není výjimečná. Jsou to provozní rytmus startupu.

Ale odpovídat na ně tradičním BI postupem vytváří spoustu režie. Obvykle začnete přesunem dat z produktové databáze do jiného systému. Pak je normalizujete, definujete metriky, znovu vytváříte vztahy a nastavujete dashboardy. Tým získá čistší analytický stack, ale zakladatel často čeká dny nebo týdny na odpověď, která mohla začít jako SQL dotaz.

Pro malý startup může být tato výměna špatná. Nepotřebujete kompletní datovou platformu, abyste položili své první 20 provozní otázky. Potřebujete bezpečný způsob, jak dotazovat zdroj pravdy, který už máte.

Databáze je už zdrojem pravdy

Ve VM0 obsahuje produktová databáze fakta, která jsou důležitá pro mnoho rozhodnutí na úrovni zakladatele:

• Organizace a uživatelé
• Stav registrace a předplatného
• Spuštění a plány agentů
• Spotřeba kreditů a události využití
• Vybrané modely a poskytovatelské trasy
• Stav konektorů
• Stav selhání a časová razítka

Tyto vztahy už existují. Jsou aktuálnější než jakýkoli downstream dashboard a odrážejí, jak produkt skutečně funguje.

To je důležité, protože mnoho raných BI otázek je relačních. Zakladatel nechce jen zobrazení stránek nebo počty spuštění. Chce propojit chování napříč systémem:

Kolik uživatelů, kteří se zaregistrovali z tohoto kanálu, něco spustilo v den nula a kolik se vrátilo po prvním spuštění?

Nebo:

Které placené organizace nic nespustily za posledních 7 dní a vypadaly dříve aktivně?

Nebo:

Kolik výpočetního výkonu spálily nové zkušební účty v prvních 6 hodinách, před a po změně naší ochrany proti zneužití?

Tyto otázky přirozeně patří do produktové databáze. Jsou mnohem složitější, pokud každá odpověď začíná přesunem dat do samostatné platformy.

Nebezpečná zkratka je přístup do produkce

Lákavá zkratka je zřejmá: prostě nechat agenta dotazovat produkci.

To není přijatelné.

Produkční databáze může obsahovat nejcitlivější materiály ve firmě: e-mailové adresy, prompty, obsah chatů, přihlašovací údaje, šifrované stavy poskytovatelů, logy, chybové zprávy, API klíče a interní provozní záznamy. I když je agent opatrný, surový přístup vytváří problém s hranicí. Agent může vidět příliš mnoho. Chyba v dotazu, reportu nebo screenshotu může odhalit informace, které tým nikdy nechtěl zveřejnit.

Zápis je ještě horší. BI by nemělo mít možnost měnit produkci. Analytik, ať už člověk nebo agent, by neměl být jedno špatné zadání od změny uživatelských dat.

Otázka tedy není, zda agenti umí psát SQL. Umí. Otázka je, zda jim můžete dát dostatek pravdy, aby byli užiteční, a přitom zachovat soukromí a bezpečnost jako tvrdé limity.

Pro nás jsou tyto limity klíčové:

• Agenti by neměli vidět surové prompty.
• Agenti by neměli vidět surové e-maily.
• Agenti by neměli vidět přihlašovací údaje nebo tajné klíče.
• Agenti by neměli vidět citlivé volné textové logy.
• Agenti by neměli mít právo zápisu do BI zdroje.
• Tým zakladatelů by měl stále rychle získat praktické provozní odpovědi.

Takto jsme potřebovali systém nastavit.

Bezpečný kompromis: maskovaná, pouze pro čtení databáze

Neon umožňuje užitečný vzor, protože větve jsou levné, izolované kopie databáze Postgres. Můžete vytvořit produkčně podobnou větev, transformovat ji a vystavit tuto větev místo samotné produkce.

Ve VM0 to používáme k vytvoření toho, čemu říkáme MaskDB.

Postup je jednoduchý:

1. Začněte z produkční rodičovské větve Neon.
2. Vytvořte novou větev podle plánu.
3. Nainstalujte PostgreSQL Anonymizer a maskovací pomocníky specifické pro VM0.
4. Aplikujte bezpečnostní štítky na citlivé sloupce.
5. Proveďte statickou anonymizaci na větvi.
6. Aplikujte finální vlastní masky na pole, která vyžadují zvláštní zacházení.
7. Vytvořte roli masked_readonly s přístupem SELECT.
8. Nechte agenty dotazovat tuto roli, ne produkci.

Důležité je, že maskování je statické. Citlivé hodnoty jsou přepsány na maskované větvi ještě před tím, než se agent připojí. To se liší od požadavku, aby každý downstream dotaz pamatoval, co nemá vybírat. Větev sama je hranicí.

V naší MaskDB jsou přihlašovací údaje a tajné klíče redigovány. E-maily a telefonní čísla jsou částečně maskována. Uživatelský obsah jako prompty, chatové zprávy, plánované prompty a výstupy agentů je odstraněn. Chybové texty jsou zredukovány na třídu místo úplného stacku nebo zprávy. Tabulky, které by se nikdy neměly objevit v analýze, lze zcela vynechat.

Zároveň zůstávají neprůhledné identifikátory jako org_id, user_id a clerk_user_id spojitelné. To umožňuje BI. Agent nemusí znát e-mailovou adresu osoby nebo text promptu. Potřebuje ale vědět, že stejná organizace se zaregistrovala, spustila úlohu, spotřebovala kredity, předplatila se, usnula nebo se později vrátila.

O to jde: zamaskovat čitelný a citlivý materiál, zachovat relační páteř.

Co agenti dokážou, když hranice existuje

Jakmile existuje maskovaná pouze pro čtení databáze, agent se může rychle stát užitečným.

Může klást otázky přímo na produktová data:

• Retence uživatelů po 7 a 30 dnech
• Aktivace od registrace k prvnímu spuštění
• Retence ukotvená k prvnímu spuštění
• Neaktivita placených organizací
• Stav předplatného a sledování odchodů
• Využití modelu podle vybraného modelu
• Vestavěné vs uživatelské poskytovatelské trasy
• Spotřeba výpočtů ve zkušební době
• Náklady na spuštění podle modelu
• Míra selhání a úspěšnosti podle kohorty

Může také kombinovat pravdu z databáze s okolními systémy.

Náš Morning Brief čerpá z Plausible, Axiom, Sentry, Google Ads, GitHub a dalších provozních zdrojů. Databáze říká, co uživatelé a organizace udělali. Plausible ukazuje, co se stalo na webu. PostHog pomáhá s kontextem produktových událostí. Axiom ukazuje, co se dělo v logách a cestách požadavků. Sentry zachytává chyby. Stripe a Clerk vysvětlují fakturaci a identitu. GitHub ukazuje vývojářskou produktivitu.

Nejde o to nahradit každý nástroj SQL. Jde o to, aby agent propojil fakta, na kterých zakladatelům skutečně záleží.

Například:

Placený Google včera přivedl více návštěv než organika. Dostali se tito uživatelé skutečně k prvnímu spuštění, nebo skončili na začátku trychtýře?

Nebo:

Změnili jsme ochranu proti zneužití zkušební verze. Spálily nové zkušební účty méně výpočtů v prvních hodinách?

Nebo:

Tato modelová trasa je levnější na spuštění. Projevuje se to v reálném historickém používání chatu, nebo jen v cenové teorii?

To nejsou dashboardové otázky. Jsou to provozní otázky. Mění se týden od týdne, někdy denně. Agent s bezpečným přístupem do databáze na ně odpoví bez nutnosti, aby vývojáři pokaždé stavěli nový pohled.

Skutečný příklad: retence a zdraví externích uživatelů

Jedna z našich denních interních analýz sleduje zdraví externích uživatelů za posledních 24 hodin.

Report začíná z MaskDB a aplikuje přísnou vylučovací množinu. Interní VM0 organizace jsou odstraněny. Clerkem zablokované nebo spamové organizace jsou odstraněny. Stejná vylučovací množina se používá všude, včetně počtů registrací a retence, takže jmenovatele lze auditovat.

Odtud může agent vytvořit kompaktní provozní report:

• Spuštění a aktivní externí organizace
• Míra dokončení
• Mix triggerů napříč webem, CLI, plány a ne-Zero trasami
• Mix modelů
• Režim poskytovatele
• Aktivita placených organizací
• Neaktivní placené organizace
• Nové placené registrace a zkušební organizace
• Sledování odchodů
• Segmentace uživatelů po 30 dnech
• Retence od registrace ke spuštění
• Retence po prvním spuštění

To je přesně typ reportu, který tým zakladatelů potřebuje. Nevyžaduje surové prompty. Nevyžaduje surové e-maily. Nevyžaduje právo zápisu do produkce.

Vyžaduje ale schopnost správně spojovat produktová fakta.

V jednom běhu agent zjistil, že malý počet aktivních externích organizací tvoří většinu objemu, že několik placených organizací utichlo a že nedávné kohorty registrací vykazují prudký aktivační útes pravděpodobně způsobený spamovými registracemi, které nafukují jmenovatele. To jsou věci, které by měl zakladatel vidět rychle, ne zjistit až za týdny při kontrole dashboardu.

Druhý příklad: ekonomika zneužití zkušební verze

Maskovaná produktová data jsou užitečná i pro otázky, které nejsou klasickými BI grafy.

Když jsme zkoumali zneužití zkušební verze, užitečnou metrikou nebyla celková spotřeba výpočtů. Celková spotřeba by byla zkreslená směrem ke starším účtům, protože měly více času spotřebovat kredity. Lepší otázka byla:

Kolik zkušebních výpočtů spálí nový účet v prvních hodinách po registraci?

S MaskDB agent měřil spotřebu výpočtů v odpovídajících oknech po registraci. Použil spotřebu kreditů z událostí využití, časová razítka registrace z metadat organizace a stav předplatného k oddělení ekonomiky zkušební verze od placeného využití.

Po zavedení ochrany průměrná spotřeba zkušebních výpočtů v prvních hodinách po registraci klesla o více než 80%. Extrémní případy téměř zmizely. Na 90. percentilu klesla spotřeba zkušebních výpočtů v prvních hodinách z asi $4.05 na asi $0.26, což je pokles o 94%.

Toto číslo není jen analytický bod. Mění provozní pohled na podnikání. Říká týmu zakladatelů, že zneužití nebylo jen detekováno, ale že jednotková ekonomika zkušební verze se posouvá správným směrem.

A bylo to možné, protože databáze měla pravdu, zatímco maskovaná větev umožnila agentovi tuto pravdu bezpečně analyzovat.

Třetí příklad: náklady modelu v reálném produktu

Ceníkové stránky a benchmarky jsou užitečné, ale neodpovídají na otázku, na které zakladatelům skutečně záleží:

Kolik tento model stojí v našem reálném produktu, napříč skutečnými spuštěními?

S MaskDB agent porovnal historická spuštění chatu spojením záznamů o spuštění s modelem vybraným při spuštění a agregací účtovaných kreditů z událostí využití.

Tento rozdíl je důležitý. Neměli byste historická spuštění přiřazovat podle aktuálního výchozího poskytovatele modelu uživatele, protože výchozí hodnoty se mění. Vybraný model při spuštění je zdroj pravdy.

V naší analýze měl DS v4 Pro medián nákladů na chat spuštění v kreditech na model asi 49% oproti Sonnetu. Jinými slovy, skutečné mediánové chat spuštění bylo zhruba o 51% levnější na této trase.

Opět jde o BI na úrovni zakladatele. Propojuje chování produktu, náklady na infrastrukturu a strategii modelu. Nevyžaduje nový sklad. Vyžaduje bezpečný přístup ke správným relačním datům.

Toto není trvalá náhrada skladu

Nastane chvíle, kdy firma potřebuje formálnější datový stack.

Když metriky vyžadují silnou sémantickou správu, když na stejných definicích závisí více týmů, když se historické doplňování komplikuje, když se dashboardy stanou součástí provozního systému, může být sklad nebo lakehouse správnou odpovědí.

Ale mnoho startupů po této odpovědi sahá příliš brzy.

Pokud jste malý tým zakladatelů, váš první BI systém by vám měl pomoci odpovídat na otázky, ne vytvářet druhý produkt na údržbu. Maskovaná databáze může být mostem. Nepředstírá, že datové modelování není důležité. Uznává, že produktová databáze už obsahuje vztahy, které potřebujete pro další rozhodnutí.

Agent neodstraňuje potřebu úsudku. Zlevňuje první verzi analýzy.

Vzor pro týmy zakladatelů

Vzor je jednoduchý:

1. Považujte produktovou databázi za první zdroj pravdy.
2. Nikdy nevystavujte surovou produkci agentům.
3. Použijte produkčně podobnou větev, ne ručně vytvořený vzorek dat.
4. Staticky maskujte citlivé sloupce před přístupem.
5. Zachovejte neprůhledné spojovací identifikátory, aby analýza fungovala.
6. Vystavte větev přes roli pouze pro čtení.
7. Nechte agenty provádět analytickou smyčku napříč maskovanou DB a okolními nástroji.

To dává týmu zakladatelů užitečný provozní systém bez nutnosti nejprve stavět celou datovou platformu.

Zároveň to vytváří čistší bezpečnostní postoj. Agent má tvrdou hranici. Databáze, kterou vidí, už byla transformována. Role, kterou používá, nemůže zapisovat. Reporty, které vytváří, lze omezit na hashované nebo agregované identifikátory.

To je rovnováha, kterou jsme chtěli ve VM0: soukromí a bezpečnost jako základ, ne kompromis, a přitom dát týmu zakladatelů mnohem rychlejší způsob, jak pochopit podnikání.

Než začnete budovat datové jezero, zeptejte se, zda maskovaná, pouze pro čtení větev vaší produktové databáze nemůže odpovědět na dalších 20 otázek, které váš tým skutečně má.

Pro nás to byla rychlejší cesta k BI.

Zdroje

• Neon, „Create Environments with Masked Production Data Using Neon Branches“: https://neon.com/blog/environments-masked-production-data
• Neon fork PostgreSQL Anonymizer: https://github.com/neondatabase/postgresql_anonymizer