Tipik bir SaaS reklam medyasyon SDK'sını entegre ettiğinizde etkinlik akışınız — her reklam isteği, her gösterim, her kullanıcı tanımlayıcısı — önce sağlayıcının sunucularına gönderilir. Sağlayıcı bu verileri işler, zenginleştirir ve bazen hassas bilgileri çıkarılmış bir kopyasını veri ambarınıza geri gönderir. Verileri gördüğünüzde, bunlar zaten sizin kontrolünüzde olmayan bir sistemden geçmiş olur.
Doğrudan Firebase üzerinde çalışan bir SDK'da ise akış tersine döner. Etkinlikler önce size ait Firestore ve BigQuery'ye yazılır. Sağlayıcı sizin projenizden veri okur; siz onun sisteminden değil. İlk GDPR denetimine kadar bu fark yalnızca teorik görünebilir.
Verilerin sahibi kendi projeniz olduğunda neler değişir?
- Silme talepleri tek bir Firestore sorgusuyla karşılanır — sağlayıcıya destek talebi açmak veya SLA süresini beklemek gerekmez
- Dışa aktarma şemasını siz belirlediğiniz için BigQuery maliyetleri öngörülebilir olur
- Şema geçişleri sağlayıcının sürüm takvimine göre değil, sizin takviminize göre yapılır
- Bildirmeniz gereken alt veri işleyenlerin listesi, çoğu zaman önemli ölçüde kısalır
Satış görüşmesinde kimsenin bahsetmediği ödünleşimler
Firebase tabanlı bir yapı maliyetsiz değildir. Normalde sağlayıcıya devredeceğiniz depolama ve sorgulama işlemleri için Google'a ödeme yaparsınız. 5 milyon DAU'ya sahip bir uygulamada aylık BigQuery faturası 400–1.200 ABD doları arasında olur. Bu kayda değer bir tutardır, ancak koruduğu reklam gelirinin yanında küsurat sayılır.
Kotaları da hesaba katmanız gerekir. Firestore'da saniye başına yazma sayısı, BigQuery'ye akış halinde veri ekleme ve Cloud Function soğuk başlatmaları, SaaS SDK'sının siz fark etmeden yönettiği gerçek kısıtlardır. Apps Kit SDK, yazma işlemlerini toplu hale getiren bir geri basınç (backpressure) katmanıyla gelir. Bu katman, 1 milyon DAU'nun altındaki çoğu uygulamanın ücretsiz kullanım kotaları içinde kalmasını sağlar.
Google'a gerçekte ne kadar ödersiniz?
Maliyet modeli sıradandır; zaten amaç da budur. Her kalemi kendi faturalandırma konsolunuzda görebilirsiniz. Aşağıdaki aralıklar, varsayılan olarak sunduğumuz geri basınç katmanı ve BigQuery'deki 90 günlük bölüm (partition) saklama süresi uygulandıktan sonra, 2026'da aktif Apps Kit SDK kurulumlarında gözlemlediğimiz tutarlardır.
- 1 milyon DAU: Firestore 40–90 ABD doları, BigQuery depolama 20–50 ABD doları, BigQuery sorguları 30–80 ABD doları, Cloud Functions 10–30 ABD doları — toplam aylık 250 ABD dolarının altında
- 5 milyon DAU: Firestore 180–350 ABD doları, BigQuery depolama 100–220 ABD doları, BigQuery sorguları 120–400 ABD doları, Cloud Functions 40–110 ABD doları — toplam aylık 400–1.200 ABD doları
- 25 milyon DAU: Firestore 700–1.400 ABD doları, BigQuery depolama 450–900 ABD doları, BigQuery sorguları 500–1.800 ABD doları, Cloud Functions 150–400 ABD doları — toplam aylık 1.800–4.800 ABD doları
Faturayı gerçekten değiştiren maliyet ayarları
Yukarıdaki aralıkların genişliği büyük ölçüde üç karardan kaynaklanır. İlki, verileri BigQuery'ye akış halinde mi yoksa GCS üzerinden toplu olarak mı aktaracağınızdır. Toplu aktarım, raporlamada 30 dakikalık gecikme karşılığında veri alım maliyetini %80'den fazla azaltır. İkincisi, bölümlerin saklama süresidir. Bugüne kadar ihtiyaç duyduğumuz tüm operasyonel sorgular için 90 gün yeterli oldu; daha eski ham veriler soğuk depolamada tutulmalıdır. Üçüncüsü ise sorgu disiplinidir. Bir yıllık gösterim verisi üzerinde hiçbir sınır koymadan SELECT * çalıştıran tek bir gösterge paneli, diğer tüm kalemlerin toplamından daha fazla maliyet yaratabilir.
Bu konu 2026'da neden daha önemli?
Bu yıl iki mevzuat değişikliği dengeleri değiştirdi. DMA'nın veri taşınabilirliği gereklilikleri artık AB'deki son kullanıcıların verilerini işleyen tüm sağlayıcılar için geçerli. Hindistan'daki DPDP için uygulamaya geçiş süresi de mart ayında sona erdi. Her iki düzenleme de talep üzerine bir kullanıcıya bağlı tüm etkinlikleri eksiksiz biçimde dışa aktarabilmenizi bekliyor.
Ana kayıt sisteminiz SDK sağlayıcınızsa, onun dışa aktarma araçlarına bağımlısınız. Ana kayıt sisteminiz Firebase projenizse, dışa aktarma işlemi zaten nasıl yazılacağını bildiğiniz bir sorgudan ibarettir.
GDPR / DPDP denetimi pratikte nasıl ilerler?
Bir düzenleyici kurum veya büyük bir kurumsal müşteri denetim istediğinde dört çıktı bekler: son kullanıcı verilerine erişen tüm alt veri işleyenlerin listesi, belirli bir kullanıcıya ait verilerin eksiksiz dışa aktarımı, silme kanıtı ve veri saklama takviminizin açıklaması. SaaS SDK'sında ilkini sağlayıcının açıklamalarını okuyarak, sonraki ikisini destek talepleri açarak, dördüncüsünü ise tahminde bulunarak hazırlarsınız.
Firebase tabanlı bir yapıda dördü de sizin kontrolünüzdeki sorgularla elde edilir. Alt veri işleyenler: projenizdeki GCP hizmetlerinin listesi. Kullanıcı verilerinin dışa aktarımı: SDK'da şablon olarak sunulan bir Firestore sorgusu ve bir BigQuery sorgusu. Silme kanıtı: etkilenen satır sayılarını döndüren bir Cloud Function. Saklama süresi: konsolda görünen bölüm süre sonu politikanız. Böylece denetim, iki haftalık bir telaş olmaktan çıkıp yarım günlük bir işe dönüşür.
İlişkilendirmeyi bozmadan SaaS SDK'sından geçiş
Ekipleri korkutan, tüm geçişi tek bir sürümde yapacaklarını düşünmeleridir. Biz süreci böyle yürütmüyoruz. Firebase tabanlı SDK, iki ila dört hafta boyunca mevcut SaaS SDK'sıyla birlikte çalışır ve yeni veri hattına yazarken eski SDK, mevcut tüm gösterge panellerini ve MMP'leri beslemeye devam eder.
- 1. hafta: Firebase tabanlı SDK'yı gölge modunda entegre edin; kullanıcıya yansıyan hiçbir değişiklik yapmadan BigQuery'de etkinlik verilerinin eşleştiğini doğrulayın
- 2. hafta: İlişkilendirme postback'lerini Firebase tabanlı akışa taşıyın; reklam medyasyonunu eski SDK'da tutun
- 3. hafta: Reklam medyasyonunu yeni SDK'ya geçirin; uyuşmazlık durumunda referans olması için SaaS SDK'sının yalnızca gözlem amaçlı etkinlik göndermesini sürdürün
- 4. hafta: Bir sonraki uygulama güncellemesinde SaaS SDK'sını kaldırarak bağımlılığı tamamen ortadan kaldırın
SaaS hangi durumlarda hâlâ daha avantajlı?
Ekibinizin mevcut bir Firebase altyapısı ve böyle bir altyapı kurma planı yoksa, Firebase tabanlı bir SDK'nın getirdiği operasyonel yükü göz ardı edemezsiniz. SaaS reklam medyasyonu, entegrasyonu tamamlayıp sonrasında onunla uğraşmak istemeyen stüdyolar ve veri sahipliğinin henüz stratejik bir varlık olmadığı prototipler için doğru tercihtir. Karar teknik değildir; denetim izinin kimin kontrolünde olmasını istediğinizle ilgilidir.
Etkinlik akışına sahip olmak, gizlilik konusunda bir duruş sergilemekten ibaret değildir. Bir sonraki sağlayıcı sözleşmenizi eliniz güçlü biçimde müzakere etmekle, elinizde yalnızca bir ekran görüntüsüyle masaya oturmak arasındaki farktır.
Bu çeyrekte ne yapmalısınız?
Zaten Firebase Analytics kullanıyorsanız, Firebase tabanlı bir reklam SDK'sına geçiş yolunun %60'ını tamamlamış durumdasınız ve muhtemelen bunun farkında değilsiniz. Bir sprint ayırarak yukarıdaki gölge modu entegrasyonunu devreye alın ve kararınızı satış sunumuna değil, veri eşleşme raporuna göre verin. Gölge aşamasını tamamlayan ekiplerin çoğu, doksan gün içinde tamamen geçiş yapmaya karar veriyor.
