BI bez jeziora danych

Większość startupowych projektów BI zaczyna się zbyt wcześnie i zbyt ambitnie.

Założyciel zadaje proste pytanie: „Czy użytkownicy z tego kanału wracają po swoim pierwszym uruchomieniu?” Odpowiedzią powinna być kwerenda. Zamiast tego często przeradza się to w projekt platformy: podłącz wszystkie źródła, zbuduj hurtownię, zdefiniuj zdarzenia, oczyść tożsamości, połącz dashboardy i czekaj.

Ta praca w końcu będzie miała znaczenie. Ale dla małego zespołu może to być zły pierwszy krok. Baza danych produktu już wie większość tego, co założyciel musi wiedzieć. Wie, kto się zarejestrował, kto coś uruchomił, czego użył, ile to kosztowało, co się nie powiodło i czy wrócił.

Prawdziwy problem nie polega na tym, gdzie znajduje się prawda. Chodzi o to, jak pozwolić agentowi analizować tę prawdę bez ujawniania surowej bazy produkcyjnej.

To jest wzorzec, którego używamy w VM0: zamaskowana, tylko do odczytu gałąź Neon, która daje naszym agentom wystarczająco dużo prawdy do prowadzenia BI, nie dając im danych, których nie powinni widzieć.

Problem założyciela: pytania pojawiają się przed zespołem danych

Firmy na wczesnym etapie nie mają braku pytań. Brakuje im czasu.

Każdego dnia zespół założycielski chce wiedzieć:

• Czy wczorajszy ruch zamienił się w prawdziwych użytkowników?
• Które kanały rejestracji przyciągają osoby, które faktycznie coś uruchamiają?
• Czy użytkownicy po pierwszym uruchomieniu wracają po 7 lub 30 dniach?
• Które płatne konta milkną?
• Która trasa modelu generuje koszty?
• Czy nadużywający okresu próbnego zużywają zasoby obliczeniowe zanim się skonwertują?
• Czy kondycja produktu poprawiła się czy pogorszyła od wczoraj?

Żadne z tych pytań nie jest egzotyczne. To codzienny rytm działania startupu.

Ale odpowiadanie na nie według tradycyjnego schematu BI generuje dużo narzutu. Zwykle zaczynasz od przeniesienia danych z bazy produktu do innego systemu. Następnie je normalizujesz, definiujesz metryki, odbudowujesz relacje i konfigurujesz dashboardy. Zespół dostaje czystszy stos analityczny, ale założyciel często czeka dni lub tygodnie na odpowiedź, która mogła zacząć się od zapytania SQL.

Dla małego startupu ten kompromis może być nieopłacalny. Nie potrzebujesz kompletnej platformy danych, by zadać pierwsze 20 pytań operacyjnych. Potrzebujesz bezpiecznego sposobu na zapytanie źródła prawdy, które już masz.

Baza danych już jest źródłem prawdy

W VM0 baza danych produktu zawiera fakty istotne dla wielu decyzji na poziomie założycielskim:

• Organizacje i użytkownicy
• Stan rejestracji i subskrypcji
• Uruchomienia agentów i harmonogramy
• Zużycie kredytów i zdarzenia użycia
• Wybrane modele i trasy dostawców
• Stan konektorów
• Stan błędów i znaczniki czasu

Te relacje już istnieją. Są świeższe niż jakikolwiek downstreamowy dashboard i odzwierciedlają rzeczywiste działanie produktu.

To ważne, bo wiele wczesnych pytań BI jest relacyjnych. Założyciel nie chce tylko liczby odsłon czy uruchomień. Chce połączyć zachowania w całym systemie:

Spośród użytkowników, którzy zarejestrowali się z tego kanału, ilu coś uruchomiło w dniu zerowym, a ilu wróciło po pierwszym uruchomieniu?

Albo:

Które płatne organizacje nie uruchomiły niczego w ostatnich 7 dniach i czy wcześniej były aktywne?

Albo:

Ile zasobów obliczeniowych zużyły nowe konta próbne w pierwszych 6 godzinach, przed i po zmianie patrolu nadużyć?

Te pytania naturalnie pasują do bazy produktu. Stają się znacznie trudniejsze, gdy każda odpowiedź zaczyna się od przeniesienia danych do osobnej platformy.

Niebezpieczny skrót to dostęp do produkcji

Kuszący skrót jest oczywisty: po prostu pozwól agentowi zapytać produkcję.

To nieakceptowalne.

Baza produkcyjna może zawierać najbardziej wrażliwe dane w firmie: adresy e-mail, prompt’y, treści czatów, dane uwierzytelniające, zaszyfrowane stany dostawców, logi, komunikaty o błędach, klucze API i wewnętrzne zapisy operacyjne. Nawet jeśli agent jest ostrożny, surowy dostęp tworzy problem granicy. Agent widzi zbyt wiele. Błąd w zapytaniu, raporcie lub zrzucie ekranu może ujawnić informacje, których zespół nigdy nie chciał pokazać.

Dostęp do zapisu jest jeszcze gorszy. BI nie powinno mieć możliwości modyfikowania produkcji. Analityk, ludzki czy agentowy, nie powinien być o jedno polecenie od zmiany danych użytkownika.

Więc pytanie nie brzmi, czy agenci potrafią pisać SQL. Potrafią. Pytanie brzmi, czy możesz dać im wystarczająco dużo prawdy, by byli użyteczni, zachowując prywatność i bezpieczeństwo jako twarde ograniczenia.

Dla nas te ograniczenia są kluczowe:

• Agenci nie powinni widzieć surowych promptów.
• Agenci nie powinni widzieć surowych e-maili.
• Agenci nie powinni widzieć danych uwierzytelniających ani sekretów.
• Agenci nie powinni widzieć wrażliwych logów tekstowych.
• Agenci nie powinni mieć dostępu zapisu do źródła BI.
• Zespół założycielski powinien nadal móc szybko zadawać praktyczne pytania operacyjne.

Taki system był nam potrzebny.

Bezpieczny kompromis: zamaskowana, tylko do odczytu baza danych

Neon umożliwia ten wzorzec, bo gałęzie to tanie, izolowane kopie bazy Postgres. Możesz utworzyć gałąź podobną do produkcyjnej, przekształcić ją i udostępnić zamiast produkcji.

W VM0 używamy tego do stworzenia MaskDB.

Przebieg jest prosty:

1. Zacznij od produkcyjnej gałęzi nadrzędnej Neon.
2. Twórz świeżą gałąź według harmonogramu.
3. Zainstaluj PostgreSQL Anonymizer i dedykowane maskujące narzędzia VM0.
4. Nadaj etykiety bezpieczeństwa dla wrażliwych kolumn.
5. Wykonaj statyczną anonimizację na gałęzi.
6. Zastosuj końcowe, niestandardowe maski dla pól wymagających szczególnej obsługi.
7. Utwórz rolę masked_readonly z dostępem SELECT.
8. Pozwól agentom zapytywać tę rolę, nie produkcję.

Ważny szczegół: maskowanie jest statyczne. Wrażliwe wartości są przepisywane na zamaskowanej gałęzi przed połączeniem agenta. To różni się od wymagania, by każde downstreamowe zapytanie pamiętało, czego nie wybierać. Sama gałąź jest granicą.

W MaskDB dane uwierzytelniające i sekrety są zaciemnione. E-maile i numery telefonów są częściowo zamaskowane. Treści użytkowników, takie jak prompt’y, wiadomości czatu, prompt’y harmonogramów i wyniki agentów, są usuwane. Tekst błędów jest redukowany do klasy zamiast pełnego stosu czy komunikatu. Tabele, które nigdy nie powinny pojawić się w analizie, mogą być całkowicie usunięte.

Jednocześnie nieprzezroczyste identyfikatory jak org_id, user_id i clerk_user_id pozostają możliwe do łączenia. To umożliwia BI. Nie potrzebujemy, by agent znał adres e-mail czy tekst promptu. Potrzebujemy, by wiedział, że ta sama organizacja się zarejestrowała, uruchomiła zadanie, zużyła kredyty, zasubskrybowała, uśpiła się lub wróciła później.

O to właśnie chodzi: zamaskować czytelne i wrażliwe dane, zachować relacyjną strukturę.

Co mogą zrobić agenci, gdy istnieje granica

Gdy istnieje zamaskowana baza tylko do odczytu, agent szybko staje się użyteczny.

Może zadawać pytania bezpośrednio do danych produktu:

• Retencja użytkowników po 7 i 30 dniach
• Aktywacja od rejestracji do pierwszego uruchomienia
• Retencja zakotwiczona w pierwszym uruchomieniu
• Uśpienie płatnych organizacji
• Stan subskrypcji i obserwacja odpływu
• Użycie modeli według wybranego modelu
• Wbudowane vs trasy użytkownika-dostawcy
• Zużycie zasobów próbnych
• Koszt na uruchomienie według modelu
• Wskaźnik błędów i ukończenia według kohorty

Może też łączyć prawdę z bazy z innymi systemami.

Nasz Morning Brief pobiera dane z Plausible, Axiom, Sentry, Google Ads, GitHub i innych źródeł operacyjnych. Baza mówi, co zrobili użytkownicy i organizacje. Plausible pokazuje, co działo się na stronie. PostHog pomaga z kontekstem zdarzeń produktowych. Axiom pokazuje, co działo się w logach i ścieżkach żądań. Sentry łapie błędy. Stripe i Clerk pomagają wyjaśnić rozliczenia i tożsamość. GitHub pokazuje wydajność inżynierii.

Nie chodzi o zastąpienie każdego narzędzia SQL-em. Chodzi o to, by agent łączył fakty, na których zależy założycielom.

Na przykład:

Płatne Google przyniosło wczoraj więcej ruchu niż organiczne. Czy ci użytkownicy faktycznie dotarli do pierwszego uruchomienia, czy zatrzymali się na początku lejka?

Albo:

Zmieniliśmy patrol nadużyć próbnych. Czy nowe konta próbne zużyły mniej zasobów w pierwszych godzinach?

Albo:

Ta trasa modelu jest tańsza na uruchomienie. Czy widać to w rzeczywistym historycznym użyciu czatu, czy tylko w teorii cenowej?

To nie są pytania dashboardowe. To pytania operacyjne. Zmieniają się z tygodnia na tydzień, czasem z dnia na dzień. Agent z bezpiecznym dostępem do bazy może na nie odpowiedzieć bez angażowania inżynierii do budowy nowego widoku za każdym razem.

Prawdziwy przykład: retencja i zdrowie użytkowników zewnętrznych

Jedna z naszych codziennych analiz wewnętrznych bada zdrowie użytkowników zewnętrznych z ostatnich 24 godzin.

Raport zaczyna się od MaskDB, potem stosuje ścisły zestaw wykluczeń. Organizacje wewnętrzne VM0 są usuwane. Organizacje zbanowane przez Clerk lub oznaczone jako spam są usuwane. Ten sam zestaw wykluczeń stosowany jest wszędzie, także do liczby rejestracji i kohort retencji, by mianowniki były audytowalne.

Stąd agent może wygenerować zwięzły raport operacyjny:

• Uruchomienia i aktywne organizacje zewnętrzne
• Wskaźnik ukończenia
• Mix wyzwalaczy: web, CLI, harmonogramy, trasy inne niż Zero
• Mix modeli
• Tryb dostawcy
• Aktywność płatnych organizacji
• Uśpione płatne organizacje
• Nowe płatne rejestracje i organizacje próbne
• Obserwacja odpływu
• Segmentacja użytkowników po 30 dniach
• Retencja od rejestracji do uruchomienia
• Retencja po pierwszym uruchomieniu

To dokładnie taki raport, jakiego potrzebuje zespół założycielski. Nie wymaga surowych promptów. Nie wymaga surowych e-maili. Nie wymaga dostępu zapisu do produkcji.

Wymaga natomiast poprawnego łączenia faktów produktowych.

W jednym uruchomieniu agent odkrył, że niewielka liczba aktywnych organizacji zewnętrznych generowała większość wolumenu, kilka płatnych organizacji ucichło, a ostatnie kohorty rejestracji wykazały wyraźny spadek aktywacji, prawdopodobnie spowodowany przez spamowe rejestracje zawyżające mianownik. To są rzeczy, które założyciel powinien widzieć szybko, a nie odkrywać tygodnie później podczas przeglądu dashboardu.

Drugi przykład: ekonomia nadużyć próbnych

Zamaskowane dane produktowe są też przydatne do pytań, które nie są klasycznymi wykresami BI.

Gdy analizowaliśmy nadużycia próbne, użyteczną metryką nie była suma zużytych zasobów. Całkowite zużycie byłoby zawyżone przez starsze konta, które miały więcej czasu na wykorzystanie kredytów. Lepsze pytanie brzmiało:

Ile zasobów próbnych zużywa nowe konto w pierwszych godzinach po rejestracji?

Korzystając z MaskDB, agent mierzył zużycie obliczeń w dopasowanych oknach po rejestracji. Wykorzystywał zużycie kredytów ze zdarzeń użycia, znaczniki czasu rejestracji z metadanych organizacji i stan subskrypcji, by oddzielić ekonomię prób od płatnych użyć.

Po wdrożeniu patrolu średnie zużycie próbnych zasobów w pierwszych godzinach po rejestracji spadło o ponad 80%. Ogon intensywnego zużycia niemal zniknął. Na 90. percentylu próbne zużycie w pierwszych godzinach spadło z około $4.05 do około $0.26, co oznacza spadek o 94%.

Ta liczba to nie tylko punkt analityczny. Zmienia operacyjny obraz biznesu. Pokazuje zespołowi założycielskiemu, że nadużycia nie tylko są wykrywane, ale ekonomia jednostkowa okresu próbnego zmierza w dobrym kierunku.

A było to możliwe, bo baza miała prawdę, a zamaskowana gałąź umożliwiła agentowi jej bezpieczną analizę.

Trzeci przykład: koszt modelu w realnym produkcie

Strony cenowe i arkusze benchmarków są przydatne, ale nie odpowiadają na pytanie, które naprawdę interesuje założycieli:

Ile kosztuje ten model w naszym realnym produkcie, na rzeczywistych uruchomieniach?

Korzystając z MaskDB, agent porównał historyczne uruchomienia czatu, łącząc rekordy uruchomień z modelem wybranym w danym momencie i sumując naliczone kredyty ze zdarzeń użycia.

To rozróżnienie jest ważne. Nie należy przypisywać historycznych uruchomień do obecnego domyślnego dostawcy modelu użytkownika, bo domyślne ustawienia się zmieniają. Wybrany model w momencie uruchomienia to źródło prawdy.

W naszej analizie DS v4 Pro miał medianowy koszt kredytowy na uruchomienie czatu około 49% kosztu Sonnet. Innymi słowy, rzeczywiste medianowe uruchomienie czatu było około 51% tańsze na tej trasie.

To znów BI na poziomie założycielskim. Łączy zachowanie produktu, koszt infrastruktury i strategię modelową. Nie wymaga nowej hurtowni. Wymaga bezpiecznego dostępu do właściwych danych relacyjnych.

To nie jest wieczny zamiennik hurtowni

Przychodzi moment, gdy firma potrzebuje bardziej formalnego stosu danych.

Gdy metryki wymagają silnego zarządzania semantyką, gdy wiele zespołów polega na tych samych definicjach, gdy historyczne uzupełnienia stają się złożone, gdy dashboardy stają się częścią systemu operacyjnego, hurtownia lub lakehouse mogą być właściwą odpowiedzią.

Ale wiele startupów sięga po to zbyt wcześnie.

Jeśli jesteś małym zespołem założycielskim, twój pierwszy system BI powinien pomagać odpowiadać na pytania, a nie tworzyć drugi produkt do utrzymania. Zamaskowana baza może być pomostem. To nie udawanie, że modelowanie danych nie ma znaczenia. To uznanie, że baza produktu już zawiera relacje potrzebne do kolejnych decyzji.

Agent nie zastępuje potrzeby osądu. Sprawia, że pierwsza wersja analizy jest tańsza do wykonania.

Wzorzec dla zespołów założycielskich

Wzorzec jest prosty:

1. Traktuj bazę produktu jako pierwsze źródło prawdy.
2. Nigdy nie udostępniaj surowej produkcji agentom.
3. Używaj gałęzi podobnej do produkcyjnej, nie ręcznie budowanego zbioru próbnego.
4. Statycznie maskuj wrażliwe kolumny przed dostępem.
5. Zachowaj nieprzezroczyste identyfikatory do łączenia, by analiza działała.
6. Udostępnij gałąź przez rolę tylko do odczytu.
7. Pozwól agentom wykonywać pętlę analityka na zamaskowanej bazie i otaczających narzędziach.

To daje zespołowi założycielskiemu użyteczny system operacyjny bez budowania od razu pełnej platformy danych.

Tworzy też czystsze podejście do bezpieczeństwa. Agent ma twardą granicę. Baza, którą widzi, już została przekształcona. Rola, której używa, nie może zapisywać. Raporty mogą być ograniczone do haszowanych lub zagregowanych identyfikatorów.

To równowaga, której chcieliśmy w VM0: prywatność i bezpieczeństwo jako podstawa, nie kompromis, a jednocześnie znacznie szybszy sposób na zrozumienie biznesu przez zespół założycielski.

Zanim zbudujesz jezioro danych, zapytaj, czy zamaskowana, tylko do odczytu gałąź twojej bazy produktu może odpowiedzieć na kolejne 20 pytań, które twój zespół naprawdę ma.

Dla nas to była szybsza droga do BI.

Źródła

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