XML entegrasyonunda en sık sorulan teknik sorulardan biri şudur:

XML kaç dakikada bir güncellenmeli?

İlk bakışta cevap basit görünebilir:

Ne kadar sık güncellenirse o kadar iyi.

Ancak gerçek sistemlerde durum bu kadar basit değildir.

Örneğin tedarikçi XML dosyasını yalnızca saatte bir yeniliyorsa sizin aynı dosyayı her dakika kontrol etmeniz yeni stok bilgisine daha erken ulaşmanızı sağlamayabilir.

Diğer taraftan tedarikçi fiyat ve stokları çok sık değiştirdiği halde sizin entegrasyonunuz XML'i günde yalnızca bir kez okuyorsa satış kanallarınız uzun süre eski veriyle çalışabilir.

Bu nedenle xml güncelleme sıklığı belirlenirken yalnızca:

“Kaç dakikada bir çalıştıralım?”

sorusu sorulmamalıdır.

Asıl soru:

“Ürün verisinin değişmesinden müşterinin gördüğü son değere kadar geçen süreyi hangi seviyede tutmamız gerekiyor?”

olmalıdır.

Ulu İthalat'ın XML Bayilik sayfasında da özellikle stoksuz e-ticaret açısından stok ve fiyat değişikliklerinin düzenli biçimde takip edilmesi ve verinin güncel tutulmasının önemli olduğu belirtiliyor.

XML Güncelleme Sıklığı Nedir?

XML güncelleme sıklığı, entegrasyon sisteminin tedarikçi XML kaynağını hangi aralıklarla kontrol ederek yeni ürün, fiyat, stok ve diğer veri değişikliklerini kendi sistemine aktardığını ifade eder.

Örneğin sistem:

15 dakikada bir

saatte bir

günde birkaç kez

veya:

günde bir kez

XML'i kontrol edebilir.

Ticaret Bakanlığı E-Ticaret Akademisi de XML entegrasyonlarının içeriğe bağlı olarak saatlik, günlük veya haftalık güncellenebileceğini belirtiyor.

Burada önemli nokta:

en sık çalışan sistem = her zaman en doğru sistem

değildir.

Doğru sıklık operasyonun gerçek ihtiyacına göre belirlenmelidir.

1. Önce Üç Farklı Güncelleme Zamanını Birbirinden Ayırın

XML operasyonunda aslında tek bir “güncelleme süresi” yoktur.

Kaynak güncelleme süresi

Tedarikçi kendi sistemindeki değişikliği XML'e ne zaman yansıtıyor?

XML kontrol süresi

Sizin entegrasyonunuz XML'i ne kadar sık çekiyor?

Satış kanalına aktarım süresi

Yeni veri okunduktan sonra web sitesi veya pazaryerine ne kadar sürede ulaşıyor?

Bu üç süre birbirinden farklıdır.

2. Tedarikçinin XML'i Yenileme Sıklığını Öğrenin

Örneğin tedarikçi XML'i:

saatte bir

yeniliyor olabilir.

Sizin XML'i:

5 dakikada bir

kontrol etmeniz teknik olarak mümkün olabilir.

Ancak kaynak yalnızca saatte bir değişiyorsa çoğu kontrolde tamamen aynı dosyayı okuyabilirsiniz.

Bu nedenle ilk soru:

Tedarikçi XML verisini ne kadar sık yeniliyor?

olmalıdır.

3. Tedarikçinin Güncellemesi ile Sizin Kontrolünüzü Karıştırmayın

Bu 110 numaranın en kritik cannibalization ayrımlarından biridir.

Canlı XML Fiyat Kuralları Nasıl Oluşturulur? rehberinde, XML Tedarikçide Fiyat Güncelleme Sıklığı Neden Önemli? içeriğinin tedarikçi tarafındaki fiyat değişikliği ile bunun XML'e yansıması arasındaki süreyi ele aldığı açıkça belirtiliyor.

110 ise şunu soruyor:

Kaynak güncellendikten sonra bizim sistem bu değişikliği ne kadar hızlı fark etmeli?

4. Tedarikçinin Söylediği Sıklık ile Gerçek Davranışı Karşılaştırın

Tedarikçi:

“XML saatlik güncelleniyor.”

diyebilir.

Ancak bunu ölçmek de yararlı olabilir.

Belirli bir süre boyunca:

• stok değişiklikleri,
• fiyat değişiklikleri,
• dosya güncellenme zamanı,
• ürün değişiklik zamanları

izlenebilir.

Böylece teorik sıklık ile gerçek veri davranışı karşılaştırılabilir.

5. Toplam Veri Gecikmesini Bir Zincir Olarak Düşünün

Basitleştirilmiş olarak:

tedarikçi değişikliği

↓

XML'e yansıma

↓

XML'in sizin sistem tarafından okunması

↓

verinin işlenmesi

↓

satış kanalına gönderilmesi

↓

kanalın güncellemeyi uygulaması

şeklinde ilerler.

Dolayısıyla müşterinin gördüğü verinin gecikmesi yalnızca sizin XML cron süreniz değildir.

6. En Yavaş Aşama Toplam Tazeliği Sınırlayabilir

Tedarikçi XML'i:

4 saatte bir

güncelliyorsa sizin XML'i:

her 2 dakikada bir

çekmeniz stok bilgisini 2 dakikalık gerçek zamanlı veriye dönüştürmez.

Kaynak zaten eski olabilir.

Bu nedenle önce kaynak tazeliği ölçülmelidir.

7. Stok Verisine Fiyat ve İçerikten Farklı Öncelik Verebilirsiniz

Bütün XML alanlarının aynı hızda güncellenmesi gerekmeyebilir.

Örneğin:

stok

sipariş verilebilirliği doğrudan etkiler.

fiyat

zararına satış riskini etkileyebilir.

Ancak:

• açıklama,
• kategori metni,
• ek görsel

çoğu operasyonda aynı dakika içerisinde değişmek zorunda olmayabilir.

Teknik altyapı destekliyorsa kritik ve daha az kritik alanların güncelleme politikaları ayrılabilir.

8. Stok Genellikle En Zaman Hassas Alanlardan Biridir

Dropshipping modelinde ürün fiziksel olarak sizin deponuzda olmayabilir.

Tedarikçi stok:

5

gösterdi.

Bu stok diğer bayiler tarafından tüketilebilir.

Sizin sisteminiz birkaç saat eski stokla çalışıyorsa müşteri artık bulunmayan ürünü satın alabilir.

Bu nedenle stok değişim hızı güncelleme sıklığı kararında önemli faktörlerden biridir.

9. Çok Hızlı Satan Ürünleri Ayrı Değerlendirin

Ürün A:

ayda bir satılıyor.

Ürün B:

saat içerisinde birkaç sipariş alabiliyor.

İkisinin de XML kontrolünü aynı risk seviyesinde değerlendirmek zorunlu değildir.

Hızlı satan ürünlerde eski stok bilgisinin ticari etkisi daha yüksek olabilir.

10. Düşük Stoklu Ürünlerde Veri Tazeliği Daha Kritik Hale Gelebilir

Tedarikçide:

500 adet

bulunan ürün ile:

2 adet

kalan ürün aynı riskte değildir.

Düşük stoklu ürünlerde bir sonraki satışla gerçek stok tükenebilir.

Bu nedenle sistem destekliyorsa:

düşük stok → daha yüksek güncelleme önceliği

mantığı düşünülebilir.

Ancak bunun yerine veya yanında stok tamponu da kullanılabilir.

Canlı XML Stok Eşiği Kullanmak Neden Önemlidir? içeriği ham tedarikçi stoğu ile satışa açılabilir stoğu ayrı değerlendiriyor.

11. Stok Eşiği Güncelleme Sıklığının Yerine Geçmez

Örneğin:

stok ≤ 3 → satış kapalı

kuralınız olabilir.

Ancak XML'i çok seyrek okuyorsanız gerçek stok:

0

olduğu halde sizin son bildiğiniz değer:

8

olabilir.

Bu durumda stok eşiği hiç devreye giremez.

Dolayısıyla:

stok eşiği + yeterli veri tazeliği

birlikte düşünülmelidir.

12. Fiyat Değişim Hızını da Ölçün

Bazı tedarikçilerin fiyatları nadiren değişebilir.

Bazılarında:

• döviz,
• kampanya,
• maliyet,
• tedarik koşulları

nedeniyle daha sık değişiklik olabilir.

Fiyatın sık değiştiği kataloglarda çok seyrek senkronizasyon eski maliyetle satış yapılmasına neden olabilir.

13. Fiyat Güncellemesini Fiyat Kuralından Ayırın

Tedarikçinin yeni maliyeti:

100 TL → 130 TL

olarak değişti.

110'un görevi:

130 TL'yi ne kadar sürede fark edeceğim?

sorusudur.

Canlı XML Fiyat Kuralları Nasıl Oluşturulur? içeriğinin görevi ise:

130 TL doğru maliyetse müşteriye hangi satış fiyatını oluşturacağım?

sorusudur.

Bu ayrım korunmalıdır.

14. Fiyat Yükselişlerinin Ticari Etkisini Hesaba Katın

Eski fiyatı uzun süre kullanmak özellikle maliyet artışlarında zarar riski oluşturabilir.

Örneğin:

tedarikçi maliyeti yükseldi,

ancak mağaza üç saat daha eski maliyet üzerinden fiyat üretmeye devam etti.

Bu üç saat içerisinde alınan siparişler istenmeyen marjla oluşabilir.

Dolayısıyla fiyat volatilitesi XML sıklığını etkileyen faktörlerden biridir.

15. Fiyat Düşüşleri de Kontrolsüz Uygulanmamalıdır

Daha sık XML çekmek yalnızca avantaj değildir.

Kaynakta yanlışlıkla:

1.500 → 150

fiyat hatası oluştuysa sık çalışan entegrasyon hatayı da daha hızlı yayabilir.

Bu nedenle:

daha sık senkronizasyon

ile

daha güçlü doğrulama

birlikte kurulmalıdır.

16. Aktif/Pasif Ürün Değişiklikleri de Zaman Hassas Olabilir

Tedarikçi bir ürünü:

aktif → pasif

durumuna geçirdi.

Sizin XML kontrolünüz bunu saatler sonra fark ederse ürün satışta kalabilir.

Canlı XML ile Pasife Alınan Ürünler Nasıl Yönetilir? rehberi tedarikçi ürün durumunun mağaza ve satış kanallarında nasıl yönetileceğini ayrıntılı ele alıyor.

110 burada yalnızca:

pasiflik değişikliğini ne kadar hızlı fark etmeliyim?

sorusunu sahiplenmelidir.

17. Bütün Feed'i Her Seferinde Baştan İşlemek Gerekli Olmayabilir

XML içerisinde:

10.000 ürün

bulunabilir.

Her beş dakikada bir:

• bütün görselleri,
• bütün açıklamaları,
• bütün kategorileri,
• bütün ürün metinlerini

yeniden işlemek gereksiz kaynak kullanımı oluşturabilir.

Önce değişen kayıtların belirlenmesi daha verimli olabilir.

18. Dosyayı Kontrol Etme ile Ürünleri Güncelleme İşlemini Ayırabilirsiniz

Sistem:

XML'i sık kontrol et

ama:

yalnızca değişen ürünleri işle

şeklinde çalışabilir.

Bu yapı özellikle büyük kataloglarda kaynak tüketimini azaltabilir.

19. Değişiklik Karşılaştırması Kullanabilirsiniz

Yeni XML ile önceki XML karşılaştırılabilir.

Örneğin:

SKU ABC:

önceki stok → 12

yeni stok → 12

ise tekrar ürün güncellemesi gerekmeyebilir.

Başka SKU:

önceki stok → 12

yeni stok → 4

ise işlem yapılabilir.

20. Alan Bazlı Değişiklik Takibi Yapabilirsiniz

Ürünün yalnızca:

stok

değişmiş olabilir.

Sistem bu nedenle:

• açıklama,
• görsel,
• kategori,
• slug

gibi alanları tekrar işlemek zorunda olmayabilir.

Özellikle binlerce ürün bulunan feed'lerde bu yaklaşım yararlı olabilir.

21. Feed Büyüklüğünü Güncelleme Sıklığı Kararında Hesaba Katın

500 ürünlük küçük XML ile:

50.000 ürünlük büyük XML

aynı işlem yüküne sahip değildir.

Dosyanın:

• indirilme süresi,
• parse süresi,
• karşılaştırma süresi,
• veritabanı yazma süresi

ölçülmelidir.

22. Güncelleme İşleminin Ne Kadar Sürdüğünü Ölçün

Örneğin job:

10 dakikada bir

çalışıyor.

Ancak bir çalışmanın tamamlanması:

18 dakika

sürüyor.

Bu durumda yeni job önceki işlem bitmeden başlayabilir.

Bu da:

• çakışan senkronizasyon,
• aynı ürünün iki kez işlenmesi,
• kaynak tüketimi,
• tutarsız kayıt

problemleri oluşturabilir.

23. Bir Önceki Senkronizasyon Bitmeden Yeni Senkronizasyon Başlatmayın

Sistem:

RUNNING

durumunu kaydedebilir.

Yeni job geldiğinde önceki işlem hâlâ çalışıyorsa:

bekle

veya:

o turu atla

gibi politika kullanılabilir.

Bu, özellikle uzun XML dosyalarında önemlidir.

24. Kilit Mekanizması Kullanabilirsiniz

Örneğin entegrasyon:

supplier_1_sync_lock

oluşturabilir.

İşlem bitince kilit kaldırılır.

Bu sayede aynı tedarikçi XML'inin aynı anda birden fazla süreç tarafından işlenmesi önlenebilir.

25. Farklı Tedarikçilere Farklı Sıklık Uygulayabilirsiniz

Tedarikçi A:

stokları çok sık değiştiriyor.

Tedarikçi B:

günde birkaç kez değişiklik yapıyor.

Tedarikçi C:

yalnızca haftada birkaç kez yeni ürün ekliyor.

Tek bir global:

“bütün XML'leri 15 dakikada bir çek”

kuralı zorunlu değildir.

Tedarikçi bazlı plan oluşturulabilir.

26. Çok Tedarikçili Ürünlerde Öncelikli Kaynağı Daha Sık Takip Edebilirsiniz

Aynı ürün birkaç tedarikçiden geliyorsa:

aktif satış kaynağı

diğer kaynaklara göre daha kritik olabilir.

Ana tedarikçinin stok ve fiyat değişiklikleri daha yüksek öncelikle işlenebilir.

Yedek tedarikçi yine takip edilir ancak operasyon kuralı farklı olabilir.

27. XML Güncelleme Sıklığını Satış Saatlerine Göre Ayarlamak Mümkün Olabilir

Bazı mağazalarda satış yoğunluğu günün belirli saatlerinde artabilir.

Teknik altyapı destekliyorsa:

yoğun saatlerde daha sık

düşük trafik dönemlerinde daha seyrek

kontrol yapılabilir.

Ancak e-ticaret 24 saat sipariş alabildiği için gece tamamen senkronizasyonu durdurmak otomatik olarak doğru değildir.

28. Kampanya Dönemlerinde Geçici Olarak Daha Sık Kontrol Gerekebilir

Kampanya dönemlerinde:

• ürün satış hızı artabilir,
• stok daha hızlı düşebilir,
• fiyat değişiklikleri yoğunlaşabilir.

Bu nedenle normal dönemde yeterli olan sıklık kampanya döneminde yetersiz kalabilir.

Kampanya bittikten sonra sistem normal programa dönebilir.

29. İlk XML Aktarımı ile Rutin Güncellemeyi Ayırın

İlk aktarımda:

• ürün adı,
• açıklama,
• kategori,
• marka,
• görseller,
• fiyat,
• stok

tamamen oluşturulabilir.

Rutin güncellemede ise yalnızca:

• fiyat,
• stok,
• aktiflik,
• değişen kritik alanlar

işlenebilir.

Bu ayrım işlem yükünü ciddi biçimde değiştirebilir.

30. Görselleri Her Senkronizasyonda Yeniden İndirmeyin

Görsel URL'si değişmediyse aynı dosyayı her XML kontrolünde tekrar indirmek gereksiz olabilir.

Görsel alanının kalite ve güncelleme yönetimi ayrı ele alınmalıdır.

Bu özellikle büyük kataloglarda senkronizasyon süresini azaltabilir.

31. Açıklamaları Her Fiyat Değişikliğinde Yeniden Yazmayın

Ürünün yalnızca fiyatı değiştiğinde özgünleştirilmiş açıklamayı tedarikçinin ham açıklamasıyla yeniden değiştirmek doğru olmayabilir.

Alan bazlı güncelleme politikası kullanılmalıdır.

Örneğin:

stok → dinamik

fiyat → dinamik

açıklama → yalnızca kontrollü güncelleme

şeklinde olabilir.

32. XML Ürün Verisi Normalizasyonunu Her Seferinde Gereksiz Yere Baştan Yapmayın

Canlı XML Ürün Verisi Normalizasyonu Nedir? içeriği farklı kaynak verilerinin ortak veri modeline dönüştürülmesini ele alıyor.

Bir ürünün ham marka, kategori ve ölçü verileri değişmediyse normalizasyonun sonucu da aynı kalabilir.

Değişiklik bazlı işleme kullanılabilir.

33. Başarısız Güncellemeyi Başarılı Gibi Kaydetmeyin

XML job başladı ancak:

• dosya indirilemedi,
• parser hata verdi,
• veritabanı yazımı yarıda kaldı.

Sistem yine:

last_sync = şimdi

yazarsa gerçek veri yaşı gizlenmiş olur.

Bunun yerine:

last_attempt

ve

last_successful_sync

ayrı tutulabilir.

34. Son Başarılı Senkronizasyon Zamanını Görünür Hale Getirin

Örneğin panelde:

Son deneme: 14:05

Son başarılı senkronizasyon: 12:00

gösterilebilir.

Bu durumda sistemin iki saattir güncellenemediği açıkça görülür.

Yalnızca son deneme zamanını göstermek problemi gizleyebilir.

35. Veri Yaşını Ölçün

Sadece:

“XML her 15 dakikada bir çalışıyor.”

bilgisi yeterli değildir.

Daha yararlı metrik:

bu stok bilgisi kaç dakikalık?

olabilir.

Örneğin:

source_data_age

veya:

last_success_age

takip edilebilir.

36. Veri Yaşı Belirli Seviyeyi Geçerse Alarm Oluşturun

Normalde veri sık güncelleniyor.

Ancak son başarılı senkronizasyon:

saatler önce

kalmış olabilir.

Bu durumda:

• teknik uyarı,
• belirli ürünlerin satışını sınırlama,
• manuel kontrol

gibi aksiyonlar düşünülebilir.

Gerçek sınır işletmeye ve risk profiline göre belirlenmelidir.

37. Başarısız Senkronizasyonda Eski Veriyi Hemen Silmeyin

XML indirilemedi diye mevcut:

• stok,
• fiyat,
• ürün

verilerini tamamen silmek genellikle tehlikeli bir davranış olur.

Önceki doğrulanmış veri korunabilir ve sistem başarısızlık durumu kaydedebilir.

Ancak eski verinin ne kadar süreyle güvenli kabul edileceği ayrıca belirlenmelidir.

38. Retry Mekanizması Kullanın

Geçici ağ problemi nedeniyle XML indirilememiş olabilir.

Sistem belirli süre sonra tekrar deneyebilir.

Ancak:

başarısız oldu → saniyede onlarca kez tekrar dene

yaklaşımı tedarikçi ve kendi sisteminiz üzerinde gereksiz yük oluşturabilir.

Kontrollü retry politikası kullanılmalıdır.

39. Sürekli Aynı Aralıkla Retry Yapmak Zorunda Değilsiniz

Örneğin ilk başarısızlıktan sonra kısa süre içerisinde yeniden deneme yapılabilir.

Arka arkaya başarısızlık devam ederse aralık kademeli artırılabilir.

Bu yaklaşım sistemin tamamen kilitlenmeden geçici sorunlara tepki vermesini sağlayabilir.

40. Tedarikçinin Teknik Kullanım Şartlarını Kontrol Edin

XML sağlayıcısı:

• istek sınırı,
• önerilen kontrol aralığı,
• IP kısıtlaması,
• belirli kullanım şartları

uygulayabilir.

Bu nedenle:

“Ben istersem saniyede bir çekerim.”

varsayımı yapılmamalıdır.

Tedarikçi ile teknik sınırlar doğrulanmalıdır.

41. Daha Sık Güncellemenin Sunucu Maliyetini Hesaba Katın

Her XML kontrolü:

• ağ trafiği,
• CPU,
• RAM,
• veri tabanı sorguları,
• görsel işlemleri

oluşturabilir.

Güncelleme sıklığı artırılırken sistem kaynak tüketimi de ölçülmelidir.

Amaç:

en sık cron

değil,

gereken veri tazeliğini güvenli kaynak tüketimiyle sağlamak

olmalıdır.

42. Aynı XML Değişmediyse Gereksiz İşlem Yapmaktan Kaçının

Teknik sistem destekliyorsa dosyanın:

• değişiklik zamanı,
• içerik hash'i,
• sürüm bilgisi

karşılaştırılabilir.

Dosya tamamen aynıysa bütün ürün kataloğunun yeniden işlenmesi gerekmeyebilir.

43. Ürün Bazlı Değişiklik Logu Tutun

Örneğin:

SKU ABC123

12:00 → stok 8

12:15 → stok 8

12:30 → stok 4

12:45 → stok 0

şeklinde kayıt tutulabilir.

Bu veriler daha sonra gerçekten ne kadar sık güncellemeye ihtiyaç olduğunu belirlemede kullanılabilir.

44. Tedarikçi Bazında Gerçek Değişiklik Sıklığını Ölçün

Örneğin bir ayda:

stok alanı 40.000 kez

fiyat alanı 200 kez

değişmiş olabilir.

Bu size:

stok yüksek frekanslı

fiyat daha düşük frekanslı

bir veri yapısı olduğunu gösterebilir.

Güncelleme politikası gerçek gözleme göre ayarlanabilir.

45. Değişmeyen Veriyi Çok Sık Çekmenin Ek Değerini Sorgulayın

Tedarikçi günde yalnızca bir kez katalog üretirken dakikada bir sorgu göndermek:

1.440 kontrol

yapıp yalnızca bir gerçek değişiklik yakalamak anlamına gelebilir.

Bu örnek yalnızca mantığı göstermek içindir.

Sıklık, yakalanan gerçek değişikliklerle birlikte değerlendirilmelidir.

46. Güncelleme Sıklığını İptal Oranıyla İlişkilendirin

Stok kaynaklı sipariş iptalleri yüksekse:

stok tazeliği yeterli mi?

sorusu araştırılabilir.

Örneğin iptal anında mağazadaki stok verisinin yaşı incelenebilir.

Sorun sürekli eski XML verisinden kaynaklanıyorsa daha sık kontrol yararlı olabilir.

47. Fiyat Kaynaklı Zararları da Ölçün

Ürün eski maliyetle satılmışsa:

son başarılı fiyat güncellemesi ne zamandı?

kontrol edilebilir.

Fiyat değişikliği ile mağazaya yansıma arasında düzenli olarak uzun gecikme varsa senkronizasyon planı yeniden değerlendirilmelidir.

48. “Her 5 Dakika” Gibi Evrensel Reçete Kullanmayın

XML güncelleme sıklığı için:

5 dakika en iyidir

1 saat yeterlidir

günde bir kez yapılmalıdır

şeklinde evrensel bir doğru yoktur.

Ticaret Bakanlığı'nın XML entegrasyonu açıklamasında da güncellemenin paylaşılan veriye göre saatlik, günlük veya haftalık olabileceği ifade ediliyor.

Doğru sıklık:

işletmenin riskine ve veri davranışına göre

belirlenmelidir.

49. Adaptif Güncelleme Sistemi Kullanılabilir

Gelişmiş bir sistem:

normal ürünler → standart sıklık

düşük stok → daha sık

hızlı satan ürün → daha sık

kampanya → daha sık

uzun süre değişmeyen katalog → daha seyrek

mantığı kullanabilir.

Ancak karmaşık sistemlerin bakım maliyeti de vardır.

Basit fakat güvenilir kural bazen daha iyi olabilir.

50. Sıklığı Belirledikten Sonra Ölçmeye Devam Edin

XML güncelleme sıklığı bir kez belirlenip sonsuza kadar unutulmamalıdır.

Şunlar değişebilir:

• ürün sayısı,
• satış hacmi,
• tedarikçi,
• pazaryeri sayısı,
• sunucu kapasitesi,
• XML boyutu,
• tedarikçi güncelleme davranışı.

Bu nedenle senkronizasyon planı düzenli aralıklarla yeniden değerlendirilmelidir.

XML GÜNCELLEME SIKLIĞI İÇİN PRATİK KONTROL LİSTESİ

1. Tedarikçi XML'i gerçekte ne kadar sık yeniliyor?
2. Kaynak fiyat değişiklikleri ne kadar sık?
3. Kaynak stok değişiklikleri ne kadar sık?
4. Stok ortak tedarikçi stoğu mu?
5. Ürünlerin satış hızı ne?
6. Düşük stoklu ürünler ayrıca yönetiliyor mu?
7. Aktif/pasif değişiklikleri ne kadar kritik?
8. XML kaç ürün içeriyor?
9. Dosyanın indirilmesi ne kadar sürüyor?
10. Parse süresi ne kadar?
11. Veritabanına yazma süresi ne kadar?
12. Tek job bir sonraki job başlamadan bitiyor mu?
13. Değişmeyen ürünler tekrar işleniyor mu?
14. Fiyat ve stok diğer alanlardan ayrı güncellenebiliyor mu?
15. Son başarılı senkronizasyon kaydediliyor mu?
16. Veri yaşı ölçülüyor mu?
17. Senkronizasyon başarısız olduğunda alarm var mı?
18. Retry politikası var mı?
19. Tedarikçi istek sınırları biliniyor mu?
20. Pazaryerine aktarım gecikmesi ölçülüyor mu?
21. Stok kaynaklı iptaller izleniyor mu?
22. Eski fiyat kaynaklı zararlar izleniyor mu?
23. Kampanya döneminde farklı kural gerekiyor mu?
24. Güncelleme sıklığı düzenli olarak yeniden değerlendiriliyor mu?

XML GÜNCELLEME SIKLIĞI NASIL BELİRLENİR?

Pratik süreç şu şekilde kurulabilir:

1. Tedarikçinin resmi XML yenileme politikasını öğrenin.

2. Gerçek veri değişikliklerini birkaç hafta ölçün.

3. Stok ve fiyat değişikliklerini ayrı inceleyin.

4. XML feed büyüklüğünü ölçün.

5. Bir tam senkronizasyonun ne kadar sürdüğünü hesaplayın.

6. Hızlı ve yavaş satan ürünleri ayırın.

7. Düşük stok riskini belirleyin.

8. Fiyat değişim riskini ölçün.

9. Tedarikçinin aktif/pasif ürün davranışını inceleyin.

10. Kabul edilebilir maksimum veri yaşını belirleyin.

11. İlk XML kontrol aralığını buna göre seçin.

12. İşlem süresinin kontrol aralığından kısa kaldığını doğrulayın.

13. Değişiklik bazlı ürün işleme kurun.

14. Kritik alanları diğer içerik alanlarından ayırın.

15. Son başarılı senkronizasyon zamanını kaydedin.

16. Başarısız işlemler için retry ve alarm kurun.

17. Pazaryeri aktarım gecikmesini ayrıca ölçün.

18. Önce sınırlı ürün grubunda test edin.

19. İptal, stok uyuşmazlığı ve fiyat hatalarını takip edin.

20. Gerçek sonuçlara göre kontrol sıklığını artırın veya azaltın.

SIK SORULAN SORULAR

XML kaç dakikada bir güncellenmeli?

Bütün XML sistemleri için geçerli tek bir süre yoktur. Tedarikçinin kendi XML yenileme sıklığı, stok ve fiyat değişim hızı, ürün satış hızı, feed büyüklüğü ve satış kanallarına aktarım süresi birlikte değerlendirilmelidir. Ticaret Bakanlığı E-Ticaret Akademisi de XML entegrasyonlarının verinin yapısına göre saatlik, günlük veya haftalık güncellenebileceğini belirtiyor.

XML'i ne kadar sık çekersem stok problemi o kadar azalır mı?

Belirli bir noktaya kadar veri tazeliği iyileşebilir; ancak tedarikçinin XML'i zaten seyrek yenileniyorsa çok sık sorgulamak daha yeni veri üretmez. Ayrıca stok eşiği, kanal senkronizasyonu ve tedarikçinin gerçek stok güvenilirliği de birlikte değerlendirilmelidir.

Stok ve fiyat aynı sıklıkta güncellenmek zorunda mı?

Hayır. Teknik altyapı destekliyorsa stok, fiyat, ürün açıklaması ve görsel gibi veri grupları farklı güncelleme politikalarına sahip olabilir. Özellikle stok ve fiyat genellikle daha zaman hassas alanlardır.

XML güncellemesi başarısız olursa ne yapılmalı?

Başarısız senkronizasyon kaydedilmeli, önceki doğrulanmış veri kontrolsüz biçimde silinmemeli ve uygun retry politikası uygulanmalıdır. Ayrıca son deneme ile son başarılı senkronizasyon zamanlarının ayrı tutulması veri tazeliğini daha doğru gösterir.

Her ürün için farklı XML güncelleme sıklığı kullanılabilir mi?

Teknik olarak mümkün olabilir. Özellikle yüksek satış hızlı, düşük stoklu veya çok değişken fiyatlı ürünlere daha yüksek öncelik verilebilir. Ancak çok karmaşık kurallar operasyonel bakım yükü yaratabileceği için sistem mümkün olduğunca ölçülebilir ve yönetilebilir tutulmalıdır.

AMAÇ XML'İ MÜMKÜN OLAN EN SIK ÇEKMEK DEĞİL, VERİYİ GEREKTİĞİ KADAR TAZE TUTMAKTIR

XML güncelleme sıklığı için yanlış yaklaşım:

“Sunucu kaldırıyorsa her dakika çalıştıralım.”

şeklindedir.

Daha kontrollü yapı:

tedarikçinin kaynak yenileme sıklığını öğren → stok ve fiyat değişim hızını ölç → satış riskini belirle → XML işlem süresini hesapla → kabul edilebilir veri yaşını belirle → uygun kontrol aralığını seç → yalnızca değişen kayıtları işle → kanal aktarımını takip et → başarısız senkronizasyonu alarm üret → sonuçları ölç → gerektiğinde sıklığı yeniden düzenle

şeklinde kurulabilir.

En kritik nokta şudur:

XML'i her 10 dakikada bir kontrol etmek, ürün verisinin 10 dakikalık olduğu anlamına gelmez.

Örneğin tedarikçi kendi XML'ini üç saat önce oluşturmuşsa sizin entegrasyonunuz o eski veriyi 10 dakikada bir tekrar tekrar okuyabilir.

Bu nedenle gerçek veri tazeliğini:

kaynak → entegrasyon → mağaza → satış kanalı

zincirinin tamamında ölçmek gerekir.