ÜRÜN FEED YÖNETİMİ YAPMAK VE MERCHANT CENTER HATALARINI AZALTMAK

Shopping kampanyaları iyi bir bütçeyle bile beklenen sonucu vermeyebilir; çünkü çoğu zaman sorun reklamlarda değil, ürün verisindedir. Eksik GTIN, tutarsız fiyat, yanlış stok, zayıf başlık ya da politika uyarıları… Hepsi tek bir yerde toplanır: Merchant Center teşhis ekranı.

Ürün feed yönetimi, “dosyayı yükledim bitti” yaklaşımından çok daha fazlasıdır. Amaç; ürün verisini arama niyetine uygun hale getirmek, sistemin doğrulama kontrollerini temiz geçirmek ve katalog büyüdükçe süreçleri bozulmadan ölçekli biçimde yönetmektir.

Bu yazıda; Merchant Center hatalarını azaltmak için veri modelinden kontrol listesine, otomasyondan test planına kadar pratik bir çerçeve bulacaksınız. Hedefimiz, onay oranını yükseltmek ve kampanya optimizasyonunun önündeki veri engellerini kaldırmaktır.

Ürün feed yönetiminin temel hedeflerini netleştirmek

Sağlam bir ürün feed yönetimi için önce “başarı” tanımını netleştirmek gerekir. Yalnızca hata sayısını azaltmak yeterli değildir; asıl amaç, doğru veriyi doğru kullanıcıyla buluşturmaktır. Bu yüzden hem teknik doğruluk hem de pazarlama etkisi birlikte ele alınmalıdır.

Onay oranını ve kapsama alanını birlikte izlemek

Onay oranı yükselirken toplam yayınlanan ürün sayısı düşüyorsa, görünürlük kaybı yaşarsınız. Bu nedenle “approved”, “disapproved”, “pending” dağılımını kategori ve marka bazında takip etmek önemlidir. Ayrıca en çok ciro getiren ürün gruplarının hatasız yayınlandığından emin olmak gerekir.

Veri doğruluğu ile performans metriklerini ilişkilendirmek

“Fiyat uyuşmazlığı” gibi hatalar yalnızca reddedilmeye yol açmaz; bazen ürün yayınlansa bile kalite sinyallerini olumsuz etkileyebilir. Bu yüzden feed sağlığı metriklerini (hata türü, tekrar sıklığı, düzeltme süresi) Shopping performansıyla (gösterim payı, tıklama oranı, dönüşüm) birlikte okumak gerekir.

Merchant Center teşhis ekranını sistematik okumak

Merchant Center Diagnostics bölümü, sorunların kök nedenine ulaşmak için en hızlı yoldur. Ancak listeyi tek tek düzeltmek yerine, hata türlerini sınıflandırıp kalıcı çözümler üretmek gerekir. Böylece aynı hata her gün yeniden üretilmez.

Hata türlerini “veri”, “politika” ve “site” olarak ayırmak

Veri hataları; eksik veya yanlış attribute’lerden kaynaklanır (gtin, price, availability gibi). Politika uyarıları; içerik veya kategori hassasiyetleriyle ilişkilidir. Site sorunları ise tarama, erişim, yapılandırılmış veri ve sayfa deneyimi gibi alanlarda görülür. Bu ayrım, doğru ekibin doğru aksiyonu almasını kolaylaştırır.

Önceliklendirmeyi ciro ve risk etkisine göre yapmak

Tüm hatalar aynı önemde değildir. Yüksek ciro ürünlerinde görülen bir reddedilme, küçük bir alt kategorideki eksikten daha kritiktir. Ayrıca “hesap seviyesinde” risk taşıyan uyarılar (ör. tekrar eden politika ihlalleri) önceliği yukarı taşır. Bu yüzden bir “etki matrisi”yle ilerlemek işleri hızlandırır.

{
  "prioritization": [
    {"type": "price_mismatch", "impact": "high", "scope": "many_items"},
    {"type": "missing_gtin", "impact": "medium", "scope": "category_specific"},
    {"type": "policy_warning", "impact": "high", "scope": "account_risk"}
  ],
  "rule": "impact_high_first_then_scope"
}

Ürün verisi modelini standardize ederek hataları önlemek

Hataların büyük bölümü, ürün verisinin farklı kaynaklardan farklı biçimlerde gelmesinden doğar. ERP, PIM, e-ticaret altyapısı ve pazaryeri panelleri arasında alan isimleri değişebilir. Çözüm; ortak bir ürün sözlüğü ve alan eşleştirme standardı oluşturmaktır.

Zorunlu alanları “tek kaynak” prensibiyle yönetmek

price, sale_price, availability, brand, gtin/mpn, shipping gibi alanlar birden fazla kaynaktan besleniyorsa tutarsızlık kaçınılmazdır. Bu alanlar için “tek doğru kaynak” belirleyip diğer kaynakları yalnızca referans olarak kullanmak gerekir. Örneğin fiyat güncellemesi ERP’den geliyorsa, site panelindeki manuel fiyat değişiklikleri süreç dışına alınmalıdır.

Varyant, stok ve fiyat mantığını net kurmak

Renk/beden gibi varyantlar doğru modellenmezse “yanlış stok” ve “fiyat uyuşmazlığı” hataları sıklaşır. Her varyantın benzersiz bir id’si olmalı; stok ve fiyat, ürün ailesi yerine varyant seviyesinde tutulmalıdır. Ayrıca kampanya fiyatı yönetimi için sale_price ve sale_price_effective_date alanları net planlanmalıdır.

• Ürün ID sabit kalmak, kaynak sistemlerde değişmemek
• Varyant ID renk/beden gibi seçeneklerde ayrışmak
• Fiyat tek para birimi ve tek formatla taşınmak
• Stok “in stock / out of stock / preorder” mantığıyla güncellenmek

Başlık ve açıklama kurgusunu arama niyetine göre güçlendirmek

Feed doğrulama kontrolleri “geçti” diye iş bitmez. Shopping tarafında görünürlük ve tıklama; büyük ölçüde title, description, product_type ve google_product_category alanlarının kalitesine bağlıdır. Bu alanlar, hem kullanıcı hem de sistem için “ürünü anlamlandırma” sinyalleridir.

Başlık şablonunu kategori bazında tasarlamak

Her ürün için aynı formatı kullanmak yerine, kategori bazında şablon oluşturmak daha verimlidir. Örneğin ayakkabıda “Marka + Model + Cinsiyet + Tür + Renk”, elektronikte “Marka + Model + Kapasite + Renk” gibi. Bu yaklaşım, hem alaka düzeyini yükseltir hem de tekrar eden hatalı ifadeleri azaltır.

Açıklamayı bilgi odaklı ve tutarlı hale getirmek

description alanında aşırı promosyon dili veya belirsiz ifadeler, kaliteyi düşürebilir. Kısa, anlaşılır, ürün özelliğine odaklanan bir yapı tercih edilmelidir. Ölçekli kataloglarda açıklamayı PIM üzerinden standartlaştırmak; manuel giriş kaynaklı tutarsızlığı azaltır.

Title template example:
"{brand} {model} {product_type} {key_feature} {color} {size}"

Description checklist:
- material / specification
- compatibility (if relevant)
- usage scenario
- warranty / package content (short)

En sık görülen Merchant Center hatalarını kökten çözmek

Bazı hata tipleri, birçok ekipte tekrar tekrar görülür. Bu bölümde, en yaygın senaryoları ve kalıcı çözüm yaklaşımını özetleyelim. Burada amaç tek tek ürün düzeltmek değil; hatayı üreten sistemi düzeltmektir.

Fiyat uyuşmazlığını veri akışıyla uyumlu çözmek

Fiyat uyuşmazlığı genellikle üç sebepten oluşur: sitedeki fiyat ile feed fiyatının farklı olması, indirimli fiyat tarih aralığının yanlış tanımlanması veya para birimi/format hatası. Çözüm; fiyatın kaynağını tekleştirmek, güncelleme sıklığını gerçek zamana yaklaştırmak ve kampanya dönemlerinde sale_price_effective_date alanını disiplinle kullanmaktır.

Eksik GTIN sorununu kategori stratejisiyle ele almak

GTIN eksikliği bazı kategorilerde görünürlük kaybına yol açabilir. Ürünler üretici barkoduna sahipse mutlaka beslemek gerekir. Özel üretim ürünlerde GTIN yoksa mpn ve brand alanları tutarlı biçimde kullanılmalıdır. Ayrıca varyantların GTIN’leri farklıysa her varyanta doğru GTIN girilmelidir.

Stok hatalarını senkronizasyon mantığıyla azaltmak

availability alanı gecikmeli güncellenirse “stokta yok ama satılıyor” ya da “stokta var ama görünmüyor” gibi riskler doğar. Çözüm; stok güncellemesini daha sık yapmak, hızlı değişen ürünlerde “scheduled fetch” yerine API tabanlı güncelleme planlamak ve kritik ürünlerde uyarı eşikleri oluşturmaktır.

Otomasyon ve kontrol listesi ile süreci sürdürülebilir kılmak

Katalog büyüdükçe manuel kontrol sürdürülemez hale gelir. Sürdürülebilirlik için iki şey gerekir: otomasyon (yenileme, doğrulama, uyarı) ve operasyonel ritim (haftalık kontrol, sorumluluk, rapor standardı). Bu sayede ekip değişse bile kalite korunur.

Günlük ve haftalık kontrol ritmini standartlaştırmak

Günlük kontrol; kritik hatalar ve hesap riskleri için, haftalık kontrol ise kategori bazlı performans ve kalite iyileştirmeleri için uygundur. Ayrıca her hata türü için “sahiplik” tanımlamak gerekir: fiyat hatası veri ekibinin, politika uyarısı içerik/ürün ekibinin, tarama problemi teknik ekibin sorumluluğu gibi.

Supplemental feed ve feed rules ile esnek düzeltmeler yapmak

Kaynak sistemleri değiştirmek zaman alabilir. Bu durumda Merchant Center içindeki kurallar veya supplemental feed ile hızlı düzeltmeler yapılabilir. Örneğin belirli bir kategoriye google_product_category eklemek, başlığa otomatik ek bilgi eklemek ya da teslimat süresi alanını tamamlamak gibi.

1. Kontrol listesi oluşturmak ve her yayın öncesi uygulamak
2. Hata takibi için haftalık rapor standardı kurmak
3. Otomatik uyarı ile kritik eşikleri kaçırmamak
4. Kural katmanı ile hızlı düzeltme yapıp kök nedeni planlamak

Test planı ve izleme ile kaliteyi güvenceye almak

Feed yönetiminde “değişiklik yaptım, umarım düzeldi” yaklaşımı risklidir. Bunun yerine küçük bir test planı ile ilerlemek gerekir. Bu plan; örnek ürün seti, kontrol metrikleri ve geri alma senaryolarını içermelidir. Böylece hatalı bir güncelleme binlerce ürünü etkilemez.

Örnek ürün setiyle değişiklikleri doğrulamak

Her kategori için temsil edici ürünler seçip (yüksek ciro, yüksek stok, düşük stok, varyantlı ürün) bu set üzerinden değişikliği test edin. Başlık şablonu değişiyorsa tıklama oranı, fiyat alanı değişiyorsa uyuşmazlık uyarıları gibi metrikleri net bağlayın.

Uyarı eşikleri belirleyip hızlı aksiyon almak

“Disapproved ürün sayısı %5 arttı” gibi eşikler, erken uyarı sağlar. Bu eşikler için ekip içi bildirim mekanizması kurmak, sorun büyümeden müdahale etmeyi kolaylaştırır. Böylece reklam bütçesi boşa akmaz ve görünürlük kaybı sınırlı kalır.

Sonuç: Ürün feed yönetimi; veri standardı, teşhis okuma alışkanlığı, içerik kurgusu ve otomasyon birleştiğinde Merchant Center hatalarını belirgin biçimde azaltır. Bu süreci ekip içinde ortak bir dil ve pratiklerle yönetmek isteyenler için e-ticaret eğitimi kapsamında feed, ölçümleme ve optimizasyon adımlarını uçtan uca ele almak hızlı ilerleme sağlar.