Çoğu satıcı, aynı oyunun farklı platform kodlarını tek ürün sayfasında toplamanın akıllı bir sadeleştirme olduğunu sanır. Katalog temiz görünür, yönetimi kolaydır, müşteri seçenek karmaşasında boğulmaz. Sonra iade talepleri gelmeye başlar: mobil oyuncuya PC bölgesine tanımlı kod gitmiştir, konsol oyuncusu kodu kullanamamıştır, biri kodu yanlış hesaba işlemiş ve geri dönüşü olmayan bir kayıp yaşamıştır.
Bu iadelerin hiçbiri müşteri dikkatsizliğinden kaynaklanmaz. Kaynak, kataloğun kurulduğu ilk gün alınan bir karardır: aynı görünen ürünler aslında farklı ürünlerdir ve stok havuzları birbirine karışmamalıdır. Bu ayrım doğru kurulmadığında hiçbir müşteri hizmetleri çabası açığı kapatmaz. İyi bir e-pin scripti seçerken SKU modelinin nasıl çalıştığını sormak, teslimat hızını sormaktan daha önemlidir.
Aynı isim taşıyan iki kod gerçekten aynı ürün mü?
Değil. İki kodun aynı ürün sayılabilmesi için sadece ismi değil, kullanılabildiği platformu, bölgesini, para birimini ve hesap tipini de paylaşması gerekir. Bu dört değişkenden biri farklıysa elindeki şey iki ayrı üründür ve tek havuzda tutulmaları teslim hatası üretir.
Pratikte bunu test etmenin basit bir yolu var: kodu yanlış platformdaki bir müşteriye verdiğinde geri alabiliyor musun? Cevap hayırsa, o kod ayrı bir stok havuzunda yaşamalıdır. Bu ayrımı ürün seviyesinde yapmayan bir dijital ürün satış scripti, büyüdüğün ölçüde daha fazla zarar yazar.
Varyant mı, ayrı ürün mü: hangisi seni korur?
Varyant yapısı, aynı ürünün gerçekten değişebilir bir özelliği olduğunda doğrudur. Örneğin aynı platform ve bölgede farklı yükleme miktarları varyanttır. Ama platform değişikliği varyant değildir, çünkü fiyat, tedarikçi, teslim talimatı ve iade koşulları hepsi değişir.
Pratik kural şudur: teslim talimatı değişiyorsa ayrı ürün, değişmiyorsa varyant. Bu cümle tek başına kataloğunun yarısını düzeltir. Ayrı ürün kurmanın maliyeti biraz daha fazla sayfa yönetimidir; varyantta birleştirmenin maliyeti ise geri alınamayan kodlardır. Hangisinin daha pahalı olduğu açık.
| Ayrım kriteri | Örnek | Yapı | Stok havuzu | Risk |
|---|---|---|---|---|
| Platform | PC / mobil / konsol | Ayrı ürün | Ayrı | Kritik |
| Bölge kilidi | TR / global / EU | Ayrı ürün | Ayrı | Kritik |
| Hesap tipi | Ana hesap / alt hesap | Ayrı ürün | Ayrı | Yüksek |
| Yükleme miktarı | 100 / 500 / 1000 birim | Varyant | Ayrı satır | Orta |
| Tedarikçi | A tedarikçi / B tedarikçi | Aynı ürün | Etiketli alt havuz | Düşük |
| Kampanya paketi | Hediye kodlu set | Ayrı ürün | Ayrı | Orta |
SKU kodunu nasıl adlandırırsan ileride pişman olmazsın?
SKU, müşterinin göreceği isim değil, senin operasyonunun omurgasıdır. Bu yüzden okunabilir, tahmin edilebilir ve genişleyebilir olmalı. Oyun kısaltması, platform, bölge, miktar ve gerekiyorsa tedarikçi etiketi sabit bir sırayla dizilir. Bir kez seçtiğin sıraya sonsuza kadar uyarsın.
Kötü adlandırmanın bedeli, katalog üç yüz ürüne çıktığında ortaya çıkar: hangi kodun hangi havuza ait olduğunu kimse bilmez, toplu içe aktarma her seferinde elle temizlik gerektirir. Standart bir SKU şeması olan bir e-pin satış yazılımı, tedarikçi listelerini otomatik eşleştirebildiği için sana haftada saatler kazandırır.
Çoklu platform kataloğunda hata kaynakları
- Karışık stok havuzu 45%
- Eksik bölge bilgisi 25%
- Standart dışı SKU adlandırma 18%
- Yanlış teslim talimatı 12%
Ayrı sayfalar SEO'yu böler mi, güçlendirir mi?
Doğru kurulduğunda güçlendirir. Oyuncu arama yaparken platformu da yazar; mobil oyuncu ile konsol oyuncusu aynı kelimeyi kullanmaz. Her platform için ayrı ürün sayfası, bu farklı aramalara ayrı ayrı cevap verir ve tek sayfanın yakalayamadığı trafiği getirir.
Tehlike, sayfaların birbirine benzemesidir. Aynı açıklamayı kopyalayıp platform adını değiştirirsen kanibalizasyon üretirsin. Her sayfa kendi teslim talimatını, kendi uyumluluk notunu ve kendi sık sorulanını taşımalı. Pinova'nın ürün şablonu bu alanları ayrı tuttuğu için sayfalar kendiliğinden farklılaşır; yapıyı özellikler bölümünde görebilirsin.
Müşteri platformu ürün sayfasında değil sepette fark eder. Sepete platform ve bölge bilgisini büyük puntoyla tekrar bastır ve onay kutusu ekle. Bu tek hamle yanlış platform iadelerinin büyük bölümünü daha ödeme yapılmadan önler.
Stok havuzlarını ayırmadan otomatik teslimat kurulabilir mi?
Kurulabilir ama sürdürülemez. Otomatik teslimatın tek şartı, siparişin hangi havuzdan kod çekeceğinin tereddütsüz belli olmasıdır. Havuzlar karışıksa sistem doğru kodu seçemez ve sen her siparişi elle kontrol etmeye başlarsın; yani otomasyonun tamamını kaybedersin.
Doğru kurgu, her SKU'nun kendi havuzuna sahip olması ve havuza giren her kodun platform, bölge ve son kullanma bilgisiyle etiketlenmesidir. Bu yapı kurulduğunda ilk defasında doğru teslim oranı neredeyse yüzde yüze çıkar. Havuz bazlı stok yönetimi sunan bir epin yazılım altyapısı olmadan çoklu platform kataloğunu büyütmeye çalışmak, açık yaralı büyümektir.
Var olan karışık kataloğu nasıl temizlersin?
Geçmişi tek hamlede silmek yerine sırayla ilerlemek gerekir. Önce en çok iade alan ürünleri ayırırsın, sonra en çok satanları, en sonunda uzun kuyruğu. Eski ürün adreslerini yeni sayfalara yönlendirirsin ki birikmiş arama değeri kaybolmasın.
Temizlik sırasında her ürün için üç soruyu yazılı olarak cevaplarsın: hangi platform, hangi bölge, teslim talimatı ne. Bu üç cevap ürün kaydında alan olarak yaşamaya başladığında katalog kendini savunur hale gelir. Süreci hangi paketle yürütebileceğini fiyat sayfasında karşılaştırabilir, kurulum desteğini panel üzerinden talep edebilirsin.
| Kontrol maddesi | Ne sağlar | Durum |
|---|---|---|
| Her platform için ayrı SKU açıldı | Yanlış teslimatı kökten keser | Zorunlu |
| Bölge bilgisi ürün kaydında alan | Bölge kilidi iadelerini önler | Zorunlu |
| SKU adlandırma şeması yazılı | Toplu içe aktarmayı otomatikleştirir | Zorunlu |
| Stok havuzları SKU bazında ayrı | Otomatik teslimatı güvenilir kılar | Zorunlu |
| Sepette platform onay kutusu | Satış öncesi hatayı yakalar | Önerilir |
| Her sayfada özgün teslim talimatı | SEO kanibalizasyonunu engeller | Önerilir |
| Eski adresler yönlendirildi | Birikmiş arama değerini korur | Geçişte zorunlu |
| Kod etiketinde son kullanma tarihi | Süresi geçmiş kod teslimini durdurur | Önerilir |
Kataloğunu hata üretmeyecek şekilde kur
Platform, bölge ve teslim talimatını ayrı alanlarda tutan, her SKU'ya kendi stok havuzunu veren bir altyapıyla iade dosyalarını kapatıp otomatik teslimatı gerçekten otomatik hale getir.
Aynı oyunun PC ve mobil kodunu tek ürün altında satabilir miyim?
Teknik olarak mümkün ama önerilmez. Teslim talimatı ve kullanım koşulları farklı olduğu için yanlış teslimat riski yüksektir ve kullanılmış kod geri alınamaz. Her platform ayrı ürün ve ayrı stok havuzu olmalıdır.
Platform ayrımı varyant olarak yapılamaz mı?
Yapılmamalı. Varyant, teslim talimatı değişmeyen farklılıklar için uygundur. Platform değiştiğinde fiyat, tedarikçi, uyumluluk notu ve iade koşulu da değişir; bu ayrı ürün gerektirir.
Ayrı sayfalar açmak arama sıralamamı böler mi?
Sayfalar birbirinin kopyası olmadığı sürece bölmez, aksine genişletir. Her sayfaya kendi uyumluluk notunu, teslim talimatını ve sık sorulanını yazdığında farklı aramalardan ayrı trafik alırsın.
Mevcut karışık kataloğu nasıl geçiririm?
Kademeli ilerle. Önce en çok iade alan ve en çok satan ürünleri ayır, eski adresleri yeni sayfalara yönlendir, her ürün için platform ve bölge alanlarını doldur. Uzun kuyruğu en sona bırakabilirsin.
Çoklu platform kataloğunda kazanan, en çok ürünü listeleyen değil, hangi kodun kime gideceğini tereddütsüz bilen satıcıdır. SKU ayrımını bir kez doğru kurduğunda iade dosyaları kapanır, destek yükü düşer ve otomatik teslimat gerçekten kendi başına çalışır. Bu yapının hazır halini görmek istersen canlı demo üzerinden çok platformlu bir ürün ailesi oluşturup stok havuzlarının nasıl ayrıldığını kendin dene.