BI senza un data lake

La maggior parte dei progetti di BI nelle startup parte troppo presto e troppo in grande.

Un founder pone una domanda semplice: "Gli utenti provenienti da questo canale tornano dopo la loro prima esecuzione?". La risposta dovrebbe essere una query. Invece, spesso si trasforma in un progetto di piattaforma: collegare ogni sorgente, costruire un data warehouse, definire gli eventi, ripulire le identità, cablare le dashboard e aspettare.

Quel lavoro alla fine conta. Ma per un piccolo team può essere la prima mossa sbagliata. Il database di prodotto sa già la maggior parte di ciò che il founder ha bisogno di sapere. Sa chi si è registrato, chi ha eseguito qualcosa, cosa ha usato, quanto è costato, cosa è andato storto e se è tornato.

Il vero problema non è dove risiede la verità. È come permettere a un agente di analizzare quella verità senza esporre il database di produzione grezzo.

È questo il pattern che usiamo in VM0: un branch Neon mascherato e di sola lettura che dà ai nostri agenti abbastanza verità per fare BI, senza dare loro i dati che non dovrebbero mai vedere.

Il problema del founder: le domande arrivano prima del team dati

Le aziende in fase iniziale non mancano di domande. Mancano di tempo.

Ogni giorno, il team founder vuole sapere cose come:

• Il traffico di ieri si è trasformato in utenti reali?
• Quali canali di registrazione producono persone che poi eseguono davvero qualcosa?
• Gli utenti alla prima esecuzione tornano dopo 7 o 30 giorni?
• Quali account a pagamento stanno diventando silenziosi?
• Quale model route sta trainando i costi?
• Gli abusatori del trial stanno bruciando capacità di calcolo prima di convertire?
• Lo stato di salute del prodotto è migliorato o peggiorato rispetto a ieri?

Nessuna di queste domande è esotica. Sono il ritmo operativo di una startup.

Ma rispondervi con il playbook tradizionale della BI crea molto sovraccarico. Di solito si comincia spostando i dati fuori dal database di prodotto e dentro un altro sistema. Poi li si normalizza, si definiscono le metriche, si ricostruiscono le relazioni e si configurano le dashboard. Il team ottiene uno stack analitico più pulito, ma il founder spesso aspetta giorni o settimane per una risposta che avrebbe potuto iniziare come una query SQL.

Per una piccola startup, questo compromesso può essere ribaltato. Non serve una piattaforma dati completa per porre le prime 20 domande operative. Serve un modo sicuro per interrogare la fonte di verità che già si possiede.

Il database è già la fonte di verità

In VM0, il database di prodotto contiene i fatti che contano per molte decisioni a livello di founder:

• Organizzazioni e utenti
• Stato di registrazione e abbonamento
• Esecuzioni e pianificazioni degli agenti
• Consumo di crediti ed eventi di utilizzo
• Modelli selezionati e provider route
• Stato dei connettori
• Stato dei fallimenti e timestamp

Quelle relazioni sono già lì. Sono più fresche di qualsiasi dashboard a valle e riflettono come il prodotto funziona davvero.

Questo è importante perché molte domande di BI in fase iniziale sono relazionali. Un founder non vuole solo le visualizzazioni di pagina o i conteggi delle esecuzioni. Vuole collegare i comportamenti attraverso il sistema:

Tra gli utenti che si sono registrati da questo canale, quanti hanno eseguito qualcosa nel giorno zero e quanti sono tornati dopo la prima esecuzione?

Oppure:

Quali organizzazioni a pagamento non hanno eseguito nulla negli ultimi 7 giorni, e in precedenza sembravano attive?

Oppure:

Quanta capacità di calcolo hanno bruciato i nuovi account trial nelle loro prime 6 ore, prima e dopo aver cambiato la nostra sorveglianza anti-abuso?

Quelle domande risiedono naturalmente nel database di prodotto. Diventano molto più difficili quando ogni risposta inizia spostando i dati in una piattaforma separata.

La scorciatoia non sicura è l'accesso grezzo alla produzione

La scorciatoia tentante è ovvia: basta lasciare che l'agente interroghi la produzione.

Non è accettabile.

Un database di produzione può contenere il materiale più sensibile dell'azienda: indirizzi email, prompt, contenuti delle chat, credenziali, stato cifrato dei provider, log, messaggi di errore, chiavi API e registri operativi interni. Anche se un agente è attento, l'accesso grezzo crea un problema di confini. L'agente può vedere troppo. Un errore in una query, in un report o in uno screenshot può far trapelare informazioni che il team non aveva mai inteso esporre.

L'accesso in scrittura è ancora peggio. La BI non dovrebbe poter modificare la produzione. Un analista, umano o agentico, non dovrebbe essere a un comando sbagliato di distanza dall'alterare i dati degli utenti.

Quindi la domanda non è se gli agenti possono scrivere SQL. Possono. La domanda è se puoi dare loro abbastanza verità per essere utili mantenendo privacy e sicurezza come vincoli rigidi.

Per noi, quei vincoli sono il punto centrale:

• Gli agenti non dovrebbero vedere i prompt grezzi.
• Gli agenti non dovrebbero vedere le email grezze.
• Gli agenti non dovrebbero vedere credenziali o segreti.
• Gli agenti non dovrebbero vedere log sensibili in testo libero.
• Gli agenti non dovrebbero avere accesso in scrittura alla fonte BI.
• Il team founder dovrebbe comunque poter porre rapidamente domande operative pratiche.

Questa è la forma del sistema di cui avevamo bisogno.

La via di mezzo sicura: un database mascherato e di sola lettura

Neon rende possibile un pattern utile perché i branch sono copie economiche e isolate di un database Postgres. Puoi creare un branch simile alla produzione, trasformarlo ed esporre quel branch invece della produzione stessa.

In VM0, usiamo questo per creare ciò che chiamiamo MaskDB.

Il flusso è semplice:

1. Partire dal branch padre Neon di produzione.
2. Creare un nuovo branch secondo una pianificazione.
3. Installare PostgreSQL Anonymizer e gli helper di mascheramento specifici di VM0.
4. Applicare le etichette di sicurezza alle colonne sensibili.
5. Eseguire l'anonimizzazione statica sul branch.
6. Applicare le maschere personalizzate finali per i campi che necessitano di gestione speciale.
7. Creare un ruolo masked_readonly con accesso SELECT.
8. Lasciare che gli agenti interroghino quel ruolo, non la produzione.

Il dettaglio importante è che il mascheramento è statico. I valori sensibili vengono riscritti sul branch mascherato prima che l'agente si connetta. Questo è diverso dal chiedere a ogni query a valle di ricordare cosa non selezionare. Il branch stesso è il confine.

Nel nostro MaskDB, credenziali e segreti sono oscurati. Email e numeri di telefono sono parzialmente mascherati. I contenuti degli utenti come prompt, messaggi di chat, prompt delle pianificazioni e output degli agenti vengono rimossi. Il testo degli errori è ridotto a una classe anziché a uno stack o messaggio completo. Le tabelle che non dovrebbero mai comparire nell'analisi possono essere eliminate del tutto.

Allo stesso tempo, gli identificatori opachi come org_id, user_id e clerk_user_id restano collegabili. È questo che rende possibile la BI. Non abbiamo bisogno che l'agente conosca l'indirizzo email di una persona o il testo di un prompt. Abbiamo bisogno che sappia che la stessa organizzazione si è registrata, ha eseguito un task, ha consumato crediti, si è abbonata, è diventata inattiva o è tornata in seguito.

Quell'equilibrio è tutto il punto: mascherare il materiale leggibile dall'uomo e sensibile, preservare la spina dorsale relazionale.

Cosa possono fare gli agenti una volta che esiste il confine

Una volta che il database mascherato di sola lettura esiste, l'agente può diventare utile molto in fretta.

Può porre domande direttamente sui dati di prodotto:

• Retention degli utenti a 7 e 30 giorni
• Attivazione dalla registrazione alla prima esecuzione
• Retention ancorata alla prima esecuzione
• Inattività delle organizzazioni a pagamento
• Stato dell'abbonamento e monitoraggio del churn
• Utilizzo dei modelli per modello selezionato
• Route integrate vs route con provider dell'utente
• Consumo di calcolo nei trial
• Costo per esecuzione per modello
• Tasso di fallimento e tasso di completamento per coorte

Può anche combinare quella verità del database con i sistemi che le ruotano attorno.

Il nostro Morning Brief attinge da Plausible, Axiom, Sentry, Google Ads, GitHub e altre sorgenti operative. Il database ci dice cosa hanno fatto utenti e organizzazioni. Plausible ci dice cosa è accaduto sul sito. PostHog può aiutare con il contesto degli eventi di prodotto. Axiom ci dice cosa è successo nei log e nei percorsi delle richieste. Sentry intercetta gli errori. Stripe e Clerk aiutano a spiegare fatturazione e identità. GitHub mostra la produttività ingegneristica.

Il punto non è sostituire ogni strumento con SQL. Il punto è permettere all'agente di collegare i fatti a cui i founder tengono davvero.

Per esempio:

Ieri Google a pagamento ha inviato più traffico dell'organico. Quegli utenti hanno effettivamente raggiunto la prima esecuzione, o si sono fermati in cima al funnel?

Oppure:

Abbiamo cambiato la sorveglianza anti-abuso dei trial. I nuovi account trial hanno bruciato meno capacità di calcolo nelle loro prime ore?

Oppure:

Questa model route costa meno per esecuzione. Lo si vede nell'utilizzo storico reale delle chat, o solo nella teoria dei prezzi?

Quelle non sono domande da dashboard. Sono domande operative. Cambiano di settimana in settimana, a volte di giorno in giorno. Un agente con accesso sicuro al database può rispondervi senza chiedere all'ingegneria di costruire una nuova view ogni volta.

Un esempio reale: retention e salute degli utenti esterni

Una delle nostre analisi interne quotidiane esamina la salute degli utenti esterni nelle ultime 24 ore.

Il report parte da MaskDB, poi applica un rigoroso insieme di esclusioni. Le organizzazioni VM0 interne vengono rimosse. Le organizzazioni spam bannate o bloccate da Clerk vengono rimosse. Quello stesso insieme di esclusioni viene applicato ovunque, inclusi i conteggi delle registrazioni e le coorti di retention, così i denominatori restano verificabili.

Da lì, l'agente può produrre un report operativo compatto:

• Esecuzioni e organizzazioni esterne attive
• Tasso di completamento
• Mix di trigger tra web, CLI, pianificazioni e route non-Zero
• Mix di modelli
• Modalità provider
• Attività delle organizzazioni a pagamento
• Organizzazioni a pagamento inattive
• Nuove registrazioni a pagamento e organizzazioni in trial
• Monitoraggio del churn
• Segmentazione degli utenti a 30 giorni
• Retention dalla registrazione all'esecuzione
• Retention alla prima esecuzione

Questo è esattamente il tipo di report di cui un team founder ha bisogno. Non richiede prompt grezzi. Non richiede email grezze. Non richiede accesso in scrittura alla produzione.

Richiede invece la capacità di unire correttamente i fatti di prodotto.

In una esecuzione, l'agente ha scoperto che un piccolo numero di organizzazioni esterne attive trainava la maggior parte del volume, che diverse organizzazioni a pagamento erano diventate silenziose e che le coorti di registrazione recenti mostravano un netto crollo nell'attivazione, probabilmente causato da registrazioni spam che gonfiavano il denominatore. Questi sono il tipo di cose che un founder dovrebbe vedere rapidamente, non scoprire settimane dopo in una revisione di dashboard.

Un secondo esempio: l'economia dell'abuso dei trial

I dati di prodotto mascherati sono utili anche per domande che non sono i classici grafici di BI.

Quando abbiamo esaminato l'abuso dei trial, la metrica utile non era la capacità di calcolo totale spesa. La spesa totale sarebbe stata distorta a favore degli account più vecchi, perché avevano avuto più tempo per consumare crediti. La domanda migliore era:

Quanta capacità di calcolo del trial brucia un nuovo account nelle sue prime ore dopo la registrazione?

Usando MaskDB, l'agente ha misurato il consumo di calcolo in finestre temporali confrontabili dopo la registrazione. Ha usato il consumo di crediti dagli eventi di utilizzo, i timestamp di registrazione dai metadati delle organizzazioni e lo stato dell'abbonamento per separare l'economia del trial dall'utilizzo a pagamento.

Dopo l'attivazione della sorveglianza, la capacità di calcolo media bruciata dai trial nelle prime ore dopo la registrazione è scesa di oltre l'80%. La coda dei consumi pesanti è quasi scomparsa. Al 90esimo percentile, la capacità di calcolo del trial nelle prime ore è scesa da circa $4,05 a circa $0,26, un calo del 94%.

Quel numero non è solo un dato analitico. Cambia la visione operativa del business. Dice al team founder che l'abuso non veniva solo rilevato, ma che l'economia unitaria del trial si stava muovendo nella direzione giusta.

Ed è stato possibile perché il database conteneva la verità, mentre il branch mascherato l'ha resa sicura da analizzare per un agente.

Un terzo esempio: il costo dei modelli nel prodotto reale

Le pagine dei prezzi e i fogli di benchmark sono utili, ma non rispondono alla domanda a cui i founder tengono davvero:

Quanto costa questo modello nel nostro prodotto reale, attraverso esecuzioni reali?

Usando MaskDB, l'agente ha confrontato le esecuzioni storiche delle chat unendo i record delle esecuzioni con il modello selezionato al momento dell'esecuzione e aggregando i crediti addebitati dagli eventi di utilizzo.

Quella distinzione conta. Non dovresti attribuire le esecuzioni storiche usando l'attuale provider di modello predefinito dell'utente, perché i valori predefiniti cambiano. Il modello selezionato al momento dell'esecuzione è la fonte di verità.

Nella nostra analisi, DS v4 Pro aveva un costo mediano in crediti-modello per esecuzione di chat pari a circa il 49% di quello di Sonnet. In altre parole, l'esecuzione di chat mediana reale era circa il 51% più economica su quella route.

Anche questa è BI a livello di founder. Collega il comportamento del prodotto, il costo dell'infrastruttura e la strategia dei modelli. Non richiede un nuovo data warehouse. Richiede un accesso sicuro ai dati relazionali giusti.

Questo non è un sostituto permanente di un data warehouse

C'è un momento in cui un'azienda ha bisogno di uno stack dati più formale.

Quando le metriche necessitano di una forte governance semantica, quando molti team dipendono dalle stesse definizioni, quando i backfill storici diventano complessi, quando le dashboard diventano parte del sistema operativo, un data warehouse o un lakehouse può essere la risposta giusta.

Ma molte startup ricorrono a quella risposta troppo presto.

Se sei un piccolo team founder, il tuo primo sistema di BI dovrebbe aiutarti a rispondere alle domande, non creare un secondo prodotto da mantenere. Un database mascherato può essere il ponte. Non finge che la modellazione dei dati non conti. Riconosce che il database di prodotto contiene già le relazioni di cui hai bisogno per il prossimo insieme di decisioni.

L'agente non elimina la necessità di giudizio. Rende più economico eseguire la prima versione dell'analisi.

Il pattern per i team founder

Il pattern è semplice:

1. Trattare il database di prodotto come prima fonte di verità.
2. Non esporre mai la produzione grezza agli agenti.
3. Usare un branch simile alla produzione, non un dataset di esempio costruito a mano.
4. Mascherare staticamente le colonne sensibili prima dell'accesso.
5. Preservare gli identificatori opachi di join così l'analisi continua a funzionare.
6. Esporre il branch attraverso un ruolo di sola lettura.
7. Lasciare che gli agenti eseguano il ciclo dell'analista tra il DB mascherato e gli strumenti circostanti.

Questo dà a un team founder un sistema operativo utile senza dover prima costruire una piattaforma dati completa.

Crea anche una postura di sicurezza più pulita. L'agente ha un confine rigido. Il database che vede è già stato trasformato. Il ruolo che usa non può scrivere. I report che produce possono essere vincolati a identificatori con hash o aggregati.

Questo è l'equilibrio che volevamo in VM0: privacy e sicurezza come base, non come compromesso, dando comunque al team founder un modo molto più rapido per comprendere il business.

Prima di costruire un data lake, chiediti se un branch mascherato e di sola lettura del tuo database di prodotto può rispondere alle prossime 20 domande che il tuo team ha davvero.

Per noi, quella è stata la via più rapida alla BI.

Fonti

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