Bir uygulamayı kaybedilen gelir açısından ilk denetlediğimde, neredeyse her şeyin yolunda olduğunu rapor edecektim. İade oranı 2.4% düzeyindeydi, hangi ölçüte göre bakılırsa bakılsın iyi bir rakam. Ekip, tüketim taleplerini Apple'ın belirlediği süre içinde yanıtlıyordu. Kağıt üzerinde, kurtarılacak bir şey yoktu.
Sonra çoğunlukla inatla bir sorgu daha çalıştırdım. Şu anda, Apple'ın zaten iade ettiği bir işlem üzerinden kaç kişi ödemeli erişim hakkına sahipti? Kırk bir. Yaklaşık 900 ödeme yapan aboneye sahip bir uygulamada. Sonucuna inanamadığım için iki kez çalıştırdım.
Bu, dashboard yeşil kalırken tabanın yaklaşık %5'inin ürünü ay be ay ücretsiz kullanması demek. Ve iade oranı hiç değişmedi. Bu erişim hakkı düzeltmesini ayrıca iade sonrası erişimin nasıl geri alınacağı yazısında ele aldım.
App Store iadelerinden abonelik gelirini nasıl geri kazanacağınızı çözmeye çalışıyorsanız oradan başlayın, çünkü iade, paranızın aslında gittiği dört yerden sadece en küçüğüdür. İşte tüm tablo.
Dört Kova, Değerlerine Göre Sıralanmış
Bunu dört kova olarak düşünüyorum ve emek-getiri sıralaması çoğu insanın tahmin ettiği gibi değil.
Sızıntı: erişimini hiç kaybetmemiş iade alan kullanıcılar. En ucuz düzeltme, en sık gözden kaçırılan.
Savunma: Apple'ın tüketim taleplerini kanıtla yanıtlamak. Yazılımların otomatikleştirebildiği tek kova olduğu için her tedarikçinin bahsettiği kova.
Win-back: iade alan veya düşen kişileri yeniden kazanmak. Karşılığını almak en uzun süren kova. Apple bu yıl sessizce bunu kolaylaştırdı.
Yeniden deneme: müdahale etmezseniz kendi kendine düzelen faturalama başarısızlıkları.
Çoğu ekip yalnızca ikinci kova üzerinde çalışır. Sürprizler bir ve üç numaralı kovalarda yaşar.
Birinci Kova: Sızıntıyı Bulun, Bir Saat Sürer
Sorgu, kabaca şöyle. Son 12 ay içinde iptal (revocation) tarihi bulunan her işlemi alın, erişim hakkı tablonuzla birleştirin ve hâlâ aktif erişim gösterenleri sayın.
Sonuç gerçekten sıfırsa bu bölümü atlayın. Ama sıfır değilse, bir şey onu kapatana kadar her ay kaybolan abonelik geliri bulmuşsunuz demektir. Apple ödemesini geri alır. Apple veritabanınıza dokunmaz. Siz bağlamadıkça bu ikisi birbirinden kopuk kalır. Tüketilebilir ürünlerde (consumables) durum daha kötüdür, çünkü bir ürün bir kez harcandıktan sonra StoreKit'in geri alacağı hiçbir şey kalmaz.
(Bunu aylarca ben de yanlış yaptım. Bildirim işleyicisi REFUND olaylarını kimsenin okumadığı bir tabloya kaydediyordu. Kaydetmek, işlemek değildir.)
Çözüm: REFUND olayını dinleyin, iptal tarihinde erişimi kaldırın ve REFUND_REVERSED durumunda erişimi yeniden vererek işleyin. Apple bazen, bir müşteri itirazının ardından kendi iadelerini geri alır ve bunun için müşteriyi cezalandırmamalısınız.
Oradayken bir sorgu daha çalıştırın. Hiç sunucu bildirimi almadığınız iadeleri sayın. Bu sıfır değilse, endpoint'iniz bozuk demektir ve ikinci kova da öyle.
İkinci Kova: Hâlâ Etkileyebileceğiniz Talepleri Savunun
Apple, bir CONSUMPTION_REQUEST'ten itibaren tüketim verisi göndermeniz için yaklaşık 12 saat tanır. Üç zorunlu alan, iki isteğe bağlı alan, bir tercih ve artık yalnızca tüketilebilirleri değil, tüm ürün türlerini kapsıyor.
Buradaki tavsiyem kısa, çünkü bu kova başka yerlerde zaten ayrıntılarıyla işlendi. Her talebi yanıtlayın. Ürünün açıkça teslim edildiği ve yoğun kullanıldığı durumları reddedin. Gerçek kazaları kabul edin. İyi niyetli bir taviz ucuzdur. Her iadeye karşı savaşmak öyle değildir, çünkü Apple geçmişinizi ağırlıklandırır.
Kimsenin bahsetmediği bağımlılık kanıttır. Yalnızca ispatlayabildiğinizi savunabilirsiniz. Yedi hafta önceki bir satın alma için "aslında ne kadar kullandılar" sorusuna kimse yanıt veremiyorsa, hiçbir otomasyon sizi kurtaramaz. Bu, tedarikçiden bağımsız olarak kapatılmaya değer bir veri modelleme açığıdır.
Maliyet tarafı için, iadelerin uygulama gelirinize gerçekte ne kadara mal olduğu yazısı, her iade edilen kullanıcının arkasındaki edinme harcaması dahil olmak üzere hesaplamayı yapıyor.
Üçüncü Kova: Aboneyi Geri Kazanın
Abonelik geliri korumasının savunmacı olmaktan çıktığı yer burasıdır. Ve bu, Apple'ın geçtiğimiz yıl içinde sizin lehinize yeniden inşa ettiği alan.
Win-back teklifleri. WWDC24 itibarıyla yeni, iOS 18 ve sonrası için geçerli. Bunları App Store Connect'te her abonelik ürünü için yapılandırır ve uygunluk koşullarını belirlersiniz: minimum ödeme süresi, son abonelikten bu yana geçen süre, teklifler arasında 2 ila 24 aylık bir bekleme. Ardından dağıtımı Apple yapar. Teklifler, müşterinin Manage Subscription sayfasında, ürün sayfanızda, kişiselleştirilmiş önerilerde, zaman zaman da Today sekmesindeki editöryel alanlarda karşımıza çıkar.
Bunu iki kez okuyun. Apple, indiriminizi e-postayla asla ulaşamayacağınız bir yerde, kaybedilmiş bir aboneye gösteriyor. Sınırlar: abonelik başına 350 teklif, mağaza başına 5 aktif teklif. Uygulama içinde, biri uygun hale geldiğinde StoreKit bir winBackOffer mesajı tetikler ve yenileme bilgisindeki eligibleWinBackOfferIDs, kullanıcının neyi kullanabileceğini gösterir. Apple'ın win-back kurulum rehberi uygunluk alanlarını kapsıyor.
Promosyon teklifleri. Abonelik başına 10 adete kadar, iOS 12.2'den beri mevcut ve sunucunuzdan bir JWS imzası gerektiriyorlar. Win-back'ten daha fazla iş gerektirir. Ama hedeflemeyi tamamen siz kontrol edersiniz, bu da iade nedenleri size belirli bir şey söylediğinde önemlidir, diyelim ki bir ülkede bir fiyatlandırma sorunu.
Teklif kodları. Uygulama içinde veya dışında kullanılabilir. Bu da onları, iade alıp ardından uygulamayı kaldıran birine ulaşmanın tek gerçekçi yolu yapar. Diğer herkese uygulama içinden ulaşabilirsiniz. Bu kişilere ise ulaşamazsınız.
Abonelik Yenileme Tarihini Uzatma. Bence hak ettiği değeri görmeyen bir seçenek. Apple'ın sunucu API'si, tek bir işlem için veya toplu olarak bir abonenin yenileme tarihini ileri itmenize izin veriyor. Bunu kötü sürümlerden sonra bir iyi niyet göstergesi olarak kullanıyoruz: biri bir faturalama hatası hakkında destek ekibine e-posta attığında bir ay uzatıyorsunuz, bu neredeyse hiçbir şeye mal olmuyor ve her kupondan daha etkili. Önlenen bir iade, geri kazanılan bir iadeden daha iyidir.
Bir istisna var. Biri ürünün kendisi yüzünden değil de bir faturalama sürprizi yüzünden iade aldıysa, onu bir indirimle kovalamayın. Önce paywall metnini düzeltin, sonra onun bunu kendi kendine yeniden keşfetmesine izin verin. App Store iade yönetimi yazısı bu operasyonel tarafı ele alıyor.
Dördüncü Kova: Kendi Kendine Düzelen Kayıp
Apple, başarısız faturalamaları en fazla 60 gün boyunca ya da müşteri kartını düzeltene veya iptal edene kadar yeniden dener. Abonelik bu süre içinde yenilenirse, ücretli hizmet kurtarma tarihinden itibaren devam eder.
Yani kaybedilmiş abonelik geliri gibi görünen kısmın bir bölümü aslında hiç kaybedilmemişti. Beklemedeydi. Bunu bozan iki şey var: hiç açmadığınız bir ödeme dönemi uzatması (grace period) ve insanlara neredeyse doğrudan iptal etmelerini söyleyen bir tahsilat (dunning) e-postası. Elde tutma araçlarına para harcamadan önce ikisini de kontrol edin.
Kendinizi Kandırmadan Ölçmek
Kohort atfı (cohort attribution) olmadan yapılan iade yönetimi, kendinden emin saçmalıklar üretir.
Her iadeyi, iadenin gerçekleştiği değil, orijinal satın almanın yapıldığı döneme atfedin. Ardından kohortun olgunlaşmasını bekleyin. Aylık planlar için 30 ila 45 gün, yıllık planlar için daha uzun, çünkü iade talepleri aylar sonra bile gelebilir.
Abonelik iade takibinin zorlaştığı ve çoğu dashboard'un sessizce hile yaptığı yer de tam olarak burasıdır. Kasım ayında kabul edilen bir win-back, Ağustos'ta düşen kohorta aittir. Raporlamanız bunları birbirine bağlamıyorsa, kurtarma rakamınız kurgudan ibarettir.
Bir değil, dört rakamı takip edin.
Kohorta göre iade oranı.
Süresi içinde yanıtlanan talepler.
İade nedenine göre ayrılmış, savunulan gelir.
Sıfıra doğru giden ve orada kalması gereken, bekleyen erişim hakkı sızıntıları.
Dashboard'a yalnızca bir tanesini koyabilseydim, sızıntı sayısı olurdu. Sıfır olmadığı her durumda kesinlikle yanlış olan tek rakam odur.
Yazılımın Gerçekte Nereye Oturduğu
İkinci ve dördüncü kovalar sorunsuzca otomatikleştirilebilir. Birinci kova bir kez otomatikleştirilir, ardından yalnızca izleme gerektirir. Üçüncü kova ise yapılandırma ve değerlendirme meselesidir ve hiçbir araç bu değerlendirmeyi sizin yerinize yapmaz.
Refund Sensor, her iki mağazada da savunma tarafını üstlenir; uygun her talebi süresi içinde işlem kanıtıyla yanıtlar ve neyi koruduğunuzu takip eder. Kimseyi geri kazanmaz ve kafa karıştırıcı bir paywall'ı düzeltmez. Bunu sizden başka kimse yapamaz.
Kaynaklar
Sık sorulan sorular
Deneyeceğim sırayla dört yol var. İade edilmiş bir işlemde hâlâ erişimi bulunan kullanıcıları bulun ve erişimlerini kapatın. Her tüketim talebini (consumption request) 12 saat içinde yanıtlayın. Kaybedilen abonelerinizi win-back veya promosyon teklifleriyle geri kazanın. Ardından faturalama yeniden deneme (billing retry) ve ödeme dönemi uzatmalarını (grace period) kontrol edin, çünkü bazı kayıplar hiç kalıcı olmamıştı.
Doğrudan değil, hayır. Apple, bir müşteri itirazının ardından bazen iadeleri kendisi geri alır ve bir REFUND_REVERSED bildirimi gönderir. Bu bildirim geldiğinde erişimi yeniden açın. Bu, uğraşmanıza gerek kalmadan elde ettiğiniz bir kurtarmadır.
Bu teklifler, otomatik yenilemeyi kapatmış olan düşmüş (lapsed) aboneleri hedefler ve uygunluk, ödenen süre ile son abonelikten bu yana geçen zamana göre belirlenir. İade edilen bir abonelik de düşmüş sayılır, dolayısıyla genellikle evet. Yine de kuralları yapılandırıp kontrol edin.
Erişim hakkı (entitlement) sorgusu. Bir saatlik iş, tedarikçi gerekmez, uygulama güncellemesi gerekmez. Bunu çalıştırdığım her uygulamada sonuç sıfır çıkmadı.
İade tutarından daha fazlasına. Tipik oranlar, ödenen işlemlerin %2 ila %5'i arasında seyreder. Gerçek maliyete, o kullanıcının arkasındaki edinme (acquisition) harcaması, bildirimi kaçırdıysanız oluşan erişim hakkı sızıntısı ve bir sonrakine fazla ödeme yapmanıza neden olan şişirilmiş LTV eklenir.
Hayır. Sızıntıyı düzeltmek ücretsizdir ve bu bir hatadır (bug). Yazılım, sizin yanıtlamadığınız talepleri yanıtlar; bu gerçek bir sorundur, ama ilk sorun değildir.
