BI uden en Data Lake

De fleste startup-BI-projekter starter for tidligt og for stort.

En founder stiller et simpelt spørgsmål: "Kommer brugere fra denne kanal tilbage efter deres første run?" Svaret burde være en forespørgsel. I stedet bliver det ofte til et platformprojekt: forbinde alle kilder, bygge et warehouse, definere events, rense identiteter, opsætte dashboards og vente.

Det arbejde bliver vigtigt på sigt. Men for et lille team kan det være det forkerte første skridt. Produktdatabasen ved allerede det meste af det, founder har brug for at vide. Den ved, hvem der har tilmeldt sig, hvem der har kørt noget, hvad de brugte, hvad det kostede, hvad der fejlede, og om de kom tilbage.

Det reelle problem er ikke, hvor sandheden findes. Det er, hvordan man lader en agent analysere den sandhed uden at eksponere den rå produktionsdatabase.

Det er det mønster, vi bruger hos VM0: en maskeret, skrivebeskyttet Neon-branch, der giver vores agents nok sandhed til at køre BI, uden at give dem adgang til data, de aldrig bør se.

Founder-problemet: spørgsmålene kommer før datateamet

Tidlige virksomheder mangler ikke spørgsmål. De mangler tid.

Hver dag vil founder-teamet vide ting som:

• Blev gårsdagens trafik til rigtige brugere?
• Hvilke signup-kanaler giver folk, der faktisk kører noget?
• Kommer first-run-brugere tilbage efter 7 eller 30 dage?
• Hvilke betalte konti bliver stille?
• Hvilken modelrute driver omkostninger?
• Brænder prøveabuser computekraft af før de konverterer?
• Er produktets sundhed blevet bedre eller værre siden i går?

Ingen af disse spørgsmål er eksotiske. De er driftsrytmen i en startup.

Men at besvare dem med den traditionelle BI-tilgang skaber meget overhead. Man starter typisk med at flytte data ud af produktdatabasen og ind i et andet system. Så normaliserer man, definerer målepunkter, genopbygger relationer og opsætter dashboards. Teamet får en renere analytics-stack, men founder venter ofte dage eller uger på et svar, der kunne være startet som en SQL-forespørgsel.

For en lille startup kan det bytteforhold være forkert. Du behøver ikke en komplet dataplatform for at stille dine første 20 driftsrelaterede spørgsmål. Du har brug for en sikker måde at forespørge den sandhed, du allerede har.

Databasen er allerede sandhedskilden

Hos VM0 indeholder produktdatabasen de fakta, der er vigtige for mange founder-beslutninger:

• Organisationer og brugere
• Signup- og abonnementsstatus
• Agent-runs og -skemaer
• Kreditforbrug og usage-events
• Valgte modeller og provider-ruter
• Connector-status
• Fejlstatus og tidsstempler

De relationer findes allerede. De er friskere end ethvert downstream-dashboard og afspejler, hvordan produktet faktisk fungerer.

Det er vigtigt, fordi mange tidlige BI-spørgsmål er relationelle. En founder vil ikke kun have sidevisninger eller run-tællinger. De vil forbinde adfærd på tværs af systemet:

Af de brugere, der registrerede sig fra denne kanal, hvor mange kørte noget på dag nul, og hvor mange kom tilbage efter deres første run?

Eller:

Hvilke betalende organisationer har ikke kørt noget de sidste 7 dage, og så de tidligere aktive ud?

Eller:

Hvor meget compute brugte nye prøvekonti i deres første 6 timer, før og efter vi ændrede vores abuse patrol?

Disse spørgsmål passer naturligt i produktdatabasen. De bliver meget sværere, hvis hvert svar starter med at flytte data til en separat platform.

Den usikre genvej er rå produktionsadgang

Den fristende genvej er åbenlys: lad bare agenten forespørge produktionen.

Det er ikke acceptabelt.

En produktionsdatabase kan indeholde det mest følsomme materiale i virksomheden: e-mailadresser, prompts, chatindhold, credentials, krypteret provider-status, logs, fejlbeskeder, API-nøgler og interne driftsoptegnelser. Selv hvis en agent er forsigtig, skaber rå adgang et grænseproblem. Agenten kan se for meget. En fejl i en forespørgsel, rapport eller et screenshot kan lække information, teamet aldrig havde tænkt skulle eksponeres.

Skriveadgang er endnu værre. BI bør ikke kunne ændre produktionen. En analytiker, menneskelig eller AI, bør ikke være ét forkert kommando fra at ændre brugerdata.

Så spørgsmålet er ikke, om agenter kan skrive SQL. Det kan de. Spørgsmålet er, om du kan give dem nok sandhed til at være nyttige, mens privatliv og sikkerhed forbliver ufravigelige krav.

For os er de krav selve pointen:

• Agenter må ikke se rå prompts.
• Agenter må ikke se rå e-mails.
• Agenter må ikke se credentials eller hemmeligheder.
• Agenter må ikke se følsomme frit-tekst-logs.
• Agenter må ikke have skriveadgang til BI-kilden.
• Founder-teamet skal stadig hurtigt kunne stille praktiske driftsrelaterede spørgsmål.

Det er formen på det system, vi havde brug for.

Det sikre kompromis: en maskeret, skrivebeskyttet database

Neon gør et nyttigt mønster muligt, fordi branches er billige, isolerede kopier af en Postgres-database. Du kan oprette en produktionslignende branch, transformere den og eksponere den branch i stedet for selve produktionen.

Hos VM0 bruger vi dette til at skabe det, vi kalder MaskDB.

Forløbet er enkelt:

1. Start fra produktions-Neon-parent-branchen.
2. Opret en frisk branch på et skema.
3. Installer PostgreSQL Anonymizer og VM0-specifikke masking-hjælpere.
4. Anvend sikkerhedslabels på følsomme kolonner.
5. Kør statisk anonymisering på branchen.
6. Anvend endelige brugerdefinerede masker på felter, der kræver særlig håndtering.
7. Opret en masked_readonly-rolle med SELECT-adgang.
8. Lad agenter forespørge den rolle, ikke produktionen.

Det vigtige er, at maskeringen er statisk. Følsomme værdier omskrives på den maskerede branch, før agenten forbinder. Det er anderledes end at bede hver downstream-forespørgsel om at huske, hvad der ikke må vælges. Branchen er selve grænsen.

I vores MaskDB bliver credentials og hemmeligheder redigeret væk. E-mails og telefonnumre maskeres delvist. Brugerindhold som prompts, chatbeskeder, skemaprompts og agentoutputs fjernes. Fejltekst reduceres til en klasse frem for en fuld stack eller besked. Tabeller, der aldrig bør indgå i analyser, kan fjernes helt.

Samtidig bevares uigennemsigtige id'er som org_id, user_id og clerk_user_id, så de stadig kan joines. Det er dét, der gør BI muligt. Vi behøver ikke, at agenten kender en persons e-mailadresse eller prompttekst. Vi har brug for, at den kan se, at samme organisation registrerede sig, kørte en opgave, brugte credits, abonnerede, blev inaktiv eller kom tilbage senere.

Den balance er hele pointen: maskér det menneskeligt læsbare og følsomme, bevar den relationelle rygrad.

Hvad agenter kan gøre, når grænsen er sat

Når den maskerede skrivebeskyttede database findes, kan agenten hurtigt blive nyttig.

Den kan stille spørgsmål direkte til produktdata:

• 7-dages og 30-dages brugerfastholdelse
• Aktivering fra registrering til første run
• Fastholdelse forankret i første run
• Betalte organisationers inaktivitet
• Abonnementsstatus og churn-overvågning
• Modelbrug pr. valgt model
• Indbyggede vs bruger-provider-ruter
• Forbrug af prøve-compute
• Omkostning pr. run pr. model
• Fejlrate og gennemførelsesrate pr. kohorte

Den kan også kombinere denne database-sandhed med de omkringliggende systemer.

Vores Morning Brief trækker fra Plausible, Axiom, Sentry, Google Ads, GitHub og andre driftskilder. Databasen fortæller, hvad brugere og organisationer gjorde. Plausible fortæller, hvad der skete på sitet. PostHog kan hjælpe med produkt-event-kontekst. Axiom fortæller, hvad der skete i logs og request paths. Sentry fanger fejl. Stripe og Clerk hjælper med at forklare fakturering og identitet. GitHub viser engineering-gennemløb.

Pointen er ikke at erstatte alle værktøjer med SQL. Pointen er at lade agenten forbinde de fakta, founders faktisk går op i.

For eksempel:

Betalt Google sendte mere trafik end organisk i går. Nåede de brugere faktisk til første run, eller stoppede de i toppen af tragten?

Eller:

Vi ændrede prøveabuse-patruljen. Brændte nye prøvekonti mindre compute af i deres første timer?

Eller:

Denne modelrute er billigere pr. run. Kan det ses i reel historisk chatbrug, eller kun i pris-teori?

Det er ikke dashboard-spørgsmål. Det er driftsrelaterede spørgsmål. De ændrer sig uge for uge, nogle gange dagligt. En agent med sikker databaseadgang kan besvare dem uden at bede engineering bygge et nyt view hver gang.

Et konkret eksempel: fastholdelse og ekstern brugersundhed

En af vores daglige interne analyser ser på ekstern brugersundhed over de seneste 24 timer.

Rapporten starter fra MaskDB og anvender derefter et strengt eksklusionssæt. Interne VM0-organisationer fjernes. Clerk-blokerede eller låste spam-organisationer fjernes. Det samme eksklusionssæt bruges overalt, også i registreringstællinger og fastholdelses-kohorter, så nævnerne forbliver reviderbare.

Derfra kan agenten lave en kompakt driftsrapport:

• Runs og aktive eksterne organisationer
• Gennemførelsesrate
• Trigger-mix på tværs af web, CLI, skemaer og ikke-Zero-ruter
• Model-mix
• Provider-mode
• Betalt organisationsaktivitet
• Inaktive betalte organisationer
• Nye betalte tilmeldinger og prøveorganisationer
• Churn-overvågning
• 30-dages brugersegmentering
• Registrering-til-run-fastholdelse
• Første-run-fastholdelse

Dette er præcis den slags rapport, et founder-team har brug for. Den kræver ikke rå prompts. Den kræver ikke rå e-mails. Den kræver ikke skriveadgang til produktionen.

Den kræver, at man kan join'e produktdata korrekt.

I ét run fandt agenten, at et lille antal aktive eksterne organisationer stod for det meste af volumen, at flere betalte organisationer var blevet stille, og at nylige registreringskohorter viste et skarpt aktiveringsfald, sandsynligvis forårsaget af spamregistreringer, der oppustede nævneren. Det er den slags ting, en founder hurtigt bør se, ikke opdage uger senere i et dashboard-review.

Et andet eksempel: økonomien i prøveabuse

Maskerede produktdata er også nyttige til spørgsmål, der ikke er klassiske BI-diagrammer.

Da vi undersøgte prøveabuse, var den nyttige måling ikke det samlede forbrugte compute. Det samlede forbrug ville være skævt mod ældre konti, fordi de havde haft mere tid til at bruge credits. Det bedre spørgsmål var:

Hvor meget prøve-compute bruger en ny konto i sine første timer efter signup?

Ved brug af MaskDB målte agenten compute-forbrug i matchede vinduer efter registrering. Den brugte kreditforbrug fra usage-events, registreringstidsstempler fra org-metadata og abonnementsstatus til at adskille prøveøkonomi fra betalt brug.

Efter patruljen gik live, faldt gennemsnitligt prøve-compute forbrugt i de første timer efter signup med mere end 80%. Den tunge hale forsvandt næsten. På 90. percentil faldt prøve-compute i de første timer fra ca. $4.05 til ca. $0.26, et fald på 94%.

Det tal er ikke bare et analytics-punkt. Det ændrer det driftsmæssige syn på forretningen. Det fortæller founder-teamet, at abuse ikke kun blev opdaget, men at enhedsøkonomien i prøven bevægede sig i den rigtige retning.

Og det var muligt, fordi databasen havde sandheden, mens den maskerede branch gjorde det sikkert for en agent at analysere den sandhed.

Et tredje eksempel: modelomkostning i det rigtige produkt

Prisoversigter og benchmark-ark er nyttige, men de besvarer ikke det spørgsmål, founders faktisk går op i:

Hvad koster denne model i vores rigtige produkt, på tværs af rigtige runs?

Ved brug af MaskDB sammenlignede agenten historiske chat-runs ved at join'e run-records med den model, der blev valgt ved run-tidspunktet, og aggregere opkrævede credits fra usage-events.

Den forskel er vigtig. Man bør ikke tilskrive historiske runs til brugerens nuværende standardmodel-provider, fordi standarder ændrer sig. Den valgte model ved run-tidspunktet er sandhedskilden.

I vores analyse havde DS v4 Pro en median model-credit-omkostning pr. chat-run, der var ca. 49% af Sonnet's. Med andre ord var det reelle median-chat-run omtrent 51% billigere på den rute.

Igen, dette er founder-niveau BI. Det forbinder produktadfærd, infrastruktur-omkostning og modelstrategi. Det kræver ikke et nyt warehouse. Det kræver sikker adgang til de rigtige relationelle data.

Dette er ikke en permanent erstatning for et warehouse

Der kommer et tidspunkt, hvor en virksomhed har brug for en mere formel datastack.

Når målepunkter kræver stærk semantisk styring, når mange teams er afhængige af de samme definitioner, når historiske backfills bliver komplekse, når dashboards bliver en del af driftsmiljøet, kan et warehouse eller lakehouse være det rigtige svar.

Men mange startups vælger det svar for tidligt.

Hvis du er et lille founder-team, bør dit første BI-system hjælpe dig med at besvare spørgsmål, ikke skabe et andet produkt, der skal vedligeholdes. En maskeret database kan være broen. Det foregiver ikke, at datamodellering er ligegyldigt. Det anerkender, at produktdatabasen allerede indeholder de relationer, du skal bruge til de næste beslutninger.

Agenten fjerner ikke behovet for dømmekraft. Den gør første version af analysen billigere at køre.

Mønstret for founder-teams

Mønstret er enkelt:

1. Behandl produktdatabasen som første sandhedskilde.
2. Eksponér aldrig rå produktion for agenter.
3. Brug en produktionslignende branch, ikke et håndlavet sample-datasæt.
4. Maskér følsomme kolonner statisk før adgang.
5. Bevar uigennemsigtige join-id'er, så analysen stadig virker.
6. Eksponér branchen gennem en skrivebeskyttet rolle.
7. Lad agenter køre analyst-loopet på tværs af den maskerede DB og de omkringliggende værktøjer.

Dette giver et founder-team et nyttigt driftsmiljø uden først at bygge en fuld dataplatform.

Det skaber også en renere sikkerhedsprofil. Agenten har en hård grænse. Databasen, den ser, er allerede transformeret. Rollen, den bruger, kan ikke skrive. De rapporter, den laver, kan begrænses til hash- eller aggregerede id'er.

Det er balancen, vi ønskede hos VM0: privatliv og sikkerhed som fundament, ikke som kompromis, mens founder-teamet stadig får en langt hurtigere måde at forstå forretningen på.

Før du bygger en data lake, så spørg, om en maskeret, skrivebeskyttet branch af din produktdatabase kan besvare de næste 20 spørgsmål, dit team faktisk har.

For os var det den hurtigere vej til BI.

Kilder

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