XML entegrasyonu kullanan bir e-ticaret işletmesinde temel problem her zaman verinin eksik olması değildir.

Bazen veri vardır fakat aynı bilgi farklı biçimlerde gelir.

Örneğin üç farklı tedarikçi aynı tür bilgiyi şu şekillerde gönderebilir:

Marka

MARKA X

Marka X

marka x

Ölçü

30 cm

30CM

300 mm

Stok durumu

1

true

Evet

Fiyat

1.250,50

1250.50

Kategori

Ev/Mutfak/Cezve

Ev > Mutfak > Cezve

Bu değerlerin bazıları anlam olarak aynı olabilir.

Ancak yazılım açısından farklı görünebilirler.

İşte XML veri normalizasyonu, bu farklı kaynak gösterimlerinin ürünün gerçek anlamını bozmadan ortak bir iç veri standardına dönüştürülmesi sürecidir.

Ulu İthalat'ın XML Bayilik sayfasında da ürün adı, fiyat, stok ve görsel gibi bilgilerin XML yoluyla satış kanallarına aktarılabildiği açıklanıyor. Ürün sayısı ve veri alanları büyüdükçe yalnızca aktarımın çalışması değil, gelen verinin mağazada tutarlı biçimde temsil edilmesi de önem kazanır.

XML Bayilik sayfası

XML Ürün Verisi Normalizasyonu Nedir?

Pratik anlamıyla normalizasyon:

aynı anlama gelen verileri ortak bir biçime dönüştürmek

olarak düşünülebilir.

Örneğin:

Kaynak 1:

MARKA X

Kaynak 2:

Marka X

Kaynak 3:

marka x

Mağazadaki standart değer:

Marka X

olabilir.

Ancak normalizasyon:

veride bulunmayan bilgiyi oluşturmak

değildir.

Örneğin XML'de malzeme bilgisi yoksa normalizasyon sistemi ürüne:

paslanmaz çelik

özelliği eklememelidir.

Bu işlem normalizasyon değil veri uydurma olur.

1. Normalizasyon ile Veri Doğrulamayı Birbirinden Ayırın

Bu ayrım 108'in en önemli noktalarından biridir.

Normalizasyon

MARKA X → Marka X

Doğrulama

Bu ürünün markası gerçekten Marka X mı?

İlk işlem biçimi düzenler.

İkinci işlem bilginin doğru olup olmadığını kontrol eder.

Dolayısıyla:

normalize edilmiş veri = otomatik olarak doğru veri

değildir.

2. Normalizasyon ile Eksik Veri Kontrolünü Ayırın

XML içerisinde:

<marka></marka>

varsa normalizasyonla marka oluşturulamaz.

Burada önce:

marka bilgisi eksik

sonucu çıkmalıdır.

Canlı XML Feed İçinde Eksik Alanlar Nasıl Tespit Edilir? içeriği de completeness ile validity kavramlarını ayrı katmanlar olarak ele alıyor.

XML Feed İçinde Eksik Alanlar Nasıl Tespit Edilir?

Ayrım:

Alan geliyor mu? → 100

Gelen değer hangi standart biçimde tutulacak? → 108

3. Normalizasyon ile Veri Temizliğini Tamamen Aynı Kavram Saymayın

Uygulamada bu terimler birbirine yaklaşabilir.

Ancak 108 içerisinde pratik ayrımı şöyle kullanabiliriz:

Temizleme: gereksiz boşluk, bozuk HTML kalıntısı veya geçersiz placeholder gibi sorunları giderme.

Normalizasyon: aynı anlamdaki değerleri ortak formata dönüştürme.

Doğrulama: değerin gerçek ve kullanılabilir olup olmadığını kontrol etme.

Eşleştirme: normalize edilmiş değeri mağazadaki doğru kayıtla bağlama.

Bu dört aşama birlikte çalışabilir.

4. Ham XML Verisini Her Zaman Koruyun

Normalizasyon yapılırken kaynak değer kaybolmamalıdır.

Örneğin XML:

MARKA X

gönderiyor.

Mağaza:

Marka X

olarak kullanıyor.

Sistemde mümkünse ikisi de tutulabilir:

Kaynak değer: MARKA X

Normalize edilmiş değer: marka x

Canonical görüntü değeri: Marka X

Böylece sorun olduğunda:

Tedarikçi ne gönderdi?

sorusu cevaplanabilir.

5. Kaynak Değer ile Kullanıcıya Gösterilen Değeri Ayırın

Normalizasyon sisteminin yaptığı işlem her zaman kullanıcıya gösterilecek değeri doğrudan değiştirmek zorunda değildir.

Örneğin karşılaştırma için:

MARKA X

↓

marka x

kullanılabilir.

Ancak müşteriye:

Marka X

gösterilebilir.

Yani:

comparison key

ile

display value

ayrı tutulabilir.

6. Önce Bir Alan Sözlüğü Oluşturun

Farklı XML'lerde aynı veri farklı alanlarla gelebilir.

Örneğin:

Tedarikçi A:

urun_ad

Tedarikçi B:

product_name

Tedarikçi C:

title

kullanabilir.

Mağazada ise ortak alan:

product_name

olabilir.

Normalizasyon başlamadan önce:

kaynak alan → ortak alan

eşleştirmesi oluşturulmalıdır.

7. Ortak Bir Ürün Veri Şeması Belirleyin

Örneğin mağaza içerisinde ortak ürün modeli:

• product_id
• supplier_id
• supplier_sku
• sku
• barcode
• product_name
• brand
• category
• price
• currency
• stock
• description
• color
• size
• unit
• images

gibi alanlardan oluşabilir.

Her tedarikçinin XML'i farklı olsa bile sonuçta veriler bu ortak modele dönüştürülebilir.

8. Tedarikçinin Alan Yapısını Mağaza Veri Modeline Doğrudan Bağlamayın

Örneğin tedarikçi bugün:

urun_ad

kullanıyor.

Yarın:

name

kullanabilir.

Mağaza sistemi doğrudan tedarikçi alan isimlerine bağımlıysa bu değişiklik büyük problem oluşturur.

Daha kontrollü yapı:

Tedarikçi XML

↓

mapping

↓

normalizasyon

↓

ortak ürün modeli

↓

mağaza

şeklinde olabilir.

9. Baş ve Son Boşlukları Temizleyin

Örneğin:

" Çelik Cezve "

ile

"Çelik Cezve"

aynı ürün adını temsil edebilir.

Bu nedenle metin alanlarında:

trim

işlemi temel normalizasyonlardan biri olabilir.

10. Birden Fazla Gereksiz Boşluğu Normalize Edin

Örneğin:

Çelik Cezve 12 No

değeri:

Çelik Cezve 12 No

şeklinde karşılaştırılabilir.

Bu yöntem marka, kategori ve ürün başlıklarında yararlı olabilir.

Ancak model kodlarının iç yapısını bozmamak gerekir.

11. Görünmeyen Boşluk Karakterlerine Dikkat Edin

İki ürün adı ekranda tamamen aynı görünebilir.

Ancak birinde normal boşluk, diğerinde farklı Unicode boşluk karakteri olabilir.

Bu durum:

• arama,
• duplicate kontrolü,
• alias eşleştirme,
• slug üretimi

gibi işlemleri etkileyebilir.

Gerekirse karşılaştırma katmanında bu karakterler standartlaştırılabilir.

12. Büyük-Küçük Harf Normalizasyonunu Karşılaştırma İçin Kullanın

Örneğin:

ÇELİK CEZVE

Çelik Cezve

çelik cezve

karşılaştırma açısından aynı metin olabilir.

Ancak sistem bütün kullanıcıya görünen ürün adlarını:

tamamı küçük harf

yapmak zorunda değildir.

Normalizasyon anahtarını görüntü değerinden ayırmak daha güvenlidir.

13. Türkçe Büyük-Küçük Harf Dönüşümünü Dikkatli Yapın

Türkçedeki:

I / ı

ve

İ / i

ilişkileri bazı dil bağımsız yazılım dönüşümlerinde beklenmedik sonuçlar oluşturabilir.

Bu nedenle Türkçe metinler normalize edilirken kullanılan yazılımın locale davranışı kontrol edilmelidir.

Amaç gerçek ürün adını bozmak değil karşılaştırmayı tutarlı hale getirmektir.

14. Özel Karakterleri Körü Körüne Silmeyin

Örneğin:

A&B

gerçek bir marka veya model ifadesi olabilir.

Normalizasyon:

özel karakter gördüm → sil

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

XML içerisinde karakterin bozulması ayrı bir problemdir.

Canlı XML Veri Akışında Özel Karakter Sorunları Nasıl Çözülür? içeriği özellikle &, <, encoding, Türkçe karakter ve XML entity sorunlarını teknik aktarım problemi olarak ele alıyor.

XML Veri Akışında Özel Karakter Sorunları Nasıl Çözülür?

Ayrım:

Karakter doğru taşınıyor mu? → 101

Doğru taşınan değer hangi ortak formata dönüştürülecek? → 108

15. Noktalama İşaretlerini Alan Bazında Değerlendirin

Örneğin ürün adı:

Çelik Cezve - 12 No

ile:

Çelik Cezve 12 No

karşılaştırma açısından benzer olabilir.

Ancak model:

AB-100

ise tire:

ürün kimliğinin parçası

olabilir.

Bu nedenle tek bir:

“bütün noktalama işaretlerini kaldır”

kuralı kullanılmamalıdır.

16. Marka Alanını Canonical Değere Eşleştirin

Marka normalizasyonu 108'in uygulanabileceği en açık alanlardan biridir.

Örneğin:

MARKA X

MarkaX

marka x

değerleri doğrulandıktan sonra tek:

Marka X

kaydına eşleştirilebilir.

Ancak bu alanın derinlemesine standardizasyonu zaten canlı XML Marka Alanı Nasıl Standartlaştırılır? içeriğinin merkezidir.

XML Marka Alanı Nasıl Standartlaştırılır?

108 içerisinde marka yalnızca genel normalizasyon mimarisinin bir örneği olarak kalmalı.

17. Marka Adını Düzeltirken Gerçek Kimliğini Değiştirmeyin

Örneğin:

Marka-X

ile

Marka X

aynı olabilir.

Ancak yalnızca benzer göründükleri için otomatik birleştirme yapılmamalıdır.

Normalizasyon:

aday eşleşme

üretebilir.

Gerçek marka eşleştirmesi ayrıca doğrulanmalıdır.

18. Kategori Verisini Ortak Kategori Ağacına Dönüştürün

Tedarikçi A:

Ev/Mutfak/Cezve

Tedarikçi B:

Mutfak > Pişirme > Cezveler

kullanabilir.

Mağazanız:

Ev & Yaşam → Mutfak → Cezveler

yapısını kullanıyor olabilir.

Burada kaynak kategori adını mağazaya aynen eklemek yerine:

kaynak kategori → mağaza kategori ID

eşleştirmesi yapılabilir.

19. Aynı Kategoriyi Sürekli Yeniden Oluşturmayın

XML:

Ev & Mutfak

EV & MUTFAK

Ev&Mutfak

gönderdiğinde sistem üç kategori oluşturmamalıdır.

Normalize edilmiş kategori değeri mevcut canonical kategoriyle eşleştirilebilir.

20. Kategori Yolu Ayırıcısını Standardize Edin

Tedarikçiler:

/

>

|

gibi farklı ayırıcılar kullanabilir.

Örneğin:

Ev/Mutfak/Cezve

ve

Ev > Mutfak > Cezve

ortak kategori segmentlerine ayrılabilir.

Ancak ürün veya kategori adının kendisinde gerçekten / bulunabileceği senaryolar da düşünülmelidir.

21. Renk Değerleri İçin Ortak Sözlük Kullanabilirsiniz

Örneğin:

Siyah

SIYAH

Black

değerleri gerçekten aynı rengi temsil ettiği doğrulanmışsa:

Siyah

canonical değerine eşleştirilebilir.

Ancak çeviri ve renk anlamı doğrulanmadan otomatik dönüşüm yapılmamalıdır.

Örneğin birbirine yakın iki renk tonu yanlışlıkla tek renge indirgenmemelidir.

22. Beden ve Ölçü Değerlerini Ayrı Alanlarda Tutun

Örneğin:

L

ile:

Large

aynı beden olabilir.

Ancak ürün ölçüsü:

L: 30 cm

gibi başka bir anlam taşıyabilir.

Alan bağlamı bilinmeden değer normalizasyonu yapılmamalıdır.

23. Ölçü Birimlerini Ortak Formata Dönüştürebilirsiniz

Örneğin:

30 cm

ve:

300 mm

matematiksel olarak aynı uzunluğu ifade edebilir.

Sistem iç değer olarak örneğin:

300 mm

kullanabilir.

Müşteriye ise:

30 cm

gösterebilir.

Ancak birim dönüşümü yalnızca:

alanın gerçekten uzunluk olduğu kesin olarak biliniyorsa

yapılmalıdır.

24. Sayıyı Birimden Ayırın

Örneğin:

30cm

değeri iki bileşene ayrılabilir:

value = 30

unit = cm

Bu yapı:

• filtreleme,
• karşılaştırma,
• varyant yönetimi

açısından daha kullanışlı olabilir.

25. Ondalık Sayı Formatlarını Standartlaştırın

Örneğin:

12,50

ile:

12.50

aynı sayıyı gösterebilir.

Ancak:

1.250,50

ile:

1,250.50

farklı yerel sayı formatlarıdır.

Bu nedenle nokta ve virgülü körü körüne silmek yerine kaynağın sayı formatı bilinmelidir.

26. Fiyatı Metinden Sayısal Veriye Dönüştürün

Örneğin:

1.250,50 TL

değeri iç sistemde:

value = 1250.50

currency = TRY

şeklinde tutulabilir.

Bu daha sonra fiyat motorunun güvenli biçimde çalışmasını kolaylaştırır.

Ancak fiyatın KDV dahil/hariç yapısı ayrıca doğrulanmalıdır.

27. KDV Formatlarını Normalizasyon Katmanında Ortaklaştırabilirsiniz

Bir kaynak:

20

başka kaynak:

0.20

başka sistem:

%20

gönderebilir.

Doğrulandıktan sonra ortak iç format:

0.20

veya sistemin seçtiği başka standart olabilir.

Ancak değerin gerçek vergi anlamının doğrulanması ayrı adımdır.

Yani:

formatı dönüştür → normalizasyon

ürünün gerçekten o KDV oranına tabi olduğunu doğrula → vergi kontrolü

olarak ayrılmalıdır.

28. Stok Değerini Sayısal Formata Dönüştürün

Örneğin:

"12"

metin olarak gelebilir.

İç sistem:

12

sayısal stok olarak tutabilir.

Ancak:

stok = 0

değeri silinmemelidir.

Sıfır:

geçerli stok değeri

olabilir.

Canlı eksik alan rehberi de sıfır stok ile eksik stok bilgisinin birbirinden ayrılması gerektiğini açıkça belirtiyor.

29. Boolean Alanları Ortak Formata Dönüştürün

Bir tedarikçi:

1

başka tedarikçi:

true

başka biri:

Evet

kullanabilir.

Eğer alan gerçekten:

aktif/pasif

anlamındaysa iç sistemde:

true / false

biçiminde standardize edilebilir.

Ancak:

1

değerinin ne anlama geldiği tedarikçi dokümantasyonundan doğrulanmalıdır.

30. Tarih Alanlarını Ortak Formatta Tutun

Kaynaklar:

23.08.2026

2026-08-23

23/08/2026

gibi tarih formatları gönderebilir.

İç veri modeli tek bir standart tarih biçimi kullanabilir.

Saat bilgisi varsa zaman dilimi de ayrıca değerlendirilmelidir.

31. SKU'yu Agresif Biçimde Normalize Etmeyin

Bu kritik bir istisnadır.

SKU:

AB-001

ve:

AB001

aynı ürün kodu olmayabilir.

Dolayısıyla:

tireleri kaldır

sıfırları sil

büyük/küçük harf farkını yok et

gibi dönüşümler kimlik alanlarında risklidir.

SKU ve barkod verileri normal metin alanlarından daha korumacı biçimde ele alınmalıdır.

32. Barkodun Başındaki Sıfırları Koruyun

Örneğin barkod:

0123456789012

ise sayıya dönüştürüldüğünde baştaki 0 kaybolabilir.

Bu nedenle barkod/GTIN gibi kimlik değerleri çoğu durumda string olarak tutulmalıdır.

Canlı XML Barkod ve SKU Alanları Nasıl Yönetilir? içeriği de ürün kimliği alanlarının korunmasını ayrıntılı biçimde ele alıyor.

XML Barkod ve SKU Alanları Nasıl Yönetilir?

33. Model Kodlarını Normal Ürün Metni Gibi Temizlemeyin

Örneğin:

ABC-100

ile:

ABC100

iki farklı model olabilir.

Model ve parça kodlarında:

• tire,
• slash,
• nokta,
• baştaki sıfır

anlam taşıyabilir.

Bu alanlar için ayrı normalizasyon politikası kullanılmalıdır.

34. Paket Adedini Yapılandırılmış Veriye Dönüştürün

Ürün açıklamasında:

6'lı

6 Adet

6 PCS

gibi ifadeler bulunabilir.

Eğer paket adedi güvenilir yapılandırılmış alan olarak geliyorsa ortak iç format:

package_quantity = 6

olabilir.

Ancak açıklama metninden otomatik paket adedi çıkarmak daha fazla hata riski taşıyabilir.

35. Tekli, Set ve Koli Birimlerini Ayrı Tutun

Örneğin:

1 adet

1 set

1 koli

aynı miktar değildir.

Normalizasyon:

hepsinin başında 1 var → hepsi aynı

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

Değer ile satış birimi ayrı alanlar olmalıdır.

36. Varyant Değerlerini Canonical Sözlüğe Bağlayın

Örneğin:

Kaynak A:

Kırmızı

Kaynak B:

KIRMIZI

Kaynak C:

Red

Doğrulanmış mapping ile tek:

Kırmızı

varyant değerine dönüşebilir.

Bu özellikle filtreleme ve stok yönetiminde tutarlılığı artırabilir.

37. Parent ve Varyant Kimliğini Normalizasyon Sırasında Kaybetmeyin

Bir ürün:

Ana ürün

ve altında:

• Siyah S,
• Siyah M,
• Beyaz S

varyantlarına sahip olabilir.

Normalizasyon, benzer ürün isimlerini tek metne indirgerken varyant ilişkisini silmemelidir.

Yoksa farklı SKU'lar yanlışlıkla tek ürün gibi görülebilir.

38. Normalizasyon Duplicate Tespitinden Önce Yararlı Olabilir

Örneğin:

ÇELİK CEZVE 12 NO

ve:

Çelik Cezve 12 No

metinleri normalizasyondan sonra daha kolay karşılaştırılabilir.

Canlı duplicate ürün rehberiniz de başlık karşılaştırmasından önce büyük-küçük harf ve boşlukların normalize edilmesini öneriyor; ancak orada normalizasyon yalnızca duplicate adaylarını bulmak için kullanılan bir teknik.

XML Dosyasında Yinelenen Ürünler Nasıl Tespit Edilir?

Ayrım:

Genel veri standardını oluştur → 108

Bu standartlaştırılmış veriyi kullanarak aynı ürün iki kez geliyor mu bul → 102

39. Normalizasyon Sonrası Ürünleri Otomatik Birleştirmeyin

İki ürün normalize edildiğinde isimleri aynı olabilir.

Örneğin:

Organizer 20 cm

ve:

Organizer 30 cm

başlık yapısı benzer olsa da ölçü farklıdır.

Normalizasyon:

aynılaştırma

değil,

karşılaştırılabilir hale getirme

işlemidir.

40. URL ve Slug Üretimini Normalizasyonun Sonraki Katmanı Olarak Düşünün

Ürün adı:

Çelik Ölçü Kaşığı

normalize edilmiş olabilir.

Bundan:

celik-olcu-kasigi

gibi URL slug'ı oluşturmak ise başka bir dönüşüm katmanıdır.

Canlı XML Ürün URL ve Slug Verileri Nasıl Düzenlenir? içeriği bu aşamaya odaklanıyor. Blog listesinde sayfanın güncel olarak yayında olduğu görülüyor.

XML Ürün URL ve Slug Verileri Nasıl Düzenlenir?

Ayrım:

Ürün verisini ortak standarda getir → 108

Bu veriden kalıcı web URL'si oluştur → 103

41. Görsel URL'lerini Metin Alanları Gibi Değiştirmeyin

Örneğin:

görsel URL'sindeki:

?id=52&size=large

ifadesinde karakterlerin anlamı vardır.

URL üzerinde:

boşlukları kaldır, noktalama temizle

gibi genel metin normalizasyonları uygulanmamalıdır.

Alan tipine göre farklı normalizasyon politikası gerekir.

42. Açıklama Alanında HTML'i Düz Metinle Karıştırmayın

Bir tedarikçi:

<b>Malzeme:</b> Çelik

gönderebilir.

Başka tedarikçi:

Malzeme: Çelik

gönderebilir.

Mağaza açıklama standardınız HTML destekliyorsa kontrollü HTML kullanılabilir.

Düz metin gerekiyorsa HTML güvenli biçimde temizlenebilir.

Ancak:

etiketleri rastgele silmek

metin yapısını bozabilir.

43. NULL, N/A, - Gibi Placeholder Değerleri Alan Bazında Yönetin

Örneğin marka:

N/A

geliyorsa gerçek marka değildir.

Ancak model kodunda:

-

karakteri ürün bilgisinin bir bölümü olabilir.

Bu nedenle global:

N/A, - ve 0 değerlerini sil

kuralı güvenli değildir.

Placeholder politikası alan bazında oluşturulmalıdır.

44. Farklı Tedarikçiler İçin Kaynak Bazlı Normalizasyon Kuralları Kullanabilirsiniz

Tedarikçi A:

stok = adet

gönderiyor olabilir.

Tedarikçi B:

stok = koli

gönderiyor olabilir.

İki XML'in alan adı:

stock

olsa bile anlamları aynı değildir.

Bu nedenle:

supplier + field

kombinasyonu normalizasyon kuralının önemli parçası olabilir.

45. Tedarikçi Bazlı Kuralları Ortak Veri Modelinden Ayırın

Sağlıklı mimari:

Tedarikçi A kuralları

Tedarikçi B kuralları

↓

ortak normalized product

şeklinde olabilir.

Böylece mağazanın geri kalan sistemi hangi tedarikçinin nasıl veri gönderdiğini bilmek zorunda kalmaz.

46. Normalizasyon Kurallarını Sıralı Çalıştırın

Örneğin:

ham değer

↓

encoding/karakter kontrolü

↓

trim

↓

boş değer kontrolü

↓

format dönüşümü

↓

alias mapping

↓

canonical değer

↓

validation

şeklinde işlem sırası kullanılabilir.

Sıra önemlidir.

Çünkü henüz düzgün okunamayan karakter içeren değeri marka eşleştirmesine sokmak yanlış sonuç üretebilir.

47. Aynı Normalizasyonun Tekrar Çalıştırılmasında Sonuç Değişmemeli

İyi bir normalizasyon sisteminde mümkün olduğunca:

bir kez normalize et

ve

aynı veriyi tekrar normalize et

işlemleri aynı sonucu üretmelidir.

Örneğin:

MARKA X

↓

Marka X

olduktan sonra ikinci işlem:

Marka X

değerini başka şeye dönüştürmemelidir.

Bu özellik toplu XML senkronizasyonlarında önemlidir.

48. Normalizasyon Kuralını Değiştirdiğinizde Bütün Kataloğun Etkileneceğini Unutmayın

Örneğin eskiden:

Siyah

ve:

Black

ayrı tutuluyordu.

Yeni kural bunları aynı canonical değere bağlayabilir.

Bu değişiklik:

• filtreleri,
• varyantları,
• ürün karşılaştırmalarını

etkileyebilir.

Bu nedenle kural değişikliği toplu veri değişikliğidir.

49. Normalizasyon Kurallarını Versiyonlayın

Örneğin:

Normalization V1

ile ürünler işlenmiş olabilir.

Daha sonra:

V2

oluşturulabilir.

Kayıt altında:

• hangi ürün,
• hangi kaynak değer,
• hangi kural versiyonu,
• hangi normalized değer

bulunursa sorun araştırmak kolaylaşır.

50. Değişiklik Logu Tutun

Örneğin:

SKU: ABC125

Alan: marka

Kaynak: MARKA X

Normalize: Marka X

Kural: BRAND_ALIAS_12

şeklinde log tutulabilir.

Bu özellikle binlerce ürün otomatik işlendiğinde değerlidir.

51. Belirsiz Dönüşümleri Otomatik Yapmayın

Örneğin:

Lacivert

ile:

Mavi

aynı renk değildir.

Sistem bunları yakın gördüğü için tek renge indirmemelidir.

Benzer şekilde:

ABC

ve:

ABC Pro

aynı marka/model olmayabilir.

Normalizasyon yalnızca anlamın değişmediğinden yeterince emin olunan dönüşümlerde otomatik yapılmalıdır.

52. Güven Seviyesi Kullanabilirsiniz

Örneğin:

Kesin

MARKA X → Marka X

Yüksek güven

MARKAX → Marka X

önceden doğrulanmış alias.

Belirsiz

Marka X Türkiye → Marka X

Bu son dönüşüm manuel kontrol gerektirebilir.

Böylece otomasyon ile veri güvenliği arasında denge kurulabilir.

53. Bilinmeyen Değeri Mevcut En Yakın Değere Zorla Bağlamayın

Yeni renk:

Füme

geldi.

Mevcut sistemde yalnızca:

• Siyah,
• Gri

var.

Sistem:

en yakın = Gri

deyip otomatik dönüştürmemelidir.

Daha güvenli sonuç:

UNKNOWN_MAPPING

olabilir.

Sonrasında yeni canonical değer oluşturulup oluşturulmayacağı incelenebilir.

54. Hata Kuyruğu Oluşturun

Normalizasyon sistemi her kayıt için mutlaka sonuç üretmek zorunda değildir.

Örneğin:

• bilinmeyen marka,
• geçersiz ölçü,
• yorumlanamayan fiyat,
• birimsiz teknik değer,
• çelişkili varyant

tespit edildiğinde ürün:

NORMALIZATION_REVIEW

kuyruğuna alınabilir.

55. Normalizasyon Sonrasında Veri Kalitesini Yeniden Kontrol Edin

Örneğin:

kaynak:

1.250,50 TL

normalize:

1250.50 TRY

oldu.

Sonrasında:

fiyat pozitif mi?

ürün için beklenen aralıkta mı?

kontrolü yapılabilir.

Yani:

normalizasyon → validation

sırası kullanılabilir.

XML VERİ NORMALİZASYONU İÇİN PRATİK KONTROL LİSTESİ

Ham veri

Kaynak değer değiştirilmeden saklanıyor mu?

Kaynak

Hangi tedarikçiden geldiği belli mi?

Alan sözlüğü

Her XML alanının ne anlama geldiği tanımlı mı?

Ortak şema

Bütün kaynaklar tek ürün modeline dönüştürülüyor mu?

Boşluk

Baş ve son boşluklar temizleniyor mu?

Case

Büyük-küçük harf karşılaştırmaları tutarlı mı?

Unicode

Görünmeyen veya farklı karakter biçimleri kontrol ediliyor mu?

Özel karakter

Gerçek veri yanlışlıkla siliniyor mu?

Marka

Kaynak marka canonical kayıtla eşleşiyor mu?

Kategori

Kaynak kategori mağaza kategorisine bağlanıyor mu?

Renk

Alias değerleri kontrollü mü?

Ölçü

Sayı ve birim ayrılmış mı?

Birim

cm, mm gibi değerler kontrollü dönüştürülüyor mu?

Fiyat

Yerel sayı biçimi doğru okunuyor mu?

Para birimi

Fiyattan ayrı tutuluyor mu?

KDV

Oran formatı ortaklaştırılıyor mu?

Stok

Sayısal değer olarak güvenli işleniyor mu?

Boolean

1/0, true/false gibi değerler doğru eşleşiyor mu?

Tarih

Ortak tarih formatı var mı?

SKU

Kimlik alanları yanlışlıkla değiştiriliyor mu?

Barkod

Baştaki sıfırlar korunuyor mu?

Model

Noktalama ve sıfırlar korunuyor mu?

Paket

Adet ve satış birimi ayrılmış mı?

Varyant

Canonical varyant sözlüğü var mı?

Alias

Kaynak → canonical eşleştirmeler kaydediliyor mu?

Belirsiz değer

Zorla eşleştirilmek yerine kontrole gidiyor mu?

Log

Dönüşümün hangi kuralla yapıldığı görülebiliyor mu?

Versiyon

Normalizasyon kuralları sürümleniyor mu?

XML ÜRÜN VERİSİ NORMALİZASYONU NASIL KURULUR?

Pratik olarak şu sırayla ilerlenebilir:

1. Kaynak XML'i değiştirmeden saklayın.

2. XML içerisindeki bütün ürün alanlarını çıkarın.

3. Her alanın anlamını doğrulayın.

4. Mağazanın ortak ürün veri şemasını oluşturun.

5. Kaynak alan → ortak alan mapping'lerini tanımlayın.

6. Alanları veri tiplerine göre sınıflandırın.

7. Metin alanlarında güvenli boşluk normalizasyonu uygulayın.

8. Karakter/encoding sorunlarını normalizasyondan önce çözün.

9. Placeholder ve eksik değer politikalarını belirleyin.

10. Marka ve kategori için canonical mapping sözlükleri oluşturun.

11. Renk ve varyant alias'larını tanımlayın.

12. Sayı, fiyat ve ondalık formatlarını standardize edin.

13. Birim dönüşüm kurallarını oluşturun.

14. SKU, barkod ve model gibi kimlik alanlarını korumalı sınıfa alın.

15. Belirsiz dönüşümlere güven seviyeleri atayın.

16. Otomatik dönüştürülemeyen değerleri inceleme kuyruğuna gönderin.

17. Normalizasyon sonrası validation çalıştırın.

18. Önce 50–100 ürün üzerinde eski/yeni değer karşılaştırması yapın.

19. Kural ve değişiklik loglarını kaydedin.

20. Sonuçlar doğruysa sistemi yeni XML ürünlerinde otomatik çalıştırın.

SIK SORULAN SORULAR

XML veri normalizasyonu ne demektir?

Farklı biçimlerde gelen ancak aynı anlamı taşıyan ürün verilerinin ortak bir iç veri standardına dönüştürülmesidir. Örneğin doğrulanmış MARKA X, Marka X ve marka x değerlerinin tek canonical marka kaydıyla eşleştirilmesi bir normalizasyon örneğidir.

Normalizasyon ürün bilgisini değiştirir mi?

Amaç gerçek ürün bilgisini değiştirmek değildir. Sunum ve veri formatı ortaklaştırılır. Örneğin 30CM değeri 30 cm biçiminde standardize edilebilir; ancak ürünün gerçek ölçüsü 30 cm iken 40 cm'ye dönüştürülemez.

XML'deki bütün alanlar aynı şekilde normalize edilebilir mi?

Hayır. Ürün adı ve marka gibi metin alanlarına uygulanabilecek kurallar SKU, barkod, model, URL veya fiyat alanlarına doğrudan uygulanmamalıdır. Özellikle ürün kimliği alanlarında karakter silmek veya baştaki sıfırları kaldırmak eşleşmeyi bozabilir.

Normalizasyon duplicate ürünleri bulmaya yardımcı olur mu?

Evet. Büyük-küçük harf ve gereksiz boşluk farklılıklarının karşılaştırma öncesinde standardize edilmesi duplicate adaylarının bulunmasını kolaylaştırabilir. Ancak normalize edilmiş iki değerin aynı çıkması ürünlerin kesin duplicate olduğu anlamına gelmez. Canlı duplicate ürün rehberinde de normalizasyon yalnızca eşleştirme sinyallerinden biri olarak kullanılıyor.

Birden fazla XML tedarikçisi varsa normalizasyon daha önemli midir?

Genellikle evet. Çünkü her tedarikçi farklı alan isimleri, kategori yolları, marka yazımları, sayı formatları veya varyant değerleri kullanabilir. Ortak normalizasyon katmanı sayesinde mağazanın geri kalan sistemi bütün kaynakları aynı ürün veri modeli üzerinden işleyebilir.

AMAÇ BÜTÜN VERİYİ AYNI GÖSTERMEK DEĞİL, AYNI ANLAMI TEK STANDARTTA TEMSİL ETMEKTİR

XML veri normalizasyonu için en tehlikeli yaklaşım:

“Bütün metinleri küçült, işaretleri sil, boşlukları kaldır ve aynı görünenleri birleştir.”

yaklaşımıdır.

Bu yöntem özellikle:

• SKU,
• barkod,
• model,
• ölçü,
• varyant

gibi alanlarda gerçek ürün bilgisini bozabilir.

Daha kontrollü sistem:

ham veriyi koru → alanın anlamını belirle → alan tipini tanı → güvenli dönüşümü uygula → canonical değere eşleştir → kimlik alanlarını koru → belirsiz kayıtları ayır → normalizasyon sonrası doğrulama yap → sonucu logla

şeklinde kurulmalıdır.

Böylece farklı tedarikçiler:

MARKA X

Marka X

marka x

gönderse de mağaza tek marka kaydı kullanabilir.

Bir tedarikçi:

1.250,50

diğeri:

1250.50

gönderse de fiyat motoru ortak sayısal formatla çalışabilir.

Bir XML:

Ev/Mutfak/Cezve

diğeri:

Ev > Mutfak > Cezve

gönderse de mağaza bunları kendi kategori sistemine bağlayabilir.

Ancak bu süreç boyunca ürünün gerçek kimliği ve gerçek özellikleri değiştirilmez.