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 altyapı organik olarak büyüyüp karmaşıklaşmıştı. Tablo envanteri, pipeline, cross-platform eşleşme, platform paritesi, taksonomi, event tracking ve dashboard olmak üzere yedi alanda 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 bir 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, bu altyapının zamanla plansız büyümüş olmasıydı. 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’lardaki performans sorunları buradan kaynaklanıyordu. Hangi dashboard’un aktif, hangisinin terk edilmiş olduğu belli değildi. En önemlisi, sistematik bir veri kalitesi kontrolü olmadığı için verinin BigQuery’ye doğru ve eksiksiz aktığından emin olunamıyordu.
Dört fazlı bir dönüşüm programı önerdik ve ilk fazı yürüttük. Bu fazın amacı, yeni bir şey kurmadan önce mevcut yapıyı baştan sona anlamaktı.
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, yani sektörde yaygın görülen oranın üstündeydi; kalan pay çoklu hesap kullanan kullanıcılardan geliyordu. 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 ve ardından yenileme) RevenueCat gelir verisiyle doğrulandı; raporlarda neden “ilk satın alma” görünmediği 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ü, yani 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 bir ö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ı besleyen pipeline durmuştu.
Ölçülmeyen şeyler. Event listesi genişti, ama işin en önemli sorularını cevaplayacak event’ler 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 gösterilebilecek veri yoktu. Otuz civarında eksik event ve otuzu aşkın isim düzeltmesini önceliklendirilmiş bir liste olarak teslim ettik.
Yol haritası
Rapor, dört fazlı programın kalan üç fazına 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: iş performansını tek ekranda gösteren bir yönetici panosu; yeni mimari üzerine kurulan, sayısı azaltılmış bir dashboard seti.
- İleri analitik: kullanıcı segmentasyonu, “sıradaki en iyi içerik” önerisi, churn risk skoru.
Fazları beklemeden ele alınması gereken bulgular ayrıca listelendi: hata event’lerinin kök nedeni, ebeveyn kapısı izleme, paywall ve retention event’leri, bucket güvenliği.
Neden böyle
- Önce mevcut durumu ölçtük. Yeni mimariyi tasarlamadan önce mevcut 1.500 objenin ne olduğunu bilmek gerekiyordu; aksi halde yeni yapı eski karmaşayı devralırdı.
- Güçlü yönleri de yazdık. Eşleşme oranı, pipeline sağlığı ve isimlendirme disiplini raporda riskler kadar yer aldı, çünkü neyin korunması gerektiğini de bilmek gerekiyordu.
- Eksik event’ler öne alındı. Paywall, retention ve ebeveyn kapısı event’leri bugün eklenmezse ileride analiz edilecek veri olmaz. Bu yüzden ileri analitik fazının önüne alındılar.