Ürün eşleştirmesini bir kez yaptığında biten bir iş sanırsın. Tabloyu kurarsın, her vitrin ürününü tedarikçideki karşılığına bağlarsın, satışlar akmaya başlar. Haftalar boyunca hiçbir şey olmaz. Sonra bir sabah destek kutunda "yanlış ürün geldi" mesajları birikir, muhasebe raporunda bir kategorinin marjı eksiye düşmüştür ve kimse ne değiştiğini hatırlamaz. Değişen şey senin tarafında değildir; tedarikçi tarafında bir kod güncellenmiştir.
SKU eşleştirmesi statik bir veri değil, iki sistem arasındaki canlı bir anlaşmadır. Karşı taraf o anlaşmanın terimlerini haber vermeden değiştirebilir. Bu yazıda eşleştirmenin hangi teknik nedenlerle bozulduğunu, her birinin vitrinde nasıl bir belirti verdiğini ve bir e-pin scripti üzerinde bunu erken yakalayacak denetim mekanizmasını nasıl kuracağını anlatıyorum. Konu teknik ama sonuçları tamamen ticari: yanlış eşleşen tek bir ürün, günlerce fark edilmeden zarar yazabilir.
Eşleştirme tablosu bozulmaz sanılır, oysa her tedarikçi güncellemesi bir mayındır
Tedarikçiler katalogunu sürekli yeniler: yeni bölge açılır, paket adı düzeltilir, eski ürün arşive alınır, kampanyalı sürüm eklenir. Bu değişikliklerin çoğu sana bildirilmez çünkü karşı taraf için bunlar rutin bakım işleridir. Senin sistemin ise o kataloğu bir sabit gerçek olarak varsayarak çalışır.
Kritik ayrım şudur: eşleştirme kırılırsa fark edilir, çünkü ürün hata verir. Eşleştirme kayarsa fark edilmez, çünkü sistem çalışmaya devam eder, sadece yanlış ürünü yanlış fiyattan satar. Bir dijital ürün satış scripti tasarlarken hedef kırılmayı önlemek değil, kaymayı görünür kılmaktır.
Kimlik olarak isim kullanmak: en yaygın ve en pahalı hata
Eşlemeyi ürün adına göre kuranların hepsi aynı duvara çarpar. Tedarikçi "Free Fire 100 Elmas" adını "Free Fire 100 + 10 Elmas" yapar. Senin sistemin eski adı bulamaz; ya ürünü pasife alır ya da benzerlik puanı en yüksek başka bir kalemle eşleştirir. İkinci senaryo çok daha kötüdür: 100 elmaslık ürün, 310 elmaslık paketin maliyetiyle eşleşir ya da tersi olur.
Çözüm basit ama disiplin ister: eşlemeyi her zaman tedarikçinin döndürdüğü değişmez kimlik alanına (ürün kodu, kalem numarası, benzersiz referans) bağla. Ad yalnızca insanın kontrol etmesi için referans olarak saklanır, hiçbir zaman anahtar olarak kullanılmaz. İyi bir e-pin yazılımı bu ayrımı veri modelinde zorunlu kılar; kullanıcıya adla eşleme seçeneği bile sunmaz.
| Bozulma nedeni | Vitrindeki belirti | Ticari etki | Kalıcı çözüm |
|---|---|---|---|
| İsim bazlı eşleme | Ürün pasife düşer veya yanlış fiyat | Yüksek: sessiz marj kaybı | Değişmez kimlikle eşleme |
| Tedarikçi kodu değişimi | Sipariş "ürün bulunamadı" hatası | Orta: satış kaybı, görünür | Bilinmeyen kod alarmı |
| Silinip yeniden eklenen ürün | Aynı ürün iki kayıt | Orta: stok ve fiyat çelişkisi | Arşiv durumu takibi |
| Çoklu tedarikçi çakışması | Fiyat gün içinde zıplar | Yüksek: güven kaybı | Öncelik sırası kuralı |
| Varyant ve bölge karışması | Teslim edilen kod işe yaramaz | Çok yüksek: iade ve şikâyet | Bölge alanının zorunlu olması |
| Para birimi kayması | Fiyat aşırı düşük veya yüksek | Yüksek: anlık zarar | Sapma eşiği ve taban fiyat |
Silinen ve yeniden doğan ürün kodları nasıl çift kayıt üretir?
Tedarikçi bir ürünü arşive alır, iki hafta sonra aynı ürünü yeni bir kodla geri koyar. Senin tarafında artık iki kalem vardır: eskisi eşleşmiş ama artık yanıt vermiyor, yenisi eşleşmemiş ama çalışıyor. Senkronizasyon çalıştığında sistem yeni kalemi "yeni ürün" olarak vitrine ekler ve müşteri aynı paketi iki farklı fiyatla görür.
Bunun önüne geçmek için eşleme tablonda ürün durumunu da tutman gerekir: aktif, arşiv, yanıt vermiyor. Bir ürün üst üste belirlediğin sayıda senkronda yanıt vermiyorsa otomatik olarak satıştan çekilir ve bir görev olarak önüne düşer. Yeni gelen kalemler ise doğrudan vitrine değil, onay kuyruğuna girer. Bu iki kural, çift kayıt sorununun neredeyse tamamını kapatır.
Eşleştirme bozulmalarının kök neden dağılımı
- Ad veya benzerlik bazlı eşleme 45%
- Tedarikçi kod ve durum değişimi 25%
- Varyant, bölge ve dil farkları 20%
- Çoklu tedarikçi öncelik çakışması 10%
Çoklu tedarikçi, aynı ürün: öncelik sırası yazılmazsa ne olur?
Aynı e-pini iki farklı tedarikçiden alıyorsan, vitrin ürününün birden fazla eşleme kaydı olur. Bu iyi bir şeydir; biri stok verince diğeri devreye girer. Ama öncelik kuralı yazılmamışsa iki tedarikçinin fiyatı gün içinde birbirini ezer ve müşteri aynı ürünü sabah bir, akşam başka bir fiyattan görür.
İhtiyacın olan şey net bir karar sırası: önce hangi tedarikçi denenecek, fiyat hangisinden alınacak, stok yoksa ne kadar süre sonra ikinciye geçilecek. Pratikte en sağlıklı yaklaşım fiyatı birincil tedarikçiden almak, teslimatı ise stok durumuna göre dinamik seçmektir. Böylece vitrin fiyatı kararlı kalır, arka tarafta esneklik korunur. Bu mantığın nasıl kurulduğuna özellikler bölümünden bakabilirsin.
Varyant, bölge ve dil farkları en pahalı yanlış teslimatı yaratır
Bir oyun anahtarının Türkiye bölgesi ile global bölgesi teknik olarak aynı ürün gibi görünür; adı da neredeyse aynıdır. Ama yanlış bölgeden teslim edilen kod müşterinin hesabında çalışmaz. Bu tür hata fiyat hatasından daha maliyetlidir çünkü hem iade hem itibar kaybı üretir, çoğu zaman ödeme sağlayıcısı tarafında da iz bırakır.
Bunun tek çözümü bölgeyi ve varyantı ayrı ve zorunlu alanlar yapmaktır. Eşleme ekranında bölge boş bırakılamaz, farklı bölgeler asla aynı vitrin ürününe bağlanamaz. Sıkı görünür ama bir kez kurulduğunda bu sınıf hataları tamamen ortadan kaldırır. İyi kurgulanmış bir e-pin satış yazılımı, kullanıcı hata yapmak istese bile bu eşlemeyi kaydetmez.
Her sabah tek bir ekranda şunları gör: yanıt vermeyen tedarikçi kodları, eşleşmemiş yeni kalemler, marjı eşiğin altına düşen ürünler ve bölgesi boş kayıtlar. Bu dört satır, hataları müşteriden önce senin görmeni sağlar.
Bozulmayı erken yakalayan denetim mekanizması nasıl çalışır?
Önleme kadar tespit de önemlidir çünkü hiçbir kural bütün senaryoları kapatmaz. Etkili bir denetim üç ayaklıdır. Birincisi tutarlılık kontrolü: her vitrin ürününün en az bir aktif eşlemesi var mı, her eşleme geçerli bir kimliğe mi bakıyor? İkincisi marj kontrolü: satış fiyatı ile güncel maliyet arasındaki fark tanımlı aralıkta mı? Üçüncüsü davranış kontrolü: bir ürünün satış hacmi veya iade oranı normalden ciddi şekilde saptı mı?
Üçüncüsü en az bilinen ama en güçlü sinyaldir. Yanlış eşleşen bir ürün genellikle ya aşırı satar (çünkü yanlışlıkla çok ucuzdur) ya da hiç satmaz (çünkü yanlışlıkla çok pahalıdır). Satış hacmindeki ani sapmayı izleyen basit bir uyarı, fiyat hatasını muhasebeden günler önce yakalar. Bu üç kontrolü otomatik çalıştıran bir epin yazılım katmanı, eşleme bakımını haftalık on dakikalık bir işe indirir.
| Kontrol | Sıklık | Uyarı eşiği | Aksiyon |
|---|---|---|---|
| Eşlemesi olmayan vitrin ürünü | Günlük | 1 adet | Satıştan çek |
| Yanıt vermeyen tedarikçi kodu | Her senkron | 3 ardışık başarısız | Pasife al, göreve düşür |
| Eşleşmemiş yeni kalem | Günlük | 1 adet | Onay kuyruğuna al |
| Marj alt sınırı | Her fiyat güncelleme | Tanımlı taban altı | Fiyatı yazma, onaya düşür |
| Fiyat sapması | Her fiyat güncelleme | %25 üzeri değişim | Manuel onay bekle |
| Bölge alanı boş | Kayıt anında | 1 adet | Kaydı reddet |
| Satış hacmi sapması | Günlük | Ortalamanın 3 katı | Eşlemeyi denetle |
| İade oranı | Haftalık | Kategori ortalaması üstü | Varyant kontrolü |
Eşleme hatalarını müşteriden önce gören bir altyapı kur
Değişmez kimlikle eşleme, zorunlu bölge alanı, onay kuyruğu ve günlük sağlık raporu bir arada çalıştığında yanlış teslimat ve sessiz marj kaybı büyük ölçüde ortadan kalkar. Pinova'nın eşleme ve denetim katmanını kendi kataloğunla test edebilirsin.
SKU eşleştirmesi neden kendiliğinden bozulur?
Bozulmanın kaynağı genellikle senin tarafın değil, tedarikçinin katalog bakımıdır. Ürün adı değişir, kod yenilenir veya kalem arşive alınır; isim bazlı eşleme kuran sistemler bu değişiklikleri sessizce yanlış bağlantıya çevirir.
Eşlemeyi ürün adı yerine neye bağlamalıyım?
Tedarikçinin döndürdüğü değişmez ürün kimliğine bağlamalısın. Ad yalnızca insan denetimi için referans olarak saklanmalı, hiçbir zaman eşleme anahtarı olarak kullanılmamalıdır.
Aynı ürünü birden fazla tedarikçiden alırsam fiyat neden oynar?
Öncelik sırası tanımlanmadığında her senkron farklı tedarikçinin fiyatını yazar. Fiyatı tek bir birincil tedarikçiden almak, teslimatı ise stok durumuna göre seçmek fiyatı kararlı tutar.
Yanlış bölgeden teslimatı nasıl tamamen engellerim?
Bölge ve varyantı ayrı, zorunlu alanlar yaparak. Farklı bölgelerin aynı vitrin ürününe bağlanmasını sistem düzeyinde engellediğinde bu hata sınıfı tümüyle ortadan kalkar.
Eşleştirme bakımı, dijital ürün satışında görünmeyen ama en belirleyici işlerden biridir. Kimliğe dayalı eşleme, zorunlu bölge alanı, onay kuyruğu ve günlük sağlık raporu kurulduğunda tedarikçi tarafındaki değişiklikler artık seni gafil avlamaz. Bu yapıyı sıfırdan kodlamak yerine hazır bir katman üzerinde görmek istersen, eşleme ekranlarını ve denetim raporlarını canlı demo içinde inceleyebilir, kapsam ve paket farklarını fiyat bölümünde karşılaştırabilirsin.

