Veri Gölü Olmadan BI

Çoğu girişim BI projesi çok erken ve çok büyük başlar.

Bir kurucu basit bir soru sorar: "Bu kanaldan gelen kullanıcılar ilk çalıştırmadan sonra geri dönüyor mu?" Yanıt bir sorgu olmalıdır. Ancak genellikle bir platform projesine dönüşür: her kaynağı bağla, bir ambar kur, olayları tanımla, kimlikleri temizle, panoları kur ve bekle.

Bu çalışmalar sonunda önemlidir. Ancak küçük bir ekip için bu yanlış bir ilk adım olabilir. Ürün veritabanı, kurucunun bilmesi gerekenlerin çoğunu zaten bilir. Kimlerin kaydolduğunu, kimlerin bir şey çalıştırdığını, ne kullandıklarını, ne kadar harcadıklarını, neyin başarısız olduğunu ve geri dönüp dönmediklerini bilir.

Asıl sorun gerçeğin nerede yaşadığı değil. Bir ajanın bu gerçeği ham üretim veritabanını ifşa etmeden analiz etmesini nasıl sağlayacağınız.

Bizim VM0'da kullandığımız desen budur: ajanlarımıza BI çalıştırmak için yeterli gerçeği veren, ancak asla görmemeleri gereken verileri vermeyen maskelenmiş, salt okunur bir Neon dalı.

Kurucu sorunu: sorular veri ekibinden önce gelir

Erken aşama şirketlerde soru eksikliği yoktur. Zaman eksikliği vardır.

Kurucu ekip her gün şunları bilmek ister:

• Dün gelen trafik gerçek kullanıcılara dönüştü mü?
• Hangi kayıt kanalları gerçekten bir şey çalıştıran kişiler üretiyor?
• İlk çalıştırma yapan kullanıcılar 7 veya 30 gün sonra geri dönüyor mu?
• Hangi ücretli hesaplar sessizleşiyor?
• Hangi model rotası maliyeti artırıyor?
• Deneme kötüye kullananlar dönüşmeden önce hesaplama yakıyor mu?
• Ürün sağlığı dünden bu yana iyileşti mi, kötüleşti mi?

Bu soruların hiçbiri sıra dışı değil. Bunlar bir girişimin işletme ritmidir.

Ancak bunları geleneksel BI yaklaşımıyla yanıtlamak çok fazla ek yük getirir. Genellikle verileri ürün veritabanından başka bir sisteme taşıyarak başlarsınız. Sonra normalleştirir, metrikleri tanımlar, ilişkileri yeniden kurar ve panoları ayarlarsınız. Ekip daha temiz bir analiz yığını elde eder, ancak kurucu genellikle bir SQL sorgusuyla başlayabilecek bir yanıt için günlerce veya haftalarca bekler.

Küçük bir girişim için bu takas ters olabilir. İlk 20 işletme sorularınızı sormak için eksiksiz bir veri platformuna ihtiyacınız yok. Zaten sahip olduğunuz gerçek kaynağı güvenli bir şekilde sorgulamanız gerekir.

Veritabanı zaten gerçek kaynağıdır

VM0'da ürün veritabanı, birçok kurucu düzeyinde karar için önemli olan gerçekleri içerir:

• Organizasyonlar ve kullanıcılar
• Kayıt ve abonelik durumu
• Ajan çalıştırmaları ve zamanlamalar
• Kredi tüketimi ve kullanım olayları
• Seçilen modeller ve sağlayıcı rotaları
• Bağlayıcı durumu
• Hata durumu ve zaman damgaları

Bu ilişkiler zaten oradadır. Herhangi bir aşağı akış panosundan daha günceldir ve ürünün gerçekte nasıl çalıştığını yansıtır.

Bu önemlidir çünkü birçok erken BI sorusu ilişkiseldir. Bir kurucu yalnızca sayfa görüntüleme veya çalıştırma sayısı istemez. Sistemdeki davranışları bağlamak ister:

Bu kanaldan kayıt olan kullanıcıların kaçı sıfırıncı gün bir şey çalıştırdı, kaçı ilk çalıştırmadan sonra geri döndü?

Veya:

Son 7 gündür hiçbir şey çalıştırmayan ücretli organizasyonlar hangileri ve önceden aktif görünüyorlar mıydı?

Veya:

Yeni deneme hesapları, kötüye kullanım denetimi değişmeden önce ve sonra ilk 6 saatte ne kadar hesaplama harcadı?

Bu sorular ürün veritabanında doğal olarak yer alır. Her yanıtı verileri ayrı bir platforma taşımakla başlatmak işleri çok daha zorlaştırır.

Güvensiz kestirme: ham üretim erişimi

Cazip kestirme açıktır: ajanın üretimi sorgulamasına izin verin.

Bu kabul edilemez.

Bir üretim veritabanı, şirketteki en hassas materyali içerebilir: e-posta adresleri, istemler, sohbet içerikleri, kimlik bilgileri, şifreli sağlayıcı durumu, günlükler, hata mesajları, API anahtarları ve dahili operasyonel kayıtlar. Bir ajan dikkatli olsa bile, ham erişim bir sınır sorunu yaratır. Ajan çok fazla görebilir. Bir sorguda, raporda veya ekranda yapılan bir hata, ekibin asla ifşa etmeyi düşünmediği bilgileri sızdırabilir.

Yazma erişimi daha da kötüdür. BI, üretimi değiştirememelidir. Bir analist, ister insan ister ajan olsun, yanlış bir komutla kullanıcı verisini değiştirme riskiyle karşı karşıya olmamalıdır.

Yani soru ajanların SQL yazıp yazamayacağı değil. Yazabilirler. Soru, onlara faydalı olacak kadar gerçeği verirken gizlilik ve güvenliği katı sınırlar olarak koruyup koruyamayacağınızdır.

Bizim için bu sınırlar esastır:

• Ajanlar ham istemleri görmemelidir.
• Ajanlar ham e-postaları görmemelidir.
• Ajanlar kimlik bilgilerini veya sırları görmemelidir.
• Ajanlar hassas serbest metin günlüklerini görmemelidir.
• Ajanlar BI kaynağına yazma erişimine sahip olmamalıdır.
• Kurucu ekip yine de pratik işletme sorularını hızla sorabilmelidir.

İhtiyacımız olan sistemin şekli budur.

Güvenli orta yol: maskelenmiş, salt okunur veritabanı

Neon, dalların ucuz, izole edilmiş bir Postgres veritabanı kopyası olması sayesinde faydalı bir desen sunar. Üretime benzer bir dal oluşturabilir, dönüştürebilir ve doğrudan üretimi değil bu dalı açığa çıkarabilirsiniz.

VM0'da buna MaskDB diyoruz.

Akış basittir:

1. Üretim Neon ana dalından başlayın.
2. Belirli bir programda yeni bir dal oluşturun.
3. PostgreSQL Anonymizer ve VM0'ya özel maskeleme yardımcılarını kurun.
4. Hassas sütunlar için güvenlik etiketleri uygulayın.
5. Dalda statik anonimleştirme çalıştırın.
6. Özel işleme ihtiyaç duyan alanlar için son özel maskeleri uygulayın.
7. masked_readonly rolünü SELECT erişimiyle oluşturun.
8. Ajanların üretimi değil bu rolü sorgulamasına izin verin.

Önemli ayrıntı, maskelemenin statik olmasıdır. Hassas değerler, ajan bağlanmadan önce maskelenmiş dalda yeniden yazılır. Bu, her aşağı akış sorgusunun neyi seçmemesi gerektiğini hatırlamasını istemekten farklıdır. Dalın kendisi sınırdır.

MaskDB'mizde kimlik bilgileri ve sırlar gizlenir. E-posta ve telefon numaraları kısmen maskelenir. Kullanıcı içeriği (istemler, sohbet mesajları, zamanlama istemleri, ajan çıktıları gibi) kaldırılır. Hata metni, tam yığın veya mesaj yerine bir sınıfa indirgenir. Analizde asla görünmemesi gereken tablolar tamamen çıkarılabilir.

Aynı zamanda, org_id, user_id ve clerk_user_id gibi opak tanımlayıcılar birleştirilebilir kalır. BI'yı mümkün kılan budur. Ajanın bir kişinin e-posta adresini veya istem metnini bilmesine gerek yoktur. Aynı organizasyonun kayıt olduğunu, bir görev çalıştırdığını, kredi tükettiğini, abone olduğunu, pasifleştiğini veya daha sonra geri döndüğünü bilmesi gerekir.

Dengenin özü budur: insan tarafından okunabilir ve hassas materyali maskele, ilişkisel omurgayı koru.

Sınır oluştuktan sonra ajanların yapabilecekleri

Maskelenmiş salt okunur veritabanı oluşturulduğunda, ajan çok hızlı şekilde faydalı hale gelebilir.

Ürün verisi üzerinde doğrudan sorular sorabilir:

• 7 ve 30 günlük kullanıcı tutma
• Kayıttan ilk çalıştırmaya aktivasyon
• İlk çalıştırma odaklı tutma
• Ücretli organizasyon pasifliği
• Abonelik durumu ve kayıp izleme
• Seçilen modele göre model kullanımı
• Yerleşik ve kullanıcı sağlayıcı rotaları
• Deneme hesaplama tüketimi
• Modele göre çalıştırma başına maliyet
• Kohorta göre hata ve tamamlama oranı

Ayrıca bu veritabanı gerçeğini çevresindeki sistemlerle birleştirebilir.

Morning Brief raporumuz Plausible, Axiom, Sentry, Google Ads, GitHub ve diğer operasyonel kaynaklardan veri çeker. Veritabanı, kullanıcıların ve organizasyonların ne yaptığını söyler. Plausible, sitede ne olduğunu gösterir. PostHog ürün-olay bağlamı sağlar. Axiom, günlüklerde ve istek yollarında ne olduğunu gösterir. Sentry hataları yakalar. Stripe ve Clerk faturalandırma ve kimlik konusunda yardımcı olur. GitHub mühendislik verimini gösterir.

Amaç her aracı SQL ile değiştirmek değildir. Amaç, ajanın kurucuların gerçekten önemsediği gerçekleri bağlamasını sağlamaktır.

Örneğin:

Dün ücretli Google organikten daha fazla trafik gönderdi. Bu kullanıcılar gerçekten ilk çalıştırmaya ulaştı mı, yoksa huninin başında mı kaldılar?

Veya:

Deneme kötüye kullanım denetimi değiştirildi. Yeni deneme hesapları ilk birkaç saatte daha az hesaplama mı harcadı?

Veya:

Bu model rotası çalıştırma başına daha ucuz. Bu gerçek tarihsel sohbet kullanımında da görünüyor mu, yoksa sadece fiyat teorisinde mi?

Bunlar pano soruları değildir. Bunlar işletme sorularıdır. Haftadan haftaya, bazen günden güne değişir. Güvenli veritabanı erişimi olan bir ajan, her seferinde mühendislikten yeni bir görünüm istemeden bu soruları yanıtlayabilir.

Gerçek bir örnek: tutma ve harici kullanıcı sağlığı

Günlük dahili analizlerimizden biri, son 24 saatte harici kullanıcı sağlığına bakar.

Rapor MaskDB'den başlar, ardından katı bir hariç tutma kümesi uygular. Dahili VM0 organizasyonları çıkarılır. Clerk tarafından yasaklanan veya kilitlenen spam organizasyonlar çıkarılır. Aynı hariç tutma kümesi, kayıt sayıları ve tutma kohortları dahil her yerde uygulanır, böylece paydalar denetlenebilir kalır.

Bundan sonra ajan, kompakt bir işletme raporu üretebilir:

• Çalıştırmalar ve aktif harici organizasyonlar
• Tamamlama oranı
• Web, CLI, zamanlayıcılar ve Zero dışı rotalar arasında tetikleyici dağılımı
• Model dağılımı
• Sağlayıcı modu
• Ücretli organizasyon etkinliği
• Pasif ücretli organizasyonlar
• Yeni ücretli kayıtlar ve deneme organizasyonları
• Kayıp izleme
• 30 günlük kullanıcı segmentasyonu
• Kayıttan çalıştırmaya tutma
• İlk çalıştırma tutma

Bu tam olarak bir kurucu ekibin ihtiyaç duyduğu rapor türüdür. Ham istem gerektirmez. Ham e-posta gerektirmez. Üretim yazma erişimi gerektirmez.

Ürün gerçeklerini doğru şekilde birleştirme yeteneği gerektirir.

Bir çalıştırmada, ajan az sayıda aktif harici organizasyonun hacmin çoğunu oluşturduğunu, birkaç ücretli organizasyonun sessizleştiğini ve son kayıt kohortlarının, spam kayıtlarının paydayı şişirmesi nedeniyle keskin bir aktivasyon uçurumu gösterdiğini buldu. Bunlar, bir kurucunun hızla görmesi gereken şeylerdir, haftalar sonra bir pano incelemesinde keşfetmemelidir.

İkinci örnek: deneme kötüye kullanım ekonomisi

Maskelenmiş ürün verisi, klasik BI grafikleri olmayan sorular için de faydalıdır.

Deneme kötüye kullanımına baktığımızda, faydalı metrik toplam harcanan hesaplama değildi. Toplam harcama, daha uzun süredir hesabı olanlara kayardı, çünkü daha fazla kredi tüketme zamanı olurdu. Daha iyi soru şuydu:

Yeni bir hesap, kayıttan sonraki ilk birkaç saatte ne kadar deneme hesaplaması harcıyor?

MaskDB kullanılarak, ajan kayıt sonrası eşleşen zaman pencerelerinde hesaplama tüketimini ölçtü. Kullanım olaylarından kredi tüketimini, organizasyon meta verilerinden kayıt zaman damgalarını ve deneme ekonomisini ücretli kullanımdan ayırmak için abonelik durumunu kullandı.

Devriye devreye girdikten sonra, kayıttan sonraki ilk saatlerde yakılan ortalama deneme hesaplaması 80%'den fazla azaldı. Yoğun tüketim kuyruğu neredeyse kayboldu. %90'lık dilimde, ilk saatlerdeki deneme hesaplaması yaklaşık $4.05'den yaklaşık $0.26'e düştü, bu da 94%'lik bir azalma.

Bu sayı sadece bir analiz noktası değildir. İşin işletme bakışını değiştirir. Kurucu ekibe, kötüye kullanımın yalnızca tespit edilmediğini, aynı zamanda denemenin birim ekonomisinin doğru yöne gittiğini gösterir.

Ve bu, veritabanında gerçek olduğu, maskelenmiş dalın ise bir ajanın bu gerçeği güvenli şekilde analiz etmesini sağladığı için mümkündü.

Üçüncü örnek: gerçek üründe model maliyeti

Fiyatlandırma sayfaları ve kıyaslama tabloları faydalıdır, ancak kurucuların gerçekten önemsediği soruya yanıt vermez:

Bu model, gerçek ürünümüzde, gerçek çalıştırmalar arasında ne kadar maliyetli?

MaskDB kullanılarak, ajan geçmiş sohbet çalıştırmalarını, çalıştırma anında seçilen modelle çalıştırma kayıtlarını birleştirerek ve kullanım olaylarından alınan kredi toplamlarını toplayarak karşılaştırdı.

Bu ayrım önemlidir. Geçmiş çalıştırmaları kullanıcının mevcut varsayılan model sağlayıcısına göre atfetmemelisiniz, çünkü varsayılanlar değişir. Çalıştırma anında seçilen model gerçek kaynaktır.

Analizimizde, DS v4 Pro'nun sohbet çalıştırması başına ortanca model-kredi maliyeti Sonnet'in yaklaşık 49%'si kadardı. Yani, gerçek ortanca sohbet çalıştırması bu rotada yaklaşık 51% daha ucuzdu.

Yine, bu kurucu düzeyinde BI'dır. Ürün davranışını, altyapı maliyetini ve model stratejisini bağlar. Yeni bir ambar gerektirmez. Doğru ilişkisel verilere güvenli erişim gerektirir.

Bu, bir ambarın sonsuza dek yerine geçmez

Bir şirketin daha resmi bir veri yığınına ihtiyaç duyduğu bir nokta vardır.

Metrikler güçlü anlamsal yönetişim gerektirdiğinde, birçok ekip aynı tanımlara bağımlı olduğunda, tarihsel doldurmalar karmaşık hale geldiğinde, panolar işletim sisteminin parçası olduğunda, bir ambar veya göl-ambar doğru yanıt olabilir.

Ancak birçok girişim bu yanıta çok erken başvurur.

Küçük bir kurucu ekipseniz, ilk BI sisteminiz size soruları yanıtlamada yardımcı olmalı, bakımını yapacağınız ikinci bir ürün yaratmamalıdır. Maskelenmiş bir veritabanı köprü olabilir. Veri modellemenin önemsiz olduğunu iddia etmez. Ürün veritabanının, bir sonraki kararlar için gereken ilişkileri zaten içerdiğini kabul eder.

Ajan, yargı ihtiyacını ortadan kaldırmaz. Analizin ilk sürümünü daha ucuza çalıştırmanızı sağlar.

Kurucu ekipler için desen

Desen basittir:

1. Ürün veritabanını ilk gerçek kaynağı olarak kabul edin.
2. Ham üretimi asla ajanlara açmayın.
3. El yapımı örnek veri kümesi yerine üretime benzer bir dal kullanın.
4. Erişimden önce hassas sütunları statik olarak maskeleyin.
5. Opak birleştirme tanımlayıcılarını koruyun ki analiz çalışmaya devam etsin.
6. Dalı salt okunur bir rol üzerinden açığa çıkarın.
7. Ajanların maskelenmiş DB ve çevresindeki araçlar üzerinde analist döngüsünü çalıştırmasına izin verin.

Bu, bir kurucu ekibe önce tam bir veri platformu kurmadan faydalı bir işletim sistemi sunar.

Ayrıca daha temiz bir güvenlik duruşu yaratır. Ajanın sert bir sınırı vardır. Gördüğü veritabanı zaten dönüştürülmüştür. Kullandığı rol yazamaz. Ürettiği raporlar, karma veya toplu tanımlayıcılarla sınırlandırılabilir.

VM0'da istediğimiz denge buydu: gizlilik ve güvenlik taban, takas değil; kurucu ekibe işi anlamak için çok daha hızlı bir yol sunarken.

Bir veri gölü kurmadan önce, ürün veritabanınızın maskelenmiş, salt okunur bir dalının ekibinizin gerçekten sahip olduğu bir sonraki 20 soruya yanıt verip veremeyeceğini sorun.

Bizim için BI'ya giden daha hızlı yol buydu.

Kaynaklar

• Neon, "Neon Dalları Kullanarak Maskelenmiş Üretim Verisiyle Ortamlar Oluşturma": https://neon.com/blog/environments-masked-production-data
• Neon'un PostgreSQL Anonymizer çatallaması: https://github.com/neondatabase/postgresql_anonymizer