Uygulama İçi Abonelik: Paywall Tasarımı ve Fiyatlandırma Kararları

Uygulama içi abonelik eklemenin teknik kısmı kolay: mağazanın abonelik ürününü tanımlar, satın alma akışını bağlarsınız. Zor olan kısım kod değil karar — paywall (ödeme duvarı) hangi anda gösterilecek, deneme süresi mi yoksa ücretsiz bir katman mı sunulacak ve kullanıcı iptal etmeye karar verdiğinde akış nasıl ilerleyecek. Bu kararlar demografiye göre değil, ölçülen kullanıcı davranışına göre verilmeli. Bu yazıda paywall yerleşiminden mağaza kurallarına, iptal oranını düşüren tasarım kararlarına kadar tüm kurulumu sırayla anlatıyoruz.

Paywall nerede ve ne zaman gösterilmeli?

Paywall'ın zamanlaması, uygulamanın türü kadar önemlidir. Kullanıcı değeri hiç görmeden ödeme ekranıyla karşılaşırsa uygulamayı kapatır; değeri gördükten çok sonra karşılaşırsa da dönüşüm fırsatı kaçar. Pratikte üç yerleşim kalıbı var.

1. Sert paywall (hard paywall): Uygulama açılır açılmaz gösterilir. Yalnızca değer önerisi tek cümleyle anlatılabilecek kadar netse işe yarar — aksi halde kullanıcı ilk açılışta uygulamadan ayrılır.
2. Yumuşak paywall (soft paywall): Kullanıcı önce çekirdek deneyimi bir kez yaşar, sonra ikinci kullanımda veya belirli bir eşikte (üçüncü kayıt, beşinci arama) ödeme ekranı devreye girer. Çoğu uygulama için doğru varsayılan budur.
3. Ölçülü paywall (metered): Belirli bir kullanım miktarına (ör. ayda 3 rapor, 10 arama) kadar ücretsiz kalınır, sınır aşılınca paywall görünür. Kullanım sıklığı yüksek ama tek seferlik değeri düşük ürünlerde (haber, araç, referans içeriği) en doğru sonucu verir.

Deneme süresi mi, ücretsiz katman mı?

İkisi de aynı sorunu farklı şekilde çözer: kullanıcıya ödemeden önce ürünü denetleme fırsatı vermek. Hangisinin doğru olduğu, ürünün değerinin ne kadar hızlı hissedildiğine bağlı.

Fiyatlandırma modelini neler belirler?

Fiyatlandırma modelinde doğru rakamı biz veremeyiz — bu, projeye özel maliyet kalemleri yazımızda anlattığımız gibi kapsam ve pazara özgü bir karar. Ama modelin biçimini belirleyen etkenler her üründe aynı.

• Değer ölçütü (value metric). Kullanıcı sayısı, işlem hacmi veya kullanım miktarı üzerinden mi ücretlendireceksiniz? Yanlış ölçüt, büyüyen kullanıcıyı cezalandırır ya da küçük kullanıcıyı kaçırır.
• Kullanıcı segmenti. Bireysel tüketici tek bir paket bekler; ekip veya kurumsal kullanıcı çok kullanıcılı, faturalandırması ayrı bir plan ister.
• Aylık ve yıllık plan arasındaki oran. Yıllık planın aylığa göre belirgin indirimli sunulması (tipik olarak %20-40 aralığında bir oran) yıllık taahhüdü teşvik eder ve iptal oranını düşürür.
• Rakip modeli, rakip rakamı değil. Rakiplerin kaç katman sunduğuna, hangi özelliği hangi pakete koyduğuna bakmak faydalıdır; birebir aynı rakamı kopyalamak değil.

Apple ve Google'ın abonelik kuralları neyi zorunlu kılıyor?

Uygulama içi abonelik, mağazaların kendi ödeme altyapısından geçmek zorundadır — üçüncü bir ödeme sağlayıcısına yönlendirmek mağaza kurallarına aykırıdır ve ret sebebidir. Karşılığında mağazalar belirli bir komisyon alır ve bazı davranışları zorunlu kılar.

Bu kurallar sabit değil — mağazalar komisyon oranlarını ve programları zaman zaman güncelliyor; güncel oranı her zaman ilgili geliştirici sözleşmesinden teyit etmek gerekir. Ancak tasarım açısından değişmeyen şey şu: iptal akışını zorlaştırmaya çalışmak hem mağaza kurallarını ihlal eder hem de kullanıcı güvenini kalıcı olarak zedeler.

İptal oranını (churn) düşüren tasarım kararları

İptal akışını zorlaştırmak mağaza kurallarınca zaten yasak; ama iptal oranını düşürmenin doğru yolu akışı gizlemek değil, iptal kararına gelmeden önce araya girmektir.

• Yenilemeden birkaç gün önce hatırlatma gönderin. Sürpriz bir tahsilat, kullanıcının markaya olan güvenini en çok kırdığı andır.
• "İptal" yerine "duraklat" seçeneği sunun. Kullanıcının o an ihtiyacı geçici olabilir; aboneliği tamamen sonlandırmak yerine bir ay ertelemek, geri kazanma ihtimalini yükseltir.
• Kullanım verisine göre proaktif destek verin. Bir özelliği hiç açmamış bir kullanıcı, iptal etmeden önce genelde sessizce uzaklaşır; düşük kullanım bir uyarı sinyali olarak değerlendirilmeli.
• İptal anında geri kazanma teklifi gösterin. İndirim değil de ek özellik veya farklı bir plan önerisi, mağaza kurallarına takılmadan sunulabilecek bir alternatiftir.

RevenueCat gibi altyapılar neyi çözer?

Abonelik durumunu (kim, hangi pakette, ne zamana kadar aktif) sıfırdan yönetmek, iki mağazanın makbuz (receipt) doğrulamasını, iadeleri ve yenileme olaylarını ayrı ayrı işlemek anlamına gelir — küçük bir ekip için gereksiz bir mühendislik yüküdür. RevenueCat gibi bir abonelik altyapısı bu doğrulamayı sunucu tarafında merkezi olarak yapar, iki mağazanın olaylarını tek bir arayüzde birleştirir ve paywall varyantlarını kod değişikliği olmadan A/B test etmeyi mümkün kılar. Mobil uygulama geliştirme hizmetimizde abonelik altyapısı gerektiğinde bu tür bir katman kurulum sürecine dahil edilir.

Ne kadar sürer?

Tek bir abonelik paketi, standart bir paywall ve mağaza doğrulaması içeren bir kurulum tipik olarak 1-2 hafta sürer. Birden fazla katman, deneme + freemium karışımı ve paywall A/B testi eklendiğinde bu süre 3-4 haftaya çıkabilir. Bildirim stratejisiyle birlikte kurulduğunda dönüşüm daha isabetli ölçülür — bu konuyu push bildirim stratejisi yazımızda ayrıca ele aldık.

Uygulamanız için hangi modelin (deneme, freemium ya da ikisinin birleşimi) doğru olduğundan emin değilseniz, mevcut kullanıcı akışınızı birlikte gözden geçirelim — kısa bir görüşme talep edin.