← Tüm Rehberler
GELİŞEN REHBERVeri ve Raporlama11 DKDOĞRULAMA: 2 Ağustos 2026

Ürün Veri Sözleşmesi Nasıl Kurulur? SKU, Varyant, Fiyat ve Stok Paritesi

Mağaza, structured data, merchant feed, reklam ve checkout arasında aynı ürünü konuşmak için uygulanabilir bir katalog veri sözleşmesi kurun.

Kimler için? E-ticaret, ürün, veri, pazarlama ve mühendislik ekipleriArama niyeti Veri mimarisi ve operasyon standardı
60 SANİYELİK KISA CEVAP

Sorunun doğrudan cevabı

Ürün veri sözleşmesi; SKU/item_id, ebeveyn-varyant ilişkisi, başlık, açıklama, görsel, fiyat, stok, teslimat ve iade alanlarının anlamını, sahibi olan sistemi, güncelleme SLA’sını ve hata davranışını yazılı hale getirir. Amaç tek bir CSV üretmek değil; ürün sayfası, Product/Offer structured data, merchant feed, reklam kataloğu ve checkout arasında aynı ürünü ve ticari durumu taşıyan doğrulanabilir bir kimlik zinciri kurmaktır.

Alan sözlüğünü aç

Neden önemli?

  • Aynı SKU farklı sistemlerde farklı isim veya fiyatla yaşarsa pazarlama raporu ile sipariş sonucu birbirinden kopar.
  • Varyant ilişkisi ve stok durumu bozulduğunda görünürlük artışı yanlış ürün, yanlış beden veya stok dışı teklif üretebilir.
  • Alan sahibi ve güncelleme SLA’sı tanımlanmayan feed hataları ekipler arasında bekleyen manuel işlere dönüşür.
  • AI keşif yüzeyleri ve klasik reklam katalogları değişse bile kalıcı ürün kimliği ve veri paritesi yatırımı korunur.

Tanım ve yöntem

Ürün veri sözleşmesi, katalogdaki her alan için tanım, kaynak sistem, format, izin verilen değer, sahip, güncelleme sıklığı, doğrulama kuralı ve hata durumunu belirleyen ekipler arası veri anlaşmasıdır. Ticari gerçeklik ile içerik gerçekliğini aynı ürün kimliğinde birleştirir.

FORMÜLParite oranı = aynı SKU için eşleşen alan sayısı / doğrulanması gereken alan sayısı × 100

Parite oranı bir platform kabul veya sıralama garantisi değildir. Fiyat ve stok gibi kritik alanlar için genel ortalama yerine kritik hata oranı ve son başarılı güncelleme yaşı da ayrı izlenmelidir.

Gerekli veriler

01

Kimlik modeli

SKU/item_id, GTIN, ebeveyn ürün, varyant ve ülke/kanal anahtarları.

02

İçerik sözleşmesi

Başlık, açıklama, görsel, ölçü, materyal, uyumluluk ve dil kuralları.

03

Ticari sözleşme

Fiyat, para birimi, stok, teslimat, iade ve satıcı/politika alanları.

04

Kalite kapıları

Zorunlu alan, format, güncellik, sayfa/feed/checkout eşleşmesi ve hata sahibi.

Tek ürün için beş yüzey parite kontrolü

Aşağıdaki örnekte yüksek alan doluluğu, ticari parite bozulduğu için yayın kapısını geçmiyor.

Tek ürün için beş yüzey parite kontrolü için örnek değerler
KalemDeğerNot
Kalıcı kimlikAYK-001 / 42 / siyahSayfa-feed-checkout aynı
Başlık ve görsel%100Görünür içerikle eşleşiyor
Fiyat ve para birimiFeed ≠ checkoutKritik hata
Stok güncelliği26 saatSLA: 2 saat
Varyant ilişkisiKopukBeden seçimi güvenilmez

Sonuç: İçerik tamam olsa da fiyat, stok ve varyant kapıları geçilmeden reklam veya AI ticaret yüzeyi açılmamalı; önce kaynak sistem ve güncelleme hattı düzeltilmelidir.

Sonucu nasıl yorumlamalısınız?

Sinyal, anlam ve önerilen sonraki adım
Gördüğünüz sinyalNe anlama gelir?Ne yapmalı?
Alan doluluğu yüksek, parite düşükKatalog dolu görünür ama yüzeyler farklı ticari gerçeklik taşır.Önce fiyat, stok, varyant ve checkout eşleşmesini kritik yayın kapısı yapın.
Aynı SKU birden fazla kimlikle akıyorAtıf, stok ve iade analizi ürünler arasında bölünür.Kalıcı item_id belirleyip kanal kimliklerini eşleme tablosunda tutun.
Feed güncellemesi başarısız ama alarm yokEski fiyat/stok bilgisi sessizce yayınlanmaya devam eder.Son başarılı güncelleme yaşı, hata oranı ve sahip SLA’sı için alarm kurun.
İçerik ekipleri ve veri ekibi farklı tanım kullanıyor“Stokta”, “teslimat süresi” veya “varyant” gibi alanlar raporda tutarsızlaşır.Alan sözlüğünü örnek değer, sahip ve kabul kriteriyle yayınlayın.

Sık yapılan hatalar

  1. Kanal bazında yeni SKU üretip kalıcı ürün kimliğini kaybetmek.
  2. Zorunlu alanları yalnız dolu/boş kontrolüyle ölçmek; anlam, format ve güncelliği test etmemek.
  3. Fiyat ve stok paritesini günlük ortalamayla gizleyip kritik anlık hataları izlememek.
  4. Varyant ebeveynini yalnız görsel bir grup sanıp sipariş ve iade kimliğiyle bağlamamak.
  5. Ürün sayfasını güncelleyip structured data, feed ve reklam kataloğunu geride bırakmak.
  6. Hata kuyruğunda sahip ve son tarih bulunmadan tüm sorunları “teknik” etiketiyle bekletmek.
UYGULAMADAN ÖNCE

Kontrol listesi

  • Her ürün ve varyant için kalıcı SKU/item_id ve ebeveyn ilişkisi tanımlı.
  • Alan sözlüğünde tanım, örnek değer, sahip, kaynak sistem ve güncelleme SLA’sı var.
  • Sayfa, structured data, feed, reklam kataloğu ve checkout paritesi ölçülüyor.
  • Fiyat, stok, para birimi ve teslimat için kritik yayın kapıları tanımlı.
  • Son başarılı güncelleme yaşı ve hata oranı için alarm/eskalasyon akışı çalışıyor.
  • Ülke ve kanal farkları ana kimliği bozmadan eşleme tablosunda tutuluyor.
  • İade, sipariş ve reklam sonuçları aynı ürün/ülke/kampanya kimliğiyle geri besleniyor.

Sık sorulan sorular

Ürün veri sözleşmesi sadece teknik ekip işi mi?

Hayır. Ürün, operasyon, pazarlama, müşteri hizmetleri ve finans ekipleri alanların anlamını ve karar etkisini birlikte belirlemelidir; teknik ekip hattı uygular.

Parite oranı kaç olursa yeterlidir?

Evrensel eşik yoktur. Kritik fiyat/stok alanlarında hedef, ortalamadan önce sıfıra yakın kritik hata ve tanımlı güncelleme SLA’sıdır. Kategori ve kanal bazında kendi toleransınızı yazılı hale getirin.

Merchant feed ile ürün sayfası aynı veri kaynağından mı gelmeli?

Tek fiziksel sistem zorunlu değildir; fakat sahiplik, kimlik ve güncelleme kuralları ortak olmalı, iki yüzey arasındaki farklar otomatik doğrulanmalıdır.

Bu sözleşme AI görünürlüğünü garanti eder mi?

Hayır. Veri paritesi yalnızca sağlam bir ön koşuldur. İndeksleme, platform uygunluğu, ülke/merchant kapsamı ve gerçek sipariş deneyimi ayrıca doğrulanmalıdır.

Kaynaklar ve yöntem notu

Kaynaklar 2 Ağustos 2026 tarihinde kontrol edildi. Sonraki editoryal kontrol: 15 Eylül 2026.

  1. Google Merchant Center — Product data specificationKimlik, başlık, açıklama, bağlantı, görsel, fiyat, stok ve varyant alanlarının güncel resmî gereksinimleri.
  2. Google Search Central — Merchant listing structured dataProduct ve Offer verisinde fiyat, para birimi, stok, teslimat ve iade bilgisinin kullanımını; doğrulama ve izleme adımlarını açıklar.
  3. OpenAI Developers — Agentic Commerce product feed products schemaNon-Ads düz dosya ürün feed’i için zorunlu alanlar, doğrulama kuralları ve satıcı/politika gereksinimleri.
  4. Google Search Central — AI features and your websiteAI Overviews ve AI Mode için ek teknik gereksinim veya özel AI dosyası olmadığını; indekslenebilirlik, metinsel içerik, iç bağlantı ve görünür verilerle eşleşen structured data temelini açıklar.

Bu rehber veri ve operasyon standardı için karar desteğidir; platform kabulü, sıralama veya ticari sonuç garantisi değildir. Güncel alan ve ülke gereksinimlerini ilgili resmî dokümantasyondan doğrulayın.