Abonelik Fiyatlandırma Stratejisi: Fiyat ve Teklifler

Abonelik fiyatlandırması tek bir sayı seçmek değil; fiyat, süre ve paket kararlarının birlikte kurgulandığı bir sistemdir. Yanlış kurgulanan bir trial süresi ya da eksik katman yapısı, iyi bir ürünü bile düşük dönüşümle cezalandırır. Bu yazıda abonelik fiyatlandırma stratejisi, paywall trial kararı ve App Store/Play Store'un resmi teklif mekanizmalarını (introductory, promotional, win-back, offer code) uygulama tipine göre nasıl kurgulayacağını adım adım göreceksin.

💡 Pro Tip: Fiyatı belirlemeden önce hangi teklif tipini (introductory mi, offer code mi) kullanacağına karar ver — çünkü Apple ve Google'da her teklif tipinin süre, tekrarlanabilirlik ve hedef kitle kısıtları farklı, ve bu kısıtlar geriye dönük fiyat kararını da şekillendirir.

İçindekiler

• Fiyatlandırmanın Üç Değişkeni: Fiyat, Süre, Paket
• Fiyat Noktası
• Süre
• Paket
• Aylık/Yıllık/Lifetime Katman Kurgusu
• Trial Uzunluğu Kararı
• Teklif Tipleri: Introductory, Promotional, Win-Back, Offer Code
• Introductory Offer
• Promotional Offer
• Offer Code
• Win-Back Offer
• Android Tarafı: Play Billing Base Plan ve Offer
• Bölgesel Fiyatlandırma ve TL Kararı
• Fiyat Değişikliği ve Zam: Mevcut Abonelere Etki
• Apple'da Fiyat Düşüşü ve Artışı
• Google Play'de Fiyat Değişikliği
• Ölçülecek Metrikler: Trial→Paid, Churn, LTV
• Karar Rehberi: Uygulama Tipine Göre Başlangıç Paketi
• SSS
• Abonelik fiyatını nasıl belirlemeliyim?
• Ücretsiz deneme kaç gün olmalı?
• Paywall'ı onboarding'in neresine koymalıyım?
• Fiyat testi App Store'da nasıl yapılır?
• Introductory offer ile offer code aynı kullanıcıya art arda uygulanabilir mi?
• Sonuç
• Kaynaklar

Fiyatlandırmanın Üç Değişkeni: Fiyat, Süre, Paket

Abonelik fiyatlandırma kararı üç bağımsız değişkenin kesişimidir: fiyat noktası (kullanıcının ödediği tutar), süre (deneme, faturalama periyodu, teklif süresi) ve paket (hangi özelliklerin hangi katmanda olduğu). Bu üçü ayrı ayrı optimize edilmez — birlikte test edilir.

Fiyat Noktası

App Store Connect, tüm para birimleri ve fiyat kademeleri genelinde 800 fiyat noktası sunar; talep üzerine 100 ek yüksek fiyat noktası da eklenebilir. Bu, "9,99₺ mi 12,99₺ mü" sorusunun aslında yüzlerce olası cevabı olduğu anlamına gelir — karar, rastgele bir sayı seçmek değil, rakip analizine ve hedef LTV'ye dayalı bir aralık daraltmasıdır.

Süre

Süre değişkeni yalnız "aylık mı yıllık mı" değildir; trial süresi, offer süresi ve faturalama periyodu birbirinden bağımsız ayarlanır. Apple'ın pay-as-you-go indirim türünde örneğin standart yenileme fiyatı 9,99$/ay olan bir abonelik için 3 ay boyunca 1,99$/ay uygulanabilir, süre bitince standart fiyata dönülür. Bu üç ayrı kararın (fiyat, indirim oranı, süre) her biri paywall dönüşümünü farklı yönde etkiler.

Paket

Paket kararı, hangi özelliğin ücretsiz katmanda, hangisinin ücretli katmanda kalacağını belirler. Bu yazı paket-içi özellik dağılımından çok fiyat/süre eksenine odaklanıyor; paywall ekranının kendisinin nasıl tasarlanacağı (buton yerleşimi, sosyal kanıt, karşılaştırma tablosu) ayrı bir konu — bunu paywall tasarımı ve abonelik dönüşümü yazısında ele alıyorum.

Aylık/Yıllık/Lifetime Katman Kurgusu

Çoğu abonelik uygulaması aylık ve yıllık iki katman sunar; bazıları lifetime (tek seferlik) seçeneği ekler. Bu üç modelin ticari mantığı farklıdır:

• Aylık: Düşük giriş bariyeri, yüksek churn riski. Kullanıcı her ay yeniden karar verir.
• Yıllık: Peşin tahsilat, LTV'yi öne çeker ama iptal-sonrası-iade beklentisi (App Store/Play iade politikaları) riskini büyütür.
• Lifetime: Tekrarlayan gelir yaratmaz; yalnız tek seferlik ödeme tercih eden kullanıcı segmentini (aboneliğe güvenmeyen, "bir kere öde bitsin" diyen) yakalamak için kullanılır — çoğu abonelik-öncelikli uygulama bunu ana teklif değil, yan seçenek olarak sunar.

Karar burada ikili değil: aylık/yıllık fiyat oranı (yıllık fiyatın aylık fiyata bölümü kaç ay eder) kullanıcıya hangi paketin "daha avantajlı" göründüğünü belirler. Paywall ekranında yıllık paketin altına "aylığa göre X ay bedava" gibi bir karşılaştırma metni koymak yaygın bir pratik ama bunun tasarımı paywall tasarımı ve abonelik dönüşümü yazısının konusu.

Trial Uzunluğu Kararı

Apple'da free trial süresi 3 gün, 1 hafta, 2 hafta, 1 ay, 2 ay, 3 ay, 6 ay veya 1 yıl olarak seçilebilir — bu sabit bir liste, aradaki değerler (ör. 10 gün) desteklenmez. Satın alma akışında trial süresinin ve trial bitince kesilecek fiyatın açıkça belirtilmesi gerekiyor.

Trial uzunluğu kararını üç faktör belirler:

• Değer gösterme süresi: Kullanıcının ürünün asıl faydasını (ör. bir haftalık alışkanlık takibi, bir aylık dil öğrenme ilerlemesi) deneyimlemesi için gereken minimum süre.
• Faturalama döngüsüyle hizalama: Haftalık bir ürün için 3 günlük trial, aylık bir ürün için 1 haftalık trial daha tutarlı bir "deneme → ilk fatura" hikayesi kurar.
• İptal sürtünmesi: Daha uzun trial, kullanıcının "unutup" ilk faturayı ödemesi ihtimalini artırır ama aynı zamanda ilk hafta içinde iptal eden kullanıcı oranını da yükseltebilir çünkü değer henüz görülmeden karar verilir.

Bu karar yalnızca fiyat/süre eksenindedir — trial'ın paywall ekranında nasıl sunulacağı (öncesinde mi sonrasında mı, kartlı mı listeli mi) paywall tasarımı ve abonelik dönüşümü yazısına bırakılmıştır.

Teklif Tipleri: Introductory, Promotional, Win-Back, Offer Code

Apple'ın App Store Connect'inde dört ayrı teklif mekanizması var; her biri farklı bir kullanıcı segmentini hedefler ve farklı kısıtlara tabidir. StoreKit 2 ile bu tekliflerin nasıl kodda ele alınacağını StoreKit 2 ile Modern In-App Purchase ve StoreKit 2 Production Rehberi yazılarında; App Store Connect tarafındaki kurulumu App Store Connect Subscriptions: Offer Codes, Family Sharing, Winback yazısında bulabilirsin. Burada yalnız fiyatlandırma-stratejisi açısından farklarına odaklanıyorum.

Introductory Offer

Yeni abonelerin tam fiyatı ödemeden önce aboneliği deneyimlemesini sağlar. Kısıtı net: bir müşteri, bir abonelik grubu başına yalnızca bir kez introductory offer kullanabilir. Yani aynı gruptaki farklı bir plana geçse bile ikinci kez introductory fiyat alamaz — bu, "her yeni ürün lansmanında eski aboneye tekrar giriş fiyatı verme" taktiğinin işe yaramayacağı anlamına gelir.

Promotional Offer

Mevcut veya eski abonelere, geliştiricinin belirlediği iş mantığına göre belirli süreli ücretsiz veya indirimli fiyat sunar. Bir abonelik için en fazla 10 aktif promotional offer tanımlanabilir. Tipik kullanım alanları: iptal etmiş bir aboneye yükseltilmiş abonelikte özel fiyat, uzun süredir yenileyen sadık bir aboneye bir ay ücretsiz, ya da düzensiz kullanan bir aboneye indirimli bir ay.

Offer Code

Offer code'lar App Store'da veya uygulama içinde kullanılabilen, alfanümerik kodlardır ve iki türde oluşturulur: tek kullanımlık 18 haneli kodlar, veya "SPRINGPROMO" gibi özel (custom) kodlar. Kullanım alanları e-posta kampanyaları, basılı materyaller, iş ortaklıkları, müşteri hizmetleri telafisi ve eski-uygulamadan-yeni-uygulamaya geçiş kampanyalarıdır. Kod, https://apps.apple.com/redeem?id=UygulamaAppleID&code=OfferCode formatında bir URL'e bağlanarak da dağıtılabilir.

Win-Back Offer

Aboneliği süresi dolmuş ve otomatik yenilemeyi kapatmış eski abonelere ulaşmayı kolaylaştırır. Bu teklif; App Store ürün sayfasında, uygulama içi otomatik teklif sayfasında, kullanıcının Apple hesabı abonelik ayarlarında veya doğrudan bir bağlantı (ör. e-posta) üzerinden keşfedilebilir. App Store Connect'te win-back offer kurgularken teklif detaylarını ve teklif önceliğini (birden fazla win-back offer varsa hangisinin öncelikli gösterileceğini) belirlersin.

1{
2  "offerTypes": {
3    "introductory": {
4      "limit": "abonelik grubu başına 1 kez",
5      "discountTypes": ["pay_as_you_go", "pay_up_front", "free"],
6      "freeTrialDurations": ["3d", "1w", "2w", "1mo", "2mo", "3mo", "6mo", "1y"]
7    },
8    "promotional": {
9      "limitPerSubscription": 10,
10      "audience": "mevcut veya eski abone"
11    },
12    "offerCode": {
13      "codeTypes": ["one_time_use_18_digit", "custom_code"],
14      "redeemUrl": "https://apps.apple.com/redeem?id={appleId}&code={offerCode}"
15    },
16    "winBack": {
17      "audience": "süresi dolmuş + auto-renew kapalı eski abone",
18      "config": "priority sırası App Store Connect'te belirlenir"
19    }
20  }
21}

Android Tarafı: Play Billing Base Plan ve Offer

Google Play tarafında eşdeğer mekanizma base plan + offer yapısıdır: aynı abonelik ürünü için birden çok konfigürasyon tanımlanır — örneğin hiç abone olmamış kullanıcılar için bir introductory offer, zaten abone olan kullanıcılar için ayrı bir upgrade offer. Bu mimari kodda nasıl ele alınır sorusunun cevabı Google Play Billing Library v7: Android Subscription 2026 yazısında; cross-platform (iOS+Android tek SDK) yaklaşımı ise RevenueCat Cross-Platform Subscription yazısında.

Önemli bir uyum takvimi notu: 31 Ağustos 2026 itibarıyla tüm yeni uygulamalar ve mevcut uygulama güncellemeleri Play Billing Library v8 veya üstünü kullanmak zorunda; ek süre gerekiyorsa uzatma talebiyle 1 Kasım 2026'ya kadar erteleme alınabilir. Bu ek süre de dolduğu için, yeni başlayan projelerde v8 altı bir sürümle fiyatlandırma/teklif mimarisi kurmak önerilmez.

1// Play Billing: base plan + offer kavramsal ilişkisi (queryProductDetails üzerinden okunur)
2val subscriptionOfferDetails = productDetails.subscriptionOfferDetails
3subscriptionOfferDetails?.forEach { offer ->
4    val basePlanId = offer.basePlanId      // ör. "monthly-base"
5    val offerId = offer.offerId            // null ise base plan'ın kendisi (offer'sız)
6    val pricingPhases = offer.pricingPhases.pricingPhaseList
7    // pricingPhases: introductory faz(lar) + standart yenileme fazı sırayla gelir
8}

Fiyat değişikliği yönetimi de API üzerinden programatik yapılır: monetization.subscriptions.patch çağrısı, basePlans koleksiyonu altındaki RegionalBasePlanConfig nesnesinde yeni fiyatı ayarlar. Mevcut aboneleri güncel fiyata taşımak (varsayılan olarak taşınmazlar, "legacy price cohort"ta kalırlar) ayrı bir çağrı gerektirir: monetization.subscriptions.basePlans.migratePrices. Pratik sonucu şu: fiyatı patch ile güncellemen mevcut aboneyi etkilemez; onları taşımak ayrı ve bilinçli bir migratePrices çağrısı ister.

Bölgesel Fiyatlandırma ve TL Kararı

App Store Connect'in fiyatlandırma aracı, güncel döviz kurlarına göre fiyatları yönetmene yardımcı olur. Bir bölgede vergi ya da kur değişikliği olduğunda abonelik fiyatı genellikle otomatik değişmez — bunu yansıtmak geliştiricinin kararıdır. Burada kritik nokta: hangi pazarların vergi dahil (tax inclusive) fiyatlandığını bilmeden fiyat değiştirmemek. Örneğin Almanya'da fiyatı düşürürsen elde edeceğin gelir, satış fiyatından AB KDV'si ve Apple'ın komisyonu düşülerek hesaplanır — yani ekrandaki fiyat ile cebine giren tutar aynı oranda değişmez.

TL fiyatlandırma kararı için pratik yaklaşım şu üç adımdır:

1. Referans pazarı seç — genelde ABD fiyatı temel alınır, TL fiyat App Store Connect'in otomatik kur eşleşmesiyle önerilen kademeye yakın tutulur.
2. Satın alma gücü paritesini gözden geçir — App Store Connect fiyatlandırma aracı güncel döviz kurlarına göre öneri üretir ("The App Store Connect pricing tool can help you manage pricing based on current exchange rates"); TL fiyatını bu öneriye mahkûm değilsin, 800 fiyat noktası içinden yerel pazara uygun kademeyi elle seçebilirsin.
3. Vergi rejimini teyit et — Apple Developer Program Lisans Sözleşmesi'nin Schedule 2 ekinde farklı vergi rejimine sahip bölgeler tanımlanır; TL fiyatındaki net gelir hesabı için bu tabloyu kontrol etmeden yüzde varsayımı yapma.

1TL fiyat karar akışı (fiyat/süre ekseni — paket içeriği bu adımın dışında)
21. Referans fiyat noktasını seç (ör. ABD kademesi)
3   → App Store Connect / Play Console otomatik TL karşılığını önerir
42. ASC önerisinden sapma kararı: yerel satın alma gücüne göre kademe indir mi? (evet/hayır)
5   → evet ise: önerilen TL fiyatından yerel kademeye in
63. Vergi rejimini kontrol et (tax inclusive mi?)
7   → net gelir = ekran fiyatı − yerel KDV − platform komisyonu
84. Fiyatı yayınla, cohort etkisini not al (bkz. sonraki bölüm: mevcut abonelere etki)

Play tarafında da benzer bir mantık geçerli: bölgesel fiyat, RegionalBasePlanConfig üzerinden ayrı ayrı tanımlanır ve fiyat değişikliği API çağrısı (monetization.subscriptions.patch) bölge kodu olarak üst-bölge kodlarını (ör. "US") kullanmayı bekler — alt-bölge/territory kodları (ör. "PR") hataya yol açar.

Fiyat Değişikliği ve Zam: Mevcut Abonelere Etki

Fiyat artırma kararı, mevcut abonelere nasıl yansıyacağı sorusundan ayrı düşünülemez. Apple ve Google bu konuda farklı ama net kurallar tanımlıyor.

Apple'da Fiyat Düşüşü ve Artışı

Fiyat düşürüldüğünde mevcut aboneler otomatik olarak yeni düşük fiyattan yenilenir — yüksek fiyatı koruma seçeneği yoktur, aboneye bildirim gitmez ve herhangi bir aksiyon gerekmez.

Fiyat artırıldığında ise Apple otomatik olarak push bildirimi, e-posta ve uygulama içi mesajla aboneleri bilgilendirir. Bazı artışlarda abonenin opt-in onayı (açıkça kabul etmesi) gerekir; küçük ve seyrek artışlarda ise yalnızca bildirim yeterli, onay istenmez. Onay gereken durumda abone kabul etmezse, mevcut faturalama döngüsü sonunda abonelik sona erer.

Geliştirici, sınırsız sayıda mevcut aboneyi eski fiyatında tutup yalnızca yeni abonelere yüksek fiyat uygulamayı seçebilir — Apple bunu doğrudan bir örnekle anlatıyor: 2024'te abone olanlar 3,99$, 2023 kohortu 2,99$, 2022 kohortu 1,99$ ödemeye devam edebilir. Birden fazla fiyat kohortunu tek fiyata toplamak istiyorsan, güncel fiyata en yakın kohorttan başlaman öneriliyor (örneğin önce 2,99$→3,99$, sonra bir sonraki en yakın kohort) — Apple'ın gerekçesi net: böylece aynı abone birden fazla kez fiyat artışı yaşamaz.

Google Play'de Fiyat Değişikliği

Play tarafında mantık biraz farklı kurgulanmış: fiyat artışında varsayılan davranış, mevcut aboneleri "legacy price cohort"ta bırakmaktır — yani sen fiyatı değiştirsen bile mevcut abone otomatik olarak yeni fiyata geçmez, sen ayrıca migratePrices çağırmadıkça eski fiyatında kalır.

• Opt-in artış (varsayılan): Kullanıcının yeni fiyatı açıkça kabul etmesi gerekir. Bildirim süreci 37 gün önceden başlar, ilk yenilemeden 30 gün önce otomatik bildirimler devreye girer; kullanıcı kabul etmezse abonelik otomatik iptal olur.
• Opt-out artış: Yalnız belirli ülkelerde ve tutar/sıklık kısıtlarına tabi olarak sunulur; kullanıcı iptal etmedikçe yeni fiyattan tahsilat yapılır, bildirim süresi ülkeye göre 30 veya 60 gündür.
• Fiyat düşüşü: Kullanıcılara e-posta ile bildirim yapılır, yeni (düşük) fiyat bir sonraki yenilemede uygulanır.

1Play Developer API — fiyat değişikliği İKİ AYRI çağrı gerektirir (kavramsal akış, gerçek yöntem adları):
2 
31) monetization.subscriptions.patch
4   → Yeni fiyat, "basePlans" koleksiyonu altındaki RegionalBasePlanConfig içinde ayarlanır.
5   → Mevcut aboneyi ETKİLEMEZ; yalnız yeni satın alma akışına uygulanır.
6 
72) monetization.subscriptions.basePlans.migratePrices
8   → Mevcut aboneleri güncel fiyata taşır; bölge parametresi ÜST bölge kodu olmalı
9     (ör. "US"), alt-bölge/territory kodu (ör. "PR") hataya yol açar.
10   → Bu çağrı, kullanıcıya yönelik fiyat değişikliği bildirimlerini otomatik tetikler.

Pratik sonucu şu: fiyatı patch ile güncellemen mevcut aboneyi etkilemez; onları taşımak ayrı ve bilinçli bir migratePrices çağrısı ister.

Ölçülecek Metrikler: Trial→Paid, Churn, LTV

Fiyat/süre/paket kararı verdikten sonra iş bitmiyor — kararın doğruluğunu birkaç metrikle takip etmen gerekiyor. Bu metrikler için hazır sektör ortalaması vermiyorum; her ekip kendi verisiyle doldurur:

• Trial→paid dönüşüm oranı: Trial başlatan kullanıcıların kaçının ilk faturayı ödediği. Bu oran, trial süresinin "değer göstermeye yeterli" olup olmadığının en direkt göstergesidir.
• Churn (kayıp) oranı: Aylık/yıllık bazda abonelikten çıkan kullanıcı oranı. Fiyat artışı sonrası opt-in onay oranı düşükse (Apple/Google'ın bildirim mekanizmasından geçen abone sayısı azsa), bu doğrudan churn'e yansır.
• LTV (yaşam boyu değer): Faturalama periyodu × ortalama abonelik süresi × net fiyat (komisyon ve vergi sonrası). Yıllık/aylık paket oranını değiştirdiğinde bu metrik hangi yönde hareket ediyor, izlemen gereken temel sinyal budur.
• Fiyat kohortu dağılımı: Zam sonrası kaç abone eski (legacy/grandfathered) fiyatta kaldı, kaçı yeni fiyata geçti veya ayrıldı. Apple'ın kademeli zam tavsiyesi (en yakın kohorttan başla) bu dağılımı yönetmek içindir.

Bu metriklerin hiçbiri tek başına karar verdirmez — trial→paid yüksek ama churn de yüksekse, sorun trial'da değil paket içeriğinde ya da fiyat/değer algısında olabilir.

Karar Rehberi: Uygulama Tipine Göre Başlangıç Paketi

Aşağıdaki tablo, uygulama tipine göre hangi fiyat/süre/teklif kombinasyonunun başlangıç noktası olarak daha tutarlı olduğunu özetler — kesin kural değil, üç değişkeni (fiyat, süre, paket) birlikte düşünmen için bir çerçeve.

Bu tablo yalnız başlangıç noktasıdır — nihai karar, kendi trial→paid ve churn verinle doğrulanmalı.

SSS

Abonelik fiyatını nasıl belirlemeliyim?

Fiyatı tek bir sayı olarak değil, referans pazar + fiyat noktası + bölgesel parite üçlüsü olarak belirle. App Store Connect'te 800 fiyat noktası (talep üzerine 100 ek) arasından seçim yaparsın; TL fiyatını doğrudan kur çevirisiyle değil, satın alma gücü paritesi ve vergi rejimini kontrol ederek sabitle. Rakip fiyatlarını ve hedef LTV'ni referans alarak dar bir aralık belirle, sonra o aralıkta test et.

Ücretsiz deneme kaç gün olmalı?

Apple'da seçebileceğin sabit süreler 3 gün, 1 hafta, 2 hafta, 1 ay, 2 ay, 3 ay, 6 ay ve 1 yıldır — aradaki bir değeri (ör. 10 gün) seçemezsin. Kararı, kullanıcının ürünün asıl faydasını deneyimlemesi için gereken minimum süreye göre ver: günlük alışkanlık ürünlerinde kısa (3-7 gün), ilerleme gerektiren ürünlerde (dil öğrenme gibi) orta (1-2 hafta) bir trial daha tutarlıdır.

Paywall'ı onboarding'in neresine koymalıyım?

Bu, fiyat/süre kararından ayrı bir tasarım sorusudur — paywall'ın konumu, buton yerleşimi ve akış kararı paywall tasarımı ve abonelik dönüşümü yazısının konusu. Bu yazının konusu yalnızca paywall'da hangi fiyat/süre/teklifin gösterileceğidir, ekranın nereye yerleştirileceği değil.

Fiyat testi App Store'da nasıl yapılır?

App Store Connect'in resmi dokümantasyonunda native bir A/B fiyat testi aracı tanımlanmıyor — fiyatlandırma aracı, güncel döviz kuruna göre fiyat önerir ve fiyat noktaları arasında seçim yaptırır, ama otomatik kohort testi yapmaz. Uygulamada fiyat denemesi yapmak istiyorsan bunu genelde üçüncü parti abonelik yönetim SDK'ları (ör. RevenueCat cross-platform kurulumu) üzerinden, kullanıcı segmentlerine farklı fiyat noktası göstererek manuel kurgularsın — bu, Apple'ın kendi sunduğu bir özellik değildir.

Introductory offer ile offer code aynı kullanıcıya art arda uygulanabilir mi?

Hayır — introductory offer bir abonelik grubu başına müşteri başına yalnızca bir kez kullanılabilir; aynı gruptaki başka bir plana geçse de ikinci kez introductory fiyat alamaz. Offer code ise ayrı bir mekanizmadır ve farklı kısıtlara (tek kullanımlık veya özel kod, App Store Connect'te tanımlanan geçerlilik) tabidir — ikisini karıştırmadan, hangi teklifin hangi segmenti (yeni abone vs. geri kazanılacak eski abone) hedeflediğini net ayırman gerekir.

Sonuç

Abonelik fiyatlandırması; fiyat noktası, süre ve paket kararlarının birlikte kurgulandığı, tek seferlik değil sürekli gözden geçirilen bir sistemdir. Apple'ın introductory/promotional/offer code/win-back teklif dörtlüsü ve Google'ın base plan + offer mimarisi, bu kararları teknik olarak uygulamanın resmi yollarıdır — ama hangi teklifi ne zaman kullanacağını belirleyen, trial→paid ve churn verinin sana söyledikleridir. Zam kararında kademeli kohort geçişi, bölgesel fiyatlandırmada vergi rejimi kontrolü, teklif seçiminde segment ayrımı bu yazının çekirdek çerçevesi.

Teknik uygulama tarafında derinleşmek için StoreKit 2 ile Modern In-App Purchase, StoreKit 2 Production Rehberi, App Store Connect Subscriptions: Offer Codes, Family Sharing, Winback ve Server-Side Receipt Validation yazılarına, paywall ekranının tasarımı için ise paywall tasarımı ve abonelik dönüşümü yazısına bakabilirsin.

Kaynaklar

• Auto-Renewable Subscriptions — App Store, Apple Developer — introductory/promotional/offer code/win-back teklif tanımları, fiyat noktaları, fiyat değişikliği kuralları.
• In-App Purchase and Subscriptions Pricing and Availability — App Store Connect Help — fiyat noktası sayısı, offer süre kısıtları, trial süre listesi.
• Subscriptions Overview — Google Play Billing — base plan + offer mimarisi, Billing Library v8 zorunluluk takvimi.
• Change Subscription Prices — Google Play Billing — opt-in/opt-out zam kuralları, migratePrices API'si, legacy price cohort davranışı.
• Offer Codes Announcement — Apple Developer News — offer code redemption URL formatı ve kullanım senaryoları.