Vaka Çalışması · Oyun & dijital medya
Upily: Wonjo Kids'in veri altyapısı için keşif ve audit
Çocuklar için oyun uygulaması Wonjo Kids'in Firebase, Adjust ve RevenueCat verisi BigQuery'de toplanmış ama organik büyümeyle karmaşıklaşmıştı. Yedi alanda — tablo envanteri, pipeline, cross-platform eşleşme, platform paritesi, taksonomi, event tracking, dashboard — 1.500'den fazla BigQuery objesini ve 330'dan fazla event'i inceledik; güçlü yönleri, riskleri ve dört fazlı dönüşüm yol haritasını tek raporda teslim ettik.
- 1.500+
- İncelenen obje
- 330+
- Event
- %98+
- Kullanıcı eşleşmesi
- 7
- Audit alanı
Tablo ve view, 18 dataset
Hacim, kategori, hata, eksik, isim
Firebase ↔ RevenueCat, aynı kullanıcı kimliği
Envanterden dashboard'a
Problem
Wonjo Kids, mobil çocuk oyun pazarında veri toplama konusunda rakiplerinin önünde bir altyapıya sahipti. Firebase’den event’ler, Adjust’tan atıf verisi, RevenueCat’ten abonelik ve işlem verisi zamanlanmış sorgularla BigQuery’de toplanıyor; Looker Studio dashboard’ları BigQuery tablolarına doğrudan bağlanıyordu.
Sorun altyapının yokluğu değil, organik büyümesiydi. Analytics veritabanı altında tablolar oluşmuş ama tutarlı bir isimlendirme standardı konmamıştı; hangi tablonun nerede, ne amaçla kullanıldığı ve verinin nereden geldiği belgelenmemişti. Tablolar çoğunlukla view olarak tanımlanmış ve Looker Studio’ya doğrudan bağlanmıştı — büyük dashboard’larda performans sorunu buradan geliyordu. Hangi dashboard’un aktif, hangisinin terk edilmiş olduğu belli değildi. Ve en önemlisi, verinin BigQuery’ye doğru ve eksiksiz aktığından emin olunamıyordu: sistematik bir veri kalitesi kontrolü yoktu.
Dört fazlı bir dönüşüm programı önerdik ve ilk fazı yürüttük: yeni bir şey kurmadan önce mevcut olanı uçtan uca anlamak.
Yedi alanda audit
Keşif iki ay sürdü. Her alan için ölçülebilir bir soru koyduk ve cevabı BigQuery’nin kendi meta verisinden, pipeline loglarından ve dashboard erişim kayıtlarından çıkardık.
| Alan | Soru | Nasıl ölçtük |
|---|---|---|
| Tablo envanteri | 18 dataset’teki 1.500’den fazla obje ne, kim kullanıyor, hangi katmanda? | INFORMATION_SCHEMA; boyut, son güncelleme, sorgu sayısı, kaynak sistem etiketi, katman sınıfı |
| Pipeline | Üç kaynaktan veri kesintisiz ve doğru akıyor mu? | Günlük ve streaming aktarımların eksik gün kontrolü; bucket sınıfı, silme koruması, yaşam döngüsü kuralları |
| Cross-platform eşleşme | Firebase’deki kullanıcı RevenueCat’teki kullanıcıyla aynı mı? | Kullanıcı kimliği eşleştirme; satın alma olaylarının iki kaynakta karşılaştırılması |
| Platform paritesi | Aynı event iOS ve Android’de aynı oranda mı tetikleniyor? | 330’dan fazla event’in platform bazlı hacim oranları |
| Taksonomi | Tablo ve alan adları standarda uyuyor mu? | snake_case uyumu, boolean öneklerinin tutarlılığı |
| Event tracking | Hangi event var, hangisi eksik, hangisi yanlış adlandırılmış? | Hacim ve kategori dağılımı; kritik hata event’leri; sektör standardıyla karşılaştırma |
| Dashboard | 14 dashboard’dan hangisi kullanılıyor, hangisi hangi tabloya bağlı? | Erişim kayıtları, veri kaynağı analizi, performans darboğazları |
Bulgular
Güçlü temeller. Firebase pipeline’ı iki yıldan uzun süredir kesintisiz ve hatasız çalışıyordu. Firebase ile RevenueCat arasındaki kullanıcı eşleşmesi %98’in üzerindeydi — sektör pratiğinin üzerinde bir değer; kalan pay çoklu hesap kullanan kullanıcılardı. Tablo adlarının %97’si standarda uyuyor, boolean alanların tamamı tutarlı önek taşıyordu. Event’lerin büyük çoğunluğu her iki platformda tutarlı oranlarda tetikleniyordu. Abonelik modeli — ücretsiz deneme sonrası yenileme — RevenueCat gelir verisiyle doğrulandı; raporlarda “ilk satın alma” görünmemesinin nedeni de böylece açıklandı.
Biriken teknik borç. Firebase’in ham günlük tabloları dışında kalan objelerin büyük bölümü — 600’den fazla tablo ve view — hiç sorgulanmıyordu; reklam ve CMS dataset’leri neredeyse tamamen kullanım dışıydı, CDC akışı aktif ama okunmuyordu. Hiç materialized view yoktu; sorgu maliyetinin büyük kısmı iki dataset’ten geliyordu ve en pahalı tablolar için özet katmanı en büyük tasarruf fırsatıydı. Tabloların üçte birinden fazlasının katmanı belirsizdi — staging ve mart katmanı yoktu, veri soyağacı izlenemiyordu. Atıf verisinin tutulduğu bucket yanlış depolama sınıfındaydı, silme koruması kapalıydı, yaşam döngüsü kuralı yoktu. Dashboard’ların çoğu aktif değildi; birkaçının beslendiği pipeline durmuştu.
Ölçülmeyen şeyler. Event listesi genişti ama işin en kritik soruları için event yoktu: paywall gösterimi ve kapanışı (dönüşüm oranı hesaplanamıyordu), 1/7/30 günlük retention (kullanıcı kazanma harcamasının getirisi ölçülemiyordu), oturum süresi (başlangıç vardı, bitiş yoktu), doğrudan ücretli abonelik başlangıcı. Bir çocuk uygulaması olarak COPPA ve KVKK kapsamındaki ebeveyn kapısı ve yaş doğrulama ekranları da izlenmiyordu — düzenleyici bir denetimde kanıtlanabilir veri yoktu. Otuz civarında eksik event ve otuzu aşkın isim düzeltmesi önceliklendirilmiş bir listeyle teslim edildi.
Yol haritası
Rapor, dört fazlı programın kalan üç fazı için temel oldu:
- Keşif ve audit — tamamlandı. Envanter, veri sözlüğü taslağı, dashboard envanteri, veri kalitesi başlangıç ölçümü, eşleşme raporu ve bu yol haritası.
- Katmanlı mimari — raw, staging, mart ve report katmanları; merkezi kullanıcı kimliği eşleştirme tablosu; en pahalı sorgular için özet tablolar ve materialized view’lar; veri sağlığı izleme.
- Dashboard konsolidasyonu — tek bakışta iş performansını gösteren yönetici panosu; yeni mimari üzerine kurulan, sayısı azaltılmış dashboard seti.
- İleri analitik — kullanıcı segmentasyonu, “sıradaki en iyi içerik” önerisi, churn risk skoru.
Kritik bulgular — hata event’lerinin kök nedeni, ebeveyn kapısı izleme, paywall ve retention event’leri, bucket güvenliği — fazları beklemeden alınacak aksiyonlar olarak ayrıca listelendi.
Neden böyle
- Önce ölç, sonra kur. Yeni mimariyi tasarlamadan önce mevcut 1.500 objenin ne olduğunu bilmek gerekiyordu; aksi hâlde yeni yapı eski karmaşayı devralırdı.
- Güçlü yönler de bulgudur. Eşleşme oranı, pipeline sağlığı ve isimlendirme disiplini raporda riskler kadar yer aldı — korunması gereken şeyin ne olduğu bilinsin diye.
- Eksik event sonradan üretilemez. Paywall, retention ve ebeveyn kapısı event’leri bugün eklenmezse yarının analizi için veri olmaz; bu yüzden ileri analitik fazının önüne alındılar.