BI ilman tietojärveä

Useimmat startupin BI-projektit alkavat liian aikaisin ja liian suurina.

Founder esittää yksinkertaisen kysymyksen: "Palaavatko tämän kanavan käyttäjät ensimmäisen suorituksensa jälkeen?" Vastauksen pitäisi olla kysely. Usein siitä kuitenkin tulee alusta-projekti: yhdistä kaikki lähteet, rakenna varasto, määrittele tapahtumat, puhdista identiteetit, rakenna dashboardit ja odota.

Tuo työ on lopulta tärkeää. Mutta pienelle tiimille se voi olla väärä ensimmäinen askel. Tuotetietokanta tietää jo suurimman osan siitä, mitä founderin tarvitsee tietää. Se tietää, kuka rekisteröityi, kuka ajoi jotain, mitä käytettiin, paljonko se maksoi, mikä epäonnistui ja tuliko käyttäjä takaisin.

Todellinen ongelma ei ole, missä totuus sijaitsee. Ongelma on, miten antaa agentille mahdollisuus analysoida totuutta paljastamatta raakaa tuotantotietokantaa.

Tätä mallia käytämme VM0:ssa: peitetty, vain luku -Neon-haara, joka antaa agenteille riittävästi totuutta BI:n ajamiseen, mutta ei paljasta tietoja, joita niiden ei pitäisi koskaan nähdä.

Founder-ongelma: kysymykset tulevat ennen data-tiimiä

Varhaisvaiheen yrityksiltä ei puutu kysymyksiä. Niiltä puuttuu aikaa.

Joka päivä founder-tiimi haluaa tietää esimerkiksi:

• Muuttuiko eilinen liikenne oikeiksi käyttäjiksi?
• Mitkä rekisteröitymiskanavat tuottavat käyttäjiä, jotka oikeasti ajavat jotain?
• Palaavatko ensimmäisen suorituksen käyttäjät 7 tai 30 päivän jälkeen?
• Mitkä maksulliset tilit ovat hiljenemässä?
• Mikä mallireitti kasvattaa kustannuksia?
• Polttavatko kokeilun väärinkäyttäjät laskentatehoa ennen konversiota?
• Parantuiko vai huononiko tuotteen terveys eiliseen verrattuna?

Yksikään näistä kysymyksistä ei ole eksoottinen. Ne ovat startupin operatiivista sykliä.

Mutta niiden ratkaiseminen perinteisellä BI-mallilla luo paljon ylimääräistä työtä. Yleensä aloitat siirtämällä dataa tuotetietokannasta toiseen järjestelmään. Sitten normalisoit sen, määrittelet mittarit, rakennat suhteet uudelleen ja pystytät dashboardit. Tiimi saa siistimmän analytiikkapinon, mutta founder odottaa usein päiviä tai viikkoja vastausta, joka olisi voinut alkaa SQL-kyselystä.

Pienelle startupille tämä vaihtokauppa voi olla väärinpäin. Et tarvitse täydellistä datapohjaa kysyäksesi ensimmäiset 20 operatiiviset kysymyksesi. Tarvitset turvallisen tavan kysyä jo olemassa olevaa totuutta.

Tietokanta on jo totuuden lähde

VM0:ssa tuotetietokanta sisältää faktat, jotka ovat tärkeitä monissa founder-tason päätöksissä:

• Organisaatiot ja käyttäjät
• Rekisteröitymis- ja tilausstatus
• Agenttien suoritukset ja aikataulut
• Kreditin kulutus ja käyttötapahtumat
• Valitut mallit ja tarjoajareitit
• Liitännäisten tila
• Epäonnistumistila ja aikaleimat

Nämä suhteet ovat jo olemassa. Ne ovat tuoreempia kuin mikään alaspäin johdettu dashboard, ja ne heijastavat, miten tuote oikeasti toimii.

Tämä on tärkeää, koska monet varhaiset BI-kysymykset liittyvät suhteisiin. Founder ei halua vain sivulatauksia tai suoritusten määriä. Hän haluaa yhdistää käyttäytymistä järjestelmän läpi:

Kuinka moni tämän kanavan kautta rekisteröitynyt käyttäjä ajoi jotain päivänä nolla, ja kuinka moni palasi ensimmäisen suorituksen jälkeen?

Tai:

Mitkä maksulliset organisaatiot eivät ole ajaneet mitään viimeiseen 7 päivään, ja vaikuttivatko ne aiemmin aktiivisilta?

Tai:

Kuinka paljon laskentatehoa uudet kokeilutilit polttivat ensimmäisen 6 tunnin aikana, ennen ja jälkeen väärinkäytösten valvonnan muutoksen?

Nämä kysymykset istuvat luontevasti tuotetietokantaan. Niistä tulee paljon vaikeampia, jos jokainen vastaus alkaa datan siirrolla erilliseen järjestelmään.

Turvaton oikotie on raaka tuotantopääsy

Houkutteleva oikotie on ilmeinen: anna agentin kysellä tuotantoa.

Se ei ole hyväksyttävää.

Tuotantotietokanta voi sisältää yrityksen arkaluonteisimmat tiedot: sähköpostiosoitteet, promptit, keskustelusisällöt, tunnukset, salatut tarjoajatiedot, lokit, virheilmoitukset, API-avaimet ja sisäiset operatiiviset tiedot. Vaikka agentti olisi huolellinen, raaka pääsy luo rajaongelman. Agentti näkee liikaa. Virhe kyselyssä, raportissa tai kuvakaappauksessa voi vuotaa tietoa, jota tiimi ei koskaan aikonut paljastaa.

Kirjoitusoikeus on vielä pahempi. BI:n ei pitäisi voida muuttaa tuotantoa. Analyytikon, oli hän ihminen tai agentti, ei pitäisi olla yhden huonon komennon päässä käyttäjädatan muuttamisesta.

Kysymys ei siis ole, osaavatko agentit kirjoittaa SQL:ää. Osaavat. Kysymys on, voitko antaa niille riittävästi totuutta hyödyllisyyden saavuttamiseksi, pitäen yksityisyyden ja turvallisuuden ehdottomina rajoina.

Meille nämä rajoitteet ovat koko pointti:

• Agentit eivät saa nähdä raakoja promptteja.
• Agentit eivät saa nähdä raakoja sähköposteja.
• Agentit eivät saa nähdä tunnuksia tai salaisuuksia.
• Agentit eivät saa nähdä arkaluonteisia vapaamuotoisia lokimerkintöjä.
• Agenteilla ei saa olla kirjoitusoikeutta BI-lähteeseen.
• Founder-tiimin pitää silti voida kysyä käytännön operatiivisia kysymyksiä nopeasti.

Tämä on järjestelmän muoto, jota tarvitsimme.

Turvallinen välimuoto: peitetty, vain luku -tietokanta

Neon mahdollistaa hyödyllisen mallin, koska haarat ovat halpoja, eristettyjä kopioita Postgres-tietokannasta. Voit luoda tuotantoa muistuttavan haaran, muuntaa sen ja avata sen tuotannon sijaan.

VM0:ssa käytämme tätä luodaksemme MaskDB:n.

Prosessi on yksinkertainen:

1. Aloita Neonin tuotantohaaran päähaarasta.
2. Luo uusi haara aikataulun mukaan.
3. Asenna PostgreSQL Anonymizer ja VM0:n omat peiteapuvälineet.
4. Lisää tietoturvamerkinnät arkaluonteisille sarakkeille.
5. Suorita staattinen anonymisointi haaralla.
6. Käytä lopullisia mukautettuja peitteitä erityiskäsittelyä vaativille kentille.
7. Luo masked_readonly-rooli, jolla on SELECT-oikeudet.
8. Anna agenttien kysellä tätä roolia, ei tuotantoa.

Tärkeä yksityiskohta on, että peittäminen on staattista. Arkaluonteiset arvot kirjoitetaan uudelleen peitetyllä haaralla ennen agentin yhteyttä. Tämä eroaa siitä, että jokaisen alaspäin menevän kyselyn pitäisi muistaa, mitä ei saa valita. Haara itsessään on raja.

MaskDB:ssä tunnukset ja salaisuudet on poistettu. Sähköpostit ja puhelinnumerot on osittain peitetty. Käyttäjäsisältö, kuten promptit, keskusteluviestit, aikataulupromptit ja agenttien tuotokset, on poistettu. Virheteksti on supistettu luokkaan, ei koko pinoon tai viestiin. Taulut, joita ei koskaan pitäisi analysoida, voidaan poistaa kokonaan.

Samalla läpinäkymättömät tunnisteet kuten org_id, user_id ja clerk_user_id säilyvät yhdisteltävinä. Se mahdollistaa BI:n. Agentin ei tarvitse tietää henkilön sähköpostiosoitetta tai promptin tekstiä. Sen pitää tietää, että sama organisaatio rekisteröityi, ajoi tehtävän, kulutti kredittiä, tilasi, hiljeni tai palasi myöhemmin.

Tämä tasapaino on koko pointti: peitä ihmisen luettavissa oleva ja arkaluonteinen materiaali, säilytä relaatiorunko.

Mitä agentit voivat tehdä, kun raja on olemassa

Kun peitetty vain luku -tietokanta on olemassa, agentista tulee nopeasti hyödyllinen.

Se voi kysyä suoraan tuotetietoon perustuvia kysymyksiä:

• 7- ja 30-päivän käyttäjäpito
• Rekisteröitymisestä ensimmäiseen suoritukseen -aktivointi
• Ensimmäiseen suoritukseen ankkuroitu pito
• Maksullisten organisaatioiden hiljentyminen
• Tilausstatus ja churn-seuranta
• Mallin käyttö valitun mallin mukaan
• Sisäänrakennetut vs käyttäjän tarjoamat reitit
• Kokeilun laskentatehon kulutus
• Kustannus per suoritus mallin mukaan
• Epäonnistumis- ja valmistumisprosentti kohorteittain

Se voi myös yhdistää tietokannan totuuden ympäröiviin järjestelmiin.

Aamuraporttimme hakee tietoja Plausiblesta, Axiomista, Sentrystä, Google Adsista, GitHubista ja muista operatiivisista lähteistä. Tietokanta kertoo, mitä käyttäjät ja organisaatiot tekivät. Plausible kertoo, mitä sivustolla tapahtui. PostHog auttaa tuotekontekstissa. Axiom kertoo, mitä lokeissa ja pyyntöpoluissa tapahtui. Sentry nappaa virheet. Stripe ja Clerk selittävät laskutusta ja identiteettiä. GitHub näyttää kehitystahtia.

Tarkoitus ei ole korvata jokaista työkalua SQL:llä. Tarkoitus on antaa agentin yhdistää faktat, joista founderit oikeasti välittävät.

Esimerkiksi:

Maksettu Google toi enemmän liikennettä kuin orgaaninen eilen. Pääsivätkö nämä käyttäjät oikeasti ensimmäiseen suoritukseen, vai pysähtyivätkö he suppilon alkuun?

Tai:

Muutimme kokeilun väärinkäytön valvontaa. Polttivatko uudet kokeilutilit vähemmän laskentatehoa ensimmäisinä tunteinaan?

Tai:

Tämä mallireitti on halvempi per suoritus. Näkyykö se oikeassa historiallisessa chat-käytössä vai vain hinnoitteluteoriassa?

Nämä eivät ole dashboard-kysymyksiä. Ne ovat operatiivisia kysymyksiä. Ne muuttuvat viikoittain, joskus päivittäin. Agentti, jolla on turvallinen tietokantapääsy, voi vastata niihin ilman, että kehitystiimin tarvitsee rakentaa uusi näkymä joka kerta.

Todellinen esimerkki: pito ja ulkoisten käyttäjien terveys

Yksi päivittäisistä sisäisistä analyyseistamme tarkastelee ulkoisten käyttäjien terveyttä viimeisen 24 tunnin ajalta.

Raportti alkaa MaskDB:stä ja käyttää tiukkaa poissulkulistaa. Sisäiset VM0-organisaatiot poistetaan. Clerk-bannatut tai lukitut roskapostiorganisaatiot poistetaan. Sama poissulku käytetään kaikkialla, myös rekisteröintimäärissä ja pitokohorteissa, jotta nimittäjät pysyvät auditoitavina.

Tämän jälkeen agentti voi tuottaa tiiviin operatiivisen raportin:

• Suoritukset ja aktiiviset ulkoiset organisaatiot
• Valmistumisprosentti
• Käynnistystapa webin, CLI:n, aikataulujen ja muiden kuin Zero-reittien välillä
• Mallijakauma
• Tarjoajamoodi
• Maksullisten organisaatioiden aktiivisuus
• Hiljentyneet maksulliset organisaatiot
• Uudet maksulliset rekisteröitymiset ja kokeilijat
• Churn-seuranta
• 30-päivän käyttäjäsegmentointi
• Rekisteröitymisestä suoritukseen -pito
• Ensimmäisen suorituksen pito

Tämä on juuri sellainen raportti, jonka founder-tiimi tarvitsee. Se ei vaadi raakoja promptteja. Se ei vaadi raakoja sähköposteja. Se ei vaadi tuotannon kirjoitusoikeutta.

Se vaatii kyvyn yhdistää tuotefaktat oikein.

Yhdellä ajolla agentti havaitsi, että pieni määrä aktiivisia ulkoisia organisaatioita tuotti suurimman osan volyymista, että useat maksulliset organisaatiot olivat hiljentyneet ja että viimeaikaiset rekisteröintikohortit osoittivat jyrkän aktivointikynnyksen, jonka todennäköisesti aiheutti roskapostirekisteröinnit nimittäjän paisuttamisena. Nämä ovat asioita, jotka founderin pitäisi nähdä nopeasti, ei viikkoja myöhemmin dashboard-katsauksessa.

Toinen esimerkki: kokeilun väärinkäytön talous

Peitetty tuotetieto on hyödyllistä myös kysymyksiin, jotka eivät ole klassisia BI-kaavioita.

Kun tarkastelimme kokeilun väärinkäyttöä, hyödyllinen mittari ei ollut kokonaislaskenta. Kokonaiskulutus olisi vinoutunut vanhempien tilien suuntaan, koska niillä oli enemmän aikaa kuluttaa kredittiä. Parempi kysymys oli:

Kuinka paljon kokeilulaskentaa uusi tili polttaa ensimmäisten tuntien aikana rekisteröitymisestä?

MaskDB:n avulla agentti mittasi laskentakulutusta rekisteröinnin jälkeisissä ikkunoissa. Se käytti kreditin kulutusta käyttötapahtumista, rekisteröintiaikaleimoja organisaatiometadatasta ja tilaustilaa erotellakseen kokeilun talouden maksullisesta käytöstä.

Valvonnan käyttöönoton jälkeen keskimääräinen kokeilulaskenta, joka poltettiin ensimmäisten tuntien aikana rekisteröitymisestä, laski yli 80%. Suurin kulutus hävisi lähes kokonaan. 90. prosenttipisteessä ensimmäisten tuntien kokeilulaskenta laski noin $4.05:sta noin $0.26:ään, eli 94% pudotus.

Tämä luku ei ole vain analytiikkapiste. Se muuttaa liiketoiminnan operatiivista näkymää. Se kertoo founder-tiimille, että väärinkäyttöä ei vain havaittu, vaan että kokeilun yksikkötalous liikkui oikeaan suuntaan.

Ja se oli mahdollista, koska tietokannassa oli totuus, ja peitetty haara teki siitä turvallista agentin analysoida.

Kolmas esimerkki: mallin kustannus oikeassa tuotteessa

Hinnoittelusivut ja vertailutaulukot ovat hyödyllisiä, mutta ne eivät vastaa kysymykseen, josta founderit oikeasti välittävät:

Mitä tämä malli maksaa oikeassa tuotteessamme, oikeissa suorituksissa?

MaskDB:n avulla agentti vertaili historiallisia chat-suorituksia yhdistämällä suoritustiedot suorituksen aikana valittuun malliin ja aggregoimalla veloitetut kreditit käyttötapahtumista.

Tällä erolla on väliä. Historiallisia suorituksia ei pidä liittää käyttäjän nykyiseen oletusmallitarjoajaan, koska oletukset muuttuvat. Suorituksen aikainen valittu malli on totuuden lähde.

Analyysissämme DS v4 Pro:n mediaanimallikreditin kustannus per chat-suoritus oli noin 49% Sonnetin kustannuksesta. Toisin sanoen, todellinen mediaanichat-suoritus oli noin 51% halvempi tuolla reitillä.

Tämä on jälleen founder-tason BI:tä. Se yhdistää tuotteen käyttäytymisen, infrastruktuurikustannuksen ja mallistrategian. Se ei vaadi uutta varastoa. Se vaatii turvallisen pääsyn oikeaan relaatiodataan.

Tämä ei korvaa varastoa ikuisesti

Tulee hetki, jolloin yritys tarvitsee muodollisemman datapinon.

Kun mittarit vaativat vahvaa semanttista hallintaa, kun monet tiimit riippuvat samoista määritelmistä, kun historialliset täydennykset monimutkaistuvat, kun dashboardit ovat osa operatiivista järjestelmää, varasto tai lakehouse voi olla oikea ratkaisu.

Mutta monet startupit tarttuvat tähän ratkaisuun liian aikaisin.

Jos olet pieni founder-tiimi, ensimmäisen BI-järjestelmän pitäisi auttaa vastaamaan kysymyksiin, ei luoda toista tuotetta ylläpidettäväksi. Peitetty tietokanta voi olla silta. Se ei väitä, ettei datamallinnuksella ole väliä. Se tunnistaa, että tuotetietokannassa on jo suhteet, joita tarvitset seuraaviin päätöksiin.

Agentti ei poista harkinnan tarvetta. Se tekee analyysin ensimmäisestä versiosta halvemman ajaa.

Malli founder-tiimeille

Malli on yksinkertainen:

1. Kohtele tuotetietokantaa ensimmäisenä totuuden lähteenä.
2. Älä koskaan paljasta raakaa tuotantoa agenteille.
3. Käytä tuotantoa muistuttavaa haaraa, älä käsin rakennettua esimerkkidataa.
4. Peitä arkaluonteiset sarakkeet staattisesti ennen pääsyä.
5. Säilytä läpinäkymättömät yhdistämistunnisteet, jotta analyysi toimii.
6. Avaa haara vain luku -roolin kautta.
7. Anna agenttien ajaa analyytikkosilmukkaa peitetyn tietokannan ja ympäröivien työkalujen yli.

Tämä antaa founder-tiimille hyödyllisen operatiivisen järjestelmän ilman, että täyttä datapohjaa tarvitsee rakentaa ensin.

Se luo myös siistimmän tietoturva-asetelman. Agentilla on selkeä raja. Näkyvä tietokanta on jo muunnettu. Käytetty rooli ei voi kirjoittaa. Raportit voidaan rajoittaa hajautettuihin tai aggregoituihin tunnisteisiin.

Tämä oli tasapaino, jonka halusimme VM0:ssa: yksityisyys ja tietoturva perustana, ei vaihtokauppana, mutta silti founder-tiimille paljon nopeampi tapa ymmärtää liiketoimintaa.

Ennen kuin rakennat tietojärven, kysy, voisiko peitetty, vain luku -haara tuotetietokannastasi vastata seuraaviin 20 kysymykseen, joita tiimilläsi oikeasti on.

Meille se oli nopeampi tie BI:hin.

Lähteet

• 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