Pazaryeri entegrasyonu, ürün, stok, fiyat ve sipariş bilgilerinin farklı sistemler arasında tutarlı biçimde aktarılmasını sağlar. Bir bağlantının kurulması sürecin tamamlandığı anlamına gelmez. Hangi sistemin hangi bilgide kaynak olduğu, hataların nasıl görüleceği ve aynı işlemin tekrar gelince ne olacağı belirlenmelidir.
Bu rehber, kendi sitesi ve bir veya daha fazla pazaryeri arasında veri akışı kuracak işletmeler için hazırlık ve test sırası sunar. Platformların alanları ve API kuralları değişebileceğinden teknik uygulama güncel sağlayıcı dokümanıyla doğrulanmalıdır. Amaç bütün platformlara tek reçete vermek değil, entegrasyonun güvenilir çalışması için gerekli kararları açıklamaktır.
1. Mevcut operasyonu haritalayın
Ürünler nerede açılıyor, stok nerede tutuluyor, fiyatı kim değiştiriyor ve siparişler hangi ekranda hazırlanıyor? Önce mevcut akış yazılır. Muhasebe, depo ve müşteri hizmetleri ekiplerinin kullandığı araçlar listelenir. Görünmeyen Excel dosyaları veya elle yapılan işler de kapsama alınır.
Bu çalışma sırasında aynı bilginin birden fazla yerde bağımsız değiştirildiği noktalar bulunur. Örneğin site stokları panelden, pazaryeri stokları elle güncelleniyorsa tutarsızlık riski vardır. Entegrasyonun amacı yalnızca veri taşımak değil, hangi bilginin nereden yönetileceğini netleştirmektir.
2. Her veri için ana kaynak belirleyin
Stok için depo sistemi, ürün açıklaması için katalog yönetimi, fiyat için ticari yönetim ekranı kaynak olabilir. Tek bir sistem bütün alanlarda kaynak olmak zorunda değildir. Ancak her alanın sorumlusu belli olmalıdır. İki yönlü güncelleme varsa çakışma kuralı tanımlanır.
Örneğin pazaryerinde elle değiştirilen fiyat sonraki eşitlemede geri dönecek mi? Kullanıcı bunu bilmezse sistem hatası sanabilir. Kural arayüzde ve kullanım notunda açıklanır. Geçici kampanya fiyatları ve platforma özgü açıklamalar için ayrı alanlar gerekebilir.
3. Ürün kimliklerini temizleyin
Ürün adı güvenilir benzersiz kimlik değildir. Aynı isimle farklı ürünler veya farklı yazımla aynı ürün bulunabilir. SKU, barkod veya sistem kimliği gibi alanların nasıl kullanılacağı belirlenir. Yinelenen ve boş değerler aktarım öncesi incelenir.
Eski katalogdan taşınan kayıtlar özellikle kontrol edilir. Kimliği değişen ürünün yeni ürün olarak açılması geçmiş ilişkileri bozabilir. Eşleştirme tablosu saklanır. Hangi yerel kaydın hangi platform kaydına karşılık geldiği gerektiğinde araştırılabilmelidir.
4. Varyantları ayrı test edin
Varyant yapısı renk, beden ve diğer seçenekleri doğru ayırmalıdır. Ana ürün ile satılabilir seçenek aynı kayıt gibi ele alınmamalıdır. Stok ve fiyatın hangi düzeyde tutulduğu belirlenir. Platformların varyant gruplama kuralları farklı olabilir.
Örnek testte bir ürünün tek seçeneği tükenir. Diğer seçeneklerin satışta kaldığı ve tükenen varyantın kapandığı doğrulanır. Görselin doğru seçeneğe bağlandığı kontrol edilir. Bir ürünün bütün seçenekleriyle aktarılması, katalog testinin temel senaryolarından biridir.
5. Kategori ve özellik eşleştirmesini hazırlayın
Yerel kategori ile pazaryeri kategorisi birebir aynı olmayabilir. Zorunlu özellikler ve değer seçenekleri incelenir. Ürünü yanlış kategoriye gönderip bütün hataları metinle çözmeye çalışmak doğru değildir. Kategori eşleştirmeleri işletmenin ürün bilgisiyle birlikte yapılır.
Boyut, malzeme veya teknik özellik gibi alanlar tutarlı biçimde saklanmalıdır. Serbest metinden her seferinde tahmin yapmak hataya açıktır. Eksik alanlar aktarım öncesi raporlanabilir. Böylece yüzlerce ürünün reddedilmesinden sonra tek tek düzeltme yapmak yerine kaynak veri iyileştirilir.
6. Görsel ve açıklama standartlarını belirleyin
Platformların görsel boyutu, arka plan veya içerik kuralları güncel dokümandan kontrol edilir. Kullanım hakkı olmayan fotoğraflar taşınmaz. Ürün açıklamasındaki HTML veya özel karakterlerin hedef sistemde nasıl işlendiği denenir. Siteye uygun düzen pazaryerinde aynı görünmeyebilir.
Ürün özellikleri ile pazarlama metni ayrılabilir. Zorunlu teknik alanlar açıklamanın içine gömülüp bırakılmamalıdır. Kaynak içerik düzenli olduğunda farklı kanallara uyarlama kolaylaşır. Ürün feed'i mantığı bu yapılandırılmış aktarımı açıklar.
7. Stok güncelleme kuralını seçin
Stok hangi olayda düşecek, iptal veya iade olduğunda ne zaman geri eklenecek? Sipariş alınması ile ödeme veya sevkiyat aşaması farklı olabilir. İşletmenin operasyonuna uygun kural belirlenir. Aynı ürün birden fazla kanalda satılıyorsa gecikme etkisi düşünülür.
Güvenlik stoğu gibi ticari kararlar gerekiyorsa açıkça tanımlanır. Entegrasyonun belirli aralıkla çalışması, her an tam eşzamanlılık anlamına gelmez. Güncelleme sıklığı ve kapasite gerçek koşullara göre seçilir. Tükenen ürünün yanlış satışta kalması müşteri deneyimini ve operasyonu bozabilir.
8. Fiyat ve kampanya kurallarını ayırın
Platform komisyonu, kargo ve kampanya koşulları farklı olabilir. Her kanala aynı fiyatı göndermek işletmenin bilinçli kararı olmalıdır. Fiyat hesaplama kuralı varsa yuvarlama, vergi ve indirim sırası açıklanır. Kaynak fiyat ile gönderilen fiyatın nasıl oluştuğu izlenebilmelidir.
Yanlışlıkla çok düşük fiyat gönderilmesini önlemek için makul kontrol sınırları düşünülebilir. Büyük toplu değişiklikler örnek ürünlerde önizlenir. Kampanya bitişinde hangi fiyatın geri geleceği belirlenir. Buy Box rekabeti değerlendirilirken yalnızca fiyat değil toplam katkı dikkate alınır.
9. Sipariş aktarımını tekrara dayanıklı kurun
Aynı sipariş bildirimi birden fazla kez gelebilir. Sistem bunu yeni sipariş gibi işlememelidir. Platform sipariş kimliği ile yerel kayıt ilişkisi korunur. Tekrar denemeler güvenilir biçimde ele alınır. Ağ kesintisi, işlemin hiç yapılmadığı anlamına gelmeyebilir.
Testte aynı sipariş iki kez alınır ve tek kayıt oluştuğu doğrulanır. Ürün, varyant, adet, adres ve tutar alanları kontrol edilir. Eksik bilgi geldiğinde kayıt sessizce kaybolmamalıdır. İncelenecek hata veya bekleme durumu oluşmalıdır.
10. Sipariş durumlarını eşleştirin
Yeni, hazırlanıyor, kargoya verildi, teslim edildi ve iptal gibi durumlar sistemler arasında farklı adlandırılabilir. Eşleştirme tablosu hazırlanır. Hangi durumun hangi işlemi tetiklediği belirtilir. Geriye dönük veya beklenmedik durum değişiklikleri düşünülür.
Örneğin iptal edilen siparişin kargoya hazırlanması önlenmelidir. Kısmi iptal veya kısmi gönderi varsa ayrı senaryolar gerekir. Bütün siparişi tek durumda tutmak bazı operasyonlarda yetersiz olabilir. İşletmenin gerçekten kullandığı akışlar test kapsamına alınır.
11. Kargo ve paket bilgilerini doğrulayın
Kargo firması, takip numarası ve gönderi etiketi akışı belirlenir. Ürün ölçüsü ile gönderime hazır paket ölçüsü farklı olabilir. Desi ve ağırlık bilgileri taşıyıcının kurallarına göre değerlendirilir. Yanlış veri maliyet ve teslimat sorunlarına yol açabilir.
Birden fazla ürünün tek pakette veya ayrı paketlerde gönderilmesi düşünülür. Takip bilgisinin doğru kanala ulaştığı test edilir. Kullanıcıya yanlış veya boş numara gönderilmemelidir. İptal edilen etiketlerin ve tekrar oluşturulan gönderilerin ilişkisi korunur.
12. Fatura ve iade süreçlerini bağlayın
Fatura tetikleyicisi işletmenin mali süreçlerine göre belirlenir. Ödeme veya sipariş durumuyla ilişki kurulurken mali müşavir ve kullanılan e-belge sistemi dikkate alınır. E-Arşiv Fatura ile ilgili güncel gereklilikler resmi kaynaklardan doğrulanır.
İade ve iptaller yalnızca stok ekleme işlemi değildir. Ödeme, belge ve sipariş durumu birlikte ele alınır. Kısmi iade senaryoları varsa hangi satırların etkilendiği doğru tutulmalıdır. Aynı iadenin tekrar aktarılması çift işleme yol açmamalıdır.
13. API erişimi ve hata yönetimini düzenleyin
Erişim anahtarları güvenli saklanır ve gerekli yetkiyle sınırlandırılır. Loglarda gizli bilgiler açıkça yazılmamalıdır. Anahtar yenileme ve yetki değişikliği için sorumlu belirlenir. Test ve canlı ortam bilgileri karıştırılmaz.
İstek sınırları, zaman aşımı ve yeniden deneme davranışı güncel platform dokümanına göre uygulanır. Hata olduğunda sınırsız hızlı tekrar yapmak sorunu büyütebilir. Geçici hata ile veri hatası ayrılır. Eksik kategori alanını tekrar tekrar göndermek yerine düzeltme gerektiren kayıt olarak işaretlemek daha anlamlıdır.
14. Pilot ürünlerle başlayın
Bütün kataloğu ilk anda aktarmak yerine farklı senaryoları temsil eden küçük grup seçilir. Basit ürün, varyantlı ürün, indirimli ürün ve stok dışı ürün örnekleri bulunabilir. Başlık, görsel, fiyat ve stok görünümü gerçek platformda kontrol edilir.
Pilot sipariş akışı da denenir. İptal, iade ve kargo bildirimi test edilir. Sorunlar düzeltilmeden toplu aktarım büyütülmez. Pilotun amacı yalnızca bağlantının çalıştığını göstermek değil, işletmenin gerçek veri çeşitliliğini sınamaktır.
15. İzleme ekranı ve günlük kontrol oluşturun
Son başarılı eşitleme, hata sayısı ve bekleyen kayıtlar görülebilmelidir. Entegrasyonun sessizce durması en zor fark edilen sorunlardan biridir. Uyarıların kime gideceği ve hangi durumda müdahale gerektiği belirlenir. Her küçük geçici hata için gereksiz bildirim yağmuru oluşturulmaz.
Günlük kontrolde sipariş sayıları ve kritik stok farkları karşılaştırılabilir. Fiyat değişiklikleri ve reddedilen ürünler incelenir. Kayıtların araştırılabilmesi için işlem kimlikleri korunur. İzleme, yalnızca geliştiricinin erişebildiği teknik loglardan ibaret olmamalıdır; operasyon ekibi temel durumu anlayabilmelidir.
16. Toplu geçiş ve geri dönüş planı
Kaynak katalog ve eşleştirme kayıtları yedeklenir. Toplu aktarım zamanı operasyonla koordine edilir. Eski elle güncelleme yöntemiyle yeni otomatik sistemin aynı anda çelişkili işlem yapması önlenir. Hangi anda hangi sistemin kaynak olacağı açıkça duyurulur.
Sorun halinde hangi akışın durdurulacağı ve kayıtların nasıl uzlaştırılacağı belirlenir. Entegrasyonu kapatmak, yapılmış sipariş veya fiyat değişikliklerini otomatik geri almaz. Geri dönüş planı veri etkisini de düşünmelidir. İlk günlerde kontrol sıklığı artırılır, sistem oturduğunda sürdürülebilir düzene geçilir.
Örnek sorun çözümü: Stoklar neden geri geliyor?
Varsayımsal bir işletmede pazaryeri panelinden stok sıfırlanıyor, birkaç dakika sonra tekrar beşe dönüyor olsun. Entegrasyonun ana kaynak olarak depo sistemindeki beş adedi gönderdiği anlaşılır. Bu durumda sorun bağlantının bozuk olması değil, kaynak kuralının kullanıcı tarafından bilinmemesidir. Stok düzeltmesi doğru kaynakta yapılmalıdır.
Başka bir senaryoda aynı sipariş iki kez stok düşürüyor olabilir. Burada sipariş kimliğiyle tekrar kontrolü incelenir. İki sorun aynı “stok yanlış” belirtisini üretse de çözümü farklıdır. Bu yüzden işlem geçmişi ve kaynak ilişkisi görünür olmalıdır. Tahminle elle düzeltmek geçici rahatlama sağlar ama kök nedeni çözmez.
Entegrasyon tesliminde bu örnekler operasyon ekibiyle denenebilir. Kullanıcı hangi alanı nerede değiştireceğini ve hata gördüğünde hangi bilgiyi paylaşacağını öğrenir. Sağlam entegrasyon yalnızca kod bağlantısı değil, veri sorumluluğu ve günlük çalışma düzenidir.
