Bir tedarikçi size:

10.000 ürünlük XML feed

veriyor olabilir.

Başka tedarikçi ise:

4.000 ürün

veriyor.

İlk bakışta 10.000 ürünlük feed daha güçlü görünebilir.

Ancak ilk feed'de:

• 1.500 ürünün görseli çalışmıyor,
• 800 ürünün fiyatı eksik,
• 2.000 ürünün barkodu belirsiz,
• kategorilerin büyük bölümü Diğer altında,
• stok güncellemesi iki gündür çalışmıyor

olabilir.

İkinci feed ise:

• ürün kimlikleri stabil,
• fiyat ve stok bilgileri güncel,
• görseller çalışıyor,
• kategori eşleştirmeleri düzgün,
• hata oranı düşük

olabilir.

Bu durumda:

ürün sayısı daha yüksek olan feed

otomatik olarak:

daha kaliteli feed

değildir.

Asıl soru:

XML feed satış operasyonunda ne kadar güvenilir ve kullanılabilir?

olmalıdır.

Ulu İthalat'ın XML Bayilik sayfası da ürün adı, fiyat, stok, görseller ve diğer ürün bilgilerinin XML yoluyla satış kanallarına aktarılabildiğini; ürün, stok ve fiyat verilerinin düzenli yönetilmesinin e-ticaret operasyonu açısından önemli olduğunu belirtiyor.

Bu nedenle xml feed kalite kontrolü tek bir alanın kontrolü değil, bütün veri akışının ölçülmesi olarak ele alınmalıdır.

XML Feed Kalite Puanı Nedir?

XML feed kalite puanı; feed'in belirlenmiş veri kalite kriterlerine ne ölçüde uyduğunu sayısal olarak özetleyen işletme içi bir metriktir.

Örneğin:

Feed A → 94/100

Feed B → 78/100

Feed C → 51/100

şeklinde karşılaştırma yapılabilir.

Ancak tek puanın anlamlı olabilmesi için:

hangi boyutların ölçüldüğü

her boyutun ağırlığı

hangi hataların puanı düşürdüğü

hangi kritik hataların yayını tamamen durdurduğu

açık biçimde tanımlanmalıdır.

W3C DQV yaklaşımı da kaliteyi tek soyut sıfat yerine quality dimensions + metrics + measurements üzerinden ele alır ve alanlara göre farklı kalite metriklerinin kullanılabileceğini belirtir.

1. Önce “Kaliteli Feed” Tanımını Yapın

Kalite:

XML parse oluyor

demek değildir.

E-ticaret açısından daha uygun tanım:

amaçlanan satış sürecinde güvenilir biçimde kullanılabilecek veri

olabilir.

Yani feed:

• teknik olarak okunabilir,
• ticari olarak yeterli,
• güncel,
• tutarlı,
• mümkün olduğunca doğru

olmalıdır.

2. Feed Kalitesini Kullanım Amacına Göre Değerlendirin

Aynı feed:

kendi web siteniz için yeterli

olabilir.

Ama:

Google Merchant için yetersiz

olabilir.

Başka platform için:

kategori veya identifier eksikleri

bulunabilir.

Dolayısıyla kalite her zaman:

fit for purpose

mantığıyla düşünülmelidir.

3. Tek Evrensel XML Feed Kalite Formülü Aramayın

W3C Data Quality Vocabulary tek bir zorunlu dimension/metric seti belirlemez; uygulayıcıların kendi kullanım amaçlarına uygun kalite metrikleri oluşturabileceğini açıkça belirtir.

Dolayısıyla:

“70 puanın altındaki bütün XML'ler kötüdür.”

gibi evrensel bir standart yoktur.

Puan sistemi sizin iş modelinize göre tasarlanmalıdır.

4. Kalite Boyutlarını Önce Ayrı Ayrı Ölçün

Örneğin XML feed için:

Yapısal geçerlilik

Tamlık

Geçerlilik

Doğruluk

Tutarlılık

Benzersizlik

Güncellik

Erişilebilirlik

Operasyonel güvenilirlik

gibi boyutlar oluşturulabilir.

Son toplam puan bunlardan türetilebilir.

5. Puanlamadan Önce Ölçülebilir Metrikler Belirleyin

Örneğin:

“Görseller iyi.”

ölçülebilir değildir.

Bunun yerine:

çalışan ana görsel URL'si bulunan ürün oranı

ölçülebilir.

Benzer şekilde:

“Barkodlar kötü.”

yerine:

beklenen ürünler içinde geçerli/doğrulanabilir GTIN bulunan oran

kullanılabilir.

6. Her Kalite Boyutunun En Az Bir Metriği Olmalıdır

Örneğin:

Tamlık

Zorunlu alan doluluk oranı.

Güncellik

Beklenen güncelleme penceresinde başarılı sync oranı.

Benzersizlik

Kimlik çakışması bulunmayan ürün oranı.

Görsel erişilebilirliği

Başarılı ana görsel URL oranı.

Bu yapı kalite puanının açıklanabilir olmasını sağlar.

7. Feed-Level ve Product-Level Kaliteyi Ayırın

Bir feed:

genel olarak %95 kaliteli

görünebilir.

Ancak belirli 500 ürün:

çok kötü durumda olabilir.

Bu nedenle iki puan tutulabilir:

Feed Quality Score

bütün kaynağın kalitesi.

Product Quality Score

tek ürünün/veri kaydının kalitesi.

8. Tedarikçi Bazlı Puan da Tutabilirsiniz

Örneğin:

Supplier A → 94

Supplier B → 72

Supplier C → 88

Bu puanlar:

tedarikçi seçmek için tek kriter

olmamalıdır.

Ancak veri operasyonu yükünü karşılaştırmak için güçlü bir sinyal olabilir.

9. Tek Bir Ortalama Bazı Kritik Problemleri Gizleyebilir

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

9.900'ü mükemmel,

100'ünün fiyatı:

0 TL

olsun.

Ortalama kalite puanı yine yüksek çıkabilir.

Ama o 100 ürün canlı satış için ciddi risktir.

Bu nedenle:

score

ve:

release gate

ayrı tutulmalıdır.

10. Kalite Puanı ile Yayına Alma Kararını Birbirine Karıştırmayın

Örneğin:

Feed Score → 92/100

ama:

CRITICAL_PRICE_ERROR = TRUE

ise feed:

yayına alınmamalı

olabilir.

Yani sistem:

quality_score = 92

release_status = BLOCKED

şeklinde sonuç üretebilir.

Bu 123'ün en önemli tasarım prensiplerinden biridir.

11. “Critical Blocker” Listesi Oluşturun

Örneğin işletme açısından:

• XML parse edilemiyor,
• bütün fiyat alanı boş,
• toplu stok sıfırlaması var,
• SKU eşleşmeleri bozuk,
• binlerce fiyat 0'a dönüyor

gibi durumlar:

puan hesaplanmadan bağımsız olarak

canlı güncellemeyi durdurabilir.

12. Kritik Hata Çok Az Üründe Olsa Bile Önemli Olabilir

Örneğin:

1 ürünün:

100.000 TL yerine 1.000 TL

gelmesi bütün feed'in ortalama skorunu çok az etkiler.

Ama ticari risk yüksektir.

Bu nedenle quality score'un yanında:

critical_issue_count

tutulmalıdır.

13. İlk Boyut Olarak Yapısal Geçerliliği Ölçebilirsiniz

Örneğin:

• XML iyi biçimlendirilmiş mi?
• root node doğru mu?
• ürün node'ları parse ediliyor mu?
• gerekli encoding okunuyor mu?

Feed hiç parse edilemiyorsa ürün kalitesi ölçümünün büyük bölümü zaten yapılamaz.

14. XML Parse Başarı Oranı Oluşturabilirsiniz

Örneğin:

10.000 beklenen kayıt.

9.980 parse edildi.

20 kayıt parser hatasına düştü.

Bir parse success ratio üretilebilir.

Ancak feed tamamen parse edilemiyorsa ayrı blocker uygulanabilir.

15. Şema Uyumunu Ayrı Ölçebilirsiniz

XSD veya tanımlanmış internal schema varsa:

şemaya uygun kayıt oranı

hesaplanabilir.

Ancak şemaya uyum:

ürün verisi doğru

demek değildir.

Sadece yapısal geçerlilik ölçüsüdür.

16. İkinci Temel Boyut Tamlık Olabilir

Tamlık:

beklenen verinin ne kadarının mevcut olduğu

ile ilgilidir.

Örneğin ürün için beklenen:

• ID,
• ürün adı,
• fiyat,
• stok,
• ana görsel

alanlarının ne kadarının mevcut olduğu ölçülebilir.

W3C DQV içerisinde referans verilen kalite modellerinde completeness, beklenen veri değerlerinin mevcut olma derecesi olarak ele alınır.

17. Basit Tamlık Formülü Kullanabilirsiniz

Örnek:

Tamlık = mevcut zorunlu alan sayısı / beklenen zorunlu alan sayısı × 100

Bu ürün veya bütün feed üzerinde hesaplanabilir.

Ancak her alanın zorunluluğu aynı değildir.

18. Koşullu Zorunlu Alanları Hesaba Katın

Örneğin:

GTIN her üründe zorunlu olmayabilir.

Renk yalnızca belirli ürünlerde gerekli olabilir.

Beden yalnızca varyantlı ürünlerde anlamlı olabilir.

Bu nedenle completeness denominator:

ürünün gerçekten ihtiyaç duyduğu alanlardan

oluşturulmalıdır.

19. Boş Değer ile Geçerli Sıfırı Ayırın

Örneğin:

stock = 0

eksik değildir.

Gerçek stok değeridir.

stock = ""

ise eksik olabilir.

Aksi halde completeness skorları yanlış oluşur.

20. Placeholder Değerleri Dolu Saymayın

Örneğin:

brand = N/A

image = no-image.jpg

barcode = -

alanları teknik olarak doludur.

Ama kalite açısından gerçek veri olmayabilir.

Tamlık hesabında placeholder politikası açık olmalıdır.

21. Tamlık Skoru Tek Başına Yeterli Değildir

Feed:

%100 dolu

olabilir.

Ama fiyatların yarısı yanlış.

Dolayısıyla:

complete

ile:

accurate

aynı şey değildir.

22. Üçüncü Boyut Geçerlilik Olabilir

Geçerlilik:

veri belirlenen format ve iş kurallarına uyuyor mu?

sorusunu cevaplar.

Örneğin:

fiyat sayısal mı?

stok kabul edilen formatta mı?

URL geçerli mi?

GTIN yapısal kurallara uyuyor mu?

23. Fiyat Geçerlilik Oranı Hesaplanabilir

Örneğin:

10.000 ürünün:

9.700'ünde kabul edilen fiyat formatı.

300'ünde:

• boş,
• metin,
• negatif,
• parse edilemeyen

değer var.

Price validity rate = %97

gibi.

24. Stok Geçerlilik Oranı da Ayrı Ölçülebilir

Örneğin:

stok değerlerinin:

• geçerli sayı,
• doğrulanmış availability,
• kabul edilen placeholder

olup olmadığı kontrol edilir.

ABC

gibi değerler invalid sayılabilir.

25. URL Geçerliliği ile URL Erişilebilirliğini Ayırın

Örneğin:

https://...jpg

syntax olarak geçerli.

Ama:

404

dönüyor.

Birincisi:

validity

ikincisi:

availability/accessibility

problemi olabilir.

122 numaralı görsel URL içeriği bu ayrımı derinleştirir.

26. Dördüncü Boyut Doğruluk Olabilir

Doğruluk en zor kalite boyutlarından biridir.

Örneğin XML:

fiyat = 599 TL

diyor.

Format tamamen geçerli.

Ama gerçek fiyat:

699 TL

ise veri yanlış.

Bunu yalnız XML'e bakarak her zaman anlayamazsınız.

27. Doğruluk İçin Güvenilir Referans Gerekebilir

Örneğin:

• tedarikçi ERP,
• resmi ürün sayfası,
• manuel ürün doğrulaması,
• güvenilir master catalog

ile karşılaştırma yapılabilir.

Dolayısıyla:

format valid

değeri:

accurate

anlamına gelmez.

28. Doğruluk Skorunu Örneklem Üzerinden Hesaplayabilirsiniz

Bütün 20.000 ürünü manuel doğrulamak mümkün olmayabilir.

Örneğin:

kategori ve fiyat bandına göre örneklem seçilir.

Kontrol edilen ürünlerin doğruluk oranı:

accuracy estimate

olarak raporlanabilir.

Bu durumda skorun:

sample-based

olduğu belirtilmelidir.

29. Otomatik Doğruluk ile Manuel Doğruluğu Ayırın

Örneğin:

automated_accuracy_signal

alanlar arasında mantık kontrolü.

verified_accuracy

harici güvenilir kaynağa karşı doğrulanmış sonuç.

İkisini tek metrik olarak karıştırmamak daha açıklayıcıdır.

30. Beşinci Boyut Tutarlılık Olabilir

Tutarlılık:

birbirini ilgilendiren alanların çelişmemesi

olarak düşünülebilir.

Örneğin:

active = false

ama:

availability = in_stock

olabilir.

Bu durum sistemin iş kurallarına göre çelişki oluşturabilir.

31. Fiyat Alanlarının Birbiriyle Tutarlılığını Kontrol Edin

Örneğin:

sale_price > list_price

normal politikaya aykırı olabilir.

Ya da:

currency = USD

ama fiyat formatı başka para birimine ait olabilir.

Bu tür cross-field kontroller consistency skoruna girebilir.

32. Varyantların Tutarlılığını Ölçün

Örneğin parent:

Siyah Tişört

varyant:

Beyaz XL

olabilir.

Bu mutlaka hata değildir.

Ancak parent/variant ilişkilerinde:

• kategori,
• marka,
• ürün tipi

gibi alanların beklenen tutarlılığı kontrol edilebilir.

33. Kategori ve Özellik Çelişkilerini Tutarlılık Skoruna Dahil Edebilirsiniz

Örneğin:

ürün kategorisi:

Elektrikli El Aletleri

ama özellikleri:

beden / kumaş / renk

yoğunlukluysa şüpheli olabilir.

119 numaralı kategori hata teşhisi bu alanı detaylandırır.

34. Altıncı Boyut Benzersizlik Olabilir

Ürün kimliklerinin gereksiz tekrar oluşturmaması önemlidir.

Örneğin:

aynı supplier SKU

iki farklı üründe kullanılmış olabilir.

Aynı GTIN:

farklı ürünlerde çakışabilir.

35. Unique Product Identity Rate Hesaplayabilirsiniz

Örneğin:

toplam 10.000 ürün.

9.900 ürünün kaynak kimliği benzersiz.

100 kayıt çakışıyor.

Benzersizlik metriği buna göre üretilebilir.

Ancak gerçek varyant/paket ilişkileri yanlış duplicate sayılmamalıdır.

36. Duplicate Candidate ile Confirmed Duplicate Ayrımı Yapın

Başlık benzerliği:

candidate.

Aynı doğrulanmış kimlik ve ürün:

confirmed duplicate

olabilir.

Quality score yalnızca kesin sorunları daha yüksek cezalandırabilir.

37. Yedinci Boyut Güncellik Olabilir

XML feed'in dün doğru olması bugün yeterli olmayabilir.

Özellikle:

• fiyat,
• stok,
• aktiflik

zaman duyarlı verilerdir.

W3C DQV de timeliness/currentness boyutlarını veri kalitesinin ayrı unsurları olarak ele alır.

38. Son Başarılı Güncelleme Zamanını Puanlamaya Katın

Örneğin feed normalde:

saatlik

güncelleniyor.

Son başarılı sync:

18 saat önce.

Veriler format açısından mükemmel olabilir.

Ama operasyon açısından bayatlamıştır.

39. last_attempt Yerine last_successful_sync Kullanın

Job her saat tetiklenmiş olabilir.

Ama son 10 çalışma hata vermiştir.

Bu nedenle:

son deneme

değil,

son başarılı veri

kalite için daha anlamlıdır.

40. Güncellik Puanını Tüm Alanlar İçin Aynı Hesaplamayın

Fiyat ve stok:

zaman açısından kritik olabilir.

Ürün açıklaması:

daha yavaş değişebilir.

Dolayısıyla:

field-specific freshness

yaklaşımı kullanılabilir.

41. Sekizinci Boyut Erişilebilirlik Olabilir

Feed verisi doğru olabilir.

Ama:

• XML URL açılmıyor,
• görseller 403,
• endpoint timeout,
• CDN çökmüş

olabilir.

Bu durumda veri operasyonel olarak kullanılamaz.

42. Feed Endpoint Availability Ölçülebilir

Örneğin belirli dönemde:

100 scheduled download.

98 başarılı.

2 başarısız.

Kaynak erişilebilirliği ayrı bir metrik olabilir.

43. Görsel Erişilebilirlik Oranı Ölçülebilir

Örneğin:

10.000 ana görsel.

9.400 başarılı.

600:

404 / 403 / timeout.

main image accessibility = %94

gibi.

122 numaralı görsel URL rehberi bu metrikteki hataların nedenlerini sahiplenir.

44. Dokuzuncu Boyut Operasyonel Güvenilirlik Olabilir

Feed doğru olsa bile entegrasyon sürekli:

• yarım job,
• timeout,
• overlap,
• partial success

yaşıyorsa operasyon kalitesi düşüktür.

Bu nedenle yalnız kaynak veriyi değil veri akışını da ölçebilirsiniz.

45. Sync Success Rate Kullanılabilir

Örneğin:

Son 100 scheduled job:

96 SUCCESS

2 PARTIAL

2 FAILED.

Bunun üzerinden operasyonel reliability metriği oluşturulabilir.

46. Partial Success'i Full Success Saymayın

10.000 ürünün:

8.000'i işlendi,

2.000'i hata verdi.

Job:

SUCCESS

olarak işaretlenirse kalite metriği yanıltıcı olur.

SUCCESS

PARTIAL_SUCCESS

FAILED

ayrımı kullanılmalıdır.

47. XML Feed Score İçin Örnek 100 Puanlık Model Oluşturabilirsiniz

Örneğin tamamen örnek bir yapı:

Yapısal geçerlilik → 10 puan

Tamlık → 20 puan

Alan geçerliliği → 15 puan

Doğruluk → 15 puan

Tutarlılık → 10 puan

Benzersizlik → 10 puan

Güncellik → 10 puan

Erişilebilirlik → 5 puan

Operasyonel güvenilirlik → 5 puan

Toplam:

100 puan

Bu ağırlıkların hiçbirinin sektör standardı olmadığını özellikle belirtmek gerekir.

48. Ağırlıkları İş Riskine Göre Değiştirin

Dropshipping operasyonunda:

stok ve fiyat

daha yüksek ağırlık taşıyabilir.

Ürün katalog sitesi için:

ürün açıklaması, kategori ve görseller

daha yüksek ağırlık alabilir.

Google feed özelinde:

kanal gereksinimleri farklılaşabilir.

49. Ağırlıkların Toplamı %100 Olmalıdır

Örneğin:

Score = Σ(Dimension Score × Dimension Weight)

mantığı kullanılabilir.

Her dimension skoru:

0–100.

Weight toplamı:

1 veya %100.

Bu, anlaşılır ve tekrar hesaplanabilir bir model oluşturur.

50. Örnek Hesap Nasıl Görünebilir?

Tamamen örnek:

Yapısal geçerlilik: 100

Tamlık: 92

Geçerlilik: 95

Doğruluk: 85

Tutarlılık: 90

Benzersizlik: 98

Güncellik: 70

Erişilebilirlik: 96

Operasyonel güvenilirlik: 90

Yukarıdaki örnek ağırlıklarla birleştiğinde toplam kalite skoru yaklaşık:

90,5 / 100

çıkabilir.

Ancak bu:

feed canlıya alınabilir

anlamına gelmez.

Critical blocker kontrolü ayrıca yapılmalıdır.

51. 90 Puan Feed'in “Mükemmel” Olduğunu Söylemez

Skor yalnızca sizin belirlediğiniz kuralların sonucudur.

Örneğin accuracy ölçümünüz zayıfsa:

90 puan

gerçek dünyada beklediğiniz kadar güvenilir olmayabilir.

Bu nedenle skorun yanında measurement coverage tutulmalıdır.

52. Measurement Coverage Ekleyebilirsiniz

Örneğin:

Quality score: 90,5

Measured coverage: %98

daha açıklayıcıdır.

Eğer accuracy yalnızca ürünlerin %2'sinde kontrol edildiyse:

skorun güven seviyesi daha düşüktür.

53. Confidence Score Ayrı Kullanılabilir

Örneğin:

Feed quality: 91

Confidence: Medium

çünkü accuracy yalnız küçük örneklem üzerinden ölçüldü.

Başka feed:

Feed quality: 89

Confidence: High

olabilir.

İkinci skor karar vermek için bazen daha güvenilir olabilir.

54. Kalite Skoruyla Birlikte Hata Sayısını da Gösterin

Dashboard:

Score: 91

Critical: 0

Errors: 34

Warnings: 412

şeklinde olabilir.

Tek sayı yerine sorun yoğunluğu da görünür.

55. Error ve Warning Aynı Ağırlıkta Olmamalıdır

Örneğin:

İkinci ek görsel eksikliği:

warning.

Fiyatın parse edilememesi:

critical/error.

İkisine aynı ceza uygulanması kalite skorunu anlamsızlaştırabilir.

56. Severity Modeli Kurabilirsiniz

Örneğin:

CRITICAL

Satış güvenli değil.

ERROR

Ürün veya önemli fonksiyon etkileniyor.

WARNING

Kalite düşük ama ürün kullanılabilir.

INFO

İyileştirme fırsatı.

Bu sınıflandırma skorun arkasındaki iş riskini yansıtır.

57. Puan Kesintisi Modeli de Kullanılabilir

Alternatif yaklaşım:

100 puandan başla.

Critical → büyük ceza.

Error → orta ceza.

Warning → küçük ceza.

Ancak çok sayıda küçük warning bütün feed'i haksız yere 0'a indirebilir.

Bu nedenle ağırlıklı dimension modeli genellikle daha açıklanabilir olabilir.

58. Çifte Cezalandırmadan Kaçının

Örneğin:

Görsel URL 404.

Bu olay:

accessibility

boyutunda ceza aldı.

Aynı hatayı:

• completeness,
• validity,
• data quality

üçünde birden tam ceza olarak kullanırsanız tek sorun skoru aşırı düşürebilir.

Her metric'in hangi dimension'a ait olduğu açık olmalıdır.

59. Bir Hata Birden Fazla Boyutu Etkileyebilir Ama Ana Boyut Seçin

W3C DQV bir metriğin birden fazla dimension ile ilişkili olabileceğini kabul eder ancak mümkün olduğunda metriğin anlamının net tutulmasını önerir.

Örneğin:

bozuk görsel URL:

esas olarak accessibility

boyutunda değerlendirilebilir.

60. Ürün Seviyesinde Puan Oluşturabilirsiniz

Örneğin:

Product A

98/100.

Product B

72/100.

Product C

40/100.

Buna göre:

AUTO_PUBLISH

REVIEW

BLOCK

gibi iş akışları üretilebilir.

61. Ancak Ürün Puanını Feed Puanına Basit Ortalama ile Taşımayın

9.999 ürün 100 puan.

1 ürün 0 puan.

Ortalama:

çok yüksek.

Ama o tek ürün:

fiyatı yanlış 100.000 TL ürün

olabilir.

Dolayısıyla feed seviyesinde:

• average,
• median,
• critical count,
• failure ratio

birlikte kullanılabilir.

62. P50, P90 veya Düşük Skor Dağılımı Kullanabilirsiniz

Örneğin:

ortalama → 92.

Ama:

ürünlerin %10'u 60'ın altında.

Bu durum average'den görünmeyebilir.

Kalite dağılımını görmek faydalıdır.

63. “Kaç Ürün Yayına Hazır?” Metriği Çok Değerlidir

Örneğin:

Total products: 10.000

Store ready: 9.200

Review: 600

Blocked: 200

Bu sonuç çoğu zaman yalnız:

Score = 89

ifadesinden daha operasyoneldir.

64. Kanal Hazırlık Skorlarını Ayırabilirsiniz

Örneğin:

Core Feed Quality: 93

Website Readiness: 97

Google Readiness: 82

Marketplace A Readiness: 88

Çünkü her hedefin veri gereksinimi farklıdır.

Google Merchant'ın güncel ürün veri spesifikasyonu da ID, başlık, fiyat, availability ve görsel gibi alanlarda belirli şartlar uygular; eksik veya yanlış kategori, GTIN, varyant ve görsel gibi sorunların ürünlerin gösterilmesini etkileyebileceğini belirtir.

65. Google Merchant Skorunu XML Feed Score ile Aynı Saymayın

Merchant Center:

ürün veri dosyasındaki:

• dosya,
• attribute,
• product-level

sorunları ayrı raporlayabilir.

Google'ın “Latest update” işleme raporu dosya ve attribute problemlerini; “Needs attention” bölümü ise daha geniş ürün sorunlarını gösterir.

Bu bir Ulu XML Quality Score ile aynı sistem değildir.

66. Merchant Hata Raporlarını Dış Kalite Sinyali Olarak Kullanabilirsiniz

Örneğin XML:

internal testte geçiyor.

Ama Google:

500 ürün için:

missing required value

uyarısı veriyor.

Bu durum:

channel readiness

skorunda kullanılabilir.

Google Merchant, veri kaynağı raporlarında dosya ve attribute problemlerinin etkilenen ürünlerle birlikte raporlanabildiğini belirtiyor.

67. Feed Kalite Puanını Tedarikçi Karşılaştırmasında Kullanabilirsiniz

Örneğin:

Supplier A:

kalite 95.

Supplier B:

kalite 78.

Ancak B:

çok daha iyi fiyat veya ürün çeşitliliği sağlayabilir.

Dolayısıyla kalite skoru:

tedarikçi seçme kararının tek cevabı

değil,

operasyonel veri maliyetinin bir göstergesi

olmalıdır.

68. Düşük Puanın Kaynağını Dimension Breakdown ile Gösterin

Örneğin:

Overall: 68

ama:

Completeness → 95

Validity → 94

Accuracy → 90

Timeliness → 20

Bu durumda problem:

ürün verisi değil, güncelleme sürecidir.

Tek toplam puan bunu tek başına anlatamaz.

69. Radar veya Dashboard Mantığı Kullanabilirsiniz

Örneğin panel:

Tamlık: 95

Geçerlilik: 92

Doğruluk: 88

Tutarlılık: 91

Güncellik: 60

gösterebilir.

Böylece hangi alanın geliştirilmesi gerektiği görülür.

70. Feed Kalite Skoru Bir Teşhis Aracı Değil, Özet Göstergedir

Örneğin:

Quality = 65

problemin nedenini söylemez.

Neden:

• görsel 404,
• kategori mapping,
• GTIN eksik,
• stok sync gecikmesi

olabilir.

Detay için ilgili teknik diagnostic raporlarına gidilmelidir.

Bu nedenle 123:

skorlama

konusunu sahiplenmeli,

önceki teknik içerikleri tekrar etmemelidir.

71. Kalite Skorunu Zaman Serisi Olarak Tutun

Örneğin:

1 Ağustos → 82

8 Ağustos → 87

15 Ağustos → 91

23 Ağustos → 94

Bu tedarikçi/feed iyileşmesini gösterebilir.

Tek bir günlük puandan daha değerlidir.

72. Ani Puan Düşüşlerini Alarm Olarak Kullanabilirsiniz

Dün:

Bugün:

Bu:

• schema değişikliği,
• görsel host problemi,
• stok alanı kaybı,
• kategori mapping hatası

gibi toplu problem göstergesi olabilir.

73. Dimension-Level Drift İzleyin

Overall:

90 → 88

küçük değişim.

Ama:

Image Accessibility: 99 → 40

olmuş olabilir.

Bu nedenle alert yalnız total score'a değil dimension'lara da bağlanmalıdır.

74. Yeni Feed Sürümünü Eski Feed ile Karşılaştırın

Örneğin:

V1 score: 91

V2 score: 94

Ancak V2'de:

critical issue = 1

varsa otomatik geçiş yapılmayabilir.

Kalite puanı regression testinin bir parçası olabilir.

75. Yeni Entegrasyon İçin Minimum Kalite Kapısı Oluşturabilirsiniz

Örneğin işletme kendi politikasında:

critical = 0

zorunlu alan completeness ≥ belirlenen eşik

parse success = gerekli seviye

gibi şartlar koyabilir.

Kesin rakamlar işletme tarafından belirlenmelidir.

76. Sabit 80/100 Yayın Eşiğini Evrensel Kural Yapmayın

Bir feed:

79 puan

ama hiçbir critical hata yok.

Başka:

95 puan

ama fiyat alanında kritik hata var.

İkinci feed daha riskli olabilir.

Bu nedenle:

score + gates

birlikte kullanılmalıdır.

77. Kategori Bazında Kalite Skoru Oluşturabilirsiniz

Örneğin:

Ev & Mutfak → 95

Hırdavat → 88

Elektronik → 67

Elektronikte:

GTIN ve model problemleri

daha yoğun olabilir.

Bu, hangi ürün grubunun iyileştirilmesi gerektiğini gösterir.

78. Field-Level Quality Score da Tutulabilir

Örneğin:

Price quality: 99

Stock quality: 97

Image quality: 84

Barcode quality: 72

Category quality: 90

Böylece supplier ile hangi alanın düzeltilmesi gerektiği daha açık konuşulabilir.

79. Sorun Sayısını Ürün Sayısına Normalize Edin

Supplier A:

1.000 hata.

100.000 ürün.

Supplier B:

500 hata.

1.000 ürün.

Salt hata sayısına göre A daha kötü görünür.

Oran kullanıldığında B'nin veri kalitesinin çok daha düşük olabileceği anlaşılır.

80. XML Feed Quality Score'un Amacı Karar Vermeyi Kolaylaştırmaktır

Puanın amacı:

güzel bir dashboard sayısı üretmek

değildir.

Amaç şunları cevaplamaktır:

Bu feed canlıya güvenle alınabilir mi?

Hangi tedarikçinin verisi daha fazla operasyon yükü çıkarıyor?

Kalite geçen aya göre iyileşti mi?

Hangi veri alanında sorun yoğunlaşıyor?

Hangi ürünler review gerektiriyor?

Bir entegrasyon değişikliği kaliteyi düşürdü mü?

Bunları cevaplamıyorsa skor sisteminin yeniden tasarlanması gerekir.

XML FEED KALİTESİ PUANLAMA KONTROL LİSTESİ

Amaç

Feed hangi kullanım amacı için puanlanıyor?

Kalite boyutları

Completeness, validity, accuracy gibi boyutlar tanımlandı mı?

Metrikler

Her dimension'ın ölçüm yöntemi belli mi?

Zorunlu alanlar

Ürün tipine göre doğru required set kullanılıyor mu?

Koşullu alanlar

GTIN, marka, varyant gibi alanlar koşula göre değerlendiriliyor mu?

Placeholder

N/A, -, no-image gibi değerler kaliteyi şişiriyor mu?

Yapısal kalite

XML parse ve schema kontrolleri mevcut mu?

Tamlık

Eksik alan oranları hesaplanıyor mu?

Geçerlilik

Fiyat, stok, URL ve identifier formatları test ediliyor mu?

Doğruluk

Harici doğrulama veya örneklem var mı?

Tutarlılık

Alanlar birbirleriyle çelişiyor mu?

Benzersizlik

SKU/GTIN/product ID çakışmaları kontrol ediliyor mu?

Güncellik

Son başarılı güncelleme zamanı ölçülüyor mu?

Erişilebilirlik

Feed ve görsel endpoint'leri çalışıyor mu?

Operasyonel güvenilirlik

Sync success/partial/failure oranı biliniyor mu?

Severity

Critical, error ve warning ayrımı yapılıyor mu?

Blocker

Yüksek puana rağmen canlıyı durduracak kurallar var mı?

Ağırlık

Dimension weight'leri iş riskine göre mi?

Çifte ceza

Aynı hata birkaç dimension'da tekrar tekrar puan düşürüyor mu?

Ürün skoru

Tek SKU bazında kalite görülebiliyor mu?

Feed skoru

Tedarikçi/feed seviyesinde agregasyon var mı?

Distribution

Düşük kaliteli ürün oranı görülüyor mu?

Channel readiness

Web sitesi ve pazaryeri skorları ayrı mı?

Confidence

Ölçüm kapsamı ve güven seviyesi biliniyor mu?

Trend

Score zaman içinde izleniyor mu?

Regression

Yeni feed sürümü eskiyle karşılaştırılıyor mu?

Audit

Kural ve ağırlık değişiklikleri versiyonlanıyor mu?

XML FEED KALİTE PUANLAMA SİSTEMİ NASIL KURULUR?

1. Önce feed'in hangi satış ve entegrasyon süreçlerinde kullanılacağını belirleyin.

2. Kaliteyi etkileyen alan ve süreçlerin envanterini çıkarın.

3. Kalite boyutlarını tanımlayın.

4. Her boyut için ölçülebilir metrik oluşturun.

5. Zorunlu, koşullu zorunlu ve isteğe bağlı alanları sınıflandırın.

6. Missing, empty, invalid ve placeholder değerlerin kurallarını belirleyin.

7. XML parse ve structural validity metriklerini oluşturun.

8. Completeness oranlarını ürün ve feed seviyesinde hesaplayın.

9. Fiyat, stok, barkod, kategori ve URL validity kontrollerini ekleyin.

10. Accuracy için güvenilir referans veya örneklem yöntemini oluşturun.

11. Consistency ve uniqueness kontrollerini ekleyin.

12. Timeliness ve son başarılı sync metriklerini oluşturun.

13. Feed/görsel erişilebilirliği ile job reliability metriklerini ekleyin.

14. Dimension ağırlıklarını iş riskine göre belirleyin.

15. Critical blocker kurallarını toplam puandan ayrı tanımlayın.

16. Product, feed ve channel readiness skorlarını ayrı hesaplayın.

17. Score yanında issue count, severity ve measurement coverage gösterin.

18. İlk modeli mevcut birkaç feed üzerinde dry-run çalıştırın.

19. Skorun gerçek operasyon problemlerini doğru yansıtıp yansıtmadığını kontrol edin.

20. Kuralları versiyonlayarak puanları zaman içinde karşılaştırın.

SIK SORULAN SORULAR

XML feed kalitesi için standart bir 100 puan sistemi var mı?

Hayır. W3C Data Quality Vocabulary kalite ölçümlerini dimension ve metric yaklaşımıyla modellemeye imkân verir ancak tek bir normatif kalite boyutu veya puan formülü belirlemez. Kullanım alanına göre farklı metrik ve ağırlıklar oluşturulabilir.

90 puan alan XML feed kesinlikle kaliteli midir?

Tek başına söylenemez. 90 puanın hangi metriklerden oluştuğu bilinmelidir. Ayrıca tek bir kritik fiyat veya stok hatası yüksek ortalama puanın içinde kaybolabilir. Bu nedenle overall score yanında critical issue ve publishability kontrolleri de tutulmalıdır.

Eksik alan oranı XML kalite puanı için yeterli midir?

Hayır. Completeness yalnızca kalite boyutlarından biridir. Bütün alanlar dolu olsa bile fiyatlar yanlış, görseller erişilemez, kategoriler hatalı veya stok verileri eski olabilir.

Google Merchant hatalarını XML kalite puanına ekleyebilir miyim?

Evet, dış kanal kalite sinyali olarak kullanılabilir. Merchant Center veri kaynağındaki dosya ve attribute problemlerini, ayrıca ürün seviyesindeki sorunları ayrı raporlayabiliyor. Ancak Merchant sorunlarını doğrudan genel XML kalite puanının tamamı olarak değerlendirmek doğru değildir.

İki tedarikçiyi sadece XML kalite skoruna göre seçmek doğru mudur?

Hayır. Veri kalitesi önemli olmakla birlikte ürün çeşidi, alış fiyatı, stok sürdürülebilirliği, sipariş/kargo performansı ve ticari şartlar da değerlendirilmelidir. XML kalite puanı özellikle entegrasyonun çıkaracağı operasyonel veri yükünü karşılaştırmak için kullanılabilir.

İYİ BİR XML FEED SKORU “KAÇ HATA VAR?” SORUSUNDAN DAHA FAZLASINI CEVAPLAMALIDIR

123 numarada ana mesajımız bu olmalı.

Basit yaklaşım:

100 hata → kötü

10 hata → iyi

şeklindedir.

Ancak:

100 hata:

ikinci görsel eksikliği

olabilir.

10 hata:

10 ürünün fiyatının 0 TL olması

olabilir.

İkinci feed daha risklidir.

Bu nedenle daha doğru sistem:

hangi kalite boyutu?

↓

hangi metric?

↓

kaç ürün etkileniyor?

↓

hatanın severity'si ne?

↓

critical blocker var mı?

↓

dimension score nedir?

↓

overall score nedir?

↓

measurement coverage yeterli mi?

↓

hangi kanal için yayına hazır?

şeklinde ilerlemelidir.

Örneğin:

Feed A

Overall: 95

Critical: 3

Publish: BLOCKED

Feed B

Overall: 88

Critical: 0

Publish: READY

Bu durumda yalnız toplam puana bakarsanız:

Feed A daha iyi

dersiniz.

Operasyonel karar ise:

Feed B bugün daha güvenli

olabilir.

Bu nedenle 123'ün en önemli ilkesi:

Kalite puanı, kritik hata kontrolünün yerine geçmemelidir.

Bir başka güçlü örnek:

Supplier A

Completeness → 98

Validity → 97

Accuracy → 95

Timeliness → 40

Burada tedarikçinin ürün verisi güçlüdür ancak feed çok geç güncellenmektedir.

Supplier B

Completeness → 70

Validity → 90

Accuracy → 90

Timeliness → 100

Burada veri hızlı gelir ama çok fazla alan eksiktir.

İki supplier aynı:

80 puan

seviyesinde görünse bile operasyon sorunları tamamen farklıdır.

Bu nedenle dashboard'da:

Overall score

yanında:

dimension breakdown

mutlaka görünmelidir.