Çoğu satıcı DLC kodu satışını basit bir iş sanır: kodu al, listeye koy, sat. Sonra ilk aydan sonra tuhaf bir tablo oluşur. Ciro fena değildir ama iadeler, "kod çalışmadı" mesajları ve ödeme kuruluşundan gelen itiraz bildirimleri birikmeye başlar. Satıcı kodların bozuk olduğunu düşünür, tedarikçiyi suçlar. Oysa kodların çoğu sapasağlamdır; sorun kodda değil, kodun hangi bölgeye ve hangi ön koşula bağlı olduğunun müşteriye hiç anlatılmamasındadır.
The Sims ekosistemi bu problemin ders kitabı örneğidir. Genişleme paketleri, oyun paketleri ve içerik kitleri; farklı mağaza bölgelerine, farklı platform kimliklerine ve çoğu zaman temel oyunun kurulu olmasına bağlıdır. Bu yazıda bölge kilidinin ticari anatomisini, iade zincirinin nasıl kurulduğunu ve doğru yapılandırılmış bir dijital ürün satış scripti ile bu zincirin nerede kırıldığını anlatıyorum. Pinova bu denklemde kod satmaz; kodu satanın iade oranını düşüren e-pin satış yazılımıdır.
Bölge kilidi tam olarak neyi kilitler, neyi kilitlemez?
Satıcıların çoğu bölge kilidini tek bir şey sanır. Aslında en az üç farklı katman vardır. Birincisi etkinleştirme bölgesi: kod yalnızca belirli ülke listesinde tanımlı hesaplarda aktive olur. İkincisi oynanabilirlik kısıtı: kod aktive olur ama içerik o bölgede çalıştırılamaz. Üçüncüsü mağaza/para birimi uyumu: hesap bölgesi ile kodun basıldığı bölge farklıysa sistem işlemi reddeder. Bu üç katmanı ayrı ayrı etiketlemeyen bir katalog, müşteriye yalan söylüyor demektir. Ürün verisi tarafında çözüm nettir: her ürüne bölge alanı, platform alanı ve ön koşul alanı ekle. Bunlar açıklama metnine gömülü cümleler değil, filtrelenebilir yapılandırılmış alanlar olmalı ki müşteri yanlış ürünü seçemesin.
Temel oyun şartı: iade taleplerinin görünmez kaynağı
DLC satışında en sık yaşanan senaryo şudur: müşteri genişleme paketini alır, kodu girer, sistem kabul eder, sonra oyunu açtığında içeriği göremez. Çünkü temel oyun kurulu değildir veya sürüm uyumsuzdur. Müşterinin gözünde bu "kod çalışmadı" demektir ve ilk gittiği yer senin destek kanalındır. Bu kaybı satış öncesi bir adımla kapatabilirsin: ürün sayfasında zorunlu onay kutusu. "Temel oyunun hesabımda kurulu olduğunu ve hesabımın bölgesinin uyumlu olduğunu doğruluyorum." Bu tek kutu iki iş yapar; müşteriyi bilgilendirir ve itiraz durumunda elinde kayıt bırakır. İyi bir e-pin scripti bu onayı sipariş kaydına damgalar, tarih ve IP ile birlikte saklar. Ödeme itirazında sunacağın kanıt tam olarak budur.
| Sorun tipi | Müşterinin gördüğü | Gerçek sebep | Önleyen mekanizma |
|---|---|---|---|
| Kod reddedildi | "Geçersiz kod" | Hesap bölgesi uyumsuz | Bölge alanı + satın alma öncesi uyarı |
| İçerik görünmüyor | "Kod boş çıktı" | Temel oyun kurulu değil | Zorunlu ön koşul onayı |
| Yanlış paket alındı | "Farklı DLC geldi" | Benzer isimli varyant karışıklığı | Varyant seçici + kapak görseli |
| Kod ikinci kez kullanılmış | "Zaten kullanılmış" | Stok kilidi yok, çift satış | Rezervasyon ve tek kullanım kilidi |
| Ödeme itirazı | "Ürün alamadım" | Teslim kaydı ispatlanamıyor | Zaman damgalı teslimat logu |
Aynı DLC'nin altı sürümü varsa müşteri nasıl doğru seçer?
The Sims tarzı geniş içerik ailelerinde ürün adları birbirine tehlikeli biçimde benzer. Bir genişleme paketi ile bir içerik kiti, isim benzerliği yüzünden karışır. Burada satıcının işi bilgi vermek değil, yanlış seçimi imkânsız hâle getirmektir. Pratikte bunun üç aracı var: ürün sayfasında büyük ve net paket türü etiketi, seçim sihirbazı tarzı iki soruluk akış (platform? bölge?) ve karşılaştırma tablosu. Böyle bir katalog mimarisi hazır gelen bir epin yazılım kurulumu, sana haftalarca özel geliştirme yapma yükünden kurtarır. Yapının hangi alanları desteklediğini özellikler sayfasında tek tek görebilirsin.
DLC kodu iade/şikâyet nedenlerinin dağılımı
- Bölge/hesap uyumsuzluğu 40%
- Temel oyun veya sürüm şartı 30%
- Yanlış varyant seçimi 20%
- Gerçek kod arızası 10%
İade politikası bir metin değil, sistem davranışıdır
Dijital kod satışında iade politikasını sadece sözleşme sayfasına yazmak yetmez. Politikanın yazılım tarafında karşılığı olmalı. Örneğin kod görüntülendiği anda "açıldı" olarak işaretlenmeli; çünkü tek kullanımlık bir kodun görüntülenmesi tüketimle eşdeğerdir. Müşteri iade talebi açtığında sistem bu durumu otomatik göstersin. Aynı şekilde kod hiç görüntülenmemişse iade tek tuşla yapılabilsin ve kod havuza dönsün. Bu ayrımı yapan bir altyapı, hem müşteriye adil davranır hem de seni haksız iadelerden korur. E-pin satış scripti seçerken "kod görüntüleme logu var mı" sorusu, göründüğünden çok daha belirleyicidir.
Bölge kısıtını küçük puntoyla saklayan satıcı kısa vadede birkaç sipariş kazanır, uzun vadede ödeme kuruluşu nezdinde risk skorunu bozar. Net uyarı, dönüşümü %2 düşürüp iadeyi %40 azaltır.
Tedarikçi zinciri: kodun kaynağı iade oranını belirler
Bir DLC kodunun hangi kanaldan geldiği, senin iade istatistiğini doğrudan şekillendirir. Toplu alınan ucuz partilerde bölge karışıklığı ve süresi geçmiş kod riski yüksektir. Bu yüzden stoğu tedarikçi bazında etiketlemelisin. Aynı ürünün iki farklı tedarikçiden gelen stoğunu ayrı partiler hâlinde tut, her partinin iade oranını ölç. Üç ay içinde hangi kaynağın sana para kaybettirdiğini sayılarla görürsün. Bu raporlamayı elle yapmak neredeyse imkânsız; parti/lot mantığı olan bir dijital ürün satış yazılımı bunu otomatik üretir. Aşağıdaki kontrol listesini kendi kurulumuna uygula.
| Kontrol maddesi | Ne işe yarar? | Var mı? |
|---|---|---|
| Ürün başına bölge ve platform alanı | Yanlış hesapta aktivasyonu engeller | Evet / Hayır |
| Zorunlu ön koşul onay kutusu | İtirazda kanıt sağlar | Evet / Hayır |
| Kod görüntüleme zaman damgası | Haksız iadeyi keser | Evet / Hayır |
| Tedarikçi/parti bazlı stok etiketi | Kötü kaynağı ayıklar | Evet / Hayır |
| Varyant karşılaştırma tablosu | Paket karışıklığını bitirir | Evet / Hayır |
| Otomatik iade + stoğa geri koyma | Kod kaybını önler | Evet / Hayır |
İade oranını düşüren DLC satış altyapısını kur
Bölge alanları, ön koşul onayı, parti bazlı stok ve zaman damgalı teslimat logu tek panelde hazır bekliyor.
Bölge kilitli DLC satmak riskli mi?
Riskli değil, şeffaflık gerektiriyor. Ürün sayfasında geçerli bölgeyi, platformu ve ön koşulu net yazdığında iade oranı normal seviyeye iner. Riski yaratan kilit değil, bilgiyi saklamaktır.
Müşteri kodu gördükten sonra iade isterse ne yapmalıyım?
Politikanı baştan tek kullanımlık dijital ürün mantığına göre kurmalısın. Görüntülenmiş kodda iade kapalı, görüntülenmemiş kodda iade açık olsun. Sistem bu ayrımı otomatik yapıyorsa tartışma yaşamazsın.
Aynı ürünü birden fazla bölge için nasıl listelemeliyim?
Tek ürün altında bölge varyantları olarak listele. Ayrı ürün sayfaları açmak SEO'nu böler ve müşteriyi karıştırır. Varyant seçiminde bölge zorunlu alan olsun.
Ödeme itirazı geldiğinde elimde hangi kanıt olmalı?
Sipariş kaydı, onay kutusunun işaretlendiği an, kodun teslim edildiği zaman damgası ve müşterinin kodu görüntülediği log. Bu dördü bir arada sunulduğunda itirazların büyük bölümü lehine kapanır.
DLC kodu satışında kazanan, en ucuz kodu bulan değil, en az iade alan satıcıdır. Bölgeyi, ön koşulu ve teslimat kaydını sistemin içine gömdüğün gün marjın da huzurun da yerine gelir. Lisans seçeneklerini fiyat bölümünden karşılaştırabilir, bölge alanlarının ve onay kutusunun gerçek bir siparişte nasıl davrandığını görmek için canlı demo üzerinde bir test siparişi geçirebilirsin.