Paywall Tasarımı: Abonelik Dönüşümünü Artıran 9 Karar

Paywall'ı tek bir ekran gibi tasarlamak, abonelik gelirini masada bırakmanın en yaygın yoludur. Gerçekte paywall bir akıştır: kullanıcıyı ne zaman karşıladığın, fiyatı nasıl çerçevelediğin, deneme süresini nasıl kurguladığın ve iptal anında ne gösterdiğin — hepsi tek bir dönüşüm hunisinin parçası. Bu yazıda paywall tasarımı ve abonelik dönüşümü üzerine, App Store ve Google Play'in kendi resmi kurallarına dayanan dokuz somut karar veriyorum.

💡 Pro Tip: Paywall'ı "hangi buton hangi renk" sorusuyla değil, "kullanıcı bu ekranı hangi anda görüyor" sorusuyla tasarlamaya başla — zamanlama, kopyadan önce gelir.

İçindekiler

• Paywall'ı bir ekran değil akış olarak düşünmek
• Zamanlama: onboarding, değer anı, limit anı
• Fiyat sunumu ve çapa etkisi
• Deneme süresi, geri kazanım ve iptal akışı
• Mağaza kurallarının çizdiği sınırlar
• Ölçüm: dönüşüm, iptal ve doğru kohort
• Dokuz kararın kontrol listesi
• SSS
• Paywall dönüşümü nasıl artırılır?
• Hard paywall mı soft paywall mı kullanmalıyım?
• Deneme süresi dönüşümü nasıl etkiliyor?
• Win-back teklifi otomatik mi çıkıyor, yoksa kod mu yazmam gerekiyor?
• iOS ve Android'de abonelik yönetimi arayüzü aynı mı?
• Paywall'ı A/B test ederken hangi metriği önceliklendirmeliyim?
• Sonuç
• Kaynaklar

Paywall'ı bir ekran değil akış olarak düşünmek

Paywall tasarımı denince akla ilk gelen şey genelde tek bir "satış ekranı" oluyor: başlık, üç madde, buton. Ama App Store'un abonelik kuralları, paywall'ı bir sign-up akışı olarak tanımlıyor — akışın kendi zorunlu bileşenleri var. Apple'ın geliştirici dokümanına göre bir abonelik sign-up ekranında üç şey net biçimde görünmeli: aboneliğin adı ve süresi (ve abonelik döneminde sunulan içerik/hizmet), tam yenileme fiyatı açıkça ve belirgin şekilde ve kullanılabilir para birimlerinde yerelleştirilmiş olarak gösterilir, ve mevcut abonelerin giriş yapıp satın almalarını geri yükleyebileceği bir yol. Apple ayrıca ayrı bir kural olarak şunu belirtiyor: uygulaman ve App Store metadata'n ToU ve gizlilik politikası linkini içermeli — bu, sign-up ekranına değil uygulamaya/mağaza sayfasına ait.

Bu üç madde bir "checklist" değil, akışın iskeleti. Kullanıcı paywall'a geldiğinde önce ne satın aldığını, sonra ne kadar ödeyeceğini, sonra geri dönüş yolunu (restore) görmeli — bu sıralama kafa karışıklığını ve dolayısıyla terk oranını azaltır.

Zamanlama: onboarding, değer anı, limit anı

Paywall'ı ne zaman göstereceğin, akışın en önemli kararı. Apple'ın kendi terminolojisinde bir seçenek "metered paywall": kullanıcıya satın alma yapmadan önce, sınırlı bir süre boyunca sınırlı miktarda içeriğe erişim tanıyan paywall türü. Resmi tanım şöyle: "A metered paywall allows access to a finite amount of content for a specified duration before needing to make a purchase."

Bunu üç zamanlama noktasına ayırabilirsin:

• Onboarding anı: Kullanıcı hesabı açar açmaz gösterilen paywall. Avantajı basitlik, dezavantajı kullanıcının ürünün değerini henüz görmemiş olması.
• Değer anı: Kullanıcı ürünün temel faydasını bir kez deneyimledikten sonra (ör. ilk raporu oluşturduktan, ilk projeyi tamamladıktan sonra) gösterilir.
• Limit anı: Metered paywall mantığıyla, ücretsiz kullanım kotası dolduğunda gösterilir — kullanıcı zaten ürünü kullanmış, şimdi devam etmek için ödeme yapması gerekiyor.

Üçü de App Store kurallarına aykırı değil; seçim, ürünün "değer anına kadarki süresi"ne bağlı. Değer anı çok kısaysa (saniyeler içinde) onboarding'e yakın konumlandırmak mantıklı; değer anı uzun sürüyorsa limit anı daha az sürtünme yaratır çünkü kullanıcı ödeme talebini görmeden önce zaten fayda görmüştür.

Ben genelde şu basit testi kullanırım: kullanıcı uygulamayı ilk açtığında, ürünün temel faydasını üç etkileşim içinde görebiliyorsa (bir fotoğraf düzenleme uygulamasında "önce/sonra" gibi anlık bir sonuç), paywall'ı o anın hemen ardına, "değer anı" mantığıyla yerleştiriyorum. Eğer fayda ancak birkaç günlük kullanım sonrası ortaya çıkıyorsa (bir alışkanlık takip uygulamasında "7 günlük seri" gibi), erken bir hard paywall kullanıcıyı hiç bu noktaya getirmeden kaybettirir — orada limit anı veya uzun bir metered pencere daha mantıklı. Bu bir formül değil, ürünün kendi değer eğrisine bakarak verilen bir tercih.

Fiyat sunumu ve çapa etkisi

Fiyatı nasıl gösterdiğin, App Store'da isteğe bağlı bir tasarım detayı değil — kural. Apple'ın dokümanına göre: "the amount that will be billed must be the most prominent pricing element in the layout" — yani faturalanacak tutar (örneğin yıllık planın toplam tutarı) layout'taki en belirgin fiyat öğesi olmak zorunda; haftalık veya aylık eşdeğeri alt sırada gösterilmeli.

Bana göre bu, klasik çapa (anchoring) etkisiyle örtüşüyor: kullanıcı önce büyük rakamı (yıllık toplam) görür, sonra haftalık/aylık eşdeğerini "aslında küçük" olarak algılayabilir — bu benim yorumum, Apple'ın kuralı bununla ilgili bir gerekçe vermiyor. Kuralın kendisi zorunlu: dizaynı buna göre kurman gerekiyor, tercih meselesi değil.

Apple ayrıca üç indirim tipini ayırt ediyor: "Free trial... Pay as you go... Pay up front." Bu üçü farklı risk algısı yaratır:

Paywall'da hangi indirim tipini birincil CTA yaptığın, hem dönüşüm oranını hem de ilk ayki iptal oranını değiştirir — birini seçmeden önce hangi metriği optimize ettiğine karar vermelisin: kayıt sayısı mı, yoksa ödeme yapan kullanıcı sayısı mı.

Kendi tercihim, birden fazla plan gösterirken varsayılan olarak seçili gelen planı yıllık yapmak ve aylık planı ikincil bir seçenek olarak bırakmak yönünde — bu, Apple'ın çapa kuralıyla da örtüşüyor çünkü yıllık toplam zaten en belirgin fiyat öğesi olmak zorunda. Ama bunu yaparken haftalık/aylık eşdeğerini gizlemiyorum; sadece görsel hiyerarşide ikinci sıraya koyuyorum. Kullanıcının "aslında ne kadar ödeyeceğimi" anlaması için her iki bilgiye de erişimi olmalı, sadece hangisinin önce göründüğü değişiyor.

Deneme süresi, geri kazanım ve iptal akışı

Bir abonelik iptal veya ödeme sorunu nedeniyle sona erdiğinde, ödemeli hizmet günlerinin sayımı durur — Apple'ın ifadesiyle: "If a subscription expires due to a cancellation or billing issue, the days of paid service stop accumulating." 60 gün içinde yenilenirse süre kaldığı yerden devam eder; bu, o pencerede dönen kullanıcıyı sıfırdan yeni abone gibi değil, kaldığı yerden devam eden abone gibi ele almanı gerektirir.

Apple, teklif türlerini dört başlıkta topluyor ve bunları edinme/elde tutma/geri kazanma eksenine yerleştiriyor: Introductory offers, Promotional offers, Win-back offers, Offer codes. Özellikle win-back tarafında geliştiricinin işi kod yazmak değil: "A win-back offer sheet automatically appears to eligible customers within your app or game, with no additional work required." Yani sistem, uygun kullanıcıya otomatik olarak bir teklif sayfası gösteriyor — sen sadece grubu ve teklifi App Store Connect'te tanımlıyorsun.

İptal akışı tarafında ise kullanıcıya kontrolü uygulamanın içinde bırakmak, Apple'ın önerdiği bir pratik; kullanıcı deneyimini basitleştirdiği için ben de tercih ediyorum. showManageSubscriptions(in:) metoduyla kullanıcı, uygulamadan çıkmadan abonelik yönetim ekranına yönlendirilebilir — Apple'ın ifadesiyle: "You can use the showManageSubscriptions(in:) method to let them manage their subscription within your app."

1// iOS 15+: uygulama içinden abonelik yönetim ekranını göster
2import StoreKit
3import UIKit
4 
5func openSubscriptionManagement(in windowScene: UIWindowScene) async {
6    do {
7        try await AppStore.showManageSubscriptions(in: windowScene)
8    } catch {
9        // Kullanıcı ekranı kapattı veya sistem hatası — sessizce yut,
10        // gerekirse ayrı bir "Ayarlar > Abonelikler" linkine yönlendir.
11    }
12}

Google Play tarafında karşılığı bir SDK metodu değil, doğrudan bir deep link: play.google.com/store/account/subscriptions — ürün bazlı yönlendirme için ?sku=your-sub-product-id&package=your-app-package parametreleri eklenir. Bu, Apple'ın uygulama-içi yönetim ekranına kıyasla bir fark noktası: Android'de kullanıcıyı Play Store'a yönlendirirsin, uygulama içinde kalan bir yönetim yüzeyi yok.

1// Android: abonelik yönetim ekranına deep link
2fun openSubscriptionManagement(context: Context, sku: String, packageName: String) {
3    val uri = Uri.parse(
4        "https://play.google.com/store/account/subscriptions" +
5        "?sku=$sku&package=$packageName"
6    )
7    context.startActivity(Intent(Intent.ACTION_VIEW, uri))
8}

Mağaza kurallarının çizdiği sınırlar

Paywall tasarımı sadece görsel bir egzersiz değil, mağaza gelir modeliyle de iç içe. Apple'da komisyon oranı aboneliğin yaşına göre değişiyor: "During a subscriber's first year of service, you receive 70%... After a subscriber accumulates one year of paid service, your net revenue increases to 85%." Small Business Program'da bu eşik yok — "you receive 85% of the subscription price at each billing cycle... regardless of whether or not the subscription has accumulated one year of paid service." Aylık ve yıllık planlarda eşik aynı: her ikisinde de bir yıllık ödemeli hizmet süresi dolmadan %85'e geçilmiyor; fark hızda değil; ben aylık planda abonenin bu süreye ulaşmadan ayrılma olasılığını daha yüksek görüyorum. Ayrıca ücretsiz denemeler ve yenileme uzatmaları bu bir yıllık ödemeli hizmet süresine sayılmıyor: "Free trials and renewal extensions are excluded from days of paid service."

Apple ayrıca "Renewal Date Extension" adında bir esneklik sunuyor: yılda en fazla iki kez, her biri en fazla 90 gün olacak şekilde yenileme tarihini uzatabilirsin — ama bu günler %85 eşiğine sayılmaz: "move the renewal date...twice per calendar year, each up to 90 days...won't count toward the one year of paid service."

Google Play tarafında ise paywall'ı etkileyen asıl sınır, Billing Library (PBL) sürüm zorunluluğu. 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Billing Library v8 veya üstünü kullanmak zorunda; daha fazla süreye ihtiyaç duyanlar için uzatma penceresi 1 Kasım 2026'da sona eriyor. Google'ın resmi deprecation tablosuna göre:

1 Kasım 2026'dan itibaren asgari zemin v8 olacak; v7'nin uzatma penceresi o tarihte sona erdiğinde artık kabul edilmeyecek. Pratikte kütüphanenin kendisi zaten çok ileride: Play Billing Library 9.0.0 19 Mayıs 2026'da, 9.1.0 ise Billing Choice API'leri ile birlikte 18 Haziran 2026'da yayınlandı. Yani paywall'ını yeni kuruyorsan doğrudan 9.x ile başlaman, v8'i "asgari uyumluluk" olarak değil "zaten geride kalmış eşik" olarak görmen daha doğru bir çerçeve.

Play tarafında paywall tasarımını etkileyen bir başka detay: prepaid planlar otomatik yenilenmiyor. "Prepaid plans do not automatically renew upon expiration." Top-up (bakiye yükleme) akışı için de ayrı bir kural var: "Prepaid plan top-ups always use the CHARGE_FULL_PRICE replacement mode, and you don't need to set this mode explicitly." Yani prepaid bir plan sunuyorsan, kullanıcıya süre dolmadan önce "top-up" (bakiye yükleme) akışını paywall'ın bir parçası olarak tasarlaman gerekiyor — sistem bunu senin için otomatik yapmıyor. Prepaid onay süresi de plan uzunluğuna bağlı: bir hafta veya daha uzun planlarda 3 gün içinde, bir haftadan kısa planlarda sürenin yarısında onaylanmalı.

Ölçüm: dönüşüm, iptal ve doğru kohort

Paywall'ı ölçerken en büyük hata, tek bir "dönüşüm oranı" sayısına bakmak. Apple ve Google, dönüşüm/LTV için kendi yayınladıkları somut bir sayısal benchmark vermiyor — Apple'ın kendi tavsiyesi nitel: paywall varyantlarını test edip etkisini ölçmen gerektiğini söylüyor, kesin bir hedef rakam sunmuyor. O yüzden ölçüm kurgusuna odaklan.

Apple tarafında "Get All Subscription Statuses" API'si tek bir çağrıda aboneliğin durumunu belirlemeni sağlıyor: "determine in one simple check whether a subscription is active, expired, in billing retry, or in grace period." Bu dört durum, paywall sonrası huninin doğru kohortlanması için kritik — "aktif abone" ile "billing retry'de bekleyen abone"yi aynı kovaya koyarsan dönüşüm oranını yanlış hesaplarsın.

Google Play tarafında karşılığı subscriptionsv2.get — durumun "source of truth"ı bu uç nokta: "considered the source of truth for subscription management." Purchase token, abonelik bitişinden 60 gün sonrasına kadar geçerliliğini koruyor — bu süre, Play Developer API ile durumu sorgulayabileceğin süredir (Apple'ın 60 günlük hizmet-devam kuralıyla karıştırılmasın).

1# Google Play: abonelik durumunu source-of-truth uç noktasından sorgula
2curl -s -X GET \
3  "https://androidpublisher.googleapis.com/androidpublisher/v3/applications/$PACKAGE_NAME/purchases/subscriptionsv2/tokens/$PURCHASE_TOKEN" \
4  -H "Authorization: Bearer $ACCESS_TOKEN"

Yeni bir satın alma geldiğinde acknowledgementState alanı ACKNOWLEDGEMENT_STATE_PENDING olarak gelir; onay bekleyen bu durum, dönüşüm ölçümünde "teknik olarak satın alınmış ama henüz onaylanmamış" satın almaları ayrı bir kovada tutmanı gerektirir — aksi halde huninin son adımını olduğundan yüksek gösterirsin.

Ayrıca taksitli (installment) bir abonelikte, taahhüt süresi boyunca ödemesi kalan bir dönemde kullanıcı iptal talep ettiğinde, SUBSCRIPTION_CANCELLATION_SCHEDULED bildirimi iptal talebi alındığında gönderilir. İptal huninde "iptal talebi" ile "gerçek dönem sonu"nu aynı olay sanmak, churn tarihini yanlış kohortlara dağıtır.

Dokuz kararın kontrol listesi

Yukarıdaki bulguları tek bir uygulanabilir listeye topluyorum — her karar bir önceki bölümden çıkıyor, sıra dizaynda karşılaşacağın sırayla:

• Akış iskeleti: Sign-up ekranında ad+süre, tam yenileme fiyatı, restore linki her zaman görünür olsun; ToU/Privacy linki uygulaman ve App Store metadata'nda yer alsın.
• Zamanlama seçimi: Değer anının ne kadar sürdüğüne göre onboarding/değer-anı/limit-anı (metered) arasında bilinçli seç, varsayılanı kopyalama.
• Çapa fiyat: Faturalanacak tutarı (yıllık toplam gibi) layout'ta en belirgin öğe yap; haftalık/aylık eşdeğeri alt sırada göster.
• İndirim tipi netliği: Free trial / pay as you go / pay up front arasında hangisinin birincil CTA olduğuna, hangi metriği optimize ettiğine göre karar ver.
• Win-back tasarımı: sistem uygun kullanıcıya otomatik teklif sheet'i gösteriyor, sen deneyimi buna göre kurgula; iptal/ödeme sorunu sonrası 60 gün içinde dönen kullanıcının ödemeli hizmet süresi kaldığı yerden devam eder.
• Uygulama içi yönetim: iOS'ta showManageSubscriptions(in:), Android'de Play Store deep link — platform farkını arayüze yansıt.
• Komisyon farkındalığı: %70→%85 eşiğinin veya Small Business Program'ın fiyatlandırma stratejine etkisini hesapla.
• PBL sürüm zemini: v8'i asgari zemin olarak bil (v7 penceresi 1 Kasım 2026'da sona eriyor) ama pratikte 9.x'in gerisinde kalma; prepaid top-up akışını ayrı tasarla.
• Kohort doğruluğu: Aktif/expired/billing-retry/grace-period durumlarını ve onay-bekleyen satın almaları ayrı kovalarda ölç.

SSS

Paywall dönüşümü nasıl artırılır?

Apple ve Google, dönüşüm için genel geçer bir sayısal hedef yayınlamıyor; Apple'ın kendi önerisi paywall varyantlarını test edip ölçmek. Pratikte artış, tek bir "büyülü değişken"den değil akışın bütününden gelir: doğru zamanlama (onboarding/değer anı/limit anı), kurallara uygun fiyat çapası (faturalanacak tutarın en belirgin öğe olması) ve doğru indirim tipi seçiminin birlikte çalışmasından. Bu üçünü ayrı ayrı test edip hangisinin senin kullanıcı tabanında etkili olduğunu ölç.

Hard paywall mı soft paywall mı kullanmalıyım?

Apple'ın dokümantasyonu "metered paywall" kavramını tanımlıyor — sınırlı süre/miktar erişim sonrası satın alma isteme. Hard/soft ayrımı resmi bir mağaza terimi değil, ürün stratejisi kararı: hard paywall kullanıcıyı hiç değer görmeden ödemeye yönlendirir, soft/metered paywall önce sınırlı bir deneyim sunar. Hangisinin doğru olduğu, ürünün değer anına ne kadar hızlı ulaştığına bağlı.

Deneme süresi dönüşümü nasıl etkiliyor?

Apple'ın resmi dokümanı deneme süresi uzunluğu ile dönüşüm arasında sayısal bir ilişki yayınlamıyor; yalnızca "free trial" indirim tipini "pay as you go" ve "pay up front" ile birlikte tanımlıyor. Deneme süresinin etkisini ölçmek istiyorsan, kendi kullanıcı tabanında A/B testi yap; tek bir evrensel "en iyi deneme süresi" yoktur.

Win-back teklifi otomatik mi çıkıyor, yoksa kod mu yazmam gerekiyor?

App Store'da win-back teklifleri otomatik: uygun kullanıcıya ek bir geliştirme yapmadan bir teklif sayfası (offer sheet) gösteriliyor. Senin işin App Store Connect'te grubu ve teklifi tanımlamak; sunum akışını sistem yönetiyor.

iOS ve Android'de abonelik yönetimi arayüzü aynı mı?

Hayır. iOS'ta showManageSubscriptions(in:) ile kullanıcıyı uygulama içinde bırakan bir yönetim ekranı açabilirsin. Android'de karşılığı bir SDK ekranı değil, Play Store'a giden bir deep link (play.google.com/store/account/subscriptions) — kullanıcı uygulamadan çıkıp Play Store'a yönlendirilir.

Paywall'ı A/B test ederken hangi metriği önceliklendirmeliyim?

Bu bir ürün stratejisi kararı; Apple yalnızca test edip ölçmeyi öneriyor, hangi metriği önceliklendireceğini söylemiyor. Pratik yaklaşım: önce tek bir birincil metrik seç (ör. ödeme yapan kullanıcı sayısı, ilk 30 günlük gelir, ya da net iptal oranı), ikincil metrikleri (deneme başlatma oranı gibi) sadece bağlam için izle. Aksi halde her varyant "bir metrikte iyi, diğerinde kötü" çıkar ve karar veremezsin.

Sonuç

Paywall tasarımı; akış iskeleti, zamanlama, fiyat çapası, indirim tipi, win-back penceresi, platform-özel yönetim arayüzü, komisyon farkındalığı, mağaza sürüm zemini ve doğru kohortlama olmak üzere dokuz kararın toplamı. Bu kararların hiçbiri izole değil — birini değiştirmek diğerini etkiler (ör. indirim tipi seçimi, ölçtüğün birincil metriği değiştirir).

Teknik uygulama tarafında StoreKit 2 ile modern IAP akışını kurmak istiyorsan StoreKit 2 ile Modern In-App Purchase makalesine, production-seviyesinde async/await ile IAP mimarisi için StoreKit 2 Production Rehberi yazısına bakabilirsin. App Store Connect'te offer code, family sharing ve winback tekliflerini nasıl kuracağını App Store Connect Subscriptions makalesinde anlattım. Android tarafında, artık eski sürüm zeminini anlatan Google Play Billing Library v7 rehberine (31 Ağustos 2026'dan itibaren asgari zemin v8'dir, bu yazı o geçiş dönemini anlatır) ya da iOS ve Android'i tek SDK ile yönetmek için RevenueCat Cross-Platform Subscription yazısına göz atabilirsin. Gelir tarafında gerçek rakamlarla bir vaka incelemesi için $1M Kazandım: Gerçek Strateji ve Rakamlar makalesi de bu yazıyı tamamlıyor.

Kaynaklar

• Apple Developer — App Store Subscriptions — sign-up ekranı kuralları, komisyon oranları, teklif türleri, win-back ve Renewal Date Extension resmi tanımları.
• Android Developers — Play Billing Deprecation FAQ — PBL sürüm zorunluluğu takvimi (v6/v7/v8/v9 deadline tablosu).
• Android Developers — Play Billing Release Notes — PBL 8.x/9.x sürüm tarihleri ve yeni API'ler.
• Android Developers — Google Play Billing Subscriptions — prepaid plan davranışı, installment abonelikler, yönetim deep link'i, iptal bildirimleri.
• Android Developers — Subscriptions Lifecycle — subscriptionsv2.get source-of-truth tanımı ve purchase token geçerlilik süresi.