App Store İadeleri: Geliştiriciler Gelirlerini İade Kayıplarından Nasıl Koruyabilir
Genellikle finans ekibinde başlar. Biri, App Store ödemesinin dashboard'un vaat ettiği rakamla uyuşmadığını fark eder. Kurcalamaya başlar. Aslında yanlış bir şey bulamaz; sadece altı hafta önceki bir dizi satın alma sessizce Apple'a geri dönmüştür.
Ama o paranın asıl meselesi şu: Sorunun en az ilginç kısmı o. Bir iade, yığınınızdan geçerken beş altı başka sisteme daha dokunur ve hiçbiri size haber vermek için elini kaldırmaz. İşte bu yüzden Apple iade savunması sunucu bildirimleri etrafında kurulmak zorunda. Aylık raporlar etrafında değil. Onlar işe yaramayacak kadar geç gelir.
Kararı Apple verir. Nokta; bunu hiçbir araç değiştiremez, bizimki dahil. Ama "Apple karar verdi" ile "siz üç hafta sonra öğrendiniz" arasında epey bir alan var ve kaçınılabilir paranın neredeyse tamamı tam da o alanda duruyor.
Öne Çıkanlar
● Her App Store iadesini Apple onaylar ya da reddeder. Siz bilgi sağlarsınız ve sonucu kaydedersiniz; geliştiricinin rolü bundan ibarettir, fazlası yok.
● Apple'ın kendi dokümanlarına göre, müşteri tarafından başlatılan bir iade talebi sunucunuza bir CONSUMPTION_REQUEST gönderir. Yanıtlamak için 12 saatiniz var.
● Yapılandırılmış bir V2 bildirim endpoint'iniz yoksa bildirim de gelmez. Beklenenden düşük bir ödeme, ilk gerçek ipucunuz olur.
● Apple, tüketim verisini kararına bir girdi olarak tanımlar. Tekrar etmekte fayda var: bir girdi, belirli bir sonucun garantisi değil.
● REFUND, REFUND_DECLINED ve REFUND_REVERSED birbirinin yerine kullanılamaz. Bunları aynı şekilde ele alan kod, sonunda ödeme yapan müşterileri dışarıda bırakır.
● Bir aboneliği iade ettiğinizde yalnızca tek bir ücreti kaybetmezsiniz; zaten hesaba kattığınız her yenilemeyi de kaybedersiniz.
App Store İadeleri Nedir?
Açıkça söylemek gerekirse: App Store iadesi, Apple'ın bir müşteriye geri verdiği paradır; ister bir uygulama ister uygulama içi satın alma için olsun, fark etmez. Aynı tutar sizin hasılatınızdan silinir. İncelemeyi Apple yapar, kararı Apple verir ve nihayetinde (her zaman hemen değil) sistemleriniz bunu sunucu olayları üzerinden öğrenir; tabii gerçekten dinleyen bir şeyiniz varsa.
İki şey sürekli iadelerle karıştırılır ve açıkçası bu kolay yapılan bir hata. İptal etmek yalnızca gelecekteki yenilemeleri durdurur; zaten ödenmiş olan ödenmiş kalır. Chargeback (ters ibraz) ise bambaşka bir şeydir: kart kuruluşuna açılan bir itiraz, Apple ile hiçbir ilgisi yok. İade bunların ikisi de değildir ve her biri kendi ayrı bildirimini tetikler.
App Store İade Süreci Nasıl İşler?
Müşteriler süreci reportaproblem.apple.com üzerinden ya da StoreKit'in iade talebi API'sini uygulamanıza entegre ettiyseniz doğrudan uygulamanızın içinden başlatır. Apple gönderilen talebi inceler. Kullanım verisine ihtiyaç duyarsa sunucunuza bunu iletmesi için oldukça dar bir süre tanınır. Ardından karar verilir ve bu karar size bir bildirim olarak ulaşır. Müşterilere ise 24 ila 48 saat içinde yanıt bekleyebilecekleri söylenir.
Üzerinde düşününce çarpıcı olan, bu sürecin sizin tarafınızdaki bir insana ne kadar az dokunduğudur. Yükseltilecek bir kuyruk yok. Savunulacak bir dava yok. Sadece Apple'ın sistemi, siz izleseniz de izlemeseniz de kendi işini yapıyor.
Apple'ın dokümantasyonu bu konuda net: Müşteri tarafından başlatılan bir iade talebi, ürün türünden bağımsız olarak V2 endpoint'inize bir CONSUMPTION_REQUEST gönderir. Ama yalnızca o endpoint gerçekten yapılandırılmışsa. Kurulumu atlarsanız, bir iade elinizde yalnızca çıplak bir REFUND olayı bırakarak gelebilir. Bu kadar. Aldığınız tek şey bu olur.
Tablo 1: İade aşamaları ve geliştirici eylemleri
App Store İade Aşaması | Ne Olur | Geliştirici Eylemi |
Satın alma | İşlem tamamlanır | İşlem kimliğini bir kullanıcıyla eşleyerek saklayın |
İade talebi | Müşteri Apple'a başvurur | Yok, süreç Apple'da |
Apple incelemesi | Apple vakayı değerlendirir | App Store Connect'i değil, bildirimleri izleyin |
CONSUMPTION_REQUEST | Apple sunucunuzdan veri ister | Onayla birlikte 12 saat içinde yanıtlayın |
Karar | Apple onaylar ya da reddeder | Burada geliştiricinin rolü yok |
REFUND veya REFUND_DECLINED | Sonuç sunucunuza ulaşır | Erişimi, geliri ve geçmişi güncelleyin |
REFUND_REVERSED | Apple verilen bir iadeyi geri alır | Erişimi kaldırdıysanız geri verin |
App Store İadeleri Neden Gelir Kaybına Yol Açar?
Satın alma tutarı herkesin ilk fark ettiği kısımdır. Ancak neredeyse hiçbir zaman pahalı kısım o değildir. Asıl acıtan, onun aşağısında duran her şeydir: kimsenin kaldırmayı akıl etmediği erişim, çoktan gitmiş gelir üzerine kurulu yaşam boyu değer hesapları, ay sonunda bekleyen bir mutabakat işi, dün uygulamadan memnun olup bugün birden memnun olmayan bir müşteriden gelen destek talebi.
Açıkçası en kötü darbeyi tahminleme alır. Tamamlanmış bir satın almayı kesinleşmiş gelir olarak ele alan her model, daha sonra ortaya çıkan iade sayısı kadar her seferinde yanılacaktır. Kohort grafikleri de tuhaflaşır: iade alan kullanıcılar churn olarak görünmek yerine kohorttan öylece kaybolma eğilimindedir, bu da elde tutma rakamlarını olduğundan daha iyi gösterir. Kimse yalan söylemiyor aslında. Sadece tam resim bu değil.
Apple İade Talebi Sırasında Geliştiriciler Neyi Kontrol Edebilir?
Kabaca üç şey ve bu liste çoğu kişinin beklediğinden kısa. Apple'ın sunucunuza gerçekten ulaşıp ulaşamadığı. Sorduğunda geri ne gönderdiğiniz. Yanıt geldiğinde sistemlerinizin ne kadar hızlı tepki verdiği. Eksik olana dikkat edin: karar. O asla sizin listenizde değil ve Apple, tüketim verisinin belirleyici bir oy değil, birçok girdiden biri olduğu konusunda oldukça açık.
Üzerinde durmaya değer küçük bir nokta: Hiçbir şey söylemeyen bir sunucu tarafsız kalmış olmaz. Yalnızca Apple'a müşterinin olay anlatımını ve geçmişini teslim eder, terazinin sizin tarafında tartılacak hiçbir şey bırakmaz.
Tüketim Bilgisi İade İncelemelerini Nasıl Etkileyebilir
Bir CONSUMPTION_REQUEST geldiğinde, yanıtı Send Consumption Information endpoint'i üzerinden verirsiniz. Payload gerçekten küçük: onay, satın almanın teslim edilip edilmediği, bir deneme sürümü olup olmadığı, ne kadarının kullanıldığı ve tercih ettiğiniz sonuç. Apple'ın ifadesiyle bu veri kararı bilgilendirir. Bilgilendirir. Belirlemez.
Onay, bir kez işaretleyip geçeceğiniz bir kutucuk değil. Apple, bu API üzerinden bir müşterinin kişisel verisini paylaşmadan önce geçerli onayın gerektiğini açıkça belirtiyor; onay yoksa, yönlendirme hiç yanıt vermemeniz yönünde. Önce hukuki zemin. Kod sonra.
Bir ayrıntı ilk seferinde neredeyse herkesi hazırlıksız yakalar. Tüketim yüzdesi alanı yalnızca tüketilebilir ürünler, tüketilemez ürünler ve yenilenmeyen abonelikler için geçerlidir. Otomatik yenilenen aboneliklerde Apple bu rakamı geçen süreden kendisi hesaplar; o alana ne gönderirseniz gönderin çöpe gider. Bu mekanizmayı Apple'ın tüketim talebi penceresine dair bu yazıda daha ayrıntılı ele alıyoruz; buna göre geliştirme yapıyorsanız okumaya değer.
App Store İadeleri Abonelik Gelirini Nasıl Etkiler
Bir abonelikteki iade, tek bir faturalama döneminden çok daha fazlasına mal olur ve arada ciddi fark var. Apple'ın kendi bildirim tabloları bunu açıkça ortaya koyuyor: Uygulama içi API üzerinden iade talep edildiğinde otomatik yenileme kapanır ve DID_CHANGE_RENEWAL_STATUS, AUTO_RENEW_DISABLED alt türüyle birlikte tetiklenir. Mevcut ücret geri alınır. Gelecekteki her ücret de basitçe yok olur.
Tek olay, yinelenen gelire iki ayrı darbe; burada insanların en çok hafife aldığı şey neredeyse bu. Ve o iade alan abone sessizce churn olarak dosyalanırsa, artık bir faturalama sonucunu ürün başarısızlığıymış gibi ele alıyorsunuz demektir ki genellikle öyle değildir. Erişim de tüm bunları yansıtmalı: iade edilen abonelikler erişimi hızla kaybetmeli, geri alınan iadeler ise aynı hızla erişimi geri kazanmalı.
App Store İade Takibi Neden Önemli
Özetle App Store iade takibi üç şeydir: iade olaylarını gerçekleştikleri anda yakalamak, her birini gerçek bir işlem ve gerçek bir kullanıcıyla ilişkilendirmek ve geri dönüp gerçekten arayabileceğiniz bir geçmiş tutmak. Bunu atlarsanız iadeler yalnızca haftalar sonra bir finans raporunda ortaya çıkar; erişimin çoktan değişmiş olması gerektiği ve her yanıt penceresinin çoktan kapandığı bir zamanda.
Gerçekten işe yarayan bir kurulum genellikle şunları kapsar:
● App Store Server Notifications V2'nin güvenilir biçimde ulaşması ve imzaların gerçekten doğrulanması
● İşlemlerin gerçek kullanıcılarla eşleşmesi; genellikle satın alma anında ayarlanan bir appAccountToken üzerinden
● Erişim ve abonelik durumunun bir gece toplu işiyle değil, doğrudan olaylara bağlı olarak değişmesi
● Müşteri bazında iade geçmişi; böylece tekrar eden örüntüler gizli kalmak yerine görünür olur
● Son tarihlerin mesai saatlerine göre değil, gerçek bir saate göre ölçülmesi
Bir de insanların genellikle sonradan, neredeyse tesadüfen keşfettiği bir yan fayda var. Düzgün saklandığında bu olaylar, tam olarak hangi ürünlerin, hangi fiyat noktalarının, hangi mağazaların en çok sızdırdığını gösterir; toplamaya bile çalışmadığınız ama sonunda dayanır hale geldiğiniz bir veri.
Apple İade Otomasyonu Manuel İşi Nasıl Azaltabilir
Apple iade otomasyonu, tekrarlayan orta kısmı üstlenir. Bildirimleri almak ve doğrulamak. Bir işlemi doğru kullanıcıyla eşleştirmek. Tüketim payload'ını oluşturmak, süre dolmadan göndermek, Apple'ın nihayetinde ne karar verdiğini kaydetmek. Yapmadığı şey ise (bunu açıkça söylemekte fayda var) size karar üzerinde herhangi bir etki kazandırmak; daha az kişinin iade istemesini de sağlamaz. İşi bu değil.
Dürüst olalım, bunun asıl gerekçesi zamanlama. On iki saat cömert görünür; ta ki bildirim gerçekten bir Pazar günü sabah 2'de gelene ve birinin bunu fark eden kişi olması gerekene kadar. Apple'ın sandbox penceresi üretim ortamından bile daha dar; bu da Apple'ın bu işi kimin halledeceğini varsaydığına dair oldukça güçlü bir ipucu.
Tablo 2: Manuel ve otomatik iade yönetimi
Manuel İade Yönetimi | Otomatik İade Yönetimi |
İadeler aylık raporlarda fark edilir | Olaylar geldikleri anda yakalanır |
Yanıtlar birinin uyanık olmasına bağlıdır | Yanıtlar Apple'ın penceresi içinde gönderilir |
İşlemler elle eşleştirilir | İşlemler kodla kullanıcılarla eşleştirilir |
Geçmiş elektronik tablolarda tutulur | Müşteri bazında aranabilir geçmiş |
Erişim şikâyetlerden sonra düzeltilir | Erişim doğrudan olaydan güncellenir |
Geliştiriciler Mobil Uygulama Gelirini İadelerden Nasıl Koruyabilir
Mobil uygulama gelirini korumak, açıkçası pratikte biraz sıkıcı bir iş. Fiyatlandırma ve yenileme koşullarını para el değiştirmeden önce açıkça belirtin. Baskı altında gerçekten güvenebileceğiniz işlem kayıtları tutun. İstisnasız her satın almaya bir kullanıcı kimliği ekleyin. Belgelenmiş onayınızın olduğu her yerde tüketim taleplerini yanıtlayın. Ve erişim değişikliklerini doğrudan iade olaylarının tetiklemesine izin verin; birinin bunu elle yapmayı hatırlamasına güvenmeyin, çünkü er ya da geç hatırlamayacaktır.
Fiyatı, yenileme tarihini ve nasıl iptal edileceğini baştan, açıkça gösteren bir paywall, taleplerin bir kısmını daha hiç gönderilmeden sessizce ortadan kaldırır. Bu tam anlamıyla önleme değil. Buradaki hiçbir şey gerçekten öyle değil. Yalnızca kaçınılabilir dilimi küçültür: yanıtlayabileceğiniz talepler, güncellemekte geç kaldığınız erişim, kimsenin fark etmediği örüntü.
Yaygın İade Yönetimi Hataları
Yapılandırılmış bir V2 endpoint'inin olmaması en pahalı hata, çünkü neredeyse diğer her şey öncelikle onun var olmasına bağlı. Bunun ötesinde aynı hatalar ekipler arasında tekrar etme eğiliminde: imzasını doğrulamadan bir payload'a güvenmek, arkasında belgelenmiş onay olmadan tüketim verisi göndermek, satın alma anında appAccountToken'ı atlamak; böylece kimse baktığı işlemin kime ait olduğunu güvenle söyleyemez.
Diğer hata ise hiç teknik değil. Organizasyonel ve tam da bu yüzden daha sinsi. İadeler yalnızca finansın meselesi olarak ele alınır, olaylar ürün ya da mühendislik ekibine hiç ulaşmaz ve iade alan kullanıcılar, sırf kimse iki departmanı birbirine bağlamadığı için tam erişimi korumaya devam eder; bazen aylarca.
Son Söz
İadeler App Store'un işleyişindeki bir hata değil. Sadece onun bir parçası, kalıcı olarak, ve bu değişmeyecek. Ekipten ekibe asıl değişen, kaybın en başta ne kadarının kaçınılabilir olduğu. Kaçırılan bildirimler. Kimsenin yanıtlamadığı talepler. Haftalarca güncellenmeyen erişim. Hepsi kendi elinizle. Hepsi de düzeltilebilir, biri düzeltmeye karar verirse.
Çoğu ekip gerçek bir iş akışını aşağı yukarı aynı anda kurar: iade hacmi, bunu sessizce elle göğüsleyen kişinin kapasitesini nihayet aştığında. Şu anda tam da o noktadaysanız, App Store kurulum adımları bu aşamada büyük ölçüde yapılandırmadan ibaret. Yeniden inşa değil.
Bu Kurallar Nerede Belgeleniyor
● Apple Destek: Uygulamalar veya içerikler için iade talep etme, müşterilerin talepleri nasıl gönderdiğini ve 24 ila 48 saatlik pencereyi açıklar.
● Apple Developer: Send Consumption Information, CONSUMPTION_REQUEST tetikleyicisini, 12 saatlik süreyi, onay kuralını ve Apple'ın veriyi nasıl kullandığını açıklar.
● Apple Developer: notificationType, REFUND, REFUND_DECLINED, REFUND_REVERSED, CONSUMPTION_REQUEST ve otomatik yenileme değişikliğini açıklar.
Sık sorulan sorular
Apple'ın bir uygulama, uygulama içi satın alma veya abonelik için müşteriye geri verdiği paradır; sonrasında hasılatınızdan düşülür. Hem inceleme hem de sonuç Apple'a aittir. Bunu sunucu bildirimleri üzerinden öğrenirsiniz; iş işten geçmeden harekete geçmenizi sağlayacak kadar hızlı olan tek kanal da aslında budur.
Müşteri, Sorun Bildir (Report a Problem) üzerinden ya da uygulama içinden StoreKit'in iade talebi API'si aracılığıyla başvurur. Apple inceler, bazen sunucunuzdan tüketim verisi ister, sonra karar verir. Müşteriler genellikle 24 ila 48 saat içinde yanıt alır.
Hayır, zerre kadar bile. Kararı her zaman Apple verir. İstendiğinde tüketim verisi gönderebilirsiniz ve Apple bunu bir girdi olarak değerlendirir; ancak bu, her iki yönde de hiçbir şeyin garantisi değildir.
İlk hasılatı geri çeker; diğer her şeyi hesaba kattığınızda genellikle daha fazlasını. Erişimin kaldırılması gerekir, tahminler tutmaz olur, finans ekibi geri alma işlemini mutabık kılmak zorunda kalır. Abonelikler bunun üstüne, zaten bir projeksiyonda yer alan kaybedilen yenilemeleri de ekler.
İade olaylarını gerçekleştikleri anda yakalamak, doğru işlem ve kullanıcıyla ilişkilendirmek ve sonradan aramaya değer bir geçmiş tutmak. Bir iadenin anında müdahale ettiğiniz canlı bir olay olması ile gelecek ayın raporunda gömülü bir sürpriz olması arasındaki fark budur.
App Store Server Notifications V2'yi alır, her imzayı kontrol eder, işlemi bir kullanıcıya bağlar ve kayıtlı kullanımdan tüketim alanlarını oluşturur. Yanıt, süre dolmadan Apple'ın API'si üzerinden gönderilir ve sonuç daha sonrası için kaydedilir.
V2 bildirimlerini yapılandırın. Her satın almaya bir kullanıcı kimliği ekleyin. Tüketim verisi için onayı önceden alın. Talepleri hızla yanıtlayın. İade olaylarının erişim değişikliklerini kendi başına tetiklemesine izin verin. Açık fiyatlandırma ve yenileme dili, daha başlamadan bir dilimi daha kesip atar.
Evet, Apple hem bildirimleri hem de yanıt API'sini sunuyor, dolayısıyla tüm döngü içinde bir insan olmadan çalışabilir. Otomasyon takibi, yanıtlamayı ve kayıt tutmayı kapsar. Ne kadar iyi olursa olsun asla kapsamayacağı şey ise kararı gerçekte kimin verdiğidir.
