Bir subscription uygulaması hangi event'i optimize etmeli?

Meta haftada ad set başına kabaca 50 event istiyor. Google günde on kullanıcı istiyor. Satın alma event’iniz 17 kez tetikleniyor.

Optimize ettiğiniz event, hangi kullanıcıları alacağınızı belirler. Install gönderirseniz platform install yapan insanları bulur. Trial başlangıcı gönderirseniz trial başlatan insanları bulur. Satın alma gönderirseniz alıcıları bulur, ama bunu ancak öğrenmesine yetecek kadar çok görürse yapar.

Çoğu subscription hesabının kırıldığı yer tam olarak o son koşuldur. Satın alma event’i, ekonominizle eşleşen event’tir. Aynı zamanda en az sıklıkla tetiklenen event de odur. Bu yüzden ekipler ya onu seçip algoritmayı aç bırakır, ya da install’lara geri döner ve funnel’ı paywall’ı hiç açmayan insanlarla doldurur.

Bunu çözen bir kural var. Kurala geçmeden önce, rakamlar.

Her platformun öğrenebilmek için neye ihtiyacı var

23 Eylül 2026’da her platformun kendi yardım sayfalarına göre kontrol edildi, Meta’nın sayfası ise 24 Eylül’de. Bunlar değişir. Tarih, sayıdan daha önemlidir.

Bu tablodan iki şey çıkıyor.

Eşikler platformlar arasında aynı değil, bu yüzden “haftada 50” bir Meta sayısıdır, bir kural değil. Bunu bir hesabın kaç kampanya taşıyabileceğinin taban değeri olarak kullanıyorum. Bu, öğrenme için bir taban değerdir, bir sonuca güvenmek için değil. Bir reklamın ROAS’ı sonraki haftayı öngörebilsin diye önce 50 veya daha fazla satın almaya ulaşması gerekti, o zaman bile yalnızca orta düzeyde öngörebildi.

Apple Ads ise bu kararın tamamen dışında duruyor. Event sorusu bir Meta, Google ve TikTok sorusu.

Seçtiğiniz event, elde ettiğiniz kullanıcıdır

Platform, kendisine söyleneni harfiyen yapar. Ad set başına satın alma hacmi çok düşük olduğu için bir hesabı satın alma optimizasyonundan trial optimizasyonuna taşıdığınızda trial başına maliyet genellikle düşer. Trial’dan paid’e oranı da bununla birlikte düşebilir ve ödeme yapan subscriber başına maliyet yükselebilir. Platform trial başlatan insanları bulmuştur ve bu insanların bir kısmı her yerde trial başlatır.

RevenueCat’in 2026 verisi, bunun neden en çok kısa trial’larda zarar verdiğini gösteriyor. Üç günlük trial’ı olan uygulamalarda, trial iptallerinin %55,4’ü gün 0’da, %84’ü ise gün 1’e kadar gerçekleşiyor. Trial için optimize edilmiş bir kampanya salı günü mükemmel görünüp perşembe gününe kadar değersizleşebilir ve platform bu farkı asla görmez, çünkü iptal, optimize ettiği bir event değildir. Trial’ın funnel’da yer alıp almaması gerektiği ayrı bir soru.

En derin event neden genelde yanlış ilk seçim

Satın alma, P&L’inizle eşleşen event’tir. Her zaman ona göre optimize edebilseydiniz, yapardınız.

Genelde yapamazsınız, iki nedenden dolayı.

Hacim. Örnek bir subscription uygulamasını ele alalım ve ilk ödemelerini ad set’e kadar izleyelim.

Örnek bir aritmetik, gerçek bir hesap değil. Her doların yeni bir 60 $’lık yıllık ilk ödeme olduğunu ve ad set’ler arasında eşit dağıldığını varsayıyor. Kendi rakamlarınız onun yerine geçer. Derin event’in kullanılabilir olup olmadığına harcama kadar yapı da karar verir.

Gecikme. Yedi günlük bir trial’ın ilk ödemesi gün 7 veya 8’e denk gelir ve iOS’ta, izlemeyi reddeden kullanıcılar için, bunu raporlayan postback platforma günler sonra ulaşır. Platform, geçen hafta ne satın aldığınızı anlatan bir sinyalden öğreniyor demektir. Meta’nın tahmini değer parametreleri ve Google’ın value bidding’i bu gecikmeyi kısaltmak içindir ve yalnızca tahmin olgunlaşmış cohort’lara karşı kontrol edildiğinde işe yarar. Value optimizasyonunun yanlış gittiği yer tam olarak burasıdır, erken devreye alındığında. SKAN’ın trial sonrası ödemeyi raporlayıp raporlayamayacağı trial süresine bağlı. Bunu SKAN, free trial sonrası subscription ödemesini ölçebilir mi? yazısında anlatıyorum.

Yani en derin event bir hedeftir, bir başlangıç noktası değil.

Kural

Bütçenizde platformun eşiğini geçecek kadar sık, öğrenme penceresi içinde ulaşacak kadar zamanında ve iyileştirildiğinde ödeme yapan subscriber’ları da iyileştirecek kadar öngörücü olan en derin event için optimize edin.

Üç koşulun hepsi birden. Ödeme yapanları öngörmeyen sık bir event bir tuzaktır. Haftada 17 kez tetiklenen öngörücü bir event ise bir tıkanmadır.

Pratikte bu bir merdiven demek.

Yalnızca Meta, Google ve TikTok. Apple Ads, platform tablosunun gösterdiği gibi merdivenin dışında kalır. Hangi bidding modunun hangi uygulamaya uyduğu, event’ten ayrı bir karar. Aggregated Event Measurement kullanan iOS kampanyalarında, o event’i optimize edebilmeniz için Meta’nın onu ayrıca uygun olarak işaretlemesi gerekir. Hangi kontrolleri yapacağınız trial ve purchase event’leri neden uygun değil olarak dönüyor yazısında.

Adım 2 için test basit. 60 günlük gelire sahip olacak kadar eski cohort’lar çekin. Aday event’i tetikleyen kullanıcılarla tetiklemeyenler arasında trial’dan paid’e oranını ve install başına 60 günlük geliri karşılaştırın. Fark küçükse, event kimseyi nitelendirmiyor demektir. Farklı birini seçin. Fark büyükse, ona teklif vermeden önce daha sonraki bir cohort setinde doğrulayın. Bir event, ona teklif vermenin size daha fazla ödeme yapan kullanıcı getirmesi olmadan da ödeme yapanları öngörebilir. Bir hesapta gün sıfır değeri, D28 ROAS’ı satın alma başına maliyetten daha iyi öngördü ve bu, bir sinyalin optimize edilmeyi hak edip etmediğini size söyleyen türden bir kontrol.

Başarı gibi görünen hata

Ucuz trial’lar klasik örnektir. %85 gün 0 iptal oranıyla 10 $’lık bir trial başına maliyet, normal bir iptal oranındaki 30 $’lık bir trial başına maliyetten daha kötüdür. Dashboard, ilk kampanyanın kazandığını söyler. Banka hesabı ise altı hafta sonra tam tersini söyler.

İkinci hata daha sessizdir. Ekipler satın alma optimizasyonunu seçer, bir ay boyunca Learning Limited’da beklediğini izler ve Meta’nın kendileri için işe yaramadığı sonucuna varır. Oysa Meta işe yarıyor. Denemek için hiç yeterli veri alamamıştır.

Üçüncüsü, eşiği geçmek için ad set’leri birleştirip bir hafta sonra bir creative testi için onları tekrar parçalara ayırmaktır. Her önemli düzenleme saati sıfırlar.

Bir subscription uygulaması reklam bütçesini artırmadan önce hangi CPA tavanını belirlemeli?

Tavanı bir benchmark’tan almıyorum. Hiçbir harcama yapmadan önce sizin unit economics’inizden belirliyorum, yani ödeme yapan bir subscriber’ın mağaza komisyonu, vergi ve refund’lar sonrasında proceeds olarak getirdiği tutar, eksi ona hizmet vermenin değişken maliyetleri. RevenueCat’in Reconciling with App Store Financial Reports sayfası proceeds’i gelirden bu şekilde ayırıyor, vergi ve komisyon tahmini olarak düşülüyor (29 Eylül 2026’da kontrol edildi). Dolayısıyla tavan, ödeme yapan subscriber başına maliyettir ve onu, bu unit economics’i gösterecek kadar eski cohort’larda değerlendiriyorum.

Bir proxy event’i optimize ediyorsanız, önce onu çevirin. Ödeme yapan subscriber başına maliyet, kabaca trial başına maliyetin trial’dan paid’e oranına bölünmesidir. Bu oran, trial’larının dönüşmesine yetecek kadar eski cohort’lardan alınmalı.

Test başlamadan önce üzerinde en fazla ne kadar kaybetmeyi göze aldığınıza karar verin. Önceden sabitlediğiniz bu rakam ne kadar sabırlı olacağınızı belirler. İlk birkaç gün belirlemez.

Ardından optimize edilen event’in neyi saydığını kontrol edin. RevenueCat’in Meta Ads entegrasyonu varsayılan olarak Trial Converted, Initial Purchase ve Renewal event’lerinin hepsini Subscribe olarak gönderir (29 Eylül 2026’da kontrol edildi). Ads Manager’daki Subscribe başına maliyet yeni ödeme yapanlarla yenilemeleri karıştırabilir, bu yüzden yeni bir ödeme yapanın gerçek maliyetinden düşük görünebilir.

Bütçeyi yalnızca ödeme yapan subscriber başına maliyet, aynı cohort yaşında, tavanın altında kaldığı sürece artırıyorum. Aritmetik, biri subscription uygulaması, biri oyun için iki çözümlü örnekle birlikte, CPA tavanınızı nasıl hesaplarsınız yazısında.

Bu sayfanın size söyleyemeyeceği şey

Kitleyi, creative’i ve harcamayı sabit tutup install, trial ve satın alma optimizasyonunu olgunlaşmış subscription geliri üzerinde karşılaştıran, yayınlanmış kontrollü bir deney bulamadım. Var olan şey platform kılavuzları, uzun vadeli sonuçlar için kısa vadeli proxy’ler üzerine araştırmalar ve tedarikçi benchmark’ları. Yukarıdaki kural savunulabilir bir ilke. Bir doğa yasası değil ve tablodaki eşikler altı ay sonra farklı olacak.

Yapabileceğiniz şey, merdiveni kendi cohort’larınıza karşı, aynı cohort yaşında karşılaştırarak çalıştırmaktır, böylece bir haftalık bir cohort hiçbir zaman üç aylık biriyle yargılanmaz.

Hesabınız nerede duruyor

Satın alma event’iniz eşiği geçmiyorsa ve bir çeyrekten uzun süredir trial optimizasyonundaysanız, bu genelde 90 dakikalık bir konuşmadır. Ücretli 90 dakikalık bir seans, kurulumunuzu ve neyi hangi sırayla değiştireceğinizi kapsar, intro call ile aynı takvim üzerinden ayarlanır. Subscription uygulamaları için paid UA’nın tam resmi ve signal engineering’in neyi çözdüğü kendi sayfalarında duruyor.

Kaynaklar ve kapsam

Platform eşikleri 23 Eylül 2026’da, Meta’nın sayfası ise 24 Eylül’de kontrol edildi. Meta: About the learning phase, Meta Business Help Center. Bu sayfaya göre ad set’ler, son önemli düzenlemelerinden sonraki hafta içinde yaklaşık 50 sonuca ulaştıklarında genellikle öğrenme aşamasından çıkıyor. Google: Best practices guide: Setting up your App campaigns ve Set up an App campaign for target return on ad spend, Google Ads Help. TikTok: Tips for Value-Based Optimization for app, TikTok Business Help Center, Mayıs 2026’da güncellendi. Apple: Maximize Conversions best practices, Apple Ads. RevenueCat’in varsayılan Subscribe eşlemesi ve proceeds tanımı: Meta Ads ve Reconciling with App Store Financial Reports, RevenueCat Docs, ikisi de 29 Eylül 2026’da kontrol edildi. Trial iptal zamanlaması: State of Subscription Apps 2026, RevenueCat, 115.000’den fazla uygulama, 2025 takvim yılı, RevenueCat tarafından hazırlandı. Bu, iptallerin bir dağılımı, tüm trial kullanıcılarının bir payı değil. Vekil sonuç argümanı, bir çalışma raporu olan Athey, Chetty, Imbens and Kang, NBER Working Paper 26463 makalesini izliyor. 80K $’lık örnek, açıklama amaçlı bir aritmetiktir, gerçek bir hesap değil.