Bir uygulamayı ölçeklemeden önce CPA tavanını nasıl hesaplarım? Tavan proceeds'ten gelir, benchmark'tan değil.

Yıllık planı 59,99 $ olan örnek bir subscription uygulaması düşünün. Aynı fiyatlarla, aynı mağaza komisyonlarıyla ve aynı refund oranıyla bir payer için 26,87 $’ı da karşılayabilir, 53,81 $’ı da. Değişen tek girdi, parasını ne kadar bekleyebileceği. Ödeme yapan bir kullanıcının size en fazla ne kadara mal olabileceği CPA tavanıdır ve ben onu, herhangi bir hesapta harcamayı artırmadan önce belirlerim.

Tavan, elinizde zaten olan üç rakamdan çıkar. Bir payer’ın ne ödediği. Mağaza, vergi ve refund’lardan sonra size ne kaldığı. Parayı ne kadar bekleyebileceğiniz. Bir platform hedefi, bir benchmark ve 3:1’lik bir oran bunların hiçbiri değildir. Önce tavanı, sonra onun altında platform hedefini belirlersiniz ve ikisi arasındaki fark cohort’larınızın yaşına bağlıdır. Örneklerdeki her rakam, adı konmuş bir varsayım üzerinde yapılan aritmetiktir, bir hesabın gerçek rakamları değil.

CPA tavanı nedir ve ne değildir?

CPA tavanı, ödeme yapan kullanıcı başına maliyettir, kurulum veya trial başına maliyet değil. Kurulumlar ve trial’lar birer proxy’dir ve tavanı onlara ancak en sonda, dönüşmeye yetecek kadar eski cohort’larda ölçülmüş dönüşüm oranlarıyla çeviririm.

Üç şey onunla karıştırılıyor:

• Bir platform hedefi. Google, hedef CPA ile bazı conversion’ların hedeften pahalıya, bazılarının daha ucuza mal olduğunu açıkça söylüyor. Hedef, teklif vermenin bir girdisidir. Bir payer’ın sizin için ne kadar değerli olduğundan haberi yoktur.
• Bir benchmark. Medyan bir CPI veya trial başına maliyet, başka fiyatları ve başka komisyon kademeleri olan başka uygulamaları anlatır. Tier 2 pazarlar yazısı, kurulumların %3’ünün ödeme yaptığı 2 $’lık bir CPI’nin, %4’ünün ödeme yaptığı 15 $’lık bir CPI’yi nasıl geçtiğini gösteriyor. Bu, payer başına 67 $’a karşı 375 $ eder. Aynı benchmark, zıt hükümler.
• Bir oran. 3:1 LTV:CAC oranına daha önce kaba bir gösterge dedim ve demeye devam edeceğim. Bir oran, gelirin proceeds mı brüt mü olduğunu ve ne zaman geldiğini gizler, bir tavanın var olma nedeni de tam bu ikisidir.

Payer başına proceeds’i nasıl hesaplarım?

Tavandaki her girdi fiyattan yapılan bir kesintidir ve bu kesintiler, çoğu modelin varsaydığından daha büyük ve daha çeşitlidir.

Mağaza komisyonu. Tek bir rakam değildir. Programa, subscriber’ın ne kadar süredir ödeme yaptığına ve bölgeye göre değişir.

Modelde sabit %30 kullanmak çoğu uygulama için çoğu zaman yanlıştır ve yanlışlığı, sizi fazla düşük teklif vermeye iten yöndedir.

Vergi. Fiyat KDV içeriyorsa mağaza, komisyonu vergi düşüldükten sonra hesaplar, bu yüzden Almanya’daki 59,99 €’luk bir planla Teksas’taki 59,99 $’lık bir plan aynı proceeds’i üretmez.

Refund’lar. Bir refund, size ulaşanı geri alır. Google Play’de, refund edilen bir siparişte Google hizmet ücretini iade eder. Apple’ın satış raporlarında bir refund, proceeds oranınız üzerinden negatif birim olarak yazılır, yani kaybettiğiniz tutar, müşterinin ödediği fiyat değil, sizin payınızdır. RevenueCat’in 2026 raporunda çoğu kategori %3 ile %4 arasında, uç değerler %9 ila %18 ve fiyatı yüksek planlar daha çok refund ediliyor.

Değişken maliyetler. Payer sayısıyla birlikte artan her şey: bir AI uygulaması için inference, içerik lisansı, destek. Sabit maliyetler dışarıda kalır. Tavan, payer başına başabaş çizgisidir. Kirayı, teklifinizi onun altında tuttuğunuz fark öder.

Bu dört kalemden sonra kalan rakam, payer başına proceeds’tir. RevenueCat katmanları aynı şekilde ayırıyor, refund’lar düşülmüş gelir, ardından tahmini vergi ve komisyon sonrası proceeds, ben de tavanı sonuncusu üzerine kuruyorum. Para ise acele etmez. Apple, satışın gerçekleştiği mali ayın bitiminden itibaren 45 gün içinde ödüyor, yani bir satış size haftalar sonra ulaşabilir. Google Play ise takip eden ayın yaklaşık 15’inde ödüyor.

Parayı ne kadar bekleyebilirsiniz?

Hiçbir benchmark bunu sizin yerinize cevaplayamaz. Yeni bir hesapta en çok zaman harcadığım yer burası.

Kuralım plana bağlı. Yıllık bir plan ilk ödemede kendini geri öder ya da hiç ödemez, bu yüzden pencere anlıktır. Haftalık ve aylık planlar değerlerinin büyük bir bölümünü ilk ödemeye yükler, gerisi renewal’larla gelir, bu yüzden onları haftalık cohort’larda okurum ve tek bir haftaya asla güvenmem. Andromeda playbook’undan gelen parmak kuralım, ortalama bir haftalık veya aylık subscriber’ın zaman içinde kabaca yıllık fiyatı geri getirdiğidir. Subscription’ın üstüne ek ürünler satan uygulamalar parasını daha hızlı geri alır, çünkü ikinci satın alma, renewal’dan önce gelir.

Sonra şirkete göre değişir. Yeni başlayan biri için her şeyi aynı ay içinde geri alın. Renewal eğrinizi henüz bilmiyorsunuz, mağaza da size haftalarca ödeme yapmayacak, bu yüzden ikinci yıla yaslanan bir tavan, kendinizden aldığınız bir borçtur. Köklü bir uygulama iki yıla doğru esneyebilir. Köklü olmak aynı anda iki şey demek. En az bir yıllık renewal verisine sahipsiniz, yani eğri tahmin edilmiyor, biliniyor. Ayrıca onu beklemeye yetecek nakitiniz veya finansmanınız var. Biri olmadan diğeri yetmez.

İki yıllık proceeds’i saymak, değerlendirmek için iki yıl beklemek demek değil. Hedef yine D30 veya D60’ta duruyor, o playbook’taki gibi, oradan renewal’a kadar ölçülmüş eğri de gerisini taşıyor. Pencere, tavanın saydığı süredir. Gün, değerlendirme yaptığınız andır.

Renewal eğrisini ölçün, çünkü aylık gelirin churn oranına bölünmesi şeklindeki olağan kısayol churn’ün sabit kaldığını varsayar ve subscription cohort’larında öyle olmaz. Fader ve Hardie, ayrılmaya en yatkın insanlar ilk gidenler olduğu için retention oranlarının zamanla yükseldiğini gösterdi. Medyanlar da düşük. RevenueCat’in 2026 raporunda üst kategoriler genelinde medyan ilk yıllık renewal %23 ile %40 arasında. Tavanınız bundan fazlasını varsayıyorsa cohort’u görmek isterim.

59,99 $’lık bir subscription uygulamasında tavan nasıl görünür?

Aşağıdaki her girdi, son sütun bir kaynak belirtmedikçe örnektir. Geri kalanını kendi fiyat listenizle, kendi komisyon kademenizle ve kendi olgunlaşmış oranlarınızla değiştirin.

İlk blok, yeni başlayanın tavanıdır, aynı ay içinde geri ödeme. İkincisi köklü uygulamanın tavanıdır ve yalnızca bir cohort’u bir yıl boyunca izlemiş ve ikinci yılı bekleyebilen bir uygulamaya açıktır. Yedi aylık ödemenin hepsinde %30 komisyonu tuttum, çünkü aylık planlar %15 kademesine nadiren ulaşır.

Komisyon kademesinin etkisi. %15 kademesinde, ister Small Business Program üzerinden ister Google Play subscription’ı olarak, aynı ilk ödeme payer başına 26,87 $ yerine 32,63 $ eder. Modelde çoğu insanın %30’da bıraktığı tek bir satırdan gelen, beşte bir daha fazla manevra alanı.

Yukarıdaki tablolardaki örnek fiyat listesi, Apple standart koşulları. Tam dolu çubuk 53,81 $.

Pencere tavanı ikiye katladı. Komisyon kademesi onu beşte bir oranında oynattı. Çoğu ekibin üzerinde tartıştığı girdi olan trial’dan paid’e oranı ise onu hiç oynatmadı, çünkü yalnızca tavanı bir teklife çevirir. Funnel oranlarına dokunmadan önce pencereyi ve komisyonu doğru belirleyin.

Reklam geliri olan bir mobil oyunda tavan nasıl görünür?

Oyunlar ROAS ile yürür ve bir soft launch’ın kurulumların pencere içinde kendini geri ödediğini kanıtlaması gerekir. Dolayısıyla tavan, ihtiyaç duyduğunuz getiriyi ihtiyaç duyduğunuz günde hâlâ karşılayan CPI’dır, satın almalar ve reklam geliri birlikte sayılarak. Reklam geliri mağaza komisyonu taşımaz ve hybrid oyunların kurulum başına, payer oranının gösterdiğinden daha fazla getirebilmesinin nedenlerinden biri de bu.

Örnek girdiler: kurulumların %3’ü gün 30’a kadar ödeme yapıyor, bir payer o zamana kadar brüt 35 $ harcıyor, yani %30 komisyondan sonra 24,50 $, ortalama bir kurulum da gün 30’a kadar 0,40 $ reklam geliri kazanıyor. Satın almalar kurulum başına %3 × 24,50 $ = 0,74 $ getiriyor, reklamlar 0,40 $ ekliyor, yani bir kurulum gün 30’a kadar yaklaşık 1,14 $ değerinde.

Kural gün 30’da geri ödemeyse CPI tavanı yaklaşık 1,14 $. Bir sonraki cohort’u finanse etmek için gün 30’a kadar %130 gerekiyorsa yaklaşık 0,87 $. Payer başına hesaplamak için kurulum değerini ödeme yapan %3’e bölün, bu reklam geliri sayıldığında yaklaşık 38 $ eder, yalnızca satın almalarda ise 24,50 $. Yalnızca uygulama içi satın almaları sayan bir model bu oyunun değerini üçte bir eksik hesaplar.

Oyun hesaplarımdan birinde CPI sabit kaldı, D0 ROAS ise yarıya indi, çünkü sipariş değeri düştü. Tavanı CPI üzerine değil, kurulum başına değer üzerine kurmanın gerekçesi bu.

CPA tavanı her ülkede aynı olmalı mı?

Okunacak kadar hacim olan her yerde ülke başına bir tane. Fiyatlar farklı, vergi uygulaması farklı, mağaza komisyonu farklı olabilir ve plan karışımı farklı, çünkü RevenueCat’in 2026 raporunda yıllık planlar, Kuzey Amerika’da satılan subscription’ların %40’ını, Orta Doğu ve Afrika’da %19’unu oluşturuyor. Bunların her biri payer başına proceeds’i değiştirir ve blended bir tavan farkı gizler. Ülke audit’imde bir ülke, blended %70 gösteren bir kampanyanın içinde üç ay boyunca %28 ROAS ile çalışmıştı. Videa hesabında ROAS hedeflerini ülkeye göre belirledim ve bütçenin pazar bazında geri ödemeyi izlemesine izin verdim.

Okunamayacak kadar küçük bir ülkeyi komşularıyla birleştirip grubu okuyun. Arkasında 80 $ harcama olan bir ülkenin ROAS’ı gürültülüdür, bir hüküm değildir.

Bir CPA tavanını Meta veya Google hedefine nasıl çeviririm?

Tavan payer başına, platform ise event başına hedef istiyor, bu yüzden önce çevirin. Trial optimizasyonunda trial başına maliyet hedefi = tavan × olgunlaşmış trial’dan paid’e oranı. Satın alma optimizasyonunda event’in neyi saydığını kontrol edin. RevenueCat’in Meta entegrasyonu varsayılan olarak trial conversion’larını, ilk satın almaları ve renewal’ları hep Subscribe olarak gönderir, bu yüzden Subscribe başına maliyet, yeni bir payer’ın gerçekten mal olduğu tutarın altında kalabilir, optimizasyon event’i yazısının anlattığı gibi.

Sonra hedefi tavanın altına koyun. Ne kadar altına koyacağınız cohort yaşına bağlı. Cohort’lar yeniyken üç şey hâlâ bilinmiyor. Çarptığınız trial’dan paid’e oranı bir benchmark ya da tahmin, attribution farkı ölçülmemiş ve refund’lar henüz yansımamış. O aşamada tavanın altındaki boşluk aynı anda iki iş görür. Bu bilinmeyenleri emer ve sabit maliyetler için kalan tek para odur. Bu yüzden geniş bırakırım ve birkaç haftalık, aynı yaştaki cohort’lar oranları doğruladıktan sonra daraltırım. Örnekte, ilk ödeme tavanının dörtte bir kadar altı, yeni bir hesap için payer başına yaklaşık 20 $ ve trial başına 7,50 $, onda bir kadar altı ise oranlar bilindiğinde yaklaşık 24 $ ve 9 $ eder. Bu marjlar örnektir. Yön örnek değildir.

Hakkında yazdığım fitness uygulamasında hedef trial başına 15 $’dı ve hesabı 30 $’ın altına indiremedim. 30 $’ın bir başarısızlık mı yoksa makul bir rakam mı olduğu, bir trial’ın o uygulama için ne kadar değerli olduğuna bağlıydı. Tavanın size harcamadan önce verdiği rakam bu, gün 25’ten sonra değil. Bir cohort onu tutturamadığında, kesmeden önce neyin değiştiğini teşhis yazısındaki yöntemle bulurum.

Platformlar da hedeflerini aynı şekilde tarif ediyor, dipnotları okursanız. Meta’nın yardım sayfası, sonuç başına maliyet hedefine ve ROAS hedefine reklam müzayedesinin girdileri diyor ve hesabın onlara oturacağına dair hiçbir garanti vermiyor. Google’ın kurulum kılavuzu, veri gelmeye başladığında tCPA’nızı gözlemlediğiniz CPA’dan %20 yüksek belirlemenizi söylüyor. Bu, hacmi nasıl kazanacağınıza dair bir tavsiye. Buna gücünüzün yetip yetmediğini yalnızca tavan söyler.

Google’da hedefsiz başlarım. 100K $’lık testimde Max Conversion Value, her iki platformda ve her pazarda tROAS’ı geçti, çünkü tROAS, Google henüz bir şey öğrenmeden hacmi kısıtlar. Tavan, sonuçları kıyasladığım çizgiydi, bir teklif girdisi değil. Hedefi ancak korunacak bir getiri olduğunda ekledim. Google’ın kendi kuralları da aynı yönü gösteriyor. App campaign’lerde tROAS için Firebase SDK gerekir ve günde en az 10 conversion veya 30 günde 300 conversion şarttır.

Bir cohort, tavana göre değerlendirilecek yaşa ne zaman gelir?

%37,4’lük bir trial’dan paid’e oranı üzerine kurulu tavan, trial’larının dönüşmeye zamanı olmuş cohort’lar için geçerli bir tavandır. Üç günlük bir cohort’u ona karşı tutarsanız her seferinde başarısız olur ve iyi giden bir kampanyayı kesersiniz. Payer başına maliyeti aynı cohort yaşında karşılaştırırım, D0’a karşı D28 çalışmasının kampanyaları karşılaştırdığı gibi ve erken rakamın geç rakamın yerini tutmasına ancak hesabın gün 0’dan gün 28’e uzanan kendi eğrisi bilindiğinde izin veririm. Cohort rutininin kendisi, aynı yaş, proceeds ve bir satın alma eşiği, hangi cohort’ların gerçekten geri ödediği yazısında.

Ters hata da aynı derecede yaygın. Gün 0 iptal oranı %85 olan ucuz bir trial başına maliyet, normal bir iptal oranındaki pahalı bir maliyetten daha kötüdür, çünkü üç günlük trial’larda iptallerin %55,4’ü gün 0’da gerçekleşiyor ve ucuz trial başlatanlar çoğunlukla iptal edenler oluyor. Tavanın payer başına olmasının nedeni tam da bu.

Bir hesap ölçeklenmeden önce hangi rakamları isterim?

1. Payer başına proceeds. Plana ve ülkeye göre fiyat, komisyon kademeniz, vergi ve refund’lar, gerçek plan karışımınıza göre blended. Sabit %30 ve brüt gelir, ikisi de tavanı yanlış yere koyar.
2. Pencere. Ne kadar bekleyebileceğiniz ve ilk ödemeden fazlasını saymayı haklı çıkaracak bir yıllık kendi renewal verinizin olup olmadığı.
3. Olgunlaşmış oranlar. Trial’dan paid’e ve kurulumdan payer’a oranlar, dönüşmeye yetecek kadar eski cohort’lardan, hacmin izin verdiği yerde ülke bazında.
4. Üç tavan. Payer başına, trial başına ve kurulum başına, komisyon kademesi veya pencere değişirse her birinin ne kadar oynayacağı.
5. Hedefe kadar boşluk. Platform hedefinin tavanın ne kadar altında durduğu ve onu daralttığınız cohort yaşı.
6. Değerlendirdiğiniz yaş. Aynı cohort yaşında payer başına maliyet, asla yalnızca platformun event’ine göre değil.

Bu altı satırı doldurabiliyorsanız ölçeklenebilirsiniz. Dolduramıyorsanız, bunları bir hesap için growth audit içinde ben dolduruyorum, o da her harcama seviyesinde tek başına alınabilir.

Kaynaklar ve kapsam

Hepsi 4 ve 5 Ekim 2026’da kontrol edildi. Mağaza koşulları sık değişir, bu yüzden bir oranı aktarmadan önce tarihe bakın. Çözümlü örnekler, adı konmuş varsayımlar üzerinde yapılan aritmetiktir, bir hesabın gerçek rakamları değil. Bağlantısını verdiğim hesap rakamlarının her biri tek bir hesaba ait, kontrollü deney değil.

• Apple: App Store Small Business Program
• Apple: Auto renewable subscriptions
• Apple: Changes for apps in the European Union, son güncelleme 18 Ağustos 2026.
• Apple: Summary sales report, App Store Connect Help.
• Apple: Overview of receiving payments, App Store Connect Help.
• Google: Service fees, Play Console Help.
• Google: Order processing and payouts, Play Console Help.
• Google: Manage your app’s orders and issue refunds, Play Console Help.
• Google: About Target CPA bidding, About Target ROAS bidding, About bidding in App campaigns ve Choose a bid strategy for your App campaign, Google Ads Help.
• Meta: About cost and bid controls, Meta Business Help Center.
• RevenueCat Docs: Taxes and commissions ve Meta Ads integration.
• RevenueCat: State of Subscription Apps 2026, 115.000 uygulama, 2025 verisi, RevenueCat’in kendi müşterileri, gözlemsel.
• Fader ve Hardie: How to Project Customer Retention, Journal of Interactive Marketing, 2007.