Bir tedarikçiden XML dosyası aldığınızda ilk sorulardan biri genellikle şudur:

Bu XML'de hangi ürün alanlarının bulunması gerekiyor?

İlk bakışta sabit bir liste oluşturmak kolay görünebilir:

• ürün adı,
• fiyat,
• stok,
• barkod,
• marka,
• açıklama,
• görsel.

Ancak gerçek entegrasyonlarda durum bundan daha karmaşıktır.

Örneğin bir ürünün barkodu olmayabilir.

Gerçekten markasız bir ürün bulunabilir.

URL/slug XML'den gelmek yerine mağaza tarafından üretilebilir.

Kategori tedarikçiden gelmeyip mağazada manuel eşleştirilebilir.

Ürün aktiflik alanı bulunmayabilir; aktiflik stok veya feed'de bulunma durumundan türetilebilir.

Başka taraftan ürün adı veya fiyat gibi kritik bir değer bulunmadığında ürünün güvenli şekilde satışa açılması mümkün olmayabilir.

Bu nedenle xml zorunlu ürün alanları değerlendirilirken:

“XML'de hangi etiketler bulunmalı?”

yerine:

“Bu ürünün kimliğini, satış fiyatını, satın alınabilirliğini ve müşteriye doğru şekilde gösterilmesini güvenilir biçimde sağlayabilmek için hangi verilere ihtiyacım var?”

sorusu sorulmalıdır.

Ulu İthalat'ın XML Bayilik sayfasında ürün adı, fiyat, stok ve görsel gibi ürün bilgilerinin XML yoluyla satış kanallarına aktarılabileceği belirtiliyor. Bu alanlar XML ürün yönetiminin temel veri grupları arasında yer alsa da her hedef sistemin kabul ettiği veya zorunlu tuttuğu alanlar ayrıca değerlendirilmelidir.

XML'de Evrensel Zorunlu Ürün Alanı Listesi Var mı?

Hayır.

Burada dört ayrı zorunluluk seviyesi vardır:

1. XML'in teknik zorunlulukları

Dosyanın geçerli XML yapısında olması.

2. XML şemasının zorunlulukları

Bir XSD veya başka şema kullanılıyorsa belirlenen alan ve yapıların sağlanması.

3. Entegrasyon yazılımının zorunlulukları

Örneğin sizin yazılımınız ürün oluşturmak için ürün ID, ad ve fiyat isteyebilir.

4. Hedef satış kanalının zorunlulukları

Örneğin Google Merchant Center kendi ürün veri spesifikasyonunda ID, başlık, açıklama, link, görsel bağlantısı, fiyat ve stok durumu gibi bazı alanları tüm ürünler için gerekli tutuyor; marka ve GTIN gibi bazı alanlarsa ürünün niteliğine göre zorunlu hale geliyor.

Dolayısıyla:

“XML standardına göre barkod zorunludur.”

şeklinde bir ifade doğru değildir.

1. Önce “Zorunlu” Kelimesinin Hangi Seviyeyi İfade Ettiğini Belirleyin

Örneğin:

XML parse edebilmek için zorunlu mu?

Mağazada ürün oluşturmak için zorunlu mu?

Ürünü satışa açmak için zorunlu mu?

Pazaryerine göndermek için zorunlu mu?

Bunlar birbirinden farklı sorulardır.

Bir alan mağaza veri tabanında isteğe bağlı olabilir ancak satış kanalında zorunlu olabilir.

2. XML'in Teknik Olarak Geçerli Olması ile Ürün Verisinin Yeterli Olmasını Ayırın

Şu XML teknik açıdan düzgün oluşturulmuş olabilir:

<urun>

<kod>123</kod>

</urun>

Ancak e-ticaret açısından:

• ürün adı yok,
• fiyat yok,
• stok yok.

Dolayısıyla:

XML geçerli

ama:

ürün satışa hazır değil

olabilir.

W3C XSD standardı da XML şemalarının yapısal ve değer kısıtları tanımlamasına olanak verirken uygulamaların bunun ötesinde kendi validasyon kurallarına ihtiyaç duyabileceğini belirtiyor.

3. Zorunlu Alanları “Teknik” ve “Ticari” Olarak Ayırın

Örneğin:

Teknik zorunluluk

Ürün kaydının benzersiz biçimde tanınması.

Ticari zorunluluk

Ürünün hangi fiyattan satılacağının bilinmesi.

Operasyonel zorunluluk

Ürünün satışa açık olup olmadığının belirlenmesi.

Kanal zorunluluğu

Hedef platformun talep ettiği alanların bulunması.

Bu ayrım XML entegrasyon kuralını daha anlaşılır hale getirir.

4. En Kritik Alanlardan Biri Kalıcı Ürün Kimliğidir

Bir ürünün sonraki XML güncellemesinde tekrar bulunabilmesi gerekir.

Bu amaçla:

• tedarikçi ürün ID,
• tedarikçi SKU,
• başka güvenilir kaynak kimliği

kullanılabilir.

Örneğin ürün bugün:

100 TL

yarın:

120 TL

olduğunda sistem bunun aynı ürün olduğunu anlayabilmelidir.

5. Ürün Adı Kimliğin Yerine Geçmemelidir

Ürün adı:

Çelik Cezve 12 No

bugün böyle olabilir.

Tedarikçi yarın:

12 No Paslanmaz Çelik Cezve

olarak değiştirebilir.

Fiziksel ürün değişmemiştir.

Bu nedenle ürün adı müşteri açısından temel alanlardan biri olsa da kalıcı sistem kimliği olarak kullanılmamalıdır.

6. Ürün Adı Çoğu E-Ticaret Kullanımında Kritik Bir Alan Olmalıdır

Kimliği ID veya SKU üzerinden korusanız bile müşteriye:

“Ürün 84582”

göstermek yeterli değildir.

Ürünün anlaşılabilir bir adı bulunmalıdır.

Google Merchant Center da ürün başlığını tüm ürünler için gerekli temel veri alanlarından biri olarak tanımlıyor.

Ancak bu, XML standardının başlık zorunluluğu olduğu anlamına gelmez.

Bu bir e-ticaret veri gereksinimidir.

7. Boş Ürün Adı ile Eksik Ürün Adını Ayrı Hata Olarak Kaydedin

Şunlar farklı durumlardır:

<urun_ad></urun_ad>

ve:

urun_ad etiketinin hiç bulunmaması.

İlkinde alan mevcut ancak değer boş.

İkincisinde alan yapıda bulunmuyor.

İki durumda da ürün yayına alınmayabilir fakat hata kaynağı farklıdır.

8. Fiyat Alanı Satışa Açılacak Ürün İçin Kritik Alanlardan Biridir

Bir ürünün:

• adı,
• görseli,
• stok bilgisi

bulunabilir.

Ancak satış fiyatının nasıl belirleneceği bilinmiyorsa güvenli satış yapılamaz.

Kaynak XML'de en azından fiyat motorunuzun kullanabileceği güvenilir bir fiyat/maliyet alanı bulunmalıdır.

9. Hangi Fiyat Alanının Zorunlu Olduğunu Belirleyin

XML içerisinde:

fiyat

bayi_fiyat

liste_fiyat

indirimli_fiyat

gibi birkaç alan bulunabilir.

Hepsinin zorunlu olması gerekmez.

Örneğin sizin sisteminiz:

bayi fiyatından satış fiyatı üret

mantığında çalışıyorsa kritik kaynak:

bayi fiyatı

olabilir.

Bu nedenle:

“Fiyat alanı var.”

demek yetmez.

“Fiyat motorumun ihtiyaç duyduğu doğru fiyat alanı var.”

denmelidir.

10. Para Birimi Bazı XML'lerde Koşullu Olarak Zorunludur

Bütün fiyatlar sabit olarak TRY kabul edilen bir XML'de ayrı:

currency

alanı bulunmayabilir.

Ancak aynı feed:

• TRY,
• USD,
• EUR

fiyatlar içeriyorsa para birimi kritik hale gelir.

Örneğin:

price = 10

tek başına yeterli değildir.

10 TL mi?

10 USD mi?

10 EUR mu?

bilinmelidir.

11. KDV Bilgisi de XML Yapısına Göre Koşullu Zorunlu Olabilir

Kaynak fiyatın KDV dahil olduğu tedarikçi dokümantasyonuyla sabitse ayrı KDV alanı her sistem için zorunlu olmayabilir.

Ancak:

• ürünlere göre farklı KDV oranları varsa,
• fiyat KDV hariç gönderiliyorsa,
• satış fiyatı vergi oranından hesaplanıyorsa

KDV bilgisi kritik hale gelebilir.

Buradaki esas kriter:

Fiyatı doğru yorumlayabiliyor muyum?

sorusudur.

12. Stok veya Satın Alınabilirlik Bilgisi Dropshipping İçin Kritik Olmalıdır

Dropshipping sisteminde ürün tedarikçinin deposundadır.

Satıcı:

ürün gerçekten satılabilir mi?

bilgisine ihtiyaç duyar.

Bu:

stok = 18

şeklinde sayısal olabilir.

Ya da:

availability = in_stock

gibi durum bilgisi olabilir.

Hangi model kullanılırsa kullanılsın sistemin satışa uygunluğu belirleyebileceği güvenilir veri bulunmalıdır.

13. Stok Miktarı Her Sistemde Mutlaka Sayısal Olmak Zorunda Değildir

Bazı feed'ler:

stokta / stokta değil

bilgisi verir.

Bazıları:

gerçek adet

gönderir.

Bu nedenle:

“Stok adedi zorunludur.”

yerine:

“Satın alınabilirlik durumu belirlenebilmelidir.”

ifadesi daha doğrudur.

14. Stok 0 Geçerli Bir Değerdir

stok = 0

eksik veri değildir.

Bu ürünün şu anda stokta bulunmadığını belirtebilir.

Dolayısıyla zorunlu alan kontrolü:

değer sıfır → alan eksik

şeklinde çalışmamalıdır.

Bu ayrım özellikle eksik alan kontrolünde önemlidir.

15. Aktif/Pasif Alanı Her XML'de Zorunlu Değildir

Bazı XML'lerde:

aktif = 1

aktif = 0

bulunur.

Başka XML'de böyle alan olmayabilir.

Ürünün durumu:

• stok,
• feed içerisinde bulunma,
• başka status alanı

üzerinden yönetilebilir.

Bu nedenle aktiflik alanı koşullu zorunlu olarak değerlendirilmelidir.

16. Aktiflik Alanı Yoksa Bunun Yerine Kullanılan Kural Belgelenmelidir

Örneğin politika:

Ürün XML'de bulunuyor ve stok > 0 → aktif

olabilir.

Ancak bu varsayım tedarikçi tarafından doğrulanmalıdır.

Çünkü XML'de bulunması ürünün mutlaka satılabilir olduğu anlamına gelmeyebilir.

17. Görsel E-Ticaret Açısından Çok Önemlidir Ancak XML Standardı Açısından Zorunlu Değildir

Bir XML kaydı görselsiz olarak teknik açıdan tamamen geçerli olabilir.

Ancak müşteri karşısında satılacak ürün için görsel çoğu satış kanalında temel gereksinimdir.

Google Merchant Center örneğinde image_link tüm ürünler için gerekli alanlardan biridir.

Dolayısıyla:

XML zorunluluğu

ile

satış kanalı zorunluluğu

birbirine karıştırılmamalıdır.

18. En Az Bir Ana Görsel İçin Kabul Kuralı Oluşturabilirsiniz

Örneğin:

Ana görsel yok → yayınlama

Ek görsel yok → yayınlanabilir

gibi politika oluşturulabilir.

Bu durumda:

resim1

kritik,

resim2

resim3

isteğe bağlı

hale gelebilir.

19. Görsel Alanının Dolu Olması Tek Başına Yeterli Değildir

resim1 = https://...

değeri vardır.

Ancak URL:

• 404 olabilir,
• yanlış ürün olabilir,
• resim dosyası olmayabilir.

Dolayısıyla:

required field present

ve

required field usable

farklı şeylerdir.

114 zorunlu alanı tanımlar.

Görsel kalite kontrolü ise ayrı validation katmanıdır.

20. Açıklama Alanının Zorunluluğu Hedef Sisteme Göre Değişebilir

Kendi mağazanız teknik olarak açıklamasız ürün oluşturabilir.

Ancak ürün sayfası kalite açısından yetersiz kalabilir.

Google Merchant Center ürün veri spesifikasyonunda açıklama tüm ürünler için gerekli alanlardan biridir.

Bu nedenle açıklama:

mağaza importer'ında opsiyonel

ama:

belirli hedef kanalda zorunlu

olabilir.

21. Kategori Alanı Her XML'de Teknik Olarak Zorunlu Değildir

Örneğin bütün ürünler mağazada geçici:

Yeni Ürünler

kategorisine alınabilir.

Daha sonra manuel eşleştirme yapılabilir.

Bu durumda XML kategori alanı olmadan ürün teknik olarak oluşturulabilir.

Ancak büyük katalog yönetiminde kategori bilgisinin bulunması çok yararlı olabilir.

22. Kategori Hedef Pazaryerinde Zorunlu Hale Gelebilir

Pazaryeri ürün oluştururken kategori seçimi isteyebilir.

Bu durumda tedarikçi kategorisi:

doğrudan hedef kategori

olmak zorunda değildir.

Ancak kategori mapping'i yapılabilmesi için kaynakta yeterli sınıflandırma bulunması yararlı olabilir.

23. Marka Alanı Her Ürün İçin Zorunlu Değildir

Gerçekten markasız ürünler bulunabilir.

Bu nedenle:

brand alanı boş → bütün ürünler hatalı

şeklinde evrensel kural doğru olmaz.

Google Merchant Center da markayı açıkça ilişkili markası veya üreticisi bulunan ürünlerde zorunlu kabul ediyor.

24. Markalı Üründe Marka Alanı Kritik Hale Gelebilir

Ürün gerçekten belirli bir markaya aitse:

markayı boş bırakmak

veya:

rastgele mağaza adını yazmak

ürün verisinin doğruluğunu bozar.

Dolayısıyla zorunluluk:

ürünün gerçek niteliğine

bağlıdır.

25. Barkod veya GTIN Her Ürün İçin Evrensel Zorunlu Değildir

Bazı ürünlere üretici tarafından GTIN atanmış olabilir.

Bazılarında olmayabilir.

Google Merchant Center örneğinde GTIN, üretici tarafından GTIN atanmış ürünlerde gerekli hale gelir.

Bu nedenle:

GTIN atanmış → doğru GTIN'i koru

GTIN yok → uydurma GTIN üretme

yaklaşımı kullanılmalıdır.

26. Barkod Boşsa Rastgele Barkod Üretmek Zorunlu Alan Sorununu Çözmez

Zorunlu alan kontrolünün amacı:

kutuyu dolu göstermek

değildir.

Amaç gerçek ürün verisini sağlamaktır.

Uydurma barkod:

• ürün eşleştirmesi,
• pazaryeri kataloğu,
• stok takibi

gibi başka sorunlar oluşturabilir.

27. SKU ve GTIN Aynı Görevi Yapmaz

SKU mağaza veya tedarikçi içi stok kimliği olabilir.

GTIN ise üretici tarafından belirlenen global ticari ürün kimliğidir.

Bu nedenle:

GTIN yok → SKU'yu GTIN alanına yaz

şeklinde bir yaklaşım kullanılmamalıdır.

28. Tedarikçi Ürün ID'si Çoğu XML Entegrasyonunda Çok Değerlidir

Örneğin tedarikçi ürün adını veya SKU'yu değiştirebilir.

Ancak:

supplier_product_id

sabit kalıyorsa ürünün geçmişini takip etmek kolaylaşır.

Bu nedenle mümkünse her kaynak ürün için stabil bir kaynak kimliği bulunması güçlü bir gereksinimdir.

29. Tek Bir Benzersiz Kimlik Yetmeyebilir

Örneğin ürün:

parent product

ve altında:

• siyah S,
• siyah M,
• beyaz S

varyantlarına sahiptir.

Bu durumda ana ürün ID yanında varyant kimliği de gerekebilir.

Aksi halde bütün stok ve fiyatlar tek kayıtta birleşebilir.

30. Varyant Alanları Yalnızca Varyantlı Ürünlerde Zorunludur

Tek varyantsız ürün için:

• beden,
• renk,
• item_group_id

alanlarının doldurulması gerekli olmayabilir.

Ancak varyantlı bir üründe:

hangi SKU hangi renk/bedene ait?

bilgisinin bulunması kritik olabilir.

Google Merchant Center da varyant bilgilerinin ürün yapısına bağlı olarak gerekli hale gelebildiğini belirtiyor.

31. Renk Her Üründe Zorunlu Olmamalıdır

Bir pense için renk satılabilir varyant oluşturmayabilir.

Bir tişörtte ise renk doğrudan varyant olabilir.

Bu nedenle:

color = required

genel kuralı yerine:

category/product-type based requirement

kullanılabilir.

32. Beden İçin de Aynı Yaklaşım Geçerlidir

Beden alanı:

kıyafet

için kritik olabilir.

Ancak:

çelik cezve

için anlamsız olabilir.

Zorunlu alan sistemi ürün tipini anlayabilmelidir.

33. Ölçü Bilgisi Bazı Ürünlerde Kritik Satış Verisidir

Örneğin:

• organizer,
• raf,
• mobilya,
• el aleti,
• kap/kutu

gibi ürünlerde ölçü müşterinin ürün seçimini doğrudan etkileyebilir.

Ancak her XML için zorunlu teknik alan değildir.

İşletme kategori bazında:

Mobilya → ölçü zorunlu

gibi kurallar oluşturabilir.

34. Paket Adedi Bazı XML'lerde Kritik Olabilir

Özellikle toptan ürünlerde:

1 adet

ile:

12'li paket

arasında büyük fark vardır.

Ürün adı içerisinde:

*12

yazması sistematik veri için yeterli olmayabilir.

Mümkünse:

package_quantity

ve:

sale_unit

ayrı alanlarda tutulabilir.

35. Koli ve Tekli Satış Birimi İçin Koşullu Zorunlu Alan Oluşturun

Tedarikçi stok:

10

gönderiyor.

Bu:

10 ürün mü?

10 koli mi?

bilinmiyorsa stok verisi teknik olarak dolu olsa bile operasyonel olarak kullanılamaz.

Dolayısıyla ürünün satış birimi belirsiz olabiliyorsa:

unit

alanı kritik hale gelir.

36. Ağırlık ve Desi Her Üründe Zorunlu Değildir

Kargo hesaplaması mağazada:

• sabit ücret,
• kategori kuralı,
• desi

ile yapılabilir.

Desi bazlı kargo motoru kullanılıyorsa ağırlık/ölçü verileri kritik olabilir.

Sabit kargoda ise aynı teknik zorunluluk bulunmayabilir.

37. URL Alanı Kaynak XML'de Zorunlu Olmak Zorunda Değildir

Mağaza ürün URL'sini kendi sistemi oluşturabilir.

Örneğin:

ürün adı → slug

üzerinden URL üretilebilir.

Dolayısıyla tedarikçinin:

url

alanının bulunmaması ürün oluşturmayı engellemek zorunda değildir.

38. Kaynak Ürün URL'si Operasyonel Referans Olarak Faydalı Olabilir

Tedarikçi URL'si:

• ürünü doğrulama,
• veri karşılaştırma,
• tedarikçi kaynağına dönme

için kullanılabilir.

Ancak:

kendi mağaza URL'sinin yerine geçmesi gerekmez.

Bu nedenle “faydalı alan” ile “yayın için zorunlu alan” ayrılmalıdır.

39. Slug Alanı da Mağaza Tarafında Üretilebilir

XML:

slug

göndermeyebilir.

Sistem ürün adından:

celik-cezve-12-no

oluşturabilir.

Dolayısıyla kaynak slug çoğu sistemde koşullu/isteğe bağlı alandır.

40. Ürün Açıklaması ile Teknik Özellikleri Aynı Alan Sanmayın

Açıklama:

ürün hakkında serbest metin

olabilir.

Teknik özellikler ise:

• ölçü,
• malzeme,
• renk,
• kapasite

gibi yapılandırılmış alanlar olabilir.

Belirli satış kanallarında bu özelliklerin ayrı attribute olarak istenmesi mümkündür.

41. Ürün Tipine Göre Zorunlu Alan Matrisi Oluşturabilirsiniz

Örneğin:

Bütün ürünler

• kaynak ürün kimliği,
• ürün adı,
• fiyatlandırmaya yeterli fiyat bilgisi,
• satılabilirlik/stok bilgisi.

Markalı ürünler

• marka.

GTIN atanmış ürünler

• GTIN.

Varyantlı ürünler

• varyant kimliği ve ayırt edici özellik.

Dövizli ürünler

• para birimi.

Koli/set ürünleri

• paket miktarı veya satış birimi.

Bu yapı tek bir “her ürün için 25 alan zorunlu” listesinden daha güvenlidir.

42. “Çekirdek Zorunlu Alan” Kavramı Kullanabilirsiniz

İşletme kendi minimum ürün modelini oluşturabilir.

Örneğin ürünün otomatik satışa açılması için:

stabil kimlik

ürün adı

geçerli kaynak fiyat

satılabilirlik bilgisi

gibi çekirdek alanlar istenebilir.

Buna daha sonra kanal ve kategori şartları eklenebilir.

Bu örnek evrensel XML standardı değil işletmenin kabul kuralıdır.

43. Zorunlu Alan ile Yayın Engelleyici Alan Aynı Olmayabilir

Örneğin marka eksik.

Sistem:

ürünü hiç import etme

yerine:

ürünü içeri al ama REVIEW_REQUIRED yap

diyebilir.

Bu nedenle her zorunlu alan için aksiyon belirlenmelidir:

REJECT

QUARANTINE

IMPORT_BUT_INACTIVE

WARN

gibi.

44. Kritik Alanları Hata Seviyelerine Ayırın

Örneğin:

CRITICAL

Ürün kimliği yok.

CRITICAL

Kaynak fiyat yok.

CRITICAL

Satılabilirlik belirlenemiyor.

ERROR / REVIEW

Varyant kimliği belirsiz.

WARNING

İkinci görsel eksik.

Bu örnek sınıflandırma işletmenin kendi yapısına göre değişebilir.

45. Eksik Ana Görsel ile Eksik Ek Görsel Aynı Öncelikte Olmamalıdır

Ürün:

ana görsele sahip.

Ancak ikinci ve üçüncü görsel yok.

Bu ürün:

görsel alanları eksik

olarak teknik rapora düşebilir.

Fakat satış açısından ana görseli hiç olmayan ürünle aynı riskte değildir.

Zorunluluk alan bazında değil işlev bazında değerlendirilmelidir.

46. Veri Alanının Bulunması ile Geçerli Olmasını Ayırın

Örneğin:

price = ABC

alan vardır.

Ancak geçerli fiyat değildir.

stock = bilinmiyor

alan vardır.

Ancak kullanılabilir stok bilgisi değildir.

image = example

alan vardır.

Ancak geçerli URL olmayabilir.

Bu nedenle:

required field presence

ve:

required field validation

iki ayrı testtir.

47. “Boş Olmamalı” Kuralı Tek Başına Yetersizdir

Örneğin:

brand = N/A

boş değildir.

Ancak gerçek marka olmayabilir.

price = -500

boş değildir.

Ancak normal satış fiyatı için geçersiz olabilir.

stock = NULL

metin olarak doludur.

Ancak stok değeri değildir.

Dolayısıyla zorunlu alan kontrolünün ardından veri doğrulaması gelmelidir.

48. Varsayılan Değer Kullanırken Çok Dikkatli Olun

Eksik kategori:

Genel

olarak atanabilir.

Ancak eksik fiyat:

0

yapmak tehlikeli olabilir.

Eksik marka:

Mağaza Markası

yapmak yanlış olabilir.

Eksik stok:

999

yapmak ciddi satış problemi oluşturabilir.

Her alan için varsayılan değer kullanılması uygun değildir.

49. Eksik Kritik Alanlarda Veri Uydurmayın

Bu 114'ün önemli kurallarından biridir.

Ürün:

markasızsa marka uydurulmamalıdır.

Barkod yoksa barkod uydurulmamalıdır.

Ölçü bilinmiyorsa tahmin edilmemelidir.

Malzeme belirtilmemişse görsele bakarak kesin bilgi yazılmamalıdır.

Zorunlu alan problemi:

gerçek olmayan veri üretmek

ile çözülmemelidir.

50. Tedarikçiden Alan Açıklama Dokümanı İsteyin

XML yalnızca şu değerleri gösterebilir:

fiyat1

fiyat2

stock

status

Ama hangi alanın ne anlama geldiği belli olmayabilir.

Tedarikçiden mümkünse:

• alan adı,
• açıklama,
• veri tipi,
• örnek,
• zorunlu/opsiyonel,
• güncelleme davranışı

bilgisi alınmalıdır.

Bu bir XML data dictionary görevi görür.

51. XSD Varsa Zorunlu Alanlar Teknik Olarak Tanımlanabilir

Tedarikçi bir XSD sağlıyorsa:

• hangi elementlerin bulunacağı,
• veri tipleri,
• occurrence kısıtları

şema üzerinden kontrol edilebilir.

W3C XSD standardı XML belgelerinin yapısı ve içeriklerinin sınırlandırılmasına imkân verir.

Ancak:

XSD'de opsiyonel

olması,

sizin mağazanız için:

operasyonel olarak opsiyonel

olduğu anlamına gelmez.

52. Şema ile İş Kuralını Ayrı Tutun

Örneğin XSD:

price

alanına izin veriyor ama zorunlu tutmuyor olabilir.

Sizin uygulama kuralınız:

price yoksa ürün satışa açılamaz

diyebilir.

Dolayısıyla iki katman bulunabilir:

schema validation

↓

business validation

53. Hedef Satış Kanalı Gereksinimlerini Ayrı Matrise Ekleyin

Örneğin mağazanız ürün için:

• ID,
• ad,
• fiyat,
• stok

ile yetinebilir.

Ancak Google'a aktarım için ayrıca:

• landing page linki,
• görsel,
• açıklama,
• availability

gibi alanlar gerekebilir. Google'ın güncel ürün verisi spesifikasyonu bunların bir bölümünü tüm ürünler için required olarak tanımlıyor.

Dolayısıyla tek ürünün:

Store Ready

ama:

Google Ready değil

durumu olabilir.

54. “Import Edilebilir” ile “Satışa Hazır” Ayrımı Yapın

Örneğin ürünün:

ID'si var.

Adı var.

Fiyatı var.

Ancak görseli yok.

Sistem ürünü veri tabanına import edebilir.

Ama:

publishable = false

tutabilir.

Bu çok kullanışlı bir ayrımdır.

55. “Kanal Hazır” Durumunu da Ayrı Tutabilirsiniz

Örnek ürün durumu:

IMPORTED

Veri tabanında bulunuyor.

STORE_READY

Kendi sitenizde satılabilir.

MARKETPLACE_READY

Pazaryeri alanları tamam.

GOOGLE_READY

Google feed gereksinimleri tamam.

Bu yapı farklı zorunlu alan setlerini aynı üründe yönetmeyi kolaylaştırır.

56. Zorunlu Alan Kurallarını Tedarikçi Bazında Uyarlayın

Tedarikçi A:

price alanını kullanıyor.

Tedarikçi B:

dealer_price

kullanıyor.

Her ikisi de sizin:

source_price

alanınıza map edilebilir.

Bu nedenle zorunluluk:

kaynak XML'de mutlaka <price> olmalı

değil,

normalized source_price oluşturulabilmeli

şeklinde tanımlanabilir.

57. Zorunlu Alanları Normalize Edilmiş Model Üzerinden Kontrol Etmek Daha Güvenlidir

Farklı tedarikçiler farklı alan adları kullanıyorsa:

ham XML'deki alan ismi

yerine:

ortak ürün veri modeli

üzerinde required kontrol yapılabilir.

Örneğin:

Tedarikçi A → urun_ad

Tedarikçi B → title

↓

Normalized → product_name

Son required kontrol:

product_name != empty

olabilir.

58. Normalizasyon Eksik Veriyi Oluşturmamalıdır

Tedarikçi:

marka göndermiyor.

Normalizasyon:

UNKNOWN

üretebilir.

Ancak bu:

marka verisi var

anlamına gelmemelidir.

Sistem:

source_missing

bilgisini korumalıdır.

59. Zorunlu Alan Kontrolünü Ürün Düzeyinde Yapın

Feed'in genelinde price etiketi bulunabilir.

Ancak:

10.000 üründen 85'inde fiyat boş olabilir.

Dolayısıyla:

XML'de price alanı var

kontrolü yeterli değildir.

Her ürün ayrı değerlendirilmelidir.

60. Varyant Düzeyinde de Zorunlu Alan Kontrolü Yapın

Ana ürün:

adı ve görseli taşıyor olabilir.

Ancak varyant:

• SKU,
• stok,
• fiyat,
• renk

gibi kendi alanlarına ihtiyaç duyabilir.

Ana ürünün alanlarının eksiksiz olması bütün varyantların satışa hazır olduğu anlamına gelmez.

61. Kategori Bazlı Zorunlu Alanlar Kullanabilirsiniz

Örneğin:

Ayakkabı

beden → gerekli olabilir.

Mobilya

ölçü → gerekli olabilir.

Elektronik

model → önemli olabilir.

Markasız ev ürünü

marka → zorunlu olmayabilir.

Bu sistem, ürün tipine göre veri kalitesini daha doğru değerlendirir.

62. Paket/Koli Ürünlerine Özel Alan Kuralı Oluşturabilirsiniz

Eğer katalogda hem:

tekli

hem:

koli

satış varsa:

sale_unit

veya:

package_quantity

gibi alanların belirli ürünlerde bulunması şart haline getirilebilir.

Bu, yanlış adet satışının önüne geçmek açısından fiyat kadar önemli olabilir.

63. Bir Alanın Eksikliği Başka Alandan Güvenle Türetiliyorsa Ayrı Politika Kullanılabilir

Örneğin slug XML'de yok.

Ama ürün adı ve benzersiz ID var.

Mağaza güvenilir biçimde slug oluşturabiliyor.

Bu durumda:

source_slug

opsiyonel olabilir.

Ancak ürünün fiyatını başka metinden tahmin etmek aynı güvenilirlikte değildir.

64. Türetilen Verinin Kaynağını Kaydedin

Örneğin:

slug_source = generated

category_source = mapping

price_source = supplier_xml

brand_source = supplier

gibi.

Bu sayede hangi alanın tedarikçiden geldiği, hangisinin mağaza tarafından üretildiği belli olur.

65. Zorunlu Alan Kuralları Değişebilir

Bugün yalnızca kendi sitenizde satış yapıyorsunuz.

Yarın yeni pazaryerine çıktınız.

Yeni kanal:

• marka,
• kategori attribute,
• GTIN,
• varyant bilgisi

isteyebilir.

Bu durumda ürün veri modelinizin required kuralları genişleyebilir.

66. Yeni Kanal Eklenince Bütün XML'i Hatalı İlan Etmeyin

Örneğin 5.000 ürün kendi siteniz için yeterli veriye sahip.

Google için 500 ürünün GTIN/marka tarafında ek kontrole ihtiyacı var.

Bu:

XML'in tamamı kullanılamaz

anlamına gelmez.

Kanal bazlı readiness kullanılabilir.

67. Zorunlu Alan Değişikliklerini Versiyonlayın

Örneğin:

Required Rules V1

ürün adı + fiyat + stok istiyor.

Sonra:

V2

paketli ürünlere satış birimi zorunluluğu ekliyor.

Kural versiyonunun tutulması:

Bu ürün neden dün geçiyordu bugün review'a düştü?

sorusunu açıklamayı kolaylaştırır.

68. Yeni Zorunlulukları Önce Dry-Run ile Test Edin

Yeni kural:

markalı üründe brand zorunlu

olarak eklendi.

Canlıya geçmeden önce:

kaç ürün etkilenecek?

hesaplanabilir.

Örneğin:

10.000 ürün

↓

420 ürün yeni kurala takılıyor.

Böylece binlerce ürünün beklenmedik şekilde kapanması önlenebilir.

69. Zorunlu Alan Kuralı ile XML Feed Testi Birlikte Çalışmalıdır

114:

hangi alan gerekli?

sorusunu çözer.

113:

bu gereksinim yeni feed üzerinde gerçekten sağlanıyor mu?

sorusunu çözer.

Örneğin:

114 kuralı:

geçerli kaynak fiyat olmadan yayın yok.

113 testi:

boş fiyatlı örnek üründe sistem gerçekten yayını engelliyor mu?

şeklinde olur.

70. Eksik Alan Raporu da Bu Kurallardan Üretilmelidir

Zorunlu alan matrisi oluşturulduktan sonra sistem:

MISSING_PRODUCT_ID

MISSING_NAME

MISSING_PRICE

MISSING_AVAILABILITY

MISSING_BRAND_WHEN_REQUIRED

MISSING_GTIN_WHEN_ASSIGNED

gibi sonuçlar üretebilir.

Bu noktada 100 numaralı eksik alan kontrolü devreye girer.

71. Hata Mesajı Yalnızca “Zorunlu Alan Eksik” Dememelidir

Daha kullanışlı çıktı:

Supplier: A

Supplier SKU: ABC125

Missing field: price

Requirement: STORE_READY

Action: REVIEW_REQUIRED

gibi olabilir.

Bu yapı hata loglarının okunmasını da kolaylaştırır.

72. Bir Ürünün Neden Yayınlanamadığını Panelde Gösterin

Örneğin:

Yayın durumu: Kapalı

Sebep: Kaynak fiyat eksik

veya:

Google'a gönderilemiyor

Sebep: Ana görsel bulunamadı

gibi.

Bu şekilde zorunlu alan sistemi operasyon ekibinin anlayabileceği hale gelir.

73. Zorunlu Alanları Sessizce Varsayılanla Doldurmak Hataları Gizleyebilir

Örneğin:

fiyat yok → 0

stok yok → 0

marka yok → Genel

kategori yok → Diğer

şeklinde otomatik doldurursanız dashboard:

%100 complete

gösterebilir.

Ancak veri gerçekte kaliteli değildir.

Bu nedenle placeholder ile gerçek veri ayrılmalıdır.

74. Completeness Oranı Hesaplayabilirsiniz

Örneğin bir ürün için 5 çekirdek zorunlu alan tanımlandı.

5/5 → %100

4/5 → %80

gibi ürün completeness puanı oluşturulabilir.

Ancak bütün zorunlu alanların önemi aynı olmak zorunda değildir.

Fiyatın eksikliği ile ikinci görselin eksikliği eşit ağırlıkta değerlendirilmemelidir.

75. Kritik Alan Bazlı Yayın Kapısı Daha Güvenlidir

Örneğin ürün:

9/10 alan dolu.

Ama eksik olan:

fiyat

ise yayınlanmamalı.

Başka ürün:

8/10.

Eksik olanlar:

ek görsel 2

ve:

ek görsel 3

ise mağaza politikasına göre yayınlanabilir.

Dolayısıyla yalnızca completeness yüzdesi yeterli değildir.

76. Ürün Alanlarını Üç Gruba Ayırmak Kullanışlıdır

Zorunlu

Olmadan ilgili süreç çalışamaz.

Koşullu zorunlu

Belirli ürün veya kanal durumunda gerekli.

İsteğe bağlı / zenginleştirici

Eksik olsa ürün çalışabilir ancak kalite veya performans artabilir.

Bu üçlü model 114'ün ana çıktılarından biri olmalıdır.

77. Örnek Çekirdek Alan Modeli Nasıl Olabilir?

Tipik bir XML e-ticaret sisteminde işletme tarafından çekirdek kabul edilebilecek alanlar:

• stabil ürün kimliği,
• ürün adı,
• fiyatlandırmaya yeterli fiyat verisi,
• stok/satın alınabilirlik bilgisi.

Bunlara operasyonunuza göre:

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

eklenebilir.

Ancak bu liste XML standardının evrensel zorunlu listesi değildir.

78. Koşullu Zorunlu Alanlara Örnekler

Ürün veya kanal durumuna göre:

• marka,
• GTIN,
• MPN,
• renk,
• beden,
• varyant grup kimliği,
• para birimi,
• KDV/vergi,
• paket miktarı,
• satış birimi,
• ağırlık,
• ölçü

zorunlu hale gelebilir.

79. İsteğe Bağlı Alanları Gereksiz Görmeyin

Örneğin:

• ek görseller,
• detaylı teknik özellikler,
• üretici kodu,
• ek açıklamalar

yayın için zorunlu olmayabilir.

Ancak müşteri deneyimi, filtreleme ve satış kanalı performansı açısından değerli olabilir.

Opsiyonel = gereksiz

değildir.

80. Google Merchant Center Güzel Bir “Kanala Göre Zorunluluk” Örneğidir

Google'ın güncel ürün verisi kurallarında tüm ürünler için:

• ID,
• başlık,
• link,
• görsel bağlantısı,
• fiyat,
• açıklama,
• availability

gibi alanlar gerekli tutuluyor.

Buna karşılık marka, GTIN ve bazı varyant alanlarının zorunluluğu ürünün özelliklerine göre değişiyor.

Bu örnek, XML'de zorunluluğun neden hedefe bağlı değerlendirilmesi gerektiğini iyi gösterir.

XML ZORUNLU ÜRÜN ALANLARI KONTROL LİSTESİ

Ürün kimliği

Ürün sonraki güncellemede aynı kayıt olarak bulunabiliyor mu?

Tedarikçi ID

Stabil kaynak kimliği var mı?

SKU

Doğru ürünü temsil ediyor mu?

Ürün adı

Boş veya anlamsız mı?

Kaynak fiyat

Satış fiyatını hesaplamaya yeterli mi?

Para birimi

Gerekliyse belirli mi?

KDV

Fiyat yorumlamak için gerekli mi?

Stok

Satın alınabilirlik belirlenebiliyor mu?

Aktiflik

Ürün durumunun nasıl belirlendiği tanımlı mı?

Ana görsel

Satış kanalı için gerekiyor mu?

Açıklama

Hedef kanal tarafından zorunlu mu?

Kategori

Kaynak kategori veya mapping yapılabiliyor mu?

Marka

Ürün gerçekten markalıysa bulunuyor mu?

GTIN

Üretici tarafından atanmışsa doğru mu?

Varyant ID

Varyantlı üründe benzersiz kayıt var mı?

Renk/Beden

Ürünü gerçekten ayırıyorsa bulunuyor mu?

Ölçü

Kategori için kritikse mevcut mu?

Paket adedi

Set/koli ürününde belirli mi?

Satış birimi

Adet, set veya koli olduğu anlaşılıyor mu?

URL/Slug

XML'den gelmesi şart mı, mağaza üretebiliyor mu?

Alan tipi

Değer doğru veri tipinde mi?

Kaynak

Tedarikçi değeri ile türetilen değer ayrılıyor mu?

Kanal gereksinimi

Mağaza ve pazaryerleri için ayrı readiness var mı?

Eksik alan aksiyonu

Reject, review veya warning politikası belirli mi?

Kural versiyonu

Zorunlulukların ne zaman değiştiği takip ediliyor mu?

XML'DE ZORUNLU ALAN SİSTEMİ NASIL OLUŞTURULUR?

1. XML'in kullandığınız ürün düğümünü belirleyin.

2. Tedarikçinin bütün ürün alanlarını çıkarın.

3. Her alanın gerçek anlamını dokümante edin.

4. Kaynak ürünün kalıcı kimlik alanını belirleyin.

5. Mağazanın ortak ürün veri modelini oluşturun.

6. Kaynak alanları ortak modele map edin.

7. Ürün oluşturmak için gereken çekirdek alanları belirleyin.

8. Satışa açmak için gereken alanları ayrıca belirleyin.

9. Hedef satış kanallarının zorunluluklarını çıkarın.

10. Marka, GTIN, varyant gibi koşullu alanları tanımlayın.

11. Kategori bazlı ek zorunlulukları belirleyin.

12. Paket, koli ve satış birimi kurallarını belirleyin.

13. Her zorunlu alan için veri tipi ve validation kuralı oluşturun.

14. Eksik ile boş değeri birbirinden ayırın.

15. Sıfır gibi geçerli değerleri koruyun.

16. Eksik kritik alanlara otomatik tahmini veri eklemeyin.

17. Her hata için REJECT, REVIEW veya WARNING aksiyonu belirleyin.

18. Mevcut kataloğu yeni kurallarla dry-run olarak kontrol edin.

19. Yeni XML feed testinde zorunlu alan kurallarını özellikle deneyin.

20. Kuralları kanal ve ürün yapısı değiştikçe yeniden değerlendirin.

SIK SORULAN SORULAR

XML dosyasında ürün adı, fiyat ve stok kesinlikle zorunlu mudur?

XML standardı açısından bu alanların isimleri veya varlığı evrensel olarak zorunlu değildir. Ancak e-ticaret uygulamasında ürünün müşteriye gösterilmesi, fiyatlandırılması ve satın alınabilirliğinin belirlenmesi için bu bilgilerin veya aynı işlevi sağlayan karşılıklarının çoğu sistemde kritik olması beklenir. Zorunluluk kullandığınız yazılım ve hedef satış kanalına göre belirlenmelidir.

Barkodu olmayan ürün XML'e alınabilir mi?

Evet, barkod bütün ürünler için evrensel XML zorunluluğu değildir. Ürüne üretici tarafından GTIN atanmışsa doğru GTIN'in korunması gerekir; olmayan bir ürün için barkod uydurulmamalıdır. Google Merchant Center da GTIN'i üretici tarafından GTIN atanmış ürünlerde gerekli kabul eder.

Marka alanı her üründe zorunlu mudur?

Hayır. Gerçekten markasız ürünler bulunabilir. Ürün açıkça belirli bir marka veya üreticiyle ilişkiliyse marka bilgisi gerekli hale gelebilir. Hedef platformun kendi ürün veri gereksinimleri ayrıca kontrol edilmelidir.

XML'de kategori yoksa ürün aktarılamaz mı?

Her zaman değil. Mağaza varsayılan kategoriye import edip sonradan kategori mapping'i yapabilir. Ancak hedef satış kanalının kategori gereksinimi veya işletmenin kendi yayın politikası nedeniyle kategori bilgisi yayın öncesi zorunlu hale getirilebilir.

Eksik zorunlu alan bulunan ürün tamamen silinmeli mi?

Genellikle silmek tek seçenek değildir. Ürün REVIEW_REQUIRED, IMPORT_BUT_INACTIVE veya benzeri bir duruma alınabilir. Böylece kaynak kayıt korunur fakat eksik kritik veri tamamlanmadan satışa açılmaz.

“ZORUNLU ÜRÜN ALANI” SABİT BİR XML LİSTESİ DEĞİL, BİR KABUL KURALIDIR

114 numarada en önemli çıkarım budur.

Yanlış yaklaşım:

“Bütün XML'lerde şu 15 alan mutlaka bulunmalıdır.”

demektir.

Daha doğru yaklaşım:

ürün kimliğini belirle → mağazanın minimum ürün modelini oluştur → satış için kritik alanları belirle → ürün türüne bağlı şartları ekle → hedef kanalın gereksinimlerini ekle → mevcut alanları normalize et → eksikliği ürün/varyant bazında kontrol et → geçersiz değerleri ayrıca doğrula → eksik kritik ürünleri incelemeye al

şeklindedir.

Örneğin üç ürün düşünelim:

Ürün A

Markasız organizer.

Marka alanı boş.

Bu normal olabilir.

Ürün B

Üretici markalı elektronik ürün.

Marka ve atanmış GTIN bilgisi eksik.

Bu daha ciddi olabilir.

Ürün C

Tekli hırdavat ürünü.

Beden alanı boş.

Bu tamamen normal olabilir.

Üç ürünün de:

“aynı zorunlu alan listesinden geçmesi”

mantıklı değildir.

Bu nedenle iyi bir XML sisteminde zorunluluk:

ürün tipi + satış kanalı + iş kuralı

birlikte değerlendirilerek belirlenmelidir.