XML entegrasyonunda ürünün:

• adı doğru,
• fiyatı doğru,
• stoğu doğru,
• görseli doğru

olabilir.

Ancak ürün yanlış kategoriye yerleşmişse katalog yine problemli hale gelir.

Örneğin:

Çelik cezve

ürünü:

Ev & Yaşam → Mutfak

yerine:

Yapı & Hırdavat

altında görünebilir.

Başka bir durumda kaynak XML:

Ev > Mutfak > Cezveler

gönderir.

Mapping tablosu bunu:

Ev & Mobilya

gibi çok genel bir kategoriye bağlar.

Teknik açıdan ürün aktarılmıştır.

Hata oluşmamıştır.

Ama kategori sonucu yanlıştır.

Bu nedenle xml kategori hatası yalnızca:

“kategori alanı boş”

veya:

“API kategori hatası verdi”

anlamına gelmez.

Daha geniş soru şudur:

“Kaynak ürünün kategori bilgisi, mapping kuralı ve mağazada oluşan nihai kategori gerçekten aynı ürün anlamını koruyor mu?”

Ulu İthalat'ın mevcut XML entegrasyonu rehberinde de tedarikçinin kategori ağacıyla mağaza veya pazaryeri kategori yapısının farklı olabileceği ve bu nedenle kategori eşleştirmesinin önceden planlanması gerektiği açıkça belirtiliyor.

XML Kategori Hatası Nedir?

Bu içerikte XML kategori hatasını:

ürünün kaynak kategorisinin yanlış okunması, yanlış eşleştirilmesi, yanlış hedef kategoriye aktarılması veya doğru kategori ilişkisinin zaman içinde bozulması

olarak ele alıyoruz.

Örneğin:

Kaynak kategori: Mutfak > Çay ve Kahve > Cezveler

Beklenen mağaza kategorisi: Mutfak > Kahve Hazırlama > Cezveler

Gerçek mağaza kategorisi: Ev Dekorasyon

ise kategori hatası vardır.

Ancak önce şunu belirlemek gerekir:

Hata tedarikçide mi, bizde mi?

1. Kaynak Kategori ile Hedef Kategoriyi Ayrı Tutun

İlk temel kural:

supplier_category

ve:

store_category

aynı alan olmamalıdır.

Örneğin:

Supplier category: Ev Gereçleri > Mutfak

Store category: Ev & Yaşam > Mutfak Gereçleri

olabilir.

Aradaki ilişki mapping üzerinden kurulmalıdır.

2. Kaynak Kategoriyi Olduğu Gibi Saklayın

Tedarikçi:

Ev/Mutfak/Cezve

gönderdi.

Sistem bunu:

Mutfak

olarak normalize etmiş olabilir.

Ancak hata çıktığında:

kaynakta gerçekten ne vardı?

bilmek gerekir.

Bu nedenle:

raw_category

değeri korunmalıdır.

3. Kategori ID ile Kategori Adını Ayırın

XML:

category_id = 125

category_name = Cezveler

gönderebilir.

ID daha stabil olabilir.

Ancak tedarikçi sistem değiştirirse ID de değişebilir.

Bu yüzden mümkünse ikisi birlikte tutulabilir.

4. Yalnızca Kategori Adıyla Mapping Yapmayın

Örneğin:

Aksesuar

ismi:

• telefon aksesuarı,
• moda aksesuarı,
• otomobil aksesuarı

altında bulunabilir.

Sadece:

Aksesuar → Aksesuar

eşleştirmesi ürünleri yanlış kategoriye taşıyabilir.

5. Tam Kategori Yolunu Kullanın

Daha güvenli örnek:

Elektronik > Telefon > Aksesuar

ile:

Moda > Kadın > Aksesuar

ayrı tutulmalıdır.

Google'ın kendi product_type rehberinde de kendi sınıflandırmanızı gönderirken yalnızca son kategori adını değil tam breadcrumb yolunu kullanmak öneriliyor.

6. Kategori Ayıracının Doğru Parse Edildiğini Kontrol Edin

Tedarikçi:

Ev/Mutfak/Cezve

kullanabilir.

Başka kaynak:

Ev > Mutfak > Cezve

gönderebilir.

Başka XML:

Ev|Mutfak|Cezve

kullanabilir.

Parser yanlış ayırıcı kullanırsa tüm kategori yolu tek kategori adına dönüşebilir.

7. XML Escape İşlemlerinden Sonra Kategori Yolunu Kontrol Edin

XML içerisinde > işareti gerektiğinde entity biçiminde temsil edilebilir.

Örneğin Google ürün tipi XML örneğinde kategori yolu:

Home > Women > Dresses

biçiminde gönderilebiliyor.

Parser sonrasında bunun doğru şekilde:

Home > Women > Dresses

olarak anlaşılması gerekir.

8. Ana Kategori ile Alt Kategorinin Yer Değiştirmediğini Kontrol Edin

Kaynak:

Ev > Mutfak > Cezve

olabilir.

Hatalı parser:

Ana kategori = Cezve

Alt kategori = Ev

şeklinde okuyabilir.

Bu tip hata az sayıda üründe değil bütün kategori ağacında tekrar eder.

9. Kategori Seviyelerinin Kaybolup Kaybolmadığını Ölçün

Kaynak:

Ev > Mutfak > Kahve Hazırlama > Cezve

gönderiyor.

Hedef:

Ev

oluyor.

Teknik mapping bulunmuş olabilir.

Ancak üç seviye bilgi kaybolmuştur.

Bu aşırı genel eşleştirme olarak işaretlenebilir.

10. Çok Genel Hedef Kategorilere Düşen Ürünleri Listeleyin

Örneğin:

Diğer

Genel

Ev Ürünleri

Aksesuar

gibi geniş kategorilerde olağan dışı ürün yoğunluğu varsa mapping problemi olabilir.

Özellikle yeni XML entegrasyonundan sonra bu kategoriler hızla büyümüşse incelenmelidir.

11. Varsayılan Kategori Kullanım Oranını Ölçün

Mapping bulunamadığında sistem:

Diğer

kategorisine atıyor olabilir.

Bu güvenli fallback olabilir.

Ancak:

10.000 ürünün 4.000'i:

Diğer

altına düştüyse mapping eksiktir.

Fallback kategori hatayı gizlememelidir.

12. “Kategori Yok” ile “Mapping Yok” Ayrımı Yapın

Durum A

Kaynak XML'de kategori bulunmuyor.

→ SOURCE_CATEGORY_MISSING

Durum B

Kaynakta kategori var fakat mağazada eşleştirme yok.

→ CATEGORY_MAPPING_MISSING

Bunların çözümü farklıdır.

13. Kaynakta Boş Kategorileri Tespit Edin

Örneğin:

<category></category>

veya:

<category> </category>

geliyor olabilir.

Bu doğrudan mapping problemi değildir.

Kaynak veri eksikliğidir.

14. Placeholder Kategorileri Gerçek Kategori Saymayın

Kaynak:

N/A

-

Genel

Kategori Yok

gönderebilir.

Bunlar her zaman gerçek ürün kategorisi değildir.

Tedarikçi bazında anlamı doğrulanmalıdır.

15. Yeni Kaynak Kategorileri Otomatik Olarak İzleyin

Dün:

145 kaynak kategori

vardı.

Bugün:

152

oldu.

Yeni 7 kategori mapping tablosunda bulunmayabilir.

Bu nedenle:

NEW_SOURCE_CATEGORY

raporu oluşturulabilir.

16. Yeni Kategori İlk Kez Geldiğinde Sessizce Fallback'e Düşürmeyin

Yeni kategori:

Elektronik > Akıllı Ev > Sensör

geldi.

Mapping bulunamadı.

Sistem bunu:

Genel Elektronik

altına sessizce atarsa problem fark edilmeyebilir.

Daha kontrollü durum:

UNMAPPED_CATEGORY

olabilir.

17. Kaybolan Kaynak Kategorileri de İzleyin

Tedarikçi daha önce:

Mutfak > Cezve

kategorisini kullanıyordu.

Bugün kategori hiç gelmiyor.

Ürünlerin tamamı başka kategoriye taşınmış olabilir.

Bu değişiklik tedarikçi taxonomy güncellemesi olabilir.

18. Kategori Adı Değişikliğini Yeni Kategori Sanmayın

Eski:

Mutfak Gereçleri

Yeni:

Mutfak Ürünleri

olabilir.

ID aynıysa sadece isim değişikliği olabilir.

Ancak mapping yalnızca kategori adına bağlıysa eski ilişki bozulabilir.

19. Kategori ID Değişikliğini de Ayrı Kontrol Edin

Kategori adı aynı:

Cezveler

ama:

ID 125 → 982

oldu.

Bu:

• tedarikçi taxonomy yenilemesi,
• kategori yeniden oluşturulması

olabilir.

Otomatik mapping yeniden doğrulanmalıdır.

20. Aynı Kaynak Kategorinin İki Hedefe Bağlandığı Durumları Bulun

Örneğin:

Supplier Category 125

aynı anda:

Store Category A

ve:

Store Category B

ile eşleştirilmiş.

Bu özellikle mapping tablosunda duplicate kayıt olduğunu gösterebilir.

21. Bir Kaynak Kategori Birden Fazla Hedefe Gidebilir, Ancak Kuralı Açık Olmalıdır

Örneğin tedarikçi çok genel:

Ev Gereçleri

kategorisi kullanıyor.

Bu gruptaki ürünlerden bazıları:

• mutfak,
• banyo,
• dekorasyon

olabilir.

Bu durumda sadece kategori mapping yeterli olmayabilir.

Ürün düzeyinde:

• alt alan,
• ürün tipi,
• marka/model,
• attribute

gibi ek kurallar gerekebilir.

22. One-to-Many Mapping'i Sessizce Çalıştırmayın

Kaynak kategori:

Ev Gereçleri

üç hedefe gidecekse:

hangi ürünün hangi hedefe gideceği

deterministik biçimde açıklanmalıdır.

Rastgele veya ilk eşleşen kategori seçilmemelidir.

23. Many-to-One Mapping Normal Olabilir

Tedarikçi:

Cezve

Kahve Cezvesi

Çelik Cezveler

gibi üç ayrı kategori kullanabilir.

Mağazada bunların tamamı:

Cezveler

altına bağlanabilir.

Bu hata değildir.

Ancak aşırı birleştirme kontrol edilmelidir.

24. Aşırı Kategori Sıkıştırmasını Tespit Edin

Örneğin 80 farklı tedarikçi alt kategorisinin tamamı:

Ev & Yaşam

kategorisine bağlanmış.

Teknik olarak many-to-one mapping vardır.

Ama katalog kullanışlılığı ciddi biçimde kaybolmuştur.

Bu durumda:

category compression ratio

gibi bir ölçüm kullanılabilir.

25. Ürün Adı ile Kategori Uyumsuzluğunu Aday Sinyal Olarak Kullanın

Örneğin ürün adı:

Çelik Cezve 12 No

hedef kategori:

Oyuncak Bebekler

ise hata ihtimali yüksektir.

Bu tür semantik kontrol güçlü bir anomali sinyalidir.

Ancak ürün adından kategori kesin olarak belirlenmemelidir.

26. Anahtar Kelime Kontrolünü Otomatik Gerçek Olarak Kabul Etmeyin

Örneğin ürün adında:

çekiç

kelimesi varsa hırdavat olma ihtimali yüksektir.

Ancak:

Çekiç Şeklinde Oyuncak

farklı kategoriye ait olabilir.

Dolayısıyla başlık-kategori uyumu:

candidate error detection

için kullanılmalıdır.

27. Marka Kategori Uyumsuzluğunu Yardımcı Sinyal Olarak Kullanabilirsiniz

Belirli marka yalnızca bir ürün grubunda bulunuyorsa yanlış kategori sinyali verebilir.

Ancak markalar farklı kategorilerde ürün üretebildiğinden:

marka → kategori

tek başına kesin kural olmamalıdır.

28. Ürün Özellikleri ile Hedef Kategoriyi Karşılaştırın

Örneğin ürün:

• beden,
• renk,
• kumaş

özellikleri taşıyor.

Ancak hedef:

Elektrikli El Aletleri

ise ciddi uyumsuzluk olabilir.

Kategoriye özgü attribute yapısı güçlü hata sinyalleri sağlayabilir.

29. Hedef Kategorinin Beklediği Zorunlu Özellikleri İzleyin

Yanlış kategoriye gönderilen ürünler bazen:

üründe olmayan zorunlu attribute'lar

istemeye başlayabilir.

Mevcut Ulu Trendyol rehberinde de yanlış kategori seçiminin zorunlu özelliklerin eksik kalmasına ve ürünün yayına alınamamasına neden olabileceği belirtiliyor.

Bu nedenle toplu:

required attribute missing

hataları kategori mapping probleminin işareti olabilir.

30. Kategori Değiştikten Sonra Hata Sayısı Arttıysa Mapping'i Kontrol Edin

Dün:

kategori hatası 10 ürün.

Bugün deployment sonrası:

4.500 ürün.

Muhtemel neden:

4.500 ürün birden yanlış sınıflandırıldı

olabilir.

Ama daha olası ortak nedenler:

• mapping tablosu değişti,
• hedef kategori ID'leri güncellendi,
• kategori parser bozuldu.

31. Hata Loglarını Kategori ID ile Birlikte Okuyun

Örneğin log:

CATEGORY_ERROR

demek yerine:

Supplier category: 125

Supplier path: Ev > Mutfak > Cezve

Mapped target: 874

Target path: Ev > Dekorasyon

şeklinde bilgi taşıyabilir.

111 numaralı hata logu içeriği bu teşhis katmanının genel yapısını sahiplenir.

32. Kategori Mapping Versiyonunu Kaydedin

Bugün:

MAP_V3

çalışıyor.

Geçen hafta:

MAP_V2

vardı.

Ürün:

önceden doğru,

bugün yanlış.

Bu durumda iki mapping versiyonu karşılaştırılabilir.

33. Kategori Değişiklik Geçmişini Tutun

Örneğin:

SKU ABC:

12 Ağustos → Mutfak > Cezveler

23 Ağustos → Ev > Dekorasyon

Bu değişiklik:

• manuel işlem,
• supplier category change,
• mapping update

sonucu olabilir.

Kaynak da kaydedilmelidir.

34. Ani Toplu Kategori Değişimlerini Alarm Olarak İzleyin

Normal sync:

50 ürün kategori değiştirdi.

Yeni sync:

7.500 ürün değiştirecek.

Bu gerçek taxonomy revizyonu olabilir.

Ancak toplu mapping hatası da olabilir.

Canlıya uygulanmadan önce review düşünülebilir.

35. Kategori Dağılımını Önce ve Sonra Karşılaştırın

Örneğin önce:

Mutfak → 2.000

Hırdavat → 1.500

Dekorasyon → 800

Sonra:

Mutfak → 50

Hırdavat → 1.450

Dekorasyon → 2.800

Bu büyük kayma araştırılmalıdır.

Kategori sayısı tek başına değil dağılım değişimi önemlidir.

36. Boşalan Kategorileri İzleyin

Dün 500 ürün bulunan:

Cezveler

kategorisi bugün:

0 ürün

oldu.

Aynı anda:

Ev Gereçleri

500 ürün arttı.

Bu güçlü bir mapping değişimi sinyalidir.

37. Bir Anda Aşırı Büyüyen Kategorileri İzleyin

Normalde:

Diğer

kategorisinde 50 ürün var.

Yeni sync sonrası:

5.000 ürün.

Bunun sebebi genellikle:

mapping bulunamadı → fallback

olabilir.

38. Ürün Ailesinin Dağıldığı Durumları Tespit Edin

Aynı ürün ailesi:

20 cm → Mutfak

30 cm → Dekorasyon

40 cm → Hırdavat

şeklinde farklı kategorilere düşmüş olabilir.

Varyant veya benzer SKU'ların hedef kategori tutarlılığı kontrol edilebilir.

39. Varyantların Aynı Ürün Türünde Olup Olmadığını Kontrol Edin

Renk veya beden varyantlarının farklı hedef kategorilere düşmesi çoğunlukla şüphelidir.

Ancak gerçekten farklı ürün türleri varsa istisnalar olabilir.

Otomatik kontrol yalnızca alarm üretmelidir.

40. Kategori Seçiminde Ürün Seviyesini Koruyun

Parent ürün:

Tişört

alt varyantlar:

Siyah S

Siyah M

Siyah L.

Kategori ilişkisi parent üzerinden yönetilebilir.

Ancak pazaryeri yapısında varyant kayıtlarının da aynı hedef kategori bağlamını taşıması gerekebilir.

41. Mağaza Kategorisi ile Google Ürün Kategorisini Aynı Şey Kabul Etmeyin

Bu önemli.

Kendi mağazanız:

Ev & Yaşam > Mutfak > Cezveler

kullanabilir.

Google ise kendi taxonomy'sini kullanır.

Google Merchant Center google_product_category değerinin Google'ın önceden tanımlı taxonomy'sinden gelmesi gerektiğini; mağazanın kendi kategori ağacının ise product_type üzerinden sunulabileceğini belirtiyor.

Bu iki alan ayrı mapping katmanlarıdır.

42. Google Kategorisini Mağaza Kategorisine Körü Körüne Kopyalamayın

Google taxonomy:

mağazanızın navigation ağacı değildir.

Benzer biçimde mağaza kategori yolunuz da geçerli bir Google kategori değeri olmak zorunda değildir.

Her hedef kendi taxonomy'siyle yönetilmelidir.

43. Google Kategori Override'ında Geçerli Taksonomi Değeri Kullanın

Google google_product_category verilirse kategori ID'si veya tam kategori yolu kullanılabileceğini ve en alakalı kategorinin seçilmesini belirtiyor. Bir ürün için yalnızca bir Google ürün kategorisi kullanılabiliyor.

Bu nedenle eski veya uydurma kategori ID'leri ayrıca validation'dan geçirilmelidir.

44. Hedef Platform Taksonomisi Değiştiğinde Mapping'i Yeniden Kontrol Edin

Kategori ağacı zaman içinde değişebilir.

Örneğin hedef platform:

• kategori kaldırabilir,
• yeni alt kategori açabilir,
• ID değiştirebilir.

Mapping tablosu:

bir kere oluştur ve unut

sistemi olmamalıdır.

45. Pasif Hedef Kategoriye Mapping Yapılmasını Engelleyin

Hedef kategori veri tabanında mevcut olabilir.

Ancak:

active = false

durumunda olabilir.

Mapping teknik olarak ID'yi bulsa da ürün yayınlanmayabilir.

Kategori geçerliliği yalnızca:

ID var mı?

değil,

aktif ve kullanılabilir mi?

olarak kontrol edilmelidir.

46. Silinmiş Hedef Kategorilerin Mapping Kayıtlarını Bulun

Kategori mağazadan kaldırılmış.

Ancak mapping tablosunda hâlâ:

source 125 → deleted target 800

ilişkisi var.

Yeni ürünler:

• hata verebilir,
• kategorisiz kalabilir,
• fallback'e düşebilir.

Bu ilişkiler periyodik kontrol edilebilir.

47. Kategori Mapping'i Sonradan Değiştiğinde Ürünleri Yeniden Değerlendirin

Eski mapping:

Ev Gereçleri → Ev & Mobilya

Yeni:

Ev Gereçleri → Mutfak Gereçleri

oldu.

Daha önce aktarılmış ürünler eski kategoride kalıyorsa yalnızca yeni ürünler düzelmiş olur.

Mapping migration planı gerekebilir.

48. Ancak Kategori Değişikliğini Körü Körüne Bütün Eski Ürünlere Uygulamayın

Bazı ürünlerde manuel kategori düzeltmeleri yapılmış olabilir.

Otomatik yeni mapping:

manuel doğru kategoriyi bozabilir.

Bu nedenle:

category_source = XML / MAPPING / MANUAL

gibi kaynak bilgisi tutulabilir.

49. Manuel Kategori Override'larını Koruyun

Örneğin XML:

Ev Gereçleri

diyor.

Operatör ürünü bilinçli olarak:

Kahve Hazırlama

kategorisine taşıdı.

Bir sonraki senkronizasyon mapping'in eski sonucu ile bu düzenlemeyi ezmemelidir; tabii sistem politikası bu şekilde tasarlandıysa.

50. Kategori Hatasını Ürün URL'siyle Gereksiz Şekilde Birleştirmeyin

Ürün kategorisi düzeldiğinde ürün URL'sinin mutlaka değişmesi gerekmez.

Özellikle ürün URL'si kategori yolundan bağımsızsa mevcut URL korunabilir.

Kategori düzeltmesi:

navigation/taxonomy

işlemidir.

URL yaşam döngüsü ayrı konudur.

51. Kategori Hatası SEO Sorunu Olabilir Ama 119'u SEO Rehberine Çevirmeyin

Yanlış kategori:

• iç link yapısını,
• breadcrumb'ı,
• kategori sayfası alaka düzeyini

etkileyebilir.

Ancak 119'un ana hedefi:

kategori SEO optimizasyonu

değil,

XML category mapping diagnostic

olmalıdır.

52. Kategori Hatalarını Tiplerine Göre Kodlayın

Örneğin:

SOURCE_CATEGORY_MISSING

UNMAPPED_CATEGORY

TARGET_CATEGORY_NOT_FOUND

TARGET_CATEGORY_INACTIVE

CATEGORY_ID_CHANGED

CATEGORY_PATH_MALFORMED

CATEGORY_TOO_GENERIC

CATEGORY_ATTRIBUTE_CONFLICT

MULTIPLE_MAPPING_CONFLICT

CATEGORY_CHANGED_UNEXPECTEDLY

gibi kodlar kullanılabilir.

53. Hata Koduyla Aksiyon Kuralını Birlikte Tutun

Örneğin:

SOURCE_CATEGORY_MISSING

→ REVIEW

TARGET_CATEGORY_NOT_FOUND

→ BLOCK

CATEGORY_TOO_GENERIC

→ WARNING

MULTIPLE_MAPPING_CONFLICT

→ BLOCK

gibi.

Gerçek politika işletmeye göre değişebilir.

54. Her Kategori Hatası Ürünün Tamamen Reddedilmesini Gerektirmez

Örneğin ürün mağazaya:

taslak

olarak import edilebilir.

Ancak doğru kategori belirlenmeden:

yayınlanmayabilir.

Bu:

IMPORTABLE

ile:

PUBLISHABLE

durumlarını ayırmayı sağlar.

55. Kategori Hatalarını Tedarikçi Bazında Ölçün

Supplier A:

10.000 ürünün 20'sinde problem.

Supplier B:

5.000 ürünün 1.500'ünde mapping yok.

İki kaynak aynı operasyon kalitesine sahip değildir.

Kategori hata oranı tedarikçi veri kalitesi açısından kullanılabilir.

56. Kaynak Kategori Bazında Hata Oranı Ölçün

Örneğin:

Ev Gereçleri

kategorisindeki ürünlerin %80'i manuel düzeltiliyorsa kaynak kategori çok geniş olabilir.

Bu durumda ürün bazında sürekli düzeltme yerine mapping modelini değiştirmek daha doğru olabilir.

57. Hedef Kategori Bazında Yanlış Pozitifleri İnceleyin

Örneğin:

Oyuncaklar

kategorisine 2.000 ürün mapping olmuş.

Örneklemde:

• tava,
• cezve,
• tornavida

çıkıyor.

Bu durumda hedef kategori mapping'i ciddi problemli olabilir.

58. Kategori Bazlı Örneklem Kontrolü Yapın

Binlerce ürünü manuel incelemek gerekmez.

Örneğin her önemli hedef kategoriden:

rastgele belirli sayıda ürün

açılabilir.

Kontrol:

• ürün adı,
• görsel,
• kaynak kategori,
• hedef kategori

üzerinden yapılır.

Tek bir evrensel örneklem sayısı yoktur.

59. Yeni Mapping'i Önce Dry-Run Olarak Çalıştırın

Örneğin yeni mapping kuralı:

Ev Gereçleri → Mutfak

olacak.

Canlıya uygulamadan:

hangi 4.250 ürünün kategorisi değişecek?

raporu üretilebilir.

Böylece yanlış kuralın büyük kataloğa yayılması engellenebilir.

60. Eski ve Yeni Mapping Sonucunu Yan Yana Gösterin

Örneğin:

SKU: ABC125

Source: Ev > Mutfak > Cezve

Current: Ev & Mobilya

New mapping: Mutfak > Cezveler

Status: CHANGE

gibi dry-run raporu oldukça kullanışlıdır.

61. Kategori Değişim Sayısını Yayın Engeli Olarak Kullanabilirsiniz

Normalde 100 ürün değişiyor.

Yeni kural:

8.000 ürün değiştirecek.

Sistem:

manual approval required

durumuna geçebilir.

Eşik işletmenin geçmiş verisine göre belirlenmelidir.

62. Mapping Kuralını Versiyonlayın

Örneğin:

CATEGORY_MAP_V4

kullanılıyor.

Kural değişince:

V5

olabilir.

Her ürün kategori güncellemesinde hangi versiyonun kullanıldığı loglanabilir.

63. Mapping'i Kim Değiştirdi Bilgisini Tutabilirsiniz

Özellikle yönetim panelinde manuel mapping varsa:

• kullanıcı,
• tarih,
• eski hedef,
• yeni hedef

kayıt altına alınabilir.

Bu, yanlış toplu mapping'in kaynağını bulmayı kolaylaştırır.

64. Category Mapping ile Category Classification'ı Ayırın

Mapping

Kaynak kategori açıkça biliniyor:

Supplier Cezveler → Store Cezveler

Classification

Kaynak kategori yeterli değil.

Ürün özelliklerinden:

bu ürün muhtemelen Cezveler

sonucu çıkarılıyor.

İkincisi daha fazla belirsizlik taşır.

65. Otomatik Sınıflandırmada Güven Seviyesi Kullanın

Örneğin:

High confidence

Ürün doğrudan yayınlanabilir.

Medium

Review gerekebilir.

Low

Otomatik kategori uygulanmayabilir.

Bu özellikle ürün başlığı/açıklamasından kategori tahmini yapılıyorsa önemlidir.

66. Yapay Zekâ veya Benzerlik Modeli Kullanılsa Bile Kaynak Mapping'i Kaybetmeyin

Model:

ürünü kategoriye önerebilir.

Ancak:

hangi kaynak kategori

hangi model sonucu

hangi hedef kategori

bilgileri tutulmalıdır.

Sistem sonradan denetlenebilir olmalıdır.

67. Kategori Hata Kontrolünü Feed Testine Dahil Edin

113 numaralı XML feed testi kapsamında:

• yeni kategori,
• unmapped kategori,
• yanlış ID,
• çok genel kategori,
• duplicate mapping,
• taxonomy change

senaryoları özellikle denenebilir.

119 ise bu hataların nasıl bulunacağını ve sınıflandırılacağını sahiplenmelidir.

68. Kategori Kontrolünü Her Senkronizasyonda Baştan Tamamen Çalıştırmak Zorunda Değilsiniz

Mapping değişmediyse ve ürünün kaynak kategorisi değişmediyse tekrar classification yapmak gereksiz olabilir.

Şunlar değiştiyse yeniden değerlendirme yapılabilir:

• source category,
• mapping version,
• target taxonomy,
• product identity.

69. Kategori Değişikliğini Normal Ürün Değişikliğinden Daha Dikkatli Ele Alın

Fiyatın değişmesi normaldir.

Stokun değişmesi normaldir.

Ancak aynı fiziksel ürünün:

Mutfak → Oyuncak

geçmesi daha sıra dışı bir değişikliktir.

Kategori değişimi daha yüksek riskli değişiklik sınıfına alınabilir.

70. Nihai Kontrolü Müşterinin Gördüğü Kategori Üzerinden Yapın

Backend mapping tablosu doğru görünebilir.

Ama frontend cache veya indeks nedeniyle ürün hâlâ eski kategoride olabilir.

Bu nedenle önemli örneklerde:

kaynak XML

↓

mapping

↓

database

↓

kategori sayfası

zinciri uçtan uca kontrol edilmelidir.

XML KATEGORİ HATASI KONTROL LİSTESİ

Kaynak kategori

XML gerçekten hangi kategori değerini gönderiyor?

Kaynak ID

Kategori ID mevcut mu ve stabil mi?

Tam yol

Parent ve child seviyeleri korunuyor mu?

Delimiter

Kategori ayıracı doğru okunuyor mu?

Boş değer

Kategori missing/empty mi?

Yeni kategori

Daha önce görülmemiş kaynak kategori var mı?

Kaybolan kategori

Önceki taxonomy'den kategori kayboldu mu?

Mapping

Kaynak kategori hedefe bağlı mı?

Çakışma

Aynı kaynak için birden fazla mapping var mı?

Fallback

Kaç ürün “Diğer” kategorisine düşüyor?

Derinlik

Alt kategori bilgisi kayboluyor mu?

Hedef kategori

ID gerçekten mevcut mu?

Aktiflik

Hedef kategori kullanılabilir mi?

Dağılım

Kategori ürün sayıları aniden değişti mi?

Boşalan kategori

Beklenmedik biçimde 0 ürüne düştü mü?

Aşırı büyüme

Bir kategori bütün kataloğu topluyor mu?

Ürün adı

Kategoriyle bariz çelişiyor mu?

Ürün özellikleri

Hedef kategorinin beklediği veriyle tutarlı mı?

Varyant

Aynı ürün ailesi farklı kategorilere dağılıyor mu?

Manuel override

XML güncellemesi manuel kategoriyi eziyor mu?

Taksonomi

Hedef platform kategori ağacı değişti mi?

Google

Store category ile Google category ayrılıyor mu?

Log

Source → mapping → target zinciri görülebiliyor mu?

Versiyon

Hangi mapping kuralı kullanıldı?

Dry-run

Toplu değişiklik uygulanmadan raporlanıyor mu?

Son kontrol

Ürün gerçekten beklenen kategori sayfasında görünüyor mu?

XML KATEGORİ HATALARI NASIL TESPİT EDİLİR?

Pratik uygulama sırası şöyle kurulabilir:

1. XML'deki kategori alanlarını ve kategori ID'lerini belirleyin.

2. Tedarikçinin kategori yolunun nasıl oluşturulduğunu doğrulayın.

3. Ham kategori değerini değişmeden saklayın.

4. Kaynak kategori ile mağaza kategorisini ayrı alanlarda tutun.

5. Tam kategori yolu üzerinden mapping tablosu oluşturun.

6. Mapping bulunmayan kaynak kategorileri raporlayın.

7. Yeni ve kaybolan kaynak kategorileri otomatik tespit edin.

8. Pasif veya silinmiş hedef kategori mapping'lerini bulun.

9. Aynı kaynak kategori için duplicate/çelişkili mapping kontrolü yapın.

10. Varsayılan kategoriye düşen ürün oranını ölçün.

11. Çok genel hedef kategorilere aşırı yoğunlaşmayı kontrol edin.

12. Önceki ve yeni kategori dağılımlarını karşılaştırın.

13. Ani toplu kategori değişikliklerini ayrı alarm olarak işaretleyin.

14. Ürün adı ve teknik özelliklerle kategori arasında belirgin uyumsuzlukları aday hata olarak bulun.

15. Varyantların aynı ürün tipi içerisinde kategori tutarlılığını kontrol edin.

16. Hedef satış kanalındaki zorunlu attribute hatalarını kategori problemleriyle ilişkilendirin.

17. Store category, marketplace category ve Google taxonomy mapping'lerini ayrı yönetin.

18. Mapping değişikliklerini dry-run ile bütün katalog üzerinde simüle edin.

19. Küçük bir ürün örnekleminde kaynak → hedef sonucu manuel doğrulayın.

20. Mapping versiyonunu, değişiklik nedenini ve nihai kategori sonucunu loglayın.

SIK SORULAN SORULAR

XML'deki kategori ile kendi sitemdeki kategori aynı olmak zorunda mı?

Hayır. Tedarikçinin kategori ağacıyla mağazanızın kategori yapısı farklı olabilir. XML entegrasyonunun amacı kaynak kategori adını körü körüne kopyalamak değil, ürünü sizin katalog yapınızdaki doğru kategoriyle eşleştirmektir. Ulu İthalat'ın mevcut genel XML entegrasyonu içeriğinde de tedarikçi ve mağaza/pazaryeri kategori yapılarının farklı olabileceği belirtiliyor.

Kategori alanı doluysa kategori hatası yok mudur?

Hayır. Alan dolu olabilir fakat yanlış kategoriye bağlanmış olabilir. Ev > Mutfak > Cezveler kaynağının Oyuncaklar kategorisine eşlenmesi completeness problemi değil mapping doğruluğu problemidir.

Binlerce ürün bir anda “Diğer” kategorisine düştüyse ne kontrol edilmeli?

Önce yeni kaynak kategoriler, mapping tablosu, kategori ID değişiklikleri, hedef kategorilerin aktifliği ve fallback kuralı kontrol edilmelidir. Büyük çaplı değişiklik tek tek binlerce ürünün bozulmasından ziyade ortak mapping veya taxonomy problemine işaret edebilir.

Google ürün kategorisi ile kendi mağaza kategorimi aynı kullanabilir miyim?

Bazen değerler benzer olabilir fakat bunlar farklı sistemlerdir. Google google_product_category için kendi predefined taxonomy'sini kullanır; mağazanızın kendi kategori yolu ise product_type gibi ayrı bir alanla gönderilebilir. Google ürün kategorisi verilirse en alakalı geçerli taxonomy değeri kullanılmalıdır.

Ürün adına bakarak otomatik kategori atanabilir mi?

Ürün adı güçlü bir yardımcı sinyal olabilir ancak tek başına kesin kaynak olarak kullanılmamalıdır. Model kodları, benzer adlar veya “çekiç şeklinde oyuncak” gibi ifadeler yanlış sınıflandırmaya yol açabilir. Başlık ve özellik tabanlı otomatik sınıflandırma güven seviyeleriyle ve gerektiğinde manuel incelemeyle kullanılmalıdır.

KATEGORİ HATASINI BULMAK İÇİN YALNIZCA HEDEF KATEGORİYE DEĞİL, BÜTÜN EŞLEŞTİRME ZİNCİRİNE BAKIN

Yanlış yaklaşım:

“Ürün yanlış kategoride; doğru kategoriye taşı.”

şeklinde yalnızca sonucu düzeltmektir.

Çünkü ertesi XML senkronizasyonunda aynı mapping hatası ürünü tekrar eski kategoriye gönderebilir.

Daha kontrollü yöntem:

kaynak kategori neydi?

↓

kategori yolu doğru parse edildi mi?

↓

mapping hangi kuralla bulundu?

↓

hangi target ID seçildi?

↓

target kategori aktif mi?

↓

ürün tipiyle mantıklı mı?

↓

kategoriye özgü attribute'lar uyumlu mu?

↓

aynı hata başka kaç üründe var?

↓

mapping'i düzelt

↓

dry-run yap

↓

sonra toplu kategori düzeltmesini uygula

şeklindedir.

Örneğin:

Kaynak: Ev > Mutfak > Cezveler

Mapping: Category 125 → Store 820

Store 820: Oyuncaklar

ise problemin çözümü:

tek ürünü Mutfak'a taşımak

değil,

125 → 820 mapping kaydını düzeltmek

olmalıdır.

119'un ana mesajı tam olarak budur:

Kategori hatasının görüldüğü ürünü değil, hatayı üreten kategori eşleştirme zincirini düzeltin.