Her çeyrekte, platformumuza yeni katılan yayıncılardan aynı soruyu duyuyoruz: Sırada hangi reklam ağını eklemeliyiz? En bariz çözüm bu gibi görünüyor: daha fazla talep, daha fazla rekabet, daha yüksek fiyatlar. Ancak pratikte, 2026'da ROAS'ını iki katına çıkaran ekipler bunu neredeyse hiçbir zaman yeni ağlar ekleyerek başarmadı. Zaten yayına aldıkları üç şeyi dürüstçe değerlendirerek başardılar.
Artık Apps Kit SDK'ya katılan her yeni hesapta ilk otuz gün boyunca uyguladığımız yol haritası bu. Doğrudan sprint planınıza aktarabilmeniz için hafta hafta anlattık.
1. Reklam yerleşimine değil, kullanıcıya göre değişen taban fiyatlar
Bir waterfall yapısının beklenen performansı gösterememesinin en yaygın nedeni sabit taban fiyatlardır. 4 ABD doları eCPM tabanı, ABD'de saat 20.00'de Wi-Fi üzerinden ödüllü video izleyen bir iOS kullanıcısı için ideal olabilir. Ancak aynı reklam yerleşimi, saat 03.00'te üçüncü kademe (Tier-3) bir pazardaki Android cihazda felaketle sonuçlanabilir.
Her reklam birimi için tek bir taban fiyat kullanmak yerine küçük bir matrise geçtik: ülke kademesi × reklam formatı × günün saat dilimi. Her reklam birimi için altı değer belirledik ve bunları önceki on dört günün teklif verileriyle her hafta yeniden hesapladık. Waterfall mantığı aynı kaldı; yalnızca taban fiyat girdisi değişti. İlk iki haftadaki medyan artış, ödüllü reklamlarda %38, geçiş reklamlarında %22 oldu.
2. Waterfall'ın alt sıralarını kısaltın
İncelediğimiz hesapların çoğunda her reklam yerleşimi için 18 ila 40 satır öğesi bulunuyor. Taban fiyatlar uygulandıktan sonra ilk altının altında kalan tekliflerin neredeyse hiçbiri kazanamıyor; yalnızca gecikmeyi ve zaman aşımı riskini artırıyorlar. Biz listeyi kararlı biçimde kısaltıyoruz: en iyi altı teklif veren ve boş kalan gösterimleri dolduracak iki yedek reklam ağı. İstisna yok.
Reklam isteğindeki gecikme, tipik olarak 1,4 saniyeden 800 ms'nin altına düşüyor. Kazanılan bu süre doğrudan gösterime dönüşüyor; çünkü reklam ekranda belirdiğinde kullanıcı hâlâ oturumda oluyor.
3. DAU başına gösterimi temel KPI olarak ele alın
ROAS, sonuçları geriden takip eden bir metriktir. Öncü metrik, yani bir şeyler ters gittiğinde ilk değişen gösterge, günlük aktif kullanıcı başına reklam gösterimidir. IPM %10 düşerse, sonraki hafta ROAS da %8–12 düşer. Her seferinde.
Bu metriği kohort, reklam formatı ve uygulama sürümü bazında ölçüyoruz. Kontrol paneli, değişimler %5 eşiğini geçtiği anda bunları öne çıkarıyor. Finans ekibi ROAS düşüşünü gördüğünde, bizim ekip uzaktan yapılandırma değişikliğini çoktan yayına almış oluyor.
Hafta hafta uyguladığımız gerçek plan
Bu üç değişiklik tek tek ele alındığında basit. Ancak sıralama, sanılandan daha önemli: Herhangi bir taban fiyat değişikliğinden önce ölçüm altyapısı kurulmalı. Aksi hâlde değişikliğin işe yarayıp yaramadığını anlayamazsınız.
- 1. hafta: Kohort ve reklam formatı bazında DAU başına gösterim panellerini yayına alın; %5 değişim için uyarı tanımlayın.
- 2. hafta: Waterfall'ı en iyi altı teklif veren ve iki yedek reklam ağıyla sınırlandırın; taban fiyatları sabit tutun.
- 3. hafta: Ülke × reklam formatı × günün saat dilimi taban fiyat matrisini tek bir ödüllü reklam yerleşiminde devreye alın.
- 4. hafta: Matrisi geçiş reklamlarına da uygulayın, kalan sabit taban fiyatları kaldırın ve aşağıdaki uygulama sonrası değerlendirmeyi yapın.
Neyi, nasıl ölçtük?
Her değişikliğin işe yarayıp yaramadığını üç sayı gösterdi. Uygulama sürümüne ve ülkeye göre segmentlere ayrılmış DAU başına gösterim, öncü göstergemizdi: Her taban fiyat değişikliğinden sonraki 24 saat içinde tepki veriyordu. Yükleme haftasına göre ayrıştırılmış kohort düzeyindeki ARPDAU, artışın gerçek mi yoksa tek günlük bir dalgalanma mı olduğunu gösteriyordu. Pek dikkat çekmeyen bir bileşik metrik olan, 7. günde uygulamayı kullanmaya devam eden kullanıcıların ARPDAU'su ise gelecek haftanın gelirini bugüne çekip çekmediğimizi ortaya koyuyordu.
Her değişikliği, yeni yüklemelerin %10'unu oluşturan ve değişikliğin uygulanmadığı bir kontrol kohortuyla en az yedi gün test etmeden geniş çapta devreye almadık. Kontrol grubu olmazsa olmaz. Bu grup olmadan taban fiyat değişikliğinizin etkisini mevsimsel bir etkiden ya da tesadüfen aynı salı günü başlayan bir Meta kampanyasından ayıramazsınız.
Uygulama sonrası değerlendirme: Ters tepen bir ayar
İkinci haftada dördüncü bir ayarı da denedik: Teklif verenlerin zaman aşımı sürelerini agresif biçimde kısaltarak 900 ms'den 600 ms'ye indirdik. Teori sağlamdı: daha hızlı açık artırmalar, oturum başına daha fazla gösterim. Pratikte ise süre sınırını, yüksek ödeme yapan iki teklif verenin p95 yanıt süresinin altına indirmiş olduk ve üç günde ödüllü reklam eCPM'inde %11 kayıp yaşadık.
Çözüm, tek bir genel zaman aşımı süresi yerine teklif veren bazında süreler kullanmaktı. Hızlı teklif verenler için 600 ms sınırını koruduk; yavaş ama değerli olan ikisi için süreyi 1100 ms'ye çıkardık. ARPDAU, 48 saat içinde eski seviyesine döndü. Çıkardığımız ders şu: Herkese uygulanan tek bir ayar, neredeyse her zaman bir şeyi bozar. Aynı ayarı segment bazında uyarlamak ise neredeyse her zaman işe yarar.
Kayda değer fark yaratmayan değişiklikler
- Yedinci bir reklam ağı eklemek: Eklenen her ağın sağladığı ek fayda hızla azaldı.
- Doğal reklam birimleri için header bidding kullanmak: Açık artırmanın ek işlem yükü, kazanımı ortadan kaldırdı.
- Oturum başına 3 gösterimin altında agresif reklam sıklığı sınırları uygulamak: 2. gün kullanıcı elde tutma oranında beklenen toparlanma yerine olumsuz sonuç aldık.
- Reklam arabuluculuğu (mediation) SDK'larını değiştirmek: %2'lik bir fark için altı haftalık çalışma; çoğu ekip için buna değmez.
ROAS'ını iki katına çıkaran ekipler, en fazla reklam ağına sahip olanlar değildi. Kullanıcılarının saat saat ne kadar değer yarattığını bilenlerdi.
Sırada ne var?
Bu çeyrekte yalnızca tek bir şey yapacaksanız, kohort düzeyinde DAU başına gösterimi ölçmeye başlayın ve bu metriği uzaktan yapılandırmayla yönetilen bir taban fiyat matrisine bağlayın. Üçüncü adım olan waterfall'ı sınırlandırmak, iki saatlik bir iş ve yalnızca gecikmedeki azalmayla bile karşılığını verir. Dördüncü adım, yani teklif veren bazında zaman aşımı süreleri, %40 artışla %100 artış arasındaki farkı yaratır. Artık bunu her yeni Apps Kit SDK hesabında varsayılan olarak devreye alıyoruz.
