BI Tanpa Data Lake

Sebagian besar proyek BI startup dimulai terlalu dini dan terlalu besar.

Seorang founder mengajukan pertanyaan sederhana: "Apakah pengguna dari channel ini kembali lagi setelah run pertama mereka?" Jawabannya seharusnya cukup berupa sebuah query. Namun, hal itu sering kali berubah menjadi proyek platform: hubungkan setiap sumber, bangun warehouse, definisikan event, bersihkan identitas, sambungkan dashboard, lalu tunggu.

Pekerjaan itu pada akhirnya memang penting. Tetapi bagi tim kecil, itu bisa jadi langkah pertama yang keliru. Database produk sudah mengetahui hampir semua yang perlu diketahui founder. Ia tahu siapa yang mendaftar, siapa yang menjalankan sesuatu, apa yang mereka pakai, berapa biayanya, apa yang gagal, dan apakah mereka kembali.

Masalah sebenarnya bukan di mana kebenaran itu berada. Masalahnya adalah bagaimana membiarkan sebuah agen menganalisis kebenaran tersebut tanpa membuka database produksi mentah.

Itulah pola yang kami gunakan di VM0: branch Neon yang dimask dan read-only, yang memberi agen kami cukup kebenaran untuk menjalankan BI, tanpa memberi mereka data yang seharusnya tidak pernah mereka lihat.

Masalah founder: pertanyaan datang sebelum tim data ada

Perusahaan tahap awal tidak kekurangan pertanyaan. Mereka kekurangan waktu.

Setiap hari, tim founder ingin tahu hal-hal seperti:

• Apakah trafik kemarin berubah menjadi pengguna nyata?
• Channel signup mana yang menghasilkan orang yang benar-benar menjalankan sesuatu?
• Apakah pengguna run-pertama kembali setelah 7 atau 30 hari?
• Akun berbayar mana yang mulai sepi?
• Rute model mana yang mendorong biaya?
• Apakah penyalahguna trial membakar compute sebelum mereka konversi?
• Apakah kesehatan produk membaik atau memburuk dibanding kemarin?

Tidak ada satu pun pertanyaan ini yang eksotis. Inilah ritme operasional sebuah startup.

Namun menjawabnya dengan playbook BI tradisional menciptakan banyak overhead. Anda biasanya mulai dengan memindahkan data keluar dari database produk ke sistem lain. Lalu Anda menormalkannya, mendefinisikan metrik, membangun ulang relasi, dan menyiapkan dashboard. Tim memang mendapat stack analitik yang lebih rapi, tetapi founder sering menunggu berhari-hari atau berminggu-minggu untuk jawaban yang sebenarnya bisa dimulai sebagai query SQL.

Bagi startup kecil, trade-off itu bisa terbalik. Anda tidak butuh platform data lengkap untuk mengajukan 20 pertanyaan operasional pertama Anda. Anda butuh cara yang aman untuk menquery sumber kebenaran yang sudah Anda miliki.

Database sudah menjadi sumber kebenaran

Di VM0, database produk berisi fakta-fakta yang penting untuk banyak keputusan setingkat founder:

• Organisasi dan pengguna
• Status signup dan langganan
• Run dan jadwal agen
• Konsumsi kredit dan event penggunaan
• Model dan rute penyedia yang dipilih
• Status konektor
• Status kegagalan dan timestamp

Relasi-relasi itu sudah ada di sana. Mereka lebih segar daripada dashboard downstream mana pun, dan mencerminkan bagaimana produk benar-benar bekerja.

Ini penting karena banyak pertanyaan BI awal bersifat relasional. Seorang founder tidak hanya menginginkan page view atau jumlah run. Mereka ingin menghubungkan perilaku di seluruh sistem:

Dari pengguna yang mendaftar dari channel ini, berapa banyak yang menjalankan sesuatu di hari nol, dan berapa banyak yang kembali setelah run pertama mereka?

Atau:

Organisasi berbayar mana yang belum menjalankan apa pun dalam 7 hari terakhir, dan apakah sebelumnya mereka tampak aktif?

Atau:

Berapa banyak compute yang dibakar akun trial baru dalam 6 jam pertama mereka, sebelum dan sesudah kami mengubah patroli penyalahgunaan?

Pertanyaan-pertanyaan itu duduk secara alami di database produk. Mereka menjadi jauh lebih sulit ketika setiap jawaban harus dimulai dengan memindahkan data ke platform terpisah.

Jalan pintas yang tidak aman adalah akses produksi mentah

Jalan pintas yang menggoda sudah jelas: biarkan saja agen menquery produksi.

Itu tidak dapat diterima.

Sebuah database produksi bisa berisi materi paling sensitif di perusahaan: alamat email, prompt, isi chat, kredensial, status penyedia terenkripsi, log, pesan error, API key, dan catatan operasional internal. Bahkan jika sebuah agen berhati-hati, akses mentah menciptakan masalah batasan. Agen bisa melihat terlalu banyak. Sebuah kesalahan dalam query, laporan, atau screenshot bisa membocorkan informasi yang tidak pernah ingin dibuka oleh tim.

Akses tulis bahkan lebih buruk. BI seharusnya tidak bisa mengubah produksi. Seorang analis, baik manusia maupun agen, seharusnya tidak berjarak satu perintah buruk dari mengubah data pengguna.

Jadi pertanyaannya bukan apakah agen bisa menulis SQL. Mereka bisa. Pertanyaannya adalah apakah Anda bisa memberi mereka cukup kebenaran agar berguna sambil menjaga privasi dan keamanan sebagai batasan yang keras.

Bagi kami, batasan-batasan itulah intinya:

• Agen tidak boleh melihat prompt mentah.
• Agen tidak boleh melihat email mentah.
• Agen tidak boleh melihat kredensial atau rahasia.
• Agen tidak boleh melihat log free-text yang sensitif.
• Agen tidak boleh memiliki akses tulis ke sumber BI.
• Tim founder tetap harus bisa mengajukan pertanyaan operasional praktis dengan cepat.

Itulah bentuk sistem yang kami butuhkan.

Jalan tengah yang aman: database yang dimask dan read-only

Neon memungkinkan pola yang berguna karena branch adalah salinan database Postgres yang murah dan terisolasi. Anda bisa membuat branch yang mirip produksi, mentransformasikannya, dan mengekspos branch itu alih-alih produksi itu sendiri.

Di VM0, kami menggunakan ini untuk membuat apa yang kami sebut MaskDB.

Alurnya sederhana:

1. Mulai dari branch induk produksi Neon.
2. Buat branch baru sesuai jadwal.
3. Pasang PostgreSQL Anonymizer dan helper masking khusus VM0.
4. Terapkan security label untuk kolom-kolom sensitif.
5. Jalankan anonimisasi statis pada branch.
6. Terapkan mask kustom final untuk field yang butuh penanganan khusus.
7. Buat role masked_readonly dengan akses SELECT.
8. Biarkan agen menquery role itu, bukan produksi.

Detail penting di sini adalah bahwa masking-nya bersifat statis. Nilai-nilai sensitif ditulis ulang di branch yang dimask sebelum agen terhubung. Ini berbeda dengan meminta setiap query downstream untuk mengingat apa yang tidak boleh diselect. Branch itu sendirilah yang menjadi batasannya.

Di MaskDB kami, kredensial dan rahasia diredaksi. Email dan nomor telepon dimask sebagian. Konten pengguna seperti prompt, pesan chat, prompt jadwal, dan output agen dihapus. Teks error direduksi menjadi sebuah kelas alih-alih stack atau pesan lengkap. Tabel yang sama sekali tidak boleh muncul dalam analisis bisa di-drop sepenuhnya.

Pada saat yang sama, identifier buram seperti org_id, user_id, dan clerk_user_id tetap bisa di-join. Itulah yang membuat BI menjadi mungkin. Kami tidak butuh agen mengetahui alamat email atau teks prompt seseorang. Yang kami butuhkan adalah agen mengetahui bahwa organisasi yang sama mendaftar, menjalankan tugas, mengonsumsi kredit, berlangganan, menjadi dorman, atau kembali kemudian.

Keseimbangan itulah intinya: mask materi yang bisa dibaca manusia dan sensitif, pertahankan tulang punggung relasionalnya.

Apa yang bisa dilakukan agen setelah batasan itu ada

Setelah database read-only yang dimask itu ada, agen bisa menjadi berguna dengan sangat cepat.

Ia bisa mengajukan pertanyaan langsung terhadap data produk:

• Retensi pengguna 7 hari dan 30 hari
• Aktivasi dari registrasi ke run pertama
• Retensi yang berlabuh pada run pertama
• Dormansi organisasi berbayar
• Status langganan dan pantauan churn
• Penggunaan model berdasarkan model yang dipilih
• Rute bawaan vs penyedia milik pengguna
• Konsumsi compute trial
• Biaya per run berdasarkan model
• Tingkat kegagalan dan tingkat penyelesaian per kohort

Ia juga bisa menggabungkan kebenaran database itu dengan sistem-sistem di sekitarnya.

Morning Brief kami menarik dari Plausible, Axiom, Sentry, Google Ads, GitHub, dan sumber operasional lain. Database memberi tahu kami apa yang dilakukan pengguna dan organisasi. Plausible memberi tahu kami apa yang terjadi di situs. PostHog bisa membantu dengan konteks event produk. Axiom memberi tahu kami apa yang terjadi di log dan jalur permintaan. Sentry menangkap error. Stripe dan Clerk membantu menjelaskan penagihan dan identitas. GitHub menunjukkan throughput rekayasa.

Intinya bukan menggantikan setiap tool dengan SQL. Intinya adalah membiarkan agen menghubungkan fakta-fakta yang benar-benar dipedulikan founder.

Sebagai contoh:

Google berbayar mengirim lebih banyak trafik daripada organik kemarin. Apakah pengguna itu benar-benar mencapai run pertama, atau mereka berhenti di puncak funnel?

Atau:

Kami mengubah patroli penyalahgunaan trial. Apakah akun trial baru membakar lebih sedikit compute dalam beberapa jam pertama mereka?

Atau:

Rute model ini lebih murah per run. Apakah itu muncul dalam penggunaan chat historis yang nyata, atau hanya dalam teori harga?

Itu bukan pertanyaan dashboard. Itu pertanyaan operasional. Mereka berubah dari minggu ke minggu, kadang dari hari ke hari. Sebuah agen dengan akses database yang aman bisa menjawabnya tanpa harus meminta tim rekayasa membangun view baru setiap kali.

Contoh nyata: retensi dan kesehatan pengguna eksternal

Salah satu analisis internal harian kami melihat kesehatan pengguna eksternal selama 24 jam terakhir.

Laporan dimulai dari MaskDB, lalu menerapkan set eksklusi yang ketat. Organisasi VM0 internal dihapus. Organisasi spam yang dibanned atau dikunci oleh Clerk dihapus. Set eksklusi yang sama diterapkan di mana-mana, termasuk hitungan registrasi dan kohort retensi, sehingga denominator tetap bisa diaudit.

Dari situ, agen bisa menghasilkan laporan operasional yang ringkas:

• Run dan organisasi eksternal aktif
• Tingkat penyelesaian
• Campuran trigger lintas web, CLI, jadwal, dan rute non-Zero
• Campuran model
• Mode penyedia
• Aktivitas organisasi berbayar
• Organisasi berbayar yang dorman
• Signup berbayar baru dan organisasi yang sedang trial
• Pantauan churn
• Segmentasi pengguna 30 hari
• Retensi dari registrasi ke run
• Retensi run pertama

Inilah persis jenis laporan yang dibutuhkan tim founder. Ia tidak membutuhkan prompt mentah. Ia tidak membutuhkan email mentah. Ia tidak membutuhkan akses tulis ke produksi.

Yang ia butuhkan adalah kemampuan untuk menjoin fakta produk dengan benar.

Dalam satu run, agen menemukan bahwa sejumlah kecil organisasi eksternal aktif mendorong sebagian besar volume, bahwa beberapa organisasi berbayar telah menjadi sepi, dan bahwa kohort registrasi terbaru menunjukkan jurang aktivasi yang tajam yang kemungkinan disebabkan oleh registrasi spam yang menggelembungkan denominator. Itulah jenis hal yang seharusnya dilihat founder dengan cepat, bukan ditemukan berminggu-minggu kemudian dalam tinjauan dashboard.

Contoh kedua: ekonomi penyalahgunaan trial

Data produk yang dimask juga berguna untuk pertanyaan yang bukan grafik BI klasik.

Ketika kami melihat penyalahgunaan trial, metrik yang berguna bukanlah total compute yang dihabiskan. Total pengeluaran akan bias ke akun yang lebih lama, karena mereka punya lebih banyak waktu untuk mengonsumsi kredit. Pertanyaan yang lebih baik adalah:

Berapa banyak compute trial yang dibakar akun baru dalam beberapa jam pertama setelah signup?

Menggunakan MaskDB, agen mengukur konsumsi compute dalam jendela yang dicocokkan setelah registrasi. Ia menggunakan konsumsi kredit dari event penggunaan, timestamp registrasi dari metadata organisasi, dan status langganan untuk memisahkan ekonomi trial dari penggunaan berbayar.

Setelah patroli aktif, rata-rata compute trial yang dibakar dalam jam-jam pertama setelah signup turun lebih dari 80%. Ekor pembakaran berat hampir lenyap. Pada persentil ke-90, compute trial jam-jam pertama turun dari sekitar $4.05 menjadi sekitar $0.26, turun 94%.

Angka itu bukan sekadar poin analitik. Ia mengubah pandangan operasional terhadap bisnis. Ia memberi tahu tim founder bahwa penyalahgunaan tidak hanya terdeteksi, tetapi bahwa unit economics dari trial bergerak ke arah yang benar.

Dan itu mungkin karena database memiliki kebenarannya, sementara branch yang dimask membuatnya aman bagi agen untuk menganalisis kebenaran tersebut.

Contoh ketiga: biaya model dalam produk yang nyata

Halaman harga dan lembar benchmark berguna, tetapi keduanya tidak menjawab pertanyaan yang sebenarnya dipedulikan founder:

Berapa biaya model ini dalam produk nyata kami, di seluruh run yang nyata?

Menggunakan MaskDB, agen membandingkan run chat historis dengan menjoin catatan run dengan model yang dipilih saat run berlangsung dan mengagregasi kredit yang dibebankan dari event penggunaan.

Pembedaan itu penting. Anda tidak boleh mengatribusikan run historis menggunakan penyedia model default pengguna saat ini, karena default berubah. Model yang dipilih saat run berlangsung adalah sumber kebenarannya.

Dalam analisis kami, DS v4 Pro memiliki biaya kredit-model median per run chat yang sekitar 49% dari milik Sonnet. Dengan kata lain, run chat median yang nyata kira-kira 51% lebih murah pada rute itu.

Sekali lagi, ini adalah BI setingkat founder. Ia menghubungkan perilaku produk, biaya infrastruktur, dan strategi model. Ia tidak membutuhkan warehouse baru. Ia membutuhkan akses aman ke data relasional yang tepat.

Ini bukan pengganti warehouse selamanya

Ada satu titik di mana sebuah perusahaan membutuhkan stack data yang lebih formal.

Ketika metrik membutuhkan tata kelola semantik yang kuat, ketika banyak tim bergantung pada definisi yang sama, ketika backfill historis menjadi rumit, ketika dashboard menjadi bagian dari sistem operasional, sebuah warehouse atau lakehouse bisa menjadi jawaban yang tepat.

Tetapi banyak startup meraih jawaban itu terlalu dini.

Jika Anda tim founder kecil, sistem BI pertama Anda seharusnya membantu Anda menjawab pertanyaan, bukan menciptakan produk kedua untuk dipelihara. Database yang dimask bisa menjadi jembatannya. Ia tidak berpura-pura bahwa pemodelan data tidak penting. Ia mengakui bahwa database produk sudah berisi relasi yang Anda butuhkan untuk rangkaian keputusan berikutnya.

Agen tidak menghilangkan kebutuhan akan penilaian. Ia membuat versi pertama dari analisis lebih murah untuk dijalankan.

Pola untuk tim founder

Polanya sederhana:

1. Perlakukan database produk sebagai sumber kebenaran pertama.
2. Jangan pernah mengekspos produksi mentah ke agen.
3. Gunakan branch yang mirip produksi, bukan dataset sampel yang dibuat manual.
4. Mask kolom sensitif secara statis sebelum akses.
5. Pertahankan identifier join yang buram agar analisis tetap bekerja.
6. Ekspos branch melalui role read-only.
7. Biarkan agen menjalankan loop analis di seluruh MaskDB dan tools di sekitarnya.

Ini memberi tim founder sistem operasional yang berguna tanpa harus membangun platform data lengkap terlebih dahulu.

Ini juga menciptakan postur keamanan yang lebih bersih. Agen memiliki batasan yang keras. Database yang dilihatnya sudah ditransformasi. Role yang dipakainya tidak bisa menulis. Laporan yang dihasilkannya bisa dibatasi pada identifier yang di-hash atau agregat.

Itulah keseimbangan yang kami inginkan di VM0: privasi dan keamanan sebagai dasar, bukan sebagai trade-off, sambil tetap memberi tim founder cara yang jauh lebih cepat untuk memahami bisnis.

Sebelum Anda membangun data lake, tanyakan apakah branch read-only yang dimask dari database produk Anda bisa menjawab 20 pertanyaan berikutnya yang benar-benar dimiliki tim Anda.

Bagi kami, itulah jalur yang lebih cepat menuju BI.

Sumber

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