BI uten datalake

De fleste BI-prosjekter i oppstartsbedrifter starter for tidlig og for stort.

En gründer stiller et enkelt spørsmål: «Kommer brukere fra denne kanalen tilbake etter sin første kjøring?» Svaret burde vært en spørring. I stedet blir det ofte et plattformprosjekt: koble til alle kilder, bygg et lager, definer hendelser, rens identiteter, sett opp dashbord, og vent.

Det arbeidet blir viktig etter hvert. Men for et lite team kan det være feil første steg. Produktdatabasen vet allerede det meste gründeren trenger å vite. Den vet hvem som registrerte seg, hvem som kjørte noe, hva de brukte, hvor mye det kostet, hva som feilet, og om de kom tilbake.

Det egentlige problemet er ikke hvor sannheten finnes. Det er hvordan man lar en agent analysere den sannheten uten å eksponere den rå produksjonsdatabasen.

Dette er mønsteret vi bruker hos VM0: en maskert, skrivebeskyttet Neon-gren som gir agentene våre nok sannhet til å kjøre BI, uten å gi dem data de aldri skal se.

Gründerproblemet: spørsmålene kommer før datateamet

Tidlige selskaper mangler ikke spørsmål. De mangler tid.

Hver dag vil gründerteamet vite ting som:

• Ble gårsdagens trafikk til faktiske brukere?
• Hvilke registreringskanaler gir folk som faktisk kjører noe?
• Kom førstegangsbrukere tilbake etter 7 eller 30 dager?
• Hvilke betalte kontoer blir stille?
• Hvilken modellrute driver kostnadene?
• Brenner prøveabonnenter opp ressurser før de konverterer?
• Ble produkthelsen bedre eller verre siden i går?

Ingen av disse spørsmålene er spesielle. De er driftsrytmen i en oppstart.

Men å svare på dem med tradisjonell BI gir mye merarbeid. Vanligvis starter du med å flytte data ut av produktdatabasen og inn i et annet system. Så normaliserer du, definerer måltall, bygger relasjoner på nytt og setter opp dashbord. Teamet får en renere analyseplattform, men gründeren venter ofte dager eller uker på et svar som kunne startet som en SQL-spørring.

For en liten oppstart kan det være feil prioritering. Du trenger ikke en komplett dataplattform for å stille dine første 20 driftsrelaterte spørsmål. Du trenger en trygg måte å spørre kilden til sannheten du allerede har.

Databasen er allerede sannhetskilden

Hos VM0 inneholder produktdatabasen faktaene som betyr noe for mange beslutninger på gründer-nivå:

• Organisasjoner og brukere
• Registrerings- og abonnementstilstand
• Agentkjøringer og tidsplaner
• Kredittforbruk og brukshendelser
• Valgte modeller og leverandørruter
• Tilstand for koblinger
• Feiltilstand og tidsstempler

Disse relasjonene finnes allerede. De er ferskere enn ethvert nedstrøms dashbord, og de gjenspeiler hvordan produktet faktisk fungerer.

Dette er viktig fordi mange tidlige BI-spørsmål er relasjonelle. En gründer vil ikke bare ha sidevisninger eller antall kjøringer. De vil koble atferd på tvers av systemet:

Av brukerne som registrerte seg fra denne kanalen, hvor mange kjørte noe på dag null, og hvor mange kom tilbake etter første kjøring?

Eller:

Hvilke betalende organisasjoner har ikke kjørt noe de siste 7 dagene, og så de tidligere aktive ut?

Eller:

Hvor mye ressurser brukte nye prøveabonnenter de første 6 timene, før og etter vi endret misbruksbeskyttelsen?

Disse spørsmålene passer naturlig i produktdatabasen. De blir mye vanskeligere når hvert svar starter med å flytte data til en separat plattform.

Den utrygge snarveien er rå produksjonstilgang

Den fristende snarveien er å la agenten spørre produksjon direkte.

Det er ikke akseptabelt.

En produksjonsdatabase kan inneholde det mest sensitive i selskapet: e-postadresser, prompt, chatinnhold, legitimasjon, kryptert leverandørtilstand, logger, feilmeldinger, API-nøkler og interne driftsdata. Selv om en agent er forsiktig, skaper rå tilgang et grenseproblem. Agenten kan se for mye. En feil i en spørring, rapport eller skjermbilde kan lekke informasjon teamet aldri mente å eksponere.

Skrivetilgang er enda verre. BI skal ikke kunne endre produksjon. En analytiker, enten menneskelig eller agent, skal ikke være ett feilkommando unna å endre brukerdata.

Så spørsmålet er ikke om agenter kan skrive SQL. Det kan de. Spørsmålet er om du kan gi dem nok sannhet til å være nyttige, samtidig som personvern og sikkerhet er harde krav.

For oss er disse kravene selve poenget:

• Agenter skal ikke se rå prompt.
• Agenter skal ikke se rå e-poster.
• Agenter skal ikke se legitimasjon eller hemmeligheter.
• Agenter skal ikke se sensitive fritekstlogger.
• Agenter skal ikke ha skrivetilgang til BI-kilden.
• Gründerteamet skal likevel kunne stille praktiske driftsrelaterte spørsmål raskt.

Det er formen på systemet vi trengte.

Den trygge mellomveien: en maskert, skrivebeskyttet database

Neon gjør et nyttig mønster mulig fordi grener er billige, isolerte kopier av en Postgres-database. Du kan lage en produksjonslignende gren, transformere den, og eksponere den grenen i stedet for produksjon.

Hos VM0 bruker vi dette til å lage det vi kaller MaskDB.

Flyten er enkel:

1. Start fra produksjonsforeldergrenen i Neon.
2. Opprett en ny gren etter en tidsplan.
3. Installer PostgreSQL Anonymizer og VM0-spesifikke maskeringshjelpere.
4. Legg til sikkerhetsmerker for sensitive kolonner.
5. Kjør statisk anonymisering på grenen.
6. Legg til tilpassede masker for felt som krever spesiell behandling.
7. Opprett en masked_readonly-rolle med SELECT-tilgang.
8. La agenter spørre denne rollen, ikke produksjon.

Det viktige er at maskeringen er statisk. Sensitive verdier skrives om på den maskerte grenen før agenten kobler til. Dette er annerledes enn å be hver nedstrøms spørring huske hva som ikke skal velges. Grensen er selve grenen.

I vår MaskDB blir legitimasjon og hemmeligheter fjernet. E-poster og telefonnumre maskeres delvis. Brukerinnhold som prompts, chatmeldinger, schedule-prompter og agentutdata fjernes. Feiltekst reduseres til en klasse i stedet for full stakk eller melding. Tabeller som aldri skal analyseres kan fjernes helt.

Samtidig beholdes ugjennomsiktige identifikatorer som org_id, user_id og clerk_user_id slik at koblinger fortsatt fungerer. Det er dette som gjør BI mulig. Vi trenger ikke at agenten vet en persons e-post eller prompttekst. Vi trenger at den vet at samme organisasjon registrerte seg, kjørte en oppgave, brukte kreditter, abonnerte, ble inaktiv eller kom tilbake senere.

Den balansen er hele poenget: maskér det menneskelesbare og sensitive, bevar den relasjonelle ryggraden.

Hva agenter kan gjøre når grensen er på plass

Når den maskerte skrivebeskyttede databasen finnes, kan agenten raskt bli nyttig.

Den kan stille spørsmål direkte mot produktdata:

• 7-dagers og 30-dagers brukerretensjon
• Aktivering fra registrering til første kjøring
• Retensjon forankret i første kjøring
• Inaktive betalende organisasjoner
• Abonnementstilstand og churn-overvåkning
• Modellbruk per valgt modell
• Innebygd vs bruker-leverandørruter
• Forbruk av prøveabonnement
• Kostnad per kjøring per modell
• Feilrate og fullføringsrate per kohort

Den kan også kombinere denne databasens sannhet med systemene rundt.

Vår Morning Brief henter fra Plausible, Axiom, Sentry, Google Ads, GitHub og andre driftskilder. Databasen forteller oss hva brukere og organisasjoner gjorde. Plausible forteller hva som skjedde på nettsiden. PostHog gir kontekst for produkthendelser. Axiom forteller hva som skjedde i logger og forespørsler. Sentry fanger feil. Stripe og Clerk forklarer fakturering og identitet. GitHub viser utviklingshastighet.

Poenget er ikke å erstatte alle verktøy med SQL. Poenget er å la agenten koble fakta som gründere faktisk bryr seg om.

For eksempel:

Betalt Google sendte mer trafikk enn organisk i går. Nådde disse brukerne faktisk første kjøring, eller stoppet de i toppen av trakten?

Eller:

Vi endret misbruksbeskyttelsen for prøveabonnement. Brant nye prøvebrukere mindre ressurser de første timene?

Eller:

Denne modellruten er billigere per kjøring. Vises det i faktisk historisk chatbruk, eller bare i pris-teori?

Dette er ikke dashbordspørsmål. Det er driftsrelaterte spørsmål. De endrer seg fra uke til uke, noen ganger dag til dag. En agent med trygg databasetilgang kan svare uten at utvikling må bygge en ny visning hver gang.

Et ekte eksempel: retensjon og ekstern brukerhelse

En av våre daglige interne analyser ser på ekstern brukerhelse de siste 24 timene.

Rapporten starter fra MaskDB, og bruker et strengt ekskluderingssett. Interne VM0-organisasjoner fjernes. Clerk-blokkerte eller låste spam-organisasjoner fjernes. Det samme ekskluderingssettet brukes overalt, inkludert registreringstall og retensjonskohorter, slik at nevnerne er etterprøvbare.

Derfra kan agenten lage en kompakt driftsrapport:

• Kjøringer og aktive eksterne organisasjoner
• Fullføringsrate
• Utløsermiks på tvers av web, CLI, tidsplaner og ikke-Zero-ruter
• Modellmiks
• Leverandørmodus
• Aktivitet blant betalende organisasjoner
• Inaktive betalende organisasjoner
• Nye betalte registreringer og prøveorganisasjoner
• Churn-overvåkning
• 30-dagers brukersegmentering
• Retensjon fra registrering til kjøring
• Retensjon etter første kjøring

Dette er akkurat den typen rapport gründerteamet trenger. Den krever ikke rå prompt. Den krever ikke rå e-poster. Den krever ikke skrivetilgang til produksjon.

Den krever evnen til å koble produktfakta riktig.

I én kjøring fant agenten at et lite antall aktive eksterne organisasjoner sto for mesteparten av volumet, at flere betalende organisasjoner hadde blitt stille, og at nylige registreringskohorter viste et tydelig aktiveringsfall sannsynligvis forårsaket av spamregistreringer som blåste opp nevneren. Dette er ting en gründer bør se raskt, ikke oppdage uker senere i en dashbordgjennomgang.

Et annet eksempel: økonomien i prøveabonnementsmisbruk

Maskerte produktdata er også nyttige for spørsmål som ikke er klassiske BI-grafer.

Da vi så på misbruk av prøveabonnement, var den nyttige målingen ikke total ressursbruk. Totalforbruk ville vært skjevt mot eldre kontoer, fordi de hadde hatt mer tid til å bruke kreditter. Det bedre spørsmålet var:

Hvor mye prøvekapasitet bruker en ny konto de første timene etter registrering?

Med MaskDB målte agenten ressursforbruk i definerte vinduer etter registrering. Den brukte kredittforbruk fra brukshendelser, registreringstidsstempler fra organisasjonsmetadata, og abonnementstilstand for å skille prøveøkonomi fra betalt bruk.

Etter at patruljen ble aktiv, falt gjennomsnittlig prøveforbruk de første timene etter registrering med over 80%. Den tunge halen forsvant nesten. På 90. persentil falt prøveforbruket de første timene fra omtrent $4.05 til omtrent $0.26, et fall på 94%.

Det tallet er ikke bare et analysetall. Det endrer driftsbildet av virksomheten. Det forteller gründerteamet at misbruk ikke bare ble oppdaget, men at enhetsøkonomien for prøveperioden beveget seg i riktig retning.

Og det var mulig fordi databasen hadde sannheten, mens den maskerte grenen gjorde det trygt for en agent å analysere den.

Et tredje eksempel: modellkostnad i det virkelige produktet

Prissider og benchmarks er nyttige, men de svarer ikke på spørsmålet gründere faktisk bryr seg om:

Hva koster denne modellen i vårt faktiske produkt, på tvers av faktiske kjøringer?

Med MaskDB sammenlignet agenten historiske chat-kjøringer ved å koble kjøringsposter med modellen valgt ved kjøring, og aggregerte belastede kreditter fra brukshendelser.

Det skillet er viktig. Du bør ikke tilskrive historiske kjøringer til brukerens nåværende standardmodell-leverandør, fordi standarden kan endres. Modellen valgt ved kjøring er sannhetskilden.

I vår analyse hadde DS v4 Pro en median modellkredittkostnad per chat-kjøring på omtrent 49% av Sonnet sin. Med andre ord var den reelle median chat-kjøringen omtrent 51% billigere på den ruten.

Igjen, dette er BI på gründer-nivå. Det kobler produktatferd, infrastrukturkostnad og modellstrategi. Det krever ikke et nytt lager. Det krever trygg tilgang til de riktige relasjonelle dataene.

Dette er ikke en evig erstatning for et lager

Det kommer et punkt hvor et selskap trenger en mer formell datastack.

Når måltall trenger sterk semantisk styring, når mange team er avhengige av samme definisjoner, når historiske etterfyllinger blir komplekse, når dashbord blir en del av driftsplattformen, kan et lager eller lakehouse være riktig svar.

Men mange oppstarter velger det svaret for tidlig.

Hvis du er et lite gründerteam, bør ditt første BI-system hjelpe deg å svare på spørsmål, ikke skape et nytt produkt å vedlikeholde. En maskert database kan være broen. Det later ikke som om datamodellering ikke betyr noe. Det erkjenner at produktdatabasen allerede inneholder relasjonene du trenger for neste beslutning.

Agenten fjerner ikke behovet for skjønn. Den gjør første versjon av analysen billigere å kjøre.

Mønsteret for gründerteam

Mønsteret er enkelt:

1. Behandle produktdatabasen som første sannhetskilde.
2. Aldri eksponer rå produksjon for agenter.
3. Bruk en produksjonslignende gren, ikke et håndlaget utvalg.
4. Maskér sensitive kolonner statisk før tilgang.
5. Bevar ugjennomsiktige koblingsnøkler slik at analyse fungerer.
6. Eksponer grenen gjennom en skrivebeskyttet rolle.
7. La agenter kjøre analytikerløkken mot den maskerte DB-en og tilhørende verktøy.

Dette gir gründerteamet et nyttig driftsverktøy uten å bygge en full dataplattform først.

Det gir også en renere sikkerhetsprofil. Agenten har en tydelig grense. Databasen den ser er allerede transformert. Rollen den bruker kan ikke skrive. Rapportene kan begrenses til hash- eller aggregerte identifikatorer.

Det er balansen vi ønsket hos VM0: personvern og sikkerhet som grunnmur, ikke kompromiss, samtidig som gründerteamet får en mye raskere måte å forstå virksomheten på.

Før du bygger en datalake, spør om en maskert, skrivebeskyttet gren av produktdatabasen kan svare på de neste 20 spørsmålene teamet ditt faktisk har.

For oss var det den raskeste veien til BI.

Kilder

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