XML Feed'de Hayalet Stok Nedir, Nasıl Önlenir? Olmayan Ürünü Satmanın Bedeli

Hayalet Stok Nedir?

Hayalet stok, mağazanda satılabilir görünen ama tedarikçi deposunda bulunmayan üründür. Adı buradan gelir: veride vardır, gerçekte yoktur. XML bayilikte stok bilgisi sana tedarikçinin feed'i üzerinden gelir; feed ile gerçek depo arasındaki her sapma, potansiyel bir hayalet stoktur.

Kritik nokta şu: hayalet stok bir veri tazeliği problemidir, bir stok problemi değil. Tedarikçinin deposu doğru olabilir; sana ulaşan veri eski olduğu için sen yanlış satarsın. Yani sorun genelde tedarikçide değil, veri ile gerçek arasındaki gecikmededir.

Neden Bu Kadar Pahalı?

Olmayan ürünü satmanın maliyeti, kaçırılan bir satıştan çok daha büyüktür. Çünkü zincirleme gider:

• Sipariş iptali: pazaryerinde satıcı kaynaklı iptal, doğrudan hizmet/mağaza puanını düşürür.
• Termin aşımı: iptal etmeyip beklersen bu sefer geç gönderim cezası yersin. İki kötü seçenek arasında kalırsın.
• Mağaza askısı: ardışık iptaller pazaryerinde mağazanın geçici olarak kapatılmasına kadar gider.
• Müşteri güveni: iptal edilen sipariş, bir daha gelmeyen müşteri demektir.
• Görünürlük kaybı: puanı düşen mağaza aramalarda geriye düşer; kayıp o siparişle sınırlı kalmaz.

Yani hayalet stok tek bir siparişi değil, mağazanın geleceğini yer. Bu yüzden stok doğruluğu, stoksuz modelde fiyatlandırma kadar kritiktir.

Sebep 1: Güncelleme Sıklığı Yetersiz

En yaygın sebep bu. Feed'i günde bir kez çekiyorsan, tedarikçinin sabah tükenen ürünü senin vitrinde akşama kadar satılabilir kalır. Hızlı dönen kategorilerde bu pencere fazlasıyla geniştir.

• Günde 1 çekim: yavaş dönen kategoriler dışında yetersizdir.
• Saatlik çekim: çoğu kategori için kabul edilebilir taban.
• Kritik/hızlı dönen ürünler: daha sık kontrol ya da sipariş anında canlı doğrulama gerekir.
• Sipariş anında doğrulama: en güvenli katman — satış öncesi son kontrol.

Sıklığı artırmanın sınırı tedarikçinin sunucusudur. Feed büyükse (on binlerce ürün) her çekim maliyetlidir; tedarikçi seni engelleyebilir. Bu yüzden sıklık, feed boyutuna ve kategorinin dönüş hızına göre ayarlanmalı — kör bir şekilde "her dakika çek" demek çözüm değildir.

Sebep 2: Feed Bayatlıyor ama Kimse Fark Etmiyor

Bu, birincisinden daha tehlikelidir. Feed URL'i çalışıyor, HTTP 200 dönüyor, veri geliyor — ama tedarikçi feed'i günlerdir güncellemiyor. Sen taze veri çektiğini sanırsın; aslında aynı bayat dosyayı tekrar tekrar indiriyorsundur.

Senkron başarılı görünür, log'lar temizdir, hiçbir alarm çalmaz. Bu yüzden en sinsi sebep budur: sistemin her parçası "çalışıyorum" der, sonuç yanlıştır.

• Feed'in son güncelleme zamanını takip et; dosyanın kendi tarih alanı varsa oku.
• Çekilen veri hiç değişmiyorsa bu bir uyarı sinyalidir — özellikle binlerce ürünlük feed'de hiçbir fiyat/stok değişmemesi normal değildir.
• Feed'in içeriğinin özetini (hash) tut; ardışık çekimlerde aynı özet çıkıyorsa tedarikçiye sor.
• Bayatlık eşiği koy: feed X saattir güncellenmediyse uyar.

Sebep 3: Pasif Ürün Feed'den Çıkmıyor

Bazı tedarikçiler ürünü pasife çektiğinde onu feed'den tamamen çıkarır. Bu iyi görünür ama tehlikeli bir yan etki yaratır: senin sisteminde o ürün hâlâ eski stok değeriyle durur, çünkü güncelleme gelmemiştir.

Yani ürün feed'den kaybolduğu için "değişmedi" sanılır ve son bilinen stok değeri korunur. Sonuç: pasife alınmış, artık satılmayan bir ürün senin vitrinde stokta durur.

Doğru davranış: her senkronda feed'de görülmeyen ürünleri işaretle ve stoğunu sıfırla. Bunu yaparken dikkat: feed geçici olarak eksik gelmişse (kısmi indirme, timeout) tüm katalogu sıfırlamak felaket olur. Bu yüzden bir sonraki başlıktaki koruma katmanı şart.

Sebep 4: Ürün Kodu Değişiyor (Churn)

Bazı tedarikçiler aynı ürünü zamanla farklı ürün koduyla yayınlar. Senin sistemin bunu yeni ürün sanır; eski kod ise feed'de görünmediği için yetim kalır. Katalogda hem ölü bir kayıt hem de yeni bir kopya oluşur.

Bunu kendi feed'lerimizden birinde ölçtüğümüzde, kod değişim oranının katalogun yarısına yaklaştığını gördük. Bu ölçekte eşleştirmeyi ürün koduna dayandırmak çalışmaz; kod bir kimlik değil, geçici bir etikettir.

• Eşleştirmeyi mümkünse barkoda dayandır — barkod, ürün kodundan çok daha kararlıdır.
• Kod churn oranını ölç: her senkronda kaç ürün kayboluyor, kaç yeni ürün geliyor?
• Kaybolan kodları hemen silme; önce stoğunu sıfırla, sonra bir süre gözlemle.
• Churn oranı yüksekse tedarikçiyle konuş — bu genelde onların ürün yönetiminde bir sorunun belirtisidir.

Sebep 5: Aynı Ürünün Çift Kaydı

Feed'de aynı ürün birden fazla kayıtla gelebilir: biri güncel ve stoklu, diğeri eski ve stoksuz (ya da tam tersi). Sisteminin hangisini esas aldığı, hayalet stok üretip üretmediğini belirler.

Yanlış kaydı seçersen iki yönlü hata çıkar: stoklu ürünü stoksuz sanıp satıştan kaldırırsın (ciro kaybı) ya da stoksuz ürünü stoklu sanıp satarsın (hayalet stok). İkisi de zarar.

• Çift kayıtları ürün koduna göre grupla ve bir tekilleştirme kuralı belirle.
• Kural net olmalı: hangi kayıt kazanır — en yüksek stoklu mu, en güncel mi?
• Tekilleştirme yoksa hangi kaydın geldiğine bağlı olarak stok her senkronda değişir; bu, takip edilemez bir dalgalanma yaratır.

Sebep 6: Tedarikçi Tatilde ama Feed Açık

Tedarikçi tatile girer, kargo göndermeyi durdurur — ama XML feed'i yayında kalır ve ürünler stokta görünmeye devam eder. Senin açından her şey normaldir: satarsın, sipariş alırsın, sonra kimse kargolamaz.

Bu senaryoyu iki tedarikçimizde yaşadık. Feed teknik olarak sağlıklıydı, veri geliyordu, hiçbir alarm çalmıyordu; ama depoda kimse yoktu. Teknik izleme bunu asla yakalayamaz, çünkü ortada teknik bir arıza yok.

Koruma Katmanı: Staleness Guard

Feed'den kaybolan ürünü sıfırlamak doğru davranıştır — ama tek başına tehlikelidir. Tedarikçinin sunucusu yarım cevap verirse, bağlantı koparsa ya da feed kısmi inerse, sistem "ürünler kayboldu" sanıp tüm katalogu sıfırlayabilir. Bir anda 60.000 ürün stoksuz olur.

Bu yüzden bir staleness guard (bayatlık koruması) gerekir: feed beklenenden çok daha küçük geldiyse, senkronu uygulamak yerine reddet ve uyar.

1. Her başarılı senkronda feed'in ürün sayısını kaydet.
2. Yeni feed, son bilinen sayının belirlediğin eşiğinin altındaysa (örneğin yarısı) senkronu uygulama.
3. Bunun yerine uyarı üret ve bir önceki veriyi koru — eski veri, boş veriden iyidir.
4. Guard tetiklendiğinde sebebi araştır: tedarikçi mi katalog küçülttü, yoksa indirme mi yarım kaldı?

Hayalet Stok Nasıl Ölçülür?

Ölçmediğin şeyi düzeltemezsin. Hayalet stok oranının tek dürüst ölçüsü şudur: stok yok diye iptal edilen sipariş sayısı ÷ toplam sipariş sayısı.

• Bu oranı tedarikçi bazında takip et — genelde sorun tek bir tedarikçide toplanır.
• Kategori bazında da bak: hızlı dönen kategorilerde oran doğal olarak yüksektir.
• İptal sebebini kaydetmiyorsan bu oranı hiç hesaplayamazsın; sebep kaydı şart.
• Oran yükseliyorsa önce güncelleme sıklığına, sonra feed tazeliğine bak.

Bu oranı düşürmenin en hızlı yolu genelde teknik değil, ticari: sürekli hayalet stok üreten tedarikçiyi ya düzeltmeye zorla ya da o kategoride başka tedarikçiye geç. Veri doğruluğu, tedarikçi seçiminin bir kriteridir.

Önleme Kontrol Listesi

1. Güncelleme sıklığı kategorinin dönüş hızına uygun mu? Günde bir çekim çoğu kategori için yetersiz.
2. Feed tazeliği izleniyor mu? Veri hiç değişmiyorsa alarm çalmalı.
3. Feed'de olmayan ürün otomatik sıfırlanıyor mu?
4. Staleness guard var mı — ve kalıcı kilitlenmeye karşı manuel çıkış yolu var mı?
5. Çift kayıt tekilleştirme kuralı tanımlı mı?
6. Barkod eşleştirme kullanılıyor mu, yoksa kırılgan ürün koduna mı güveniliyor?
7. Tedarikçi tatil takvimi biliniyor mu ve elle dondurma yolu var mı?
8. İptal sebepleri kaydediliyor mu? Kaydedilmiyorsa hayalet stok oranını ölçemezsin.

Bu sekiz madde, hayalet stok kaynaklı iptallerin büyük kısmını kapatır. Hiçbiri tek başına yeterli değildir; hayalet stok tek sebepli bir arıza değil, veri ile gerçek arasındaki mesafenin toplamıdır.