Çoğu satıcı mobil uygulama aboneliği satmanın diğer dijital ürünlerden farklı olmadığını sanır. Kodu tedarik ediyorsun, panelden yayınlıyorsun, müşteri satın alıyor, sistem otomatik teslim ediyor. Oyun içi para ya da hediye kartı satarken işleyen döngünün aynısı. Fakat abonelik ürünlerinde işin içine üçüncü bir taraf giriyor: uygulama mağazası. Ve mağazalar kendi ekosistemlerinde dönen abonelik parasının nereden geçtiğine, diğer ürün tiplerine kıyasla çok daha yakından bakıyor.
Sonuç tanıdık geliyor: bir sabah tedarikçin "kodlar bitti" diyor, müşterinin kodu "bu bölgede geçersiz" hatası veriyor, uygulamanın geliştiricisinden nazik ama net bir uyarı maili düşüyor. Kimse sana hangi maddeyi ihlal ettiğini söylemiyor, çünkü ihlal genelde tek maddede değil; mağaza kuralları, geliştirici sözleşmesi ve bölgesel fiyat politikasının kesiştiği yerde duruyor. Bu rehberde o kesişimi netleştirip, kullandığın e-pin satış scripti üzerinde uyumlu bir katalog nasıl kurulur sorusunu adım adım yanıtlayacağız.
Abonelik Kodu Satarken Aslında Hangi Kuralın İçindesin?
Üç ayrı metin aynı anda devrede. Birincisi mağazanın son kullanıcı şartları; kodun kime, nasıl, hangi bölgede kullanılabileceğini belirliyor. İkincisi geliştirici sözleşmesi; uygulamanın sahibinin abonelik satışını hangi kanallardan yapabileceğini düzenliyor. Üçüncüsü senin tedarikçinle yaptığın ticari anlaşma. Sen bu üçlünün en dışındaki halkasın ama arıza çıktığında müşteriyle muhatap olan tek taraf sensin.
Pratikte şu ayrımı yapmak işi çözüyor: ürün mağaza tarafından resmen üretilmiş ve devredilebilir olarak tanımlanmış mı, yoksa bir kullanıcının kendi hesabına tanımlı avantajını mı yeniden satıyorsun? Birincisi normal ticaret, ikincisi kaçınılmaz arıza. Devredilebilirlik, abonelik ürünlerinde tek gerçek ayrım noktası. Katalogunu bu soruya göre temizlediğinde destek yükün ciddi biçimde düşüyor.
Uygulama İçi Satın Alma Zorunluluğu Seni Kapsıyor mu?
Mağaza kurallarının en çok tartışılan maddesi, dijital içerik ve abonelik satışının uygulama içi satın alma altyapısı üzerinden yapılması zorunluluğu. Bu madde doğrudan geliştiriciyi bağlıyor, seni değil. Yani sen bir uygulamanın aboneliğini kendi sitenden sattığında kuralı ihlal eden taraf teknik olarak sen değilsin. Ama etki sana geliyor: geliştirici mağaza baskısıyla harici satış kanallarını kapattığında, senin tedarik hattın bir gecede kuruyor.
Bu yüzden akıllı satıcı iki şey yapıyor. Birincisi, harici satışa açıkça izin veren ürünlere ağırlık veriyor; çoğu üretkenlik, tasarım ve öğrenme uygulaması resmî bayilik ya da toplu lisans kanalı sunuyor. İkincisi, tek bir ürüne bağımlı kalmıyor. Dijital ürün satış yazılımı tarafında kategori bazlı ciro raporun varsa, tek ürünün toplam cironun yüzde kaçını taşıdığını görürsün; bu oran otuzu geçtiğinde alarm çalmalı.
| Kod tipi | Kaynağı | Devredilebilir mi? | Tipik arıza |
|---|---|---|---|
| Mağaza hediye kartı | Resmî dağıtım | Evet | Bölge uyuşmazlığı |
| Geliştirici promo kodu | Uygulama sahibi | Genelde hayır | Tek kullanım, iptal riski |
| Toplu lisans anahtarı | Kurumsal sözleşme | Hayır | Sözleşme ihlali, geri alma |
| Web üzerinden abonelik | Geliştiricinin kendi sitesi | Duruma göre | Bayilik şartı |
| Hesaba tanımlı avantaj | Son kullanıcı | Hayır | Erişim kaybı, itiraz |
Promo Kod, Hediye Kartı ve Bölge Farkı: Üç Ayrı Hukuk
Bu üçü aynı panelde aynı ürün kartıyla satıldığı için karışıyor, oysa davranışları tamamen farklı. Hediye kartı bakiye yükler; bölgeye bağlıdır, hesabın ülkesiyle eşleşmezse kullanılmaz ve bu kural esnetilemez. Promo kod belirli bir uygulamaya, belirli bir süre için tanımlı tek kullanımlık haktır; geliştirici istediği an kampanyayı kapatabilir ve kullanılmamış kodlar ölür. Toplu lisans ise bir kuruma bağlıdır ve parçalanarak satılamaz.
Bölge farkı ayrı bir başlık. Aynı aboneliğin ülkeler arasında fiyat farkı olması normal; o farkı sömürmek için kullanıcıya hesap bölgesi değiştirmesini söylemek ise mağaza şartlarının doğrudan ihlali. Ürün açıklamasına bu talimatı yazan satıcı, hem mağaza hem ödeme sağlayıcısı hem de tüketici hakem heyeti nezdinde kendi aleyhine kanıt üretiyor. Bölge kısıtı gizlenecek bir detay değil, ürünün teknik özelliğidir. Ürün kartında filtrelenebilir bir alan olarak tutulmalı.
Abonelik kodu siparişlerinde destek taleplerinin dağılımı
- Bölge uyuşmazlığı 40%
- Kod zaten kullanılmış 30%
- Yenileme ve iptal soruları 19%
- Teslim gecikmesi 11%
Hesap Askıya Alma Zinciri Nasıl Başlıyor?
Zincir neredeyse her zaman tek bir müşteri şikâyetiyle başlıyor. Kod çalışmıyor, müşteri mağaza desteğine yazıyor, destek kodun kaynağını sorguluyor ve izini tedarikçiye kadar sürüyor. Tedarikçinin hattı kapanıyor, senin stokun ölüyor. İkinci dalga ödeme tarafından geliyor: aynı hafta içinde birkaç itiraz düştüğünde sağlayıcı işlem hacmini kısıtlıyor. Üçüncü dalga pazarlama tarafında; reklam hesabı yanıltıcı ürün bildirimiyle inceleme alıyor.
Bu zincirin her halkası önlenebilir ve önleme noktası ilk adımda. Müşteriye kodun bölge kısıtını satın alma öncesi göstermek, kod teslim ekranında kullanım adımlarını yazmak ve arıza durumunda mağazaya değil sana yazmasını sağlayacak bir destek akışı kurmak zinciri baştan kırıyor. İyi kurulmuş bir epin yazılım altyapısında bunların üçü de ürün şablonunun parçası, her üründe elle tekrarlanan bir iş değil.
Aynı aboneliğin her bölgesini ayrı varyant olarak tanımla ve sepette bölge onayı isteyen bir kutu koy. Bu tek değişiklik, destek taleplerinin en büyük kalemini doğrudan küçültüyor.
Uyumlu Bir Abonelik Katalogu Nasıl Kurulur?
İşe eleme ile başla. Devredilebilirliği belgelenemeyen her ürünü çıkar; kısa vadede ciro kaybı gibi görünür ama iade, itiraz ve destek maliyetini hesapladığında çoğu zaten zararına satılıyordur. Kalan ürünler için yedi alanı zorunlu yap: uygulama adı, abonelik süresi, kapsam, geçerli bölge, teslim süresi, kullanım adımları ve iade koşulu. Bu yedi alan dolu değilse ürün yayına çıkmasın.
Sonra stok tarafını sıkılaştır. Parti bazlı stok, son kullanma tarihi takibi ve düşük stok uyarısı olmadan abonelik kodu satmak, bir gün mutlaka "kullanılmış kod teslim ettim" durumuna düşmek demek. Son adım raporlama: ürün bazlı iade oranı ve destek talebi sayısı yan yana görünüyorsa hangi tedarikçinin kaliteli olduğunu tahminle değil veriyle bilirsin. Özellik listesinde parti takibi ve ürün bazlı iade raporunun bulunup bulunmadığını mutlaka kontrol et.
İade ve Abonelik İptali Talepleri Kimin Sorunu?
Müşteri aboneliğini iptal etmek istediğinde çoğu zaman sana yazıyor, çünkü parayı sana ödedi. Oysa kod bir kez hesaba tanımlandıktan sonra ilişki mağazayla kurulmuş oluyor ve iptal ya da yenileme yönetimi orada yapılıyor. Bunu satın alma anında anlatmak, sonradan açıklamaktan çok daha kolay. Teslim şablonuna iki satırlık bir yönlendirme eklemek destek yükünün belirgin kısmını eritiyor.
Kullanılmamış ve teslim edilmemiş kodlarda iade politikanı ise net yaz; "dijital ürün iade edilemez" gibi toptan bir cümle tüketici mevzuatı karşısında her zaman ayakta kalmıyor. Kodun teslim edilip edilmediğini, açılıp açılmadığını sistem üzerinden kanıtlayabiliyorsan pozisyonun güçlü. İade politikası bir metin değil, sistemin ürettiği kanıtla birlikte anlam kazanan bir kuraldır. Paket karşılaştırmasında teslim kaydı ve görüntüleme logu detayına dikkat et.
| Kontrol | Amaç | Nerede | Durum |
|---|---|---|---|
| Devredilebilirlik belgesi | Tedarik hattını korumak | Ürün açılışı | Zorunlu |
| Bölge varyantı | En büyük arızayı önlemek | Ürün yapısı | Zorunlu |
| Parti ve son tarih takibi | Ölü kod teslimini engellemek | Stok modülü | Zorunlu |
| Kullanım adımları şablonu | Destek yükünü azaltmak | Teslim maili | Zorunlu |
| İptal yönlendirme notu | Yanlış muhatap trafiğini kesmek | Teslim ekranı | Önerilir |
| Ürün bazlı iade raporu | Kötü tedarikçiyi ayıklamak | Raporlama | Önerilir |
| Tek ürün ciro payı uyarısı | Bağımlılık riskini görmek | Panel özeti | Önerilir |
Abonelik katalogunu kurallara uygun kurmaya hazır mısın?
Bölge varyantı, parti takibi, teslim kaydı ve ürün bazlı iade raporu hazır gelen bir altyapıyla ilerle; arızayı müşteri değil sistem yakalasın.
Uygulama aboneliğini kendi sitemden satmak kural ihlali mi?
Mağazanın uygulama içi satın alma zorunluluğu geliştiriciyi bağlar, seni değil. Ancak sattığın kodun devredilebilir olması ve kaynağının belgelenebilir olması şart; aksi hâlde ihlal tedarik zincirinde ortaya çıkar.
Bölge farkından yararlanan kod satmak neden riskli?
Kod hesap bölgesiyle eşleşmediğinde ya baştan çalışmaz ya sonradan iptal edilir. Kullanıcıya bölge değiştirmesini önermek ise mağaza şartlarının açık ihlali ve ödeme itirazlarının başlıca sebebi.
Müşteri aboneliğini iptal etmek isterse ne yapmalıyım?
Kod hesaba tanımlandıktan sonra iptal ve yenileme mağaza hesabı üzerinden yönetilir. Bunu teslim şablonuna iki satırla yazdığında talep trafiğinin çoğu doğru adrese gider.
Hangi rapor bana en çok zaman kazandırır?
Ürün bazlı iade ve destek talebi raporu. Hangi tedarikçinin kodlarının arıza yaptığını veriyle gösterir ve katalog temizliğini tahmine bırakmaz.
Abonelik kodu satışı, kurallarını bilene istikrarlı marj bırakan; bilmeyene her ay yeni bir sürprizle gelen bir kategori. Ayrımı yapan şey ne tedarikçinin fiyatı ne de reklam bütçesi; devredilebilirliği belgelenmiş bir katalog, bölge varyantına dayanan bir ürün yapısı ve arızayı müşteriden önce yakalayan bir stok sistemi. Bu üçünün tek panelde nasıl birleştiğini kendi ürünlerinle test etmek istersen canlı demo üzerinden bir abonelik ürünü oluşturup teslim akışını baştan sona deneyebilirsin.