Çok Kanallı Feed Yönetimi: Birleşik Feed Stratejisi Neden Kazandırır?

Bir markanın satış yaptığı her yeni kanal, e-ticaret ekiplerinin büyüme kararı verirken çoğu zaman hafife aldığı ek bir bakım maliyeti yaratır. Mevcut bir Meta kataloğuna Google Shopping eklemek nispeten kolaydır. Ancak bunların üzerine bir marketplace feed’i, ardından bir karşılaştırmalı alışveriş motoru ve sonrasında yeni bir pazar için bölgesel bir varyant eklendiğinde, belirli bir noktadan sonra feed yönetiminin operasyonel yükü arka plandaki basit bir görev olmaktan çıkar ve ekibin diğer işlere ayırabileceği kapasiteyi yapısal olarak sınırlamaya başlar.

Tipik süreç genellikle şöyle ilerler: İlk kanal, özenle yönetilen bir feed’e sahip olur. İkinci kanal, bazı düzenlemelerle ilk feed’in bir kopyasını kullanır. Üçüncü kanal ise ikincinin bir kopyasıyla oluşturulur. Marka 8.000 SKU ile dört farklı kanalda satış yapmaya başladığında, aslında aynı ürün verisinin dört farklı versiyonunu yönetiyor hâle gelir. Fiyat değiştiğinde, bir ürün tükendiğinde veya bir başlık yalnızca tek bir yerde güncellendiğinde bu versiyonlar birbirinden biraz daha uzaklaşır.

Versiyonlar arasındaki sapma küçük bir operasyonel sorun değildir; zaman içinde büyüyen bir yükümlülüktür. Canlı sitedeki fiyatlarla feed’deki fiyatların uyuşmaması politika ihlallerine ve ürünlerin reddedilmesine yol açabilir. Stok bilgilerindeki uyumsuzluklar ücretli trafiği stokta olmayan ürünlerin landing page’lerine yönlendirebilir. Kanallar arasındaki ürün başlığı tutarsızlıkları ise aynı ürünün farklı platformlarda farklı şekilde tanımlanmasına neden olarak marka sunumunda tutarsızlık ve attribution süreçlerinde karmaşa yaratır. Feed’in diğerlerinden ayrışan her versiyonu, başlı başına ayrı bir hata kaynağıdır. Eklenen her yeni kanalla birlikte olası tutarsızlık noktalarının sayısı da artar.

Çoğu Ekibin Gözden Kaçırdığı Çok Kanallı Feed Sorunu

Çok kanallı e-ticarette feed yönetiminin temel sorunu, işin teknik olarak zor olması değildir. Asıl sorun, bir şey bozulana kadar bu işin görünmez kalmasıdır. Sorun ortaya çıktığında ise zarar çoktan ürün reddedilmeleri, boşa harcanan reklam bütçesi ve kaçırılan gelir olarak kendini göstermiş olur.

Bir ürünün fiyatı değiştiğinde ne olduğunu düşünün. Tek kanallı bir yapıda fiyat güncellemesi e-ticaret platformundan feed’e, feed’den de satış kanalına aktarılır. Tek güncelleme, tek hata noktası. Birleşik feed mimarisi olmayan dört kanallı bir yapıda ise aynı fiyat değişikliğinin dört ayrı feed dosyasına aktarılması gerekir. Her feed’in farklı bir güncelleme takvimi ve farklı bir yönetim süreci olabilir. Bu durumda dört kanalın tamamında doğru fiyatın aynı anda görüntülenme olasılığı düşüktür. Herhangi bir anda en az bir kanalın güncelliğini yitirmiş bir fiyat gösterme olasılığı ise yüksektir.

Hata oranı katalog büyüklüğüyle birlikte artar. 500 SKU’ya sahip bir marka, fiyat tutarsızlıklarını manuel kontrollerle yakalayabilir. Ancak 8.000 SKU’ya sahip bir marka için bu yaklaşım sürdürülebilir değildir. Hatalar sessizce birikir ve çoğu zaman ancak Merchant Center uyarıları, dönüşüm oranındaki anomaliler veya reklamda görünen fiyat ile ürün sayfasındaki fiyatın uyuşmadığına ilişkin müşteri şikâyetleri ortaya çıktığında fark edilir.

Organizasyonel yapı da soruna başka bir katman ekler. Çok kanallı e-ticaret ekiplerinin çoğunda farklı kanallar farklı kişiler tarafından yönetilir. Ücretli arama yöneticisi Google feed’inden, sosyal medya ekibi Meta kataloğundan, marketplace ekibi ise Amazon içeriklerinden sorumludur. Hiç kimse dört kanalın tamamını tek noktadan göremez ve ana veri kaynağındaki değişikliklerin her kanalın feed’ine ne zaman ve nasıl aktarılacağını yöneten ortak bir süreç bulunmaz.

Birleşik Feed Pratikte Ne Anlama Gelir?

Birleşik feed stratejisi çoğu zaman tüm kanallara dağıtılan tek bir statik dosya olarak yanlış anlaşılır. Aslında böyle değildir. Birleşik feed, kanala özel çıktıların dönüşüm kuralları aracılığıyla üretildiği tek bir ana veri kaynağıdır. Ana kaynak, eksiksiz ve güvenilir ürün verilerini içerir. Dönüşüm katmanı ise veriler her kanala gönderilmeden önce kanala özel biçimlendirme, özellik eşleştirme ve alan uzunluğu sınırlamalarını uygular. Böylece kanallar farklı çıktılar alsa bile tüm bu çıktılar aynı merkezi veri kaynağından türetilir.

Bu ayrım önemlidir çünkü kanalların gerçekten farklı gereksinimleri vardır. Google Shopping, 150 karaktere kadar ürün başlıklarını destekler ve temel ürün tanımlayıcılarından biri olarak GTIN kullanır. Meta Catalogs farklı görsel oranı gereksinimlerine sahiptir ve retailer_product_id kullanır. Marketplace’ler ise her ikisinden de farklı, kategoriye özel özellik şemalarına sahiptir. Tek bir statik dosyanın bu üç yapının tüm gereksinimlerini aynı anda karşılaması mümkün değildir. Ancak bir dönüşüm katmanı bunu sağlayabilir.

Mimari şu şekilde çalışır: E-ticaret platformu veya ürün bilgi yönetim sistemi (PIM), tüm ürün özelliklerini eksiksiz ve değiştirilmemiş biçimde içeren ana veri kaynağı olarak görev yapar. Feed yönetim katmanı, kanala özel çıktılar oluşturmak için dönüşüm kurallarını uygular. Örneğin başlıkları kanalın karakter sınırına göre kısaltır, şirket içi kategori adlarını kanalın taksonomi değerleriyle eşleştirir, farklı para birimi formatları gerektiren kanallar için fiyatları yeniden biçimlendirir ve kanalın uygunluk kriterlerini karşılamayan ürünleri hariç tutar. Ortaya çıkan kanal feed’leri, her platformun veri yenileme gereksinimlerine uygun bağımsız güncelleme takvimleriyle gönderilir.

İşi Tekrarlamadan Kanala Özel Gereksinimleri Yönetmek

Kanalların veri gereksinimlerinin hangi noktalarda farklılaştığını anlamak, bu farklılıkları otomatik olarak yönetecek dönüşüm kurallarını tasarlamak açısından kritik öneme sahiptir. Aşağıdaki tablo, üç temel kanal türü arasındaki başlıca farklılıkları özetlemektedir.

Bu tablodaki her satır, manuel olarak yönetilen çoklu feed yapısında ana veri her değiştiğinde ayrı ayrı karar verilmesini gerektiren bir farklılaşma noktasını temsil eder. Dönüşüm kurallarına sahip birleşik bir feed mimarisinde ise her farklılık, kural seviyesinde yalnızca bir kez tanımlanır ve feed her yenilendiğinde katalogdaki tüm ürünlere otomatik olarak uygulanır.

Başlık kısaltma, dönüşüm kurallarının pratikte nasıl çalıştığını gösteren iyi bir örnektir. Ana feed, ürünü şirket içi kullanım için eksiksiz biçimde tanımlayan 180 karakterlik bir başlık içerebilir. Google Shopping dönüşüm kuralı bu başlığı 150 karaktere indirirken ticari açıdan en önemli özellikleri başta korur. Meta için tanımlanan dönüşüm kuralı ise başlığı 100 karaktere göre kısaltır. Marketplace kuralı da ilgili platformun kendi karakter sınırını uygular. Tek bir ana başlık, üç kanala uygun çıktı, sıfır manuel tekrar.

Feed Karmaşasının Organizasyonel Etkisi

Parçalı feed yönetiminin teknik sonuçları ROAS ve ürün reddedilme oranları üzerinden ölçülebilir. Organizasyonel sonuçlarını ölçmek ise daha zordur, ancak etkileri en az teknik sonuçlar kadar önemlidir.

Farklı ekipler farklı kanal feed’lerinden sorumlu olduğunda, feed kalitesi yönetilen bir süreç olmaktan çıkar ve ekipler arası koordinasyon problemine dönüşür. Merchandising ekibinin yaptığı bir fiyat değişikliğinin tüm kanallarda yayına girebilmesi için dört farklı feed sorumlusuna ulaşması gerekir. Bu kişilerden biri izinliyse veya bildirim kendisine ulaşmazsa, hata fark edilene kadar sorumlu olduğu kanalda eski fiyat gösterilmeye devam eder. Bu, herhangi bir kişinin hatası değildir. Doğru çalışabilmek için sürekli manuel koordinasyon gerektiren bir sürecin yapısal problemidir.

Bu durumun ekipler arasında yarattığı gerilim de sürekli tekrarlanan bir örüntüdür. Performans pazarlama ekibi düşük Shopping ROAS’ını teklif stratejisine bağlar. Ayrı bir feed sorumlusu varsa, sorunun başlık kalitesinden kaynaklandığını savunur. Merchandising ekibi ise feed güncelleme sürecinin manuel bildirim gerektirdiği kendilerine iletilmediği için yaptıkları fiyat değişikliklerinin kanallara doğru şekilde aktarılmadığının farkında olmayabilir. Her durumda temel neden aynıdır: feed, sahipliği açıkça tanımlanmış ortak bir altyapı olarak yönetilmemektedir. Feed, bunun yerine her kanal ekibinin ayrı ayrı üstlendiği operasyonel bir sorumluluk olarak ele alınır. Ancak bu, feed’in ortak bir altyapı olarak yönetilmesiyle aynı şey değildir.

Birleşik feed mimarisi, bu belirsizliği tasarım gereği ortadan kaldırır. Tek bir ana veri kaynağı, bu kaynağın bakımından sorumlu tek bir ekip veya sistem ve tüm kanal çıktılarının geçtiği tanımlı bir dönüşüm süreci bulunur. Ana kaynakta yapılan değişiklikler otomatik olarak tüm kanallara aktarılır. Böylece koordinasyon yükü, sürekli yürütülen bir arka plan işinden çıkar ve yalnızca dönüşüm kurallarının kapsamadığı istisnai durumlarda devreye giren bir sürece dönüşür.

Birleşik Feed Mimarisini Oluşturmak

Halihazırda parçalı feed yönetimi kullanan markalarda birleşik bir mimariye geçiş öngörülebilir bir sırayla gerçekleştirilmelidir. Bu sıralama önemlidir; çünkü aktif kampanyalar devam ederken tüm kanalları aynı anda birleştirmeye çalışmak gereğinden fazla eş zamanlı risk yaratır.

Adım 1: Mevcut yapıyı denetleyin. Tüm aktif feed dosyalarını çıkarın ve her birinin hangi kaynaktan geldiğini, kim tarafından yönetildiğini, ne sıklıkla güncellendiğini ve her kanalın tanılama raporlarındaki hata oranını belgeleyin. Bu denetim, kanallar arasındaki farklılaşmanın gerçek boyutunu ortaya çıkarır ve en yüksek hata oranına sahip kanalları belirleyerek birleşik yapıya geçişte hangi kanallara öncelik verilmesi gerektiğini gösterir.

Adım 2: Ana veri kaynağını belirleyin. Çoğu operasyonda bu kaynak e-ticaret platformu (Shopify, Magento, BigCommerce) veya bir PIM sistemidir. Dönüşüm kurallarını tasarlamaya başlamadan önce ana veri kaynağının tüm kanallarda ihtiyaç duyulan özellikleri içerdiğinden emin olun. Ana kaynakta eksik olan özellikler dönüşüm katmanında çözülemez.

Adım 3: Önce en yüksek öncelikli kanal için dönüşüm kurallarını tasarlayın. En yüksek reklam harcamasına ve en yüksek hata oranına sahip kanaldan başlayın. Mimariyi diğer kanallara genişletmeden önce bu kanalın dönüşüm kurallarını oluşturun ve test edin. Böylece bir dönüşüm kuralının beklenmedik sonuçlar üretmesi durumunda etkinin yayılma alanını sınırlandırmış olursunuz.

Adım 4: Güncelleme sıklığını ve senkronizasyon mantığını belirleyin. Ana veri kaynağının ne sıklıkla güncellendiğini ve bu değişikliklerin her kanala ne kadar hızlı aktarılması gerektiğini tanımlayın. Sık fiyat değişikliklerinin yaşandığı yüksek hacimli kataloglarda gerçek zamana yakın senkronizasyon gerekir. Daha düşük değişim hızına sahip kataloglarda ise günde bir veya iki kez planlanan güncellemeler yeterli olabilir. Adım 5: Kalan kanalları sırayla sisteme dahil edin. İlk kanal birleşik mimari üzerinde stabil biçimde çalışmaya başladıktan sonra, oluşturduğunuz dönüşüm yapısını kullanarak diğer kanalları tek tek ekleyin. Her yeni kanal kendine özgü dönüşüm kuralları gerektirir; ancak ana veri kaynağının veya temel mimarinin yeniden oluşturulmasına gerek kalmaz.

EnhanceFeed gibi platformlar, bu mimaride dönüşüm katmanı olarak çalışmak üzere tasarlanmıştır. Ana ürün veri kaynağına yapay zekâ destekli özellik zenginleştirme ve kanala özel biçimlendirme kuralları uygular, ardından ortaya çıkan çıktıları yapılandırılmış güncelleme takvimlerine göre farklı kanallara dağıtır. Birden fazla kanalda büyük kataloglar yöneten ekipler için bu yaklaşım, birleşik feed yönetiminin temel operasyonel maliyetini ortadan kaldırır: dönüşüm katmanını şirket içinde oluşturma ve sürekli bakımını yapma ihtiyacını.

Tek Veri Kaynağı, Birden Fazla Dağıtım Noktası

Birleşik feed stratejisi öncelikle teknik bir karar değildir. Bir markanın kanal portföyü büyüdükçe ürün verilerini nasıl yöneteceğine ilişkin operasyonel bir karardır.

Büyük ölçekte feed kalitesini koruyan markalar, bunu diğer markalardan daha fazla iş yaparak başarmıyor. Aynı işi ana veri kaynağında bir kez ve doğru şekilde yapıyor; ardından tanımlı bir dönüşüm süreciyle kanala özel farklılıkları yönetiyorlar. Feed’leri kanal kanal yöneten markalar ise aynı işi dört veya beş kez tekrarlar, her seferinde biraz farklı hatalar üretir ve temel veriyi iyileştirmek yerine bu farklılıkları düzeltmek için orantısız miktarda zaman harcar.

Parçalı bir feed yapısına eklenen her yeni satış kanalı, bakım yükünü doğrusal olmayan biçimde artırır. Birleşik feed mimarisine eklenen her yeni kanal ise yükü yalnızca tanımlı ve yönetilebilir bir miktarda artırır. İki kanal aşamasında verilen mimari karar, operasyonun beş kanala ulaştığında ne kadar karmaşık ve maliyetli olacağını belirler.

Feed’i bir altyapı olarak ele alın. Bir kez oluşturun. Tüm kanallara dağıtılmasını sağlayın.