Bir oturum çökmeyle sona erdiğinde, yalnızca kullanıcının güvenini kaybetmezsiniz. Oturumun geri kalanında gerçekleşecek tüm reklam gösterimlerini, oturum kapanışında gönderilecek tüm postback'leri ve ertesi gün kullanıcı tutma oranının önemli bir bölümünü de kaybedersiniz. Hesap hiç iç açıcı değil.
Kayıp zinciri
Sorunsuz çalışan bir mobil uygulamada ortalama oturum süresi 6–9 dakikadır. Gösterim sınırları uygulandıktan sonra oturum başına ortalama reklam gösterimi 2,4'tür. İkinci dakikada çöken bir oturumda ortalama yaklaşık 1,6 gösterim kaybolur; bu kaybın telafisi yoktur.
Bunu %1 çökme oranına ve 5 milyon DAU'ya uyguladığınızda, günde 80.000 kayıp gösterim ortaya çıkar. 7 $ eCPM ile bu, her gün 560 $ gelir kaybı demektir. Üstelik yalnızca kararlılıktaki tek bir yüzde puanlık fark yüzünden.
Gelir kaybının tam modeli
Formül kısa: günlük gelir kaybı = DAU × çökme oranı × (oturum başına gösterim – çökme öncesi gösterim) × eCPM / 1000. Formüle gerçekçi rakamlar koyduğunuzda tablonun ağırlığı ortaya çıkar.
- 1 milyon DAU × %1,5 çökme oranı × 1,6 kayıp gösterim × 6 $ eCPM ≈ günlük 144 $, yıllık 52 bin $
- 5 milyon DAU × %1,0 çökme oranı × 1,6 kayıp gösterim × 7 $ eCPM ≈ günlük 560 $, yıllık 204 bin $
- 25 milyon DAU × %0,6 çökme oranı × 1,6 kayıp gösterim × 8 $ eCPM ≈ günlük 1.920 $, yıllık 700 bin $
- Üstelik bu rakamlar yalnızca kayıp gösterimleri hesaba katıyor; kullanıcı tutma oranındaki düşüşü dışarıda bırakıyor. Oysa bu düşüşün etkisi genellikle daha büyük.
ANR'ler gelir açısından çökmelerden bile daha kötüdür
Android'de ANR (Application Not Responding — Uygulama Yanıt Vermiyor), geliri sessizce baltalar. Kullanıcı donmuş bir arayüzle karşılaşır, uygulamayı zorla kapatır ve kaldırır. Ancak çökme raporu oluşmadığı için Crashlytics'i takip eden ekip bunu hiç görmez. Reklam SDK'sını ana iş parçacığında başlatan uygulamalarda %0,5'in üzerinde ANR oranlarına sık rastlanır.
iOS'taki karşılığı, watchdog tarafından sonlandırılmadır: 0x8badf00d çıkış koduyla görülür ve genellikle aynı temel nedenden kaynaklanır; uygulama açılışında ana iş parçacığında senkron işlemler yürütülmesi. İkisini de çökmeler gibi ele alın: uyarılar oluşturun, gelir kaybını aynı şekilde modelleyin ve her sürümün yayın öncesi kontrollerine dahil edin.
Platforma özel önleyici geliştirme yaklaşımları
Her Apps Kit SDK entegrasyonunda varsayılan olarak uyguladığımız yaklaşımlar bunlar. Hiçbiri özel bir ustalık gerektirmiyor. Ancak denetlediğimiz tipik kod tabanlarında hiçbirine rastlamıyoruz.
- Android: SDK'yı Application.onCreate içinde değil, bir WorkManager göreviyle başlatın
- Android: reklam görünümlerini WeakReference ile tutun ve onDestroyView içinde referanslarını null yapın
- iOS: didFinishLaunching içinden SDK başlatma işlemini utility QoS kuyruğuna aktarın; ana iş parçacığını asla bloke etmeyin
- iOS: reklam delegate'lerini geçersiz kılın ve güçlü referans döngülerini deinit içinde değil, viewWillDisappear içinde kırın
- Her iki platformda da: her reklam isteğini kullanıcı iznini, ağ bağlantısını ve SDK'nın hazır olup olmadığını takip eden bir durum makinesinin kontrolünden geçirin
Çökmeler nereden kaynaklanıyor?
- SDK'nın ana iş parçacığında başlatılması — karşılaştığımız en yaygın neden
- onCreate / didFinishLaunching içinde senkron reklam yükleme
- Reklam görünümlerini gereğinden uzun süre bellekte tutmanın yarattığı bellek baskısı
- Kullanıcı izin durumu ile reklam isteği arasındaki yarış koşulları
Geliri etkileyen çökmeler için uyarı oluşturma
Çökme oranı uyarıları genellikle sabit bir yüzde eşiğine bağlanır ve tetiklendiklerinde görmezden gelinir. Bunun yerine uyarıları gelir etkisine bağlayın: belirli bir çökme imzası için hesaplanan günlük gelir kaybı X $ eşiğini aştığında uyarı verin. Böylece uyarı, nöbetçi mühendisin gece uyanmaya değer bulacağı bir bildirime dönüşür. BigQuery dışa aktarım verileri üzerinde tam olarak bunu yapan bir Cloud Function şablonu sunuyoruz.
Önleyici entegrasyon yaklaşımı
SDK'yı bir arka plan dispatcher'ında başlatın, her reklam isteğini kullanıcı izin durumunu yöneten bir durum makinesinin kontrolünden geçirin ve reklam yerleşimi kapatıldığı anda reklam görünümü referanslarını serbest bırakın. Bunların hiçbiri yeni değil. Ancak denetlediğimiz tipik entegrasyonlarda hiçbiri uygulanmıyor.
Çökme oranını yalnızca kod kalitesine ilişkin bir metrik değil, geliri artırmanın bir yolu olarak ele alın. Uygulama kararlılığına yönelik çalışmaları önceliklendirme tartışması çok daha kısa sürer.
Bu hafta ne yapmalısınız?
Çökme panelinizi açın, en sık görülen üç çökme imzası için yukarıdaki modeli uygulayın ve her birinin yanına dolar cinsinden kaybı yazın. En büyük kayba yol açanı düzelten sürüm, bir sonraki App Store inceleme süreci tamamlanmadan maliyetini çıkaracaktır.
