Abonelik Modeline Geçerken Bilinmesi Gerekenler

Tek seferlik satıştan aboneliğe geçmek iş modelini değiştiriyor ve yazılım tarafında da beklenenden farklı bir yük çıkarıyor.

Beklenen yük tahsilat. Gerçek yük ise durum takibi. Sistem her an kimin neye erişebildiğini bilmek zorunda, çünkü yanlış bilirse ya ödeyene hizmet vermiyor ya ödemeyene veriyor.

Mağaza kuralını baştan bilmek

iOS ve Android tarafında uygulama içinde tüketilen dijital içerik ve abonelik için mağazalar kendi ödeme sistemini şart koşuyor ve komisyon alıyor.

Fiziksel ürün ya da uygulama dışında verilen hizmet bu kuralın dışında kalıyor. Hangi tarafta olduğunuz mağaza incelemesinde belirleyici, o yüzden bunu kod yazmadan önce netleştiriyoruz. Yanlış tarafta kalan bir uygulama incelemeden dönüyor ve takvim kayıyor.

Makbuz kanıt değil

Bu, abonelik sistemlerindeki en pahalı hata. Uygulamanın gönderdiği satın alma bilgisine güvenip hak yazmak.

O bilgi cihazdan geliyor ve cihaz güvenilir bir kaynak değil. İşlem, mağazanın kendi sunucusuna sorularak doğrulanmalı. İşlem gerçekten var mı, sizin uygulamanıza mı ait, iddia edilen ürünle aynı mı ve iptal edilmiş mi. Dördü birden kontrol ediliyor.

Doğrulama yapılamıyorsa hak yazılmamalı. Hata durumunda açık tarafa düşen bir sistem, o açığı bulan ilk kişi tarafından sömürülüyor.

Bir satın alma tek hesaba bağlanmalı

Bağlanmazsa aynı makbuz birden fazla hesabı ücretsiz olarak açıyor. Gördüğümüz en yaygın suistimal bu ve kod tarafında çözümü basit, ama sonradan eklemek zor.

Olayın türüne değil duruma bakmak

Mağaza ve ödeme sağlayıcıları olay bildirimi gönderiyor. Yenilendi, iptal edildi, ödeme başarısız gibi.

Bu olayların türüne göre karar vermek hataya açık. Doğrusu güncel duruma bakmak. Ödemesi gecikmiş bir abonelik hâlâ aktif sayılırsa, ödemeyi durduran kullanıcı hizmet almaya devam ediyor.

Aynı olay iki kez gelebilir

Sağlayıcılar aynı bildirimi birden çok kez gönderiyor ve ikinci gelişin de imzası geçerli oluyor. Bu bir hata değil, tasarım gereği böyle.

Olay kimliği kaydedilmeli ve ikinci geliş yutulmalı. Yoksa bir yenileme bildirimi aboneliği iki kez uzatıyor ve bunu kimse fark etmiyor.

İade ve iptal

Kullanıcı mağazadan iade aldığında bunu size bildiren bir uç yoksa, iadeyi ancak kullanıcı uygulamayı bir daha açtığında fark ediyorsunuz. O arada hizmet vermeye devam ediyorsunuz.

Bildirim ucunu baştan kurmayı öneriyoruz. Sonradan eklemek mümkün ama arada geçen süre doğrudan kayıp.

Kota ve hak düşümü

Sınırlı hak veren planlarda düşüm tek bir işlemde yapılmalı. Önce kontrol edip sonra düşmek, aynı anda gelen iki istekte aynı hakkı iki kez kullandırıyor.

Bu özellikle pahalı işlemlerde önemli. Her hak bir maliyet doğuruyorsa, yarış durumuna açık bir düşüm doğrudan faturaya yansıyor.

Abonelik bitince ne olacak

Bu karar baştan verilmeli. Veri siliniyor mu, donduruluyor mu, salt okunur mu kalıyor.

Sonradan verilen bu karar kullanıcı verisini ortada bırakıyor. Ayrıca hesap silme yolunun uygulamanın içinde olması mağaza kuralı, dışarıda bir forma yönlendirmek yeterli sayılmıyor.

Muhasebeye yansıması

Mağaza satışlarında para size doğrudan gelmiyor. Mağaza üzerinden ve komisyon düşülerek geliyor, üstelik gecikmeli.

Yani sistemdeki satış tutarı ile bankaya geçen tutar aynı olmuyor. Raporlamayı baştan bu farkı gösterecek şekilde kurmak gerekiyor, yoksa her ay mutabakat elle yapılıyor.

Deneme süresi ve ilk dönem

Ücretsiz deneme iyi çalışıyor ama iki tuzağı var.

Birincisi, deneme süresi biten kullanıcının erişimini kapatmayı unutmak. Bu sessiz bir kayıp ve genelde aylar sonra fark ediliyor.

İkincisi, aynı kişinin tekrar tekrar deneme açması. Deneme hakkının neye bağlandığı baştan belirlenmeli. E-postaya mı, cihaza mı, ödeme yöntemine mi. Üçü de farklı sıkılıkta ve üçünün de kaçırılma yolu var.

Plan değişikliği

Kullanıcı üst pakete geçtiğinde ya da alt pakete indiğinde aradaki farkın nasıl hesaplanacağı bir karar.

Kalan gün oranlanacak mı, fark hemen mi tahsil edilecek, alt pakete inen kullanıcı dönem sonuna kadar üst pakette mi kalacak. Bu sorular cevaplanmadan yazılan kod, ilk plan değişikliğinde elle düzeltme gerektiriyor.

Web ve mağaza birlikte satıyorsa

İki kaynaktan gelen abonelik aynı hesapta birleşiyor ve hangisinin geçerli olduğu bir kural gerektiriyor.

Kullanıcı hem uygulamadan hem siteden abone olduysa ne oluyor? İki taraf da açık bırakılıp kural yazılmazsa, en sık karşılaştığımız karışıklık bu oluyor ve destek yükü olarak geri dönüyor.

Neyi ölçmek lazım

Abonelik işinde bakılacak rakam aylık ciro değil. Kaç kişi gitti, ne kadar kaldı ve yeni gelen gideni karşılıyor mu.

Bu üç rakam sistemden çıkmıyorsa, büyüdüğünüzü sanarken yerinizde sayıyor olabilirsiniz. Ayrılma sebebinin kaydedilmesi de değerli, çünkü iptal eden kullanıcı size ürünün nerede yetersiz kaldığını söylüyor.