Pazaryeri entegrasyonu: Ürün eşleştirmede kritik kararlar

Depodaki beyaz kupa doğru kayıtta duruyor, fakat pazaryerinden gelen sipariş siyah seçeneğe bağlanıyor. Başka bir üründe stok güncellemesi eski ilana gidiyor; yeni açılan ilan satışa açık kalıyor. Entegrasyon isteği teknik olarak başarılı olabilir. Sorun, hangi dış kaydın hangi iç ürünü temsil ettiğinin yanlış kurulmasıdır. Pazaryeri entegrasyonunda ürün eşleştirme, veri göndermeden önce çözülmesi gereken temel ilişkidir.

Bir entegrasyonun varlığı ürün, ilan ve varyant kimliklerinin doğru bağlandığını kanıtlamaz. İç katalogla kanalın veri modeli farklı olabilir. Bu rehber kurgusal bir kupa mağazası üzerinden eşleştirme kararlarını ve testlerini anlatıyor. Örnek kodlar temsilidir. Gerçek kanalın güncel alanları, onay akışı ve teknik sürümü kendi resmî belgelerinden doğrulanmalıdır; eski örneklerin hâlâ geçerli olduğu varsayılmamalıdır.

İç ürün ile dış ilanı aynı varlık saymayın

İç sistemde ürün ailesi ve satın alınabilir varyant bulunabilir. Kanal tarafında ise katalog ürünü, satıcıya ait satış kaydı ve farklı seçenek ilişkileri ayrı yapılar taşıyabilir. Bütün bunları tek bir “ürün kodu” alanına sıkıştırmak önemli ayrımları kaybettirir. Önce hangi kaydın neyi temsil ettiğini çizerek açıklayın.

Kupa ailesinin beyaz ve siyah seçenekleri iç sistemde ayrı varyantlar olsun. Aynı varyant iki kanalda farklı dış kimlik alabilir. Kanal hesabı veya pazar da ilişkinin parçası olabilir. Bir dış kodun bütün hesaplarda aynı anlamı taşıdığı varsayılmamalıdır. Veri sözlüğü, iç kimlik, satıcı kodu ve dış kayıt kimliğinin görevini ayırmalıdır. Teknik ekip kadar ürünleri yöneten kişi de bu ilişkileri anlaşılır biçimde görebilmelidir.

Kararlı ana kimliği görünür addan ayırın

Ürün başlığı güncellenebilir, çevrilebilir veya kanal koşuluna göre düzenlenebilir. Başlıktan eşleştirme yapmak bu değişikliklerde kırılgan hale gelebilir. Kararlı iç varyant kimliği ve onaylı dış eşleştirme kaydı daha güvenilir bir temel sağlayabilir. Hangi alanın kimlik, hangisinin açıklama olduğu açık kalmalıdır.

SKU veya barkod gibi alanların kapsamı kullanılan sistemlere göre değerlendirilir. Veri biçimi, benzersizlik ve değişiklik kuralları güncel teknik belgeyle kontrol edilmelidir. Aynı fiziksel ürüne ait bilginin yanlışlıkla başka kimlikle çoğalması veya bir kodun farklı üründe yeniden kullanılması siparişleri etkileyebilir. Kod düzeni yalnızca güzel görünmesi için seçilmemelidir. Güncelleme ve geçmiş kayıtların neye bağlanacağı düşünülerek yönetilmelidir.

Mevcut ilanları yeni aktarım öncesi inceleyin

Mağazanın pazaryerinde daha önce açılmış ürünleri olabilir. Yeni entegrasyon bunları yok sayıp yeniden oluşturursa kopyalar veya çelişen stok kaynakları ortaya çıkabilir. Mevcut dış kayıtları envantere alın. Hangi ilanların aktif, hangilerinin eski ve hangilerinin iç katalogda karşılıksız olduğunu belirleyin.

Otomatik aday ile onaylı eşleşmeyi ayırın

Kod veya başlık benzerliği eşleştirme adayı üretebilir; fakat belirsiz durumda otomatik kesin karar vermek risklidir. Renk, hacim, paket adedi ve marka gibi ayırt edici bilgiler karşılaştırılabilir. İnceleyen kişi hangi kanıta göre onay verdiğini kaydedebilir. Aynı isimle satılan iki farklı paket varsa yalnızca başlık eşleşmesi yanlış sonuca götürebilir. Eşleşmemiş veya kararsız kayıt, sessizce rastgele ürüne bağlanmak yerine ayrı iş listesinde kalmalıdır.

Varyant gruplarını iki tarafta karşılaştırın

İç sistemin renk ve hacim ilişkisi kanal tarafında aynı biçimde kurulmayabilir. Hangi seçeneklerin aynı aile altında bulunduğu ve hangilerinin ayrı içerik açtığı teknik kurallara bağlıdır. Bu farkın müşteri seçimine ve sipariş satırına nasıl yansıyacağı incelenmelidir. Genel bir “varyant destekleniyor” açıklaması yeterli değildir.

Örneğimizde beyaz 350 mililitre ve siyah 500 mililitre seçenekleri ayrı stok kalemleridir. Kanalın gruplama alanı yanlış kullanılırsa aynı ürün gibi görünebilirler. Aktarım öncesi küçük bir aileyle deneme yapın. Seçenek isimleri, görseller, fiyat ve siparişe giren kimlik kontrol edilir. Pazaryeri entegrasyonu geliştirmede yalnızca bütün ürünlerin görünmesi değil doğru seçenek ilişkisinin korunması hedeflenmelidir. Bir ürün ailesinin kabulü bütün katalog örneklerinin doğrulandığını göstermez.

Kategori ve özellik eşleştirmesini ayrı katman kurun

İç mağazanın kategorileri kanalın kategori yapısıyla aynı olmayabilir. Bir iç kategori birden fazla dış karşılık gerektirebilir veya bazı ürünler ayrı değerlendirme isteyebilir. Gerekli özellikler de kategoriye göre değişebilir. Ürünün doğru sınıfta bulunması, alanların doğru anlamda aktarılmasıyla birlikte ele alınmalıdır.

Özellik adı benzerliği yeterli olmayabilir. İçeride kullanılan kapasite değeriyle kanalın beklediği alan, birim veya tanımlı seçenek farklı olabilir. Eşleştirme tablosunda anlam ve dönüşüm kuralı yazılabilir. Bir değer bulunmadığında otomatik tahmin yapmak yerine eksik bilgi süreci oluşturun. Katalog ekibinin düzelteceği veri ile teknik ekibin düzelteceği dönüşüm ayrılmalıdır. Böylece bütün aktarım hataları tek bir “ürün gönderilemedi” mesajı altında kaybolmaz.

Ürün oluşturma ile yayında olma durumunu ayırın

Bir isteğin kabul edilmesi, ürünün müşteriye satışa açıldığını göstermeyebilir. İşlem kuyruğu, alan doğrulaması veya onay aşaması bulunabilir. Kullanılan kanalın gerçek akışı güncel belgelerden öğrenilmelidir. Entegrasyon bu aşamaları izleyebilecek kayıt ve ekran sağlamalıdır.

Toplu gönderimde bazı ürünler başarılı, bazıları sorunlu olabilir. Genel yanıt koduna bakarak bütün paketi tamamlandı saymak hatalıdır. Ürün bazında sonuç ve hata sebebi görülebilmelidir. İşlem referansının hangi iç kayıtlara ait olduğu saklanırsa tekrar deneme daha kontrollü yapılabilir. Belirsiz sonuçta bütün ürünleri yeniden oluşturmak kopya riskini büyütebilir. Oluşturma, güncelleme ve mevcut kaydı yeniden sorgulama farklı işlemler olarak tasarlanmalıdır. Beklenen son durumla karşılaştırma yapılmadan yayın tamamlandı denmemelidir.

Fiyat ve stok yönünü alan bazında belirleyin

Katalog bilgisi bir sistemden, stok başka sistemden gelebilir. Kanal fiyatı için ayrı ticari kural bulunabilir. Her alanın yetkili kaynağı ve güncelleme yönü belirlenmelidir. Bir dış panelde elle yapılan değişikliğin sonraki aktarımda korunup korunmayacağı da açık olmalıdır. Aksi halde ekipler birbirinin işini sürekli geri alabilir.

Fiyatın para birimi, onaylı vergi ve kampanya bağlamı ilgili sorumlularla değerlendirilir. Teknik dönüşüm kuralı ticari kararı sessizce değiştirmemelidir. Stokta ise satılabilir miktarın hangi varyant ve konuma ait olduğu korunmalıdır. Bir ilan başka iç kayda bağlandıktan sonra eski güncelleme işlerinin ne yapacağı düşünülür. Eşleştirme değişikliği yalnızca tablo satırını düzeltmek değildir; bekleyen işlemler ve geçmiş ilişkiler de etkilenebilir.

Sipariş satırının dönüş yolunu doğrulayın

Ürünü dışarıya doğru göndermek işin yarısıdır. Sipariş geldiğinde dış satırın doğru iç varyanta bağlanması gerekir. Depo hangi ürünü hazırlayacağını bu ilişkiye göre görebilir. Sipariş, paket ve satır kimlikleri farklı görevler taşıyabilir. Hangisinin tekrar kontrolünde veya kısmi işlemde kullanılacağı tanımlanmalıdır.

Bir siparişte aynı ürünün birden fazla satırı veya farklı seçenekleri bulunabilir. Sadece genel başlığa bakmak yanlış toplama yaratabilir. Testte alınan satırın kodu, miktarı ve ürün özelliği iç kayıtla karşılaştırılır. Eşleşme yoksa siparişin sessizce yanlış ürünle açılması önlenmelidir. İnceleme yolu ve sorumlu kişi belirlenir. Müşteri iletişimi ve zaman baskısı bu kararı canlıda doğaçlama vermek için gerekçe olmamalıdır.

İptal ve iade ilişkisini ilk günden düşünün

Kısmi iptal veya iade, aynı siparişin bazı satırlarını etkileyebilir. Hangi dış işlemin hangi iç satıra bağlı olduğu bilinmezse stok ve ödeme kaydı karışabilir. Eşleştirme, yalnızca ürün açma anında kullanılan bir yardımcı veri olarak görülmemelidir. İşlem yaşam döngüsü boyunca anlamını korumalıdır.

Ürün kodu sonradan değişmiş olsa bile eski sipariş araştırılabilir kalmalıdır. Geçmiş eşleşmenin nasıl saklanacağı ve hangi değişikliklerin geçmişe uygulanmayacağı değerlendirilir. Ürünün satışa kapatılması ile ilişkili kayıtların silinmesi farklı ihtiyaçlardır. İade edilen fiziksel ürünün kontrolü de ayrı iş akışıdır; dış kanal bildirimi otomatik olarak satılabilir stok anlamına gelmeyebilir. Onaylı operasyon kuralı uygulamada doğru temsil edilmelidir. Her aşamanın sonucu kendi kayıtlarıyla doğrulanır.

Tekrar ve kesinti davranışını ürün bazında sınayın

Ağ kesilince oluşturma veya güncelleme isteği yeniden denenebilir. İlk deneme çalışmış ama yanıt kaybolmuş olabilir. Aynı işin tekrarının kopya ilan veya çift kayıt oluşturmaması için uygun kimlik ve kontrol yöntemi gerekir. Kanalın sunduğu mekanizmalar güncel sürüm üzerinden değerlendirilir.

Hata mesajları geçici ve veri kaynaklı sorunlar olarak ayrılabilir. Geçici kesinti yeniden denemeye uygunken eksik özellik düzeltilmeden tekrar gönderilmesi gereksiz olabilir. İşletme hangi kayıtların beklediğini görebilmelidir. Toplu işte tek sorunlu ürünün diğerlerinin durumunu gizlememesi önemlidir. E-ticaret entegrasyon planında bu durumlar örnek ürün ve kontrollü olaylarla denenebilir. Sorunun bulunması kadar hangi ekibin hangi düzeltmeyi yapacağının anlaşılması da teslim kapsamıdır.

Sürüm değişikliğini bakım sürecine bağlayın

Kanalların teknik alanları, zorunlulukları ve servis sürümleri değişebilir. Bir zamanlar çalışan örnek kod sonraki dönemde geçerli olmayabilir. Entegrasyonun hangi sürüme bağlı olduğu ve duyuruları kimin takip edeceği yazılmalıdır. Başlangıç geliştirmesi bakım ihtiyacını ortadan kaldırmaz.

Değişiklik sonrası temsil edici ürün, güncelleme ve sipariş dönüşü tekrar denenebilir. Özellikle kimlik ve gruplama mantığı etkileniyorsa mevcut eşleştirmeler gözden geçirilir. Güncel teknik belgeyle kontrol edilen kararın tarihi kaydedilebilir. Ancak yalnızca belgeyi okumak uygulamanın yeni akışta çalıştığını kanıtlamaz. Test sonucu ve kalan sınırlamalar birlikte tutulmalıdır. Kanal adı listede göründüğü için bütün özelliklerin kalıcı olarak desteklendiği varsayılmamalıdır.

Küçük bir pilot katalogla eşleştirmeyi onaylayın

Pilot listede tek seçenekli ürün, varyant ailesi, eski mevcut ilan ve eksik özellikli kayıt bulunabilir. Her biri oluşturma, güncelleme ve sipariş dönüşü açısından incelenir. Ürün sayısının iki sistemde aynı görünmesi yeterli değildir. Renk, paket adedi, görsel ve satır kimliği doğru ilişkiye sahip olmalıdır.

Onaylanan eşleşmeler, açık sorunlar ve kapsam dışında kalan ürünler ayrı kaydedilebilir. Büyük aktarım için hangi koşulun tamamlanması gerektiği anlaşılır olur. Başarılı pazaryeri entegrasyonu yalnızca veri akışının kesilmemesi değildir. İşletmenin hangi dış kaydın hangi fiziksel ürüne ve iç işlem geçmişine bağlı olduğunu açıklayabilmesidir. Bu ilişki doğru kurulduğunda stok, sipariş ve müşteri hizmetleri aynı ürünü konuşabilir. Katalog büyüdükçe aynı kontrol düzeni sürdürülmelidir.

Sık Sorulan Sorular

Ürün adları aynıysa otomatik eşleştirebilir miyiz?

Başlık benzerliği aday bulabilir, fakat tek başına kesin ilişki sayılmamalıdır. Varyant, paket ve diğer ayırt edici bilgiler kontrol edilmelidir. Adlar değişebilir; kararlı kimlik ve onaylı eşleştirme kaydı daha sağlam bir yönetim sağlar.

İç SKU ile dış ürün kimliği aynı olmak zorunda mı?

Kanalın ve iç sistemin kurallarına bağlıdır. Farklı kimlikler bir eşleştirme kaydıyla ilişkilendirilebilir. Alanın kapsamı ve benzersizlik koşulları güncel teknik belgelerden doğrulanmalıdır; görünüş benzerliğinden sonuç çıkarılmamalıdır.

Başarılı yanıt bütün ürünlerin yayında olduğunu gösterir mi?

Her akışta böyle değildir. Toplu iş, doğrulama ve onay aşamaları bulunabilir. Ürün bazında son durum kontrol edilmelidir. Genel yanıtla gerçek satışa açıklık farklı aşamalar olabilir; entegrasyon bu farkı görünür tutmalıdır.

Eski ilanları yeni entegrasyonda ne yapmalıyız?

Önce envantere alın ve iç katalogdaki karşılıklarını araştırın. Yok sayıp yeniden oluşturmak kopya veya çelişen güncelleme yaratabilir. Belirsiz kayıtlar inceleme listesinde tutulmalı, otomatik rastgele ilişki kurulmamalıdır.

Eşleştirme değişince geçmiş siparişler etkilenir mi?

Teknik tasarıma göre etkilenebilir; bu nedenle geçmiş ilişki ve yeni yayın ayrı düşünülmelidir. Eski siparişin hangi ürünü temsil ettiği anlaşılır kalmalıdır. Değişikliğin bekleyen işlere ve geçmiş kayıtlara etkisi test edilmelidir.

Pilot testte hangi ürünler bulunmalı?

Tek seçenek, farklı varyantlar, mevcut dış ilan ve eksik verili örnekler yararlı olabilir. Oluşturma kadar güncelleme ve sipariş dönüşü de denenmelidir. Sadece toplam ürün sayısını karşılaştırmak doğru eşleştirmeyi kanıtlamaz.