Ürün Bilgi Yönetimi (PIM) Nedir?

Product Information Management (PIM), Türkçesiyle Ürün Bilgi Yönetimi; ürün bilgisini farklı kaynaklardan alan, ortak bir veri modelinde doğrulayan, zenginleştiren, onaylayan, sürümleyen ve e-ticaret sitesi ile satış kanallarına kontrollü biçimde dağıtan süreç, yönetişim modeli ve yazılım yeteneğidir. PIM’in değeri yalnız “tek ekran” değildir; alan sahipliği, kalite kuralları, izlenebilirlik ve kanal sözleşmeleriyle güvenilir katalog üretme disiplinidir.

Bir PIM bütün ürün verisinin tek fiziksel veritabanı olmak zorunda değildir. Açıklama ve teknik nitelik PIM’de, maliyet ERP’de, kullanılabilir stok WMS veya stok servisinde, fiyat bir fiyat motorunda, asıl görsel dosyası DAM’de yetkili olabilir. “Tek doğruluk kaynağı” ifadesi bu nedenle ürün kaydı düzeyinde değil, alan ve olay düzeyinde tanımlanmalıdır.

PIM nedir ve e-ticarette ne işe yarar?

PIM, ham ürün kaydını kanala hazır, kanıtlanabilir ve yönetilebilir ürün bilgisine dönüştüren omurgadır. Kaynaktan gelen alanı kanonik modele eşler; birimi ve sözlüğü standartlaştırır; eksik, çelişkili veya geçersiz değeri ayırır; görev ve onay akışını işletir; ardından her kanalın kategori, nitelik, dil ve format sözleşmesine göre yayınlar. Sonuç, otomatik başarı garantisi değil, ölçülebilir ve geri alınabilir bir bilgi üretim sürecidir.

Katman	Temel soru	PIM’in rolü	Kanıt
Model	Hangi varlık ve alanlar var?	Aile, model, varyant, nitelik, ilişki ve kapsam şemasını yönetir.	Sürüm kontrollü veri sözlüğü
Sahiplik	Kim hangi alanı değiştirebilir?	Owner, steward, editör ve onaylayıcı sorumluluğunu uygular.	RACI ve audit trail
Kalite	Yayın için hangi koşullar gerekir?	Tamlık, geçerlilik, tutarlılık ve güncellik kurallarını çalıştırır.	Kural sonucu ve istisna kaydı
Dağıtım	Hangi sürüm hangi kanala gitti?	Eşleme, dönüşüm, yayın, geri çekme ve mutabakatı izler.	Yayın kimliği ve geri okuma

Her işletmenin ayrı bir PIM sistemine ihtiyacı var mı?

Hayır; ayrı PIM ihtiyacı rastgele bir SKU eşiğiyle belirlenmez. Tek mağaza, az varyant, sınırlı değişiklik, tek dil ve küçük ekipte e-ticaret platformunun yerleşik katalog yönetimi yeterli olabilir. İhtiyaç; ürün ailesi karmaşıklığı, kaynak ve kanal sayısı, ülke ve dil kapsamı, değişiklik sıklığı, onay derinliği, hata maliyeti, mevzuat kanıtı ve pazara çıkış süresinin birlikte değerlendirilmesiyle ortaya çıkar.

Sinyal	Yerleşik katalog yeterli olabilir	Ayrı PIM değerlendirilir	Karar kanıtı
Model	Az aile, basit varyant	Çok seviyeli aile ve ilişki	Temsili katalog örneği
Kaynak	Bir ekip, bir ana kaynak	Çok tedarikçi ve çelişen değer	Kaynak envanteri
Kanal	Tek site, tek dil	Çok pazar, dil ve override	Kanal-alan matrisi
Yönetişim	Tek editör, basit kontrol	Görev ayrılığı ve çok kademeli onay	Workflow senaryosu
Risk	Düşük hata etkisi	Güvenlik, mevzuat veya lansman riski	Risk ve kontrol kataloğu

Ürünü ilk kez satışa hazırlama adımları için ürün hazırlama sürecinin temel rehberi ayrı bir operasyon katmanını açıklar. PIM kararı ise aynı işlerin yüzlerce aile, kanal ve sorumluyla nasıl kurala bağlanacağını sorgular.

PIM diğer e-ticaret sistemlerinden nasıl ayrılır?

PIM; ERP, MDM, DAM, PLM, PDM, CMS, PXM, OMS, WMS ve feed yönetiminin eş anlamlısı değildir. Sistem sınırı ürün veya ekran adına göre değil, yetkili alan ve iş olayına göre çizilir. Örneğin ürün adı PIM’de onaylanırken maliyet ERP’de, görsel hakkı DAM’de, sipariş durumu OMS’de, raf hareketi WMS’de kalabilir; entegrasyon bunları ortak kimlik ve sürümle bağlar.

Sistem	Birincil amaç	PIM ile temas	PIM’in devralmaması gereken tipik iş
ERP	Finansal ve ticari kayıtlar	Ürün kimliği, vergi, maliyet veya tedarik alanları	Muhasebe kaydı ve finansal kapanış
MDM	Kurumsal ana veri yönetişimi	Ürün tarafında kurumsal kimlik ve referans veri	Müşteri, tedarikçi ve tüm etki alanlarını tek başına yönetmek
DAM	Dijital varlık, hak ve rendition	Ürün-varlık ilişkisi ve yayın uygunluğu	Asıl dosya işleme ve hak yaşam döngüsü
PLM/PDM	Tasarım ve mühendislik yaşam döngüsü	Onaylı teknik özelliklerin ticari dile aktarımı	CAD, BOM ve mühendislik değişikliği
CMS	Sayfa ve editoryal içerik	Ürün içeriğini sayfa şablonunda sunma	Kanonik ürün şeması ve varyant kimliği
PXM	Bağlamsal ürün deneyimi	PIM verisini hedef kitle ve kanala uyarlama	Temel kimlik ve kalite disiplinini atlamak
OMS	Sipariş orkestrasyonu	Satılabilir ürün referansı	Sipariş yönlendirme ve durum yönetimi

Alan ve olay sahipliğinin ayrıntılı tasarımı için ERP ile e-ticaret veri akışı; sipariş tarafı için OMS sorumluluk sınırı; fiziksel operasyon için WMS ve depo yürütme çerçevesi tamamlayıcıdır.

Ürün, model, varyant ve SKU nasıl modellenir?

Sağlam bir PIM modeli ürün ailesini ortak nitelik şeması, ürün modelini ticari kavram, varyantı satılabilir seçeneği ve SKU’yu işletme içi stok tutma birimini ayrı tanımlar. Parent kayıt kimi platformda yalnız gruplama düğümüdür ve satılamaz; başka bir platformda ayrı kayıt olabilir. Renk veya beden gibi bir özellik de ancak satılabilirliği gerçekten ayıran iş kuralı varsa varyant eksenidir.

Varlık	Anlam	Örnek	Kritik kural
Ürün ailesi	Ortak nitelik ve zorunluluk seti	Dizüstü bilgisayar	Kategoriyle aynı olmak zorunda değildir.
Ürün modeli	Pazarlanan temel ürün kavramı	X200 serisi	Satılabilir olup olmadığı sözleşmede yazılır.
Parent ürün	Varyantları gruplayan kayıt	X200	Her zaman SKU veya stok kaydı değildir.
Varyant	Seçenek kombinasyonuyla ayrılan ürün	X200, 16 GB, gri	Eksenler kontrollü değer kullanır.
Satılabilir SKU	İşletme içi ticari/operasyonel kimlik	X200-16-GRY	Kararlı, benzersiz ve yeniden atanmayan politika gerekir.

İlişki	Varyanttan farkı	Modelleme	Kanal riski
Bundle/set	Birden çok bileşenin ticari birleşimi	Bileşen kimliği, adet ve geçerlilik	Kanaldaki set desteği farklı olabilir.
Kit	Operasyonel olarak birlikte hazırlanan bileşen	BOM veya kit bileşimiyle bağlantı	Stok hesabı PIM’in işi olmayabilir.
Multipack	Aynı ürünün belirli adette paketi	Paket adedi ve ayrı ticari kimlik	GTIN ve fiyat semantiği doğrulanmalıdır.
Related product	Satılabilirliği ayırmayan ilişki	Aksesuar, alternatif, tamamlayıcı	İlişki türü kanal alanına dönüşür.

Product, Offer ve Inventory neden ayrı tutulmalıdır?

Product ürünün ne olduğunu, Offer belirli satıcının hangi koşullarla sunduğunu, Inventory ise belirli konum veya havuzdaki mevcutluk durumunu anlatır. Aynı ürünün farklı satıcı, para birimi, fiyat, teslimat ve stok kayıtları olabilir. Bu ayrım yapılmazsa açıklama değişikliği fiyat olayına, varyant düzeltmesi stok kaydına veya kanal teklifi ana ürüne yanlışlıkla yazılabilir.

Alan örneği	Product	Offer	Inventory	Tipik yetkili kaynak
Malzeme	Evet	Hayır	Hayır	PIM/PLM
Satış fiyatı	Hayır	Evet	Hayır	ERP/fiyat motoru
Satıcı	Hayır	Evet	Hayır	Ticari sistem
Depo bakiyesi	Hayır	Hayır	Evet	WMS/ERP
Pazarlanabilir başlık	Evet	Kanal override olabilir	Hayır	PIM

Fiziksel ve satılabilir stok ayrımı için e-ticarette stok yönetimi ilkeleri, kanal gecikmeleri için stok ve fiyat senkronizasyonu rehberi kullanılmalıdır.

SKU, GTIN, EAN, UPC, MPN ve kanal kimlikleri nasıl ayrılır?

SKU işletmenin kendi kimliğidir; GTIN, GS1 sistemi içindeki ticari ürün kimliğidir; EAN ve UPC terimleri barkod/numaralandırma ailesi bağlamında kullanılır ve GTIN ile gelişigüzel eş anlamlı sayılmamalıdır. MPN üreticinin parça numarasıdır. Parent SKU, Google id, item_group_id ve marka alanı farklı kapsam ve otoritelere sahiptir; PIM bunları birebir kopyalamak yerine açık dönüşüm sözleşmeleriyle eşler.

GS1’in güncel kuralları için GS1 General Specifications 26.0 ve GS1 GTIN resmî açıklaması birincil kaynaktır.

Taksonomi, kategori, aile, koleksiyon ve faset farkı nedir?

Taksonomi kavramları hiyerarşi ve ilişki içinde sınıflandırır; kategori gezinme veya kanal sınıflandırması sağlar; ürün ailesi ortak özellik şemasını belirler; koleksiyon editoryal veya dönemsel gruplama, etiket esnek işaretleme, faset ise filtrelenebilir boyuttur. Bunları tek bir ağaçta zorla birleştirmek zorunlu alanları, navigasyonu ve kanal eşlemelerini birbirine bağımlı hâle getirir.

Kanonik ürün veri modeli nasıl kurulur?

Kanonik model, her kaynağın veya kanalın alanlarını kopyalayan en büyük tablo değildir; işletmenin kararlı ürün anlamlarını, kimliklerini, veri tiplerini, birimlerini, kapsamlarını ve ilişkilerini tanımlayan ortak sözleşmedir. Kaynak alanları bu modele alınır, kanal alanları modelden türetilir. Model; miras, override, fallback, null semantiği, doğrulama ve sürüm değişikliği kurallarını birlikte içermelidir.

Alan bazlı source of truth matrisi nasıl hazırlanır?

Source of truth matrisi, her alanın yetkili kaynağını, yazma yönünü, güncelleme olayını, çatışma kuralını, beklenen tazeliği ve kanıtını tanımlar. “PIM bütün ürün verisinin sahibi” veya “son yazan kazanır” genellemeleri risklidir. Kritik alanlarda sürüm, kaynak önceliği, onay ve manuel istisna gerekir; aynı alana ERP ile PIM’in kuralsız çift yönlü yazması engellenmelidir.

Tedarikçi verisi PIM’e nasıl alınır ve temizlenir?

XML, CSV, Excel, API veya portal yalnız veri alım katmanıdır; başarılı import ürünün yayına hazır olduğunu göstermez. Önce dosya ve şema profili çıkarılır, kolonlar sürümlenir, kimlikler doğrulanır, alanlar kanonik modele eşlenir, birimler ve sözlükler normalize edilir, kopyalar aday olarak bulunur, survivorship kuralı uygulanır ve sonuç kalite ile onay kapılarına gönderilir.

Kaynak bağlantısının operasyonel ayrıntıları için tedarikçi XML entegrasyonu rehberi incelenebilir; PIM burada bağlantıdan sonraki kalıcı model ve kalite katmanıdır.

Ürün veri kalitesi nasıl ölçülür?

Ürün veri kalitesi tek bir tamlık yüzdesi değildir. Doğruluk değerin gerçeğe uygunluğunu, tamlık gerekli alanların doluluğunu, geçerlilik biçim ve kural uyumunu, tutarlılık alanlar arası çelişkisizliği, güncellik beklenen yaş sınırını, benzersizlik ise gereksiz kopya bulunmamasını ölçer. Bir kayıt yüzde yüz dolu olduğu hâlde yanlış, eski veya mevzuata aykırı olabilir.

Doğrulama, workflow ve yönetişim nasıl tasarlanır?

Doğrulama motoru yalnız “zorunlu alan dolu mu” kontrolü yapmamalıdır; veri tipi, aralık, sözlük, alanlar arası koşul, kimlik benzersizliği, kanıt geçerliliği ve kanal kuralını sürümlü çalıştırmalıdır. Hata şiddeti yayın engeli, uyarı veya bilgilendirme olarak ayrılır. Workflow ise data owner, steward, editör, onaylayıcı ve entegrasyon sahibini görev ayrılığı ve dört göz ilkesiyle bağlar.

PIM ile DAM, görsel ve belge yönetimi nasıl bağlanır?

PIM ürün ile varlık arasındaki ilişkiyi ve kanal için uygunluğu tutabilir; asıl dosya, rendition üretimi, lisans, kullanım bölgesi ve hak süresi çoğu mimaride DAM’in sorumluluğudur. Dosya adı, açı, alt metin, hak sahibi, lisans bitişi ve kanal boyutu ayrı alanlardır. Kullanım kılavuzu, sertifika ve güvenlik belgesi de sürüm, dil, ürün eşleşmesi, geçerlilik ve erişim düzeyiyle yönetilmelidir.

GS1 görsel standardı için GS1 Product Image Specification 4.4, erişilebilir alternatif metin için W3C/WAI görsel rehberi esas alınmalıdır.

Çok dil, ülke, kanal ve override nasıl yönetilir?

Locale dil ve bölgesel biçimi, market ticari/hukuki pazarı, channel yayın hedefini, scope ise değerin hangi kombinasyonda geçerli olduğunu tanımlar. Kanonik değer varsayılan olabilir; kanal veya pazar override’ı yalnız gerekli alanlarda, sahibi ve nedeni kayıtlı biçimde uygulanır. Fallback zinciri eksik çeviriyi görünmezce yanlış dile düşürmemeli; para, ölçü, beden, tarih ve ondalık kuralları açıkça test edilmelidir.

Çok ülke hazırlığında e-ihracata başlangıç çerçevesi ticari bağlamı açıklar; PIM bunun ürün verisi tarafını taşır.

Kanal eşleme ve ürün sendikasyonu nasıl çalışır?

Ürün sendikasyonu, onaylı ürün verisinin hedef kategori ve nitelik sözlüğüne dönüştürülerek teslim edilmesi, hedef sistemde işlenmesi, hata sonucunun alınması, gerektiğinde yeniden denenmesi veya geri çekilmesi ve geri okumayla mutabıklaştırılmasıdır. “Dosya üretildi” veya HTTP 200 yanıtı uçtan uca başarı değildir; accepted, processed ve published durumları ayrı zaman damgaları ve kimliklerle izlenmelidir.

Kanal operasyonunun ayrıntıları toplu ürün aktarımı kontrolünde, çözüm mimarisi pazaryeri entegrasyonu kavramlarında ve seçim ölçütleri entegrasyon sağlayıcısı değerlendirme rehberinde ayrıca ele alınır.

Google Merchant ve structured data açısından PIM’in sınırı nedir?

PIM, Google için id, item_group_id, gtin, mpn, brand ve varyant alanlarını kanal sözleşmesine göre üretebilir; fakat şirket içi alanlarla birebir aynı anlamı varsayamaz. Mayıs 2026 konuşma odaklı alanları opsiyoneldir ve temel verinin yerine geçmez. Merchant girdisi, açılış sayfası, Product/ProductGroup yapılandırılmış verisi ve Google’ın işlediği kayıt tutarlı olmalıdır; PIM görünürlük veya zengin sonuç garantisi vermez.

Güncel durum için Merchant API son güncellemeleri, opsiyonel konuşma odaklı ürün alanları ve Google ProductGroup varyant rehberi resmî kaynaklardır. Hesap ve feed operasyonu için Merchant Center entegrasyonu rehberi ayrı kapsamda kullanılabilir.

SEO ve yapay zekâ destekli keşifte PIM ne sağlayabilir?

PIM; tutarlı kimlik, açıklayıcı nitelik, kanıtlı ilişki, doğru varyant ve güncel belge üretimini kolaylaştırarak arama ve yapay zekâ sistemlerine daha düzenli giriş sağlar. Bununla birlikte teknik yayın, taranabilirlik, indeksleme, politika, sayfa deneyimi, rekabet ve sorgu bağlamı ayrıca etkilidir. Belirli bir alanın sıralama, AI özeti, satış veya ücretsiz listeleme sağlayacağına dair garanti verilemez.

Ürün sayfası kapsamı için ürün sayfası tasarım ilkeleri, organik görünürlük için e-ticaret SEO rehberi, yapay zekâ bağlamı için AI aramalarında e-ticaret görünürlüğü ve kontrollü içerik üretimi için yapay zekâ destekli e-ticaret yaklaşımı tamamlayıcıdır.

Ürün güvenliği, GPSR ve DPP için PIM nasıl hazırlanır?

PIM, mevzuata uygunluğu otomatik garanti etmez; kapsam dahilindeki ürün için üretici veya sorumlu kişi, tanımlayıcı, uyarı, belge, kanıt, dil, pazar ve geçerlilik alanlarını yönetebilir. Türkiye, AB GPSR ve ürün özelindeki teknik mevzuatın kapsamı farklıdır. ESPR ve Dijital Ürün Pasaportu ürün grubu bazında gelişir; 2026 standart referansları her ürün için bugün doğrudan zorunluluk anlamına gelmez.

Resmî dayanaklar Ticaret Bakanlığı uzaktan satış ürün güvenliği duyurusu, AB Genel Ürün Güvenliği Tüzüğü, ESPR 2024/1781 ve Decision (EU) 2026/1736 metinleridir. Hukuki ve teknik kapsam uzmanla doğrulanmalıdır.

PIM entegrasyonu nasıl güvenilir tasarlanır?

API, webhook, batch, ETL/iPaaS ve mesaj kuyruğu birbirinin yerine geçen etiketler değildir; gecikme, hacim, hata toleransı, sıralama ve geri oynatma ihtiyacına göre seçilir. Veri sözleşmesi kimlik, şema sürümü, alan semantiği, occurred-at ve received-at zamanları, idempotency anahtarı, sequence, hata modeli ve sahipliği tanımlamalıdır. Exactly-once varsaymak yerine tekrar teslim, deduplication ve mutabakat tasarlanmalıdır.

Sözleşme temelleri için OpenAPI 3.2.0, AsyncAPI 3.1.0, RFC 9457 Problem Details ve CloudEvents resmî başvuru noktalarıdır.

PIM performansı, gözlemlenebilirliği ve güvenliği nasıl ölçülür?

PIM kapasitesi yalnız SKU sayısıyla ölçülmez; varyant derinliği, aile başına nitelik, locale-channel kapsamı, varlık hacmi, import/export sıklığı, API throughput’u, indeksleme, workflow kuyruğu ve toplu işlem boyutu birlikte test edilir. Güvenlikte SSO, MFA, RBAC/ABAC, görev ayrılığı, tenant izolasyonu, sır yönetimi, audit, yedek, RTO/RPO ve çıkış export’u kanıtlanmalıdır.

API riskleri için OWASP API Security Top 10 2023 güncel bir kontrol başlangıcıdır; tek başına tam güvenlik standardı değildir.

PIM KPI’ları ve fayda hesabı nasıl kurulmalıdır?

PIM başarısı yalnız tamlık veya lisans kurulumu değildir; ilk seferde doğru yayın, red oranı, veri yaşı, düzeltme süresi, manuel dokunuş, kopya oranı, görsel-belge kapsaması, çeviri tamlığı, yayın gecikmesi ve mutabakat farkı birlikte izlenmelidir. Fayda atfında baseline, karşılaştırılabilir kohort ve neden kodu gerekir; iade veya satış değişimi doğrudan PIM’e mal edilemez.

PIM maliyeti ve üç yıllık TCO nasıl hesaplanır?

PIM maliyeti yalnız lisans değildir. Veri keşfi ve temizleme, modelleme, taksonomi, entegrasyon, DAM, çeviri, eğitim, migrasyon, test ortamı, API veya depolama tüketimi, destek, yükseltme, güvenlik ve çıkış maliyetleri hesaba katılmalıdır. Piyasa fiyatı uydurmak yerine sağlayıcının lisans metriği, varsayımlar ve miktarlar teklif üzerinde doğrulanmalı; üç yıllık TCO aynı kapsamla karşılaştırılmalıdır.

PIM sağlayıcısı nasıl seçilir?

Sağlayıcı seçimi demo ekranına veya özellik onay kutusuna indirgenmemelidir. Ağırlıklı puan kartı gerçek katalog verisi, kanal sözleşmesi, güvenlik kanıtı, performans yükü, hata ve rollback senaryosu, migrasyon, işletim, toplam maliyet ve çıkış taşınabilirliğini birlikte değerlendirmelidir. “Roadmap’te var” bugünkü çalışan ve sözleşmeli yetenek değildir; her iddia sürüm, limit, ortam ve kabul ölçütüyle kanıtlanmalıdır.

12 temsili PIM senaryosu hangi kararları görünür kılar?

Temsili senaryolar, bir PIM özelliğinin ekran görüntüsünden öte gerçek katalog, kaynak, risk, kontrol ve kabul ölçütüyle sınanmasını sağlar. Aşağıdaki örnekler sonuç garantisi veya proje süresi değildir; işletmenin kendi verisiyle uyarlanacak test modelleridir. Her senaryoda yetkili kaynak, kanonik model, kalite ve workflow, kanal kapsamı, ölçüm, beklenen etki ile istisna veya geri dönüş açıkça ayrılmıştır.

Temsili senaryo 1: Moda: beden ve renk varyantlarının yönetimi

Bu temsili senaryo, iki marka, üç ülke ve çoklu beden sistemleri kullanan moda perakendecisi. için PIM kararının veri ve kontrol düzeyinde nasıl test edilebileceğini gösterir. Amaç belirli bir sonuç vaat etmek değil; kaynağın, modelin, onayın, kanal sözleşmesinin ve geri dönüşün aynı kabul planında kanıtlanmasıdır.

Temsili senaryo 2: Elektronik: teknik özellik ve GTIN ayrımı

Temsili senaryo 3: Kozmetik: iddia, içerik ve pazar uyarıları

Temsili senaryo 4: Mobilya: ölçü, malzeme ve teslimat ayrımı

Temsili senaryo 5: B2B endüstriyel parça: MPN ve uyumluluk ilişkisi

Temsili senaryo 6: Tedarikçi XML şema değişikliği

Temsili senaryo 7: Pazaryeri taksonomi değişikliği

Temsili senaryo 8: Google Merchant veri hazırlığı

Temsili senaryo 9: Embargolu ürün lansmanı

Temsili senaryo 10: Çok dilli e-ihracat kataloğu

Temsili senaryo 11: DAM hak süresi dolan görsel

Temsili senaryo 12: PIM migrasyonu ve kimlik koruma

Sağlayıcıya hangi kanıt soruları sorulmalıdır?

İyi bir sağlayıcı sorusu evet veya hayır cevabı istemez; çalışan sürümü, sınırı, gerçek veri örneğini, logu, export’u, test sonucunu ve sözleşmeli sorumluluğu ister. Aşağıdaki sorular demo ile PoC’yi, bugünkü özellik ile roadmap’i ve standart ürün ile özel geliştirmeyi ayırır. İşletme bunları kendi risk ağırlığına göre puanlamalı, kritik eleme koşullarını teklif öncesinde yazılı hâle getirmelidir.

Veri modeli ve yönetişim

1. S01: Gerçek katalog örneğimizle aile, model, satılamayan parent, varyant ve SKU hiyerarşisini canlı ortamda gösterebilir misiniz?
2. S02: Çok seviyeli varyant derinliğinin belgelenmiş sınırı, performans etkisi ve lisans etkisi nedir?
3. S03: Attribute tipleri, birim, enum, referans varlık ve ilişkiler hangi sürümde yerel olarak destekleniyor?
4. S04: Aile bazlı zorunluluk, koşullu requiredness ve miras kuralları için çalışan örnek ve export kanıtı sunar mısınız?
5. S05: Null, bilinmiyor, uygulanamaz, doğrulanmadı, false ve sıfır değerlerini veri modelinde nasıl ayırıyorsunuz?
6. S06: Alan bazlı source of truth, yazma yönü ve çatışma kuralı nerede tanımlanıyor; audit örneği nedir?
7. S07: Controlled vocabulary için owner, eş anlam, geçerlilik, deprecation ve kanal mapping sürümü tutuluyor mu?
8. S08: Taksonomi, kategori, ürün ailesi, koleksiyon, etiket ve faset ayrı nesne veya ilişki olarak modellenebiliyor mu?
9. S09: Stable ID politikası nedir; silme, birleştirme, ayırma ve yeniden açmada kimlik nasıl korunuyor?
10. S10: Veri sözlüğü, model ve mapping bütünüyle makinece okunabilir formatta dışa aktarılabiliyor mu?

Kalite, workflow ve audit

1. S11: Kural motoru tip, aralık, regex, sözlük, çapraz alan, ilişki ve dış referans kontrollerini hangi limitlerle destekliyor?
2. S12: Blocker, error, warning ve info şiddetlerinin yayın kapısına etkisini gerçek örnekle gösterebilir misiniz?
3. S13: Completeness paydası aile, kanal, locale ve uygulanamaz alanlara göre nasıl hesaplanıyor?
4. S14: Doğruluk kanıtı ile yalnız tamlık skorunu ürün ekranında ve raporda nasıl ayırıyorsunuz?
5. S15: Data owner, steward, editör ve onaylayıcı rollerine alan/aile/channel kapsamı atanabiliyor mu?
6. S16: Hazırlayanın kendi kritik değişikliğini onaylamasını teknik olarak engelleyen four-eyes kontrolü var mı?
7. S17: Değişiklik öncesi/sonrası değer, kullanıcı, zaman, kaynak, gerekçe ve onay audit trail’de tutuluyor mu?
8. S18: Toplu düzenlemede dry-run, etki diff’i, örnekleme, onay, seçici rollback ve kanıt nasıl çalışıyor?
9. S19: Workflow tanımı değiştiğinde açık görevler ve audit kayıtları hangi sürüm semantiğiyle devam ediyor?
10. S20: İstisna veya muafiyetin sahibi, nedeni, süresi, kapsamı ve yeniden değerlendirme tarihi tutuluyor mu?

Entegrasyon ve kanal yayını

1. S21: API için desteklenen güncel sözleşme sürümü, deprecation süresi ve geriye uyumluluk politikası nedir?
2. S22: Webhook imzası, timestamp toleransı, tekrar teslim ve replay korumasını test ortamında gösterebilir misiniz?
3. S23: Idempotency anahtarı aynı payload ve farklı payload ile tekrarlandığında sistem nasıl davranıyor?
4. S24: Out-of-order update için entity version, sequence, occurred-at ve received-at nasıl değerlendirilir?
5. S25: Retry, exponential backoff, jitter, retry bütçesi ve kalıcı hata ayrımı nerede yapılandırılır?
6. S26: Dead-letter kuyruğunun sahibi, alarmı, yeniden oynatma aracı ve veri kaybı kanıtı nedir?
7. S27: Full, delta, scheduled publish ve unpublish işlemlerinin her biri için geri alma yöntemi var mı?
8. S28: Submitted, accepted, processed, rejected ve published durumlarını kanal kayıt kimliğiyle ayırabiliyor musunuz?
9. S29: Hedef kanaldan read-back ve alan bazlı reconciliation hangi konektörlerde gerçekten destekleniyor?
10. S30: Kanal taksonomi ve attribute sözlüğü değişiklikleri nasıl sürümleniyor, etki analizi nasıl çıkarılıyor?
11. S31: Standart konektör, partner çözümü ve özel geliştirme hangi belgede açıkça ayrılıyor?
12. S32: API rate limit, pagination, async job, payload boyutu ve eşzamanlılık sınırlarını sözleşmeye ekliyor musunuz?

DAM, locale, AI ve uyum

1. S33: DAM entegrasyonunda asıl dosya, rendition, checksum, hak, bölge ve bitiş tarihi nasıl taşınıyor?
2. S34: Süresi dolan lisanslı görseli ilgili kanal ve pazardan otomatik durdurma kanıtı sunabilir misiniz?
3. S35: Belge için sürüm, dil, ürün ilişkisi, veren kurum, geçerlilik ve erişim kontrolü destekleniyor mu?
4. S36: Locale, language, market, channel ve scope ayrı semantiklerle modellenebiliyor mu?
5. S37: Fallback zinciri ve yasak fallback kombinasyonları negatif testle nasıl kanıtlanıyor?
6. S38: Çeviri durumu, terminoloji sözlüğü, kaynak dil ve insan onayı audit’e dahil mi?
7. S39: AI ile çıkarılan attribute için kaynak pasaj, model/sürüm, güven skoru ve onay kararı tutuluyor mu?
8. S40: AI taslağında sağlık iddiası, telif, marka dili ve kişisel veri riskleri için hangi kapılar vardır?
9. S41: Türkiye ürün güvenliği, GPSR veya DPP için sunduğunuz alanlar standart özellik mi, şablon mu, hukuki vaat mi?
10. S42: Mevzuat sözlüğü değiştiğinde hangi ürünlerin etkilendiğini gösteren yeniden değerlendirme mekanizması var mı?

Güvenlik ve mahremiyet

1. S43: SSO protokolleri, MFA zorunluluğu ve acil durum hesabı kontrolleri hangi paket ve sürümde sunuluyor?
2. S44: RBAC dışında attribute, family, supplier, locale veya embargo koşuluna dayalı ABAC destekleniyor mu?
3. S45: Tedarikçi portalında tenant izolasyonu için bağımsız test veya rapor ve negatif erişim kanıtı sunar mısınız?
4. S46: Paylaşımlı yönetici hesabını engelleme, kullanıcı yaşam döngüsü ve ayrılan personel erişim kesme süresi nedir?
5. S47: API anahtarı ve webhook secret’ları nerede saklanır, nasıl döndürülür ve loglarda nasıl maskelenir?
6. S48: Embargolu ürün, yayımlanmamış fiyat ve ticari sır için görüntüleme ile export yetkisi ayrı mıdır?
7. S49: Audit logları değiştirilemez mi; saklama, arama, export ve zaman senkronizasyonu sınırları nelerdir?
8. S50: Bağımsız sızma testi, güvenlik sertifikası ve kritik bulgu giderme politikasının güncel kanıtı nedir?
9. S51: Veri bölgesi, alt işlemci, yedek konumu ve sınır ötesi aktarım koşulları sözleşmede nasıl tanımlanır?
10. S52: Güvenlik olayı bildirim süresi, iletişim akışı ve adli kanıt erişimi için taahhüt nedir?

Performans, gözlemleme ve DR

1. S53: Temsili katalog hacmimizde import, bulk edit, arama ve yayın P50/P95/P99 sonuçlarını birlikte test eder misiniz?
2. S54: SKU dışında variant, attribute, locale, channel, asset ve workflow hacmi kapasite hesabına nasıl giriyor?
3. S55: API throughput, burst, rate limit ve kuyruk büyümesinde backpressure davranışını gösterebilir misiniz?
4. S56: İndeks güncellemesi ve büyük reindex sırasında editör ve yayın performansı nasıl etkileniyor?
5. S57: Queue age, retry, dead-letter, publish latency ve reconciliation farkı için hangi metrik ve alarmlar hazırdır?
6. S58: Log, metric ve trace verisinde correlation ID uçtan uca korunuyor mu; müşteri export edebilir mi?
7. S59: Planlı bakım, sürüm yükseltme ve geriye alma sırasında kullanılabilirlik nasıl ölçülür?
8. S60: RTO ve RPO hangi bileşenler için sözleşmelidir; son restore tatbikatı sonucu nedir?
9. S61: Silinen veya yanlış güncellenen katalog sürümünü point-in-time geri yükleme kapsamı nedir?
10. S62: Bölgesel arıza, bağımlı kanal kesintisi ve uzun kuyruk için işletim runbook’u paylaşılır mı?

Maliyet, sözleşme ve çıkış

1. S63: Lisans metriği SKU, ürün modeli, channel, locale, kullanıcı, API, depolama veya işlem hacminden hangilerine bağlıdır?
2. S64: Arşiv, taslak, varyant, bundle ve supplier kaydı lisans sayımına nasıl dahil edilir?
3. S65: Sandbox, test, eğitim ve DR ortamlarının fiyatı ve kullanım limitleri nedir?
4. S66: Standart konektörün kurulum, sürüm yükseltme, API tüketimi ve kanal değişikliği maliyeti nedir?
5. S67: Veri temizleme, taxonomy, migration, eğitim ve change request ücretleri ayrı kalemlerle sunuluyor mu?
6. S68: Üç yıllık fiyat artışı, kur farkı, endeks, minimum taahhüt ve aşım ücreti nasıl hesaplanır?
7. S69: SLA service credit tek telafi mi; kritik veri kaybı veya güvenlik olayı için şartlar nelerdir?
8. S70: Sözleşme sonunda veri, model, mapping, ilişki, audit, workflow ve medya referanslarının export formatı nedir?
9. S71: Export için ek ücret, süre, API limiti veya profesyonel hizmet zorunluluğu var mı?
10. S72: Veri silme sertifikası, yedeklerden silme takvimi ve taşınma desteği nasıl kanıtlanır?

PoC, migration ve işletim

1. S73: PoC ücretsiz deneme veya demo değilse kapsam, süre, veri seti, sorumluluk ve kabul kriterini nasıl sözleşmelendiriyorsunuz?
2. S74: Bizim kopya, bozuk birim, eksik locale, yanlış varyant ve expired asset örneklerimizi PoC’ye alır mısınız?
3. S75: PoC’de bir kanalın accepted, processed, rejected, published ve read-back durumlarını gösterebilir misiniz?
4. S76: PoC performans testi üretim topolojisine ne kadar benzer; farklar ve ölçekleme varsayımları nelerdir?
5. S77: UAT hataları için severity, düzeltme süresi, yeniden test ve go-live engeli nasıl yönetilir?
6. S78: Migration discovery ve profiling çıktısı hangi alan, kimlik, ilişki ve kalite istatistiklerini içerir?
7. S79: Stable ID, kanal listing ID, URL, mapping ve DAM ilişkisini koruma yöntemi nedir?
8. S80: Kaç tam prova, delta sync, freeze, cutover, rollback ve hypercare adımı teklife dahildir?
9. S81: Rollback tetikleyicisi, karar yetkisi, veri snapshot’ı ve tüketici sistemlerin geri dönüşü nasıl koordine edilir?
10. S82: Canlı sonrası data quality owner, entegrasyon nöbeti, destek seviyesi ve release yönetimi kimdedir?

Bu 82 soru, tek başına seçim kararı değildir. Yanıtların PoC, UAT, güvenlik incelemesi, sözleşme eki ve referans görüşmesiyle doğrulanması gerekir; olumlu satış sunumu kanıt yerine geçmez.

Uygulanabilir PIM kontrol listesi nasıl kullanılmalıdır?

Kontrol listesi satın alma sonrasında işaretlenecek genel niyetler değil, kanıt üretmesi gereken eylem ve doğrulamalardır. Her maddeye owner, son tarih, kanıt bağlantısı, durum ve risk seviyesi eklenmelidir. “Tamamlandı” demek için belge, test sonucu, export, ekran kaydı veya mutabakat raporu bulunmalı; uygulanmayan madde gerekçeli ve süreli istisna olarak yönetilmelidir.

1. Strateji ve iş hedefi

• PIM kararının çözeceği üç ölçülebilir iş problemi owner’larıyla onaylandı.
• Baseline döneminde time-to-market başlangıç ve bitiş olayları tanımlandı.
• Hata maliyeti kanal, ürün ailesi ve neden koduyla ölçüldü.
• Ayrı PIM gerektirmeyen katalog senaryoları yazılı olarak değerlendirildi.
• Başarı KPI’ları satış garantisinden ayrılarak veri ve süreç düzeyinde kuruldu.
• İlk faz ürün ailesi, pazar, locale ve kanal kapsamı sınırlandı.
• Yönetim sponsoru ile ürün veri owner’ı farklı sorumlulukları kabul etti.
• Kritik mevzuat ve embargo riskleri karar puanına dahil edildi.
• Build, buy ve yerleşik katalog seçenekleri aynı gereksinim setiyle karşılaştırıldı.
• Faz dışı DAM, MDM, DPP ve ileri taksonomi işleri açık backlog’a alındı.

2. Mevcut durum ve kaynak envanteri

• Tüm ürün kaynağı sistem, dosya, portal ve manuel tablolar envanterlendi.
• Her kaynak için owner, format, sıklık, hacim ve kalite profili kaydedildi.
• Aynı alanın çelişen kaynakları ve fiilî kazanma kuralı belirlendi.
• Ürün, model, varyant, offer ve inventory kayıt sayıları ayrı ölçüldü.
• Kaynak kodlama, dil, ondalık, tarih ve birim biçimleri profillendi.
• Mevcut kanal listing ID ve mapping tablolarının yeri doğrulandı.
• DAM varlık kimlikleri, hak alanları ve kırık ilişki oranı çıkarıldı.
• Manuel kopyalama ve spreadsheet adımları gözlemle belgelendi.
• Mevcut audit, onay ve istisna kanıtlarındaki boşluklar listelendi.
• Bağımlı sistemlerin bakım, batch ve freeze pencereleri kaydedildi.

3. Ürün veri modeli

• Kanonik varlık diyagramı ürün ailesi, model, parent, varyant ve SKU’yu ayırıyor.
• Product, Offer ve Inventory alanları ayrı şema ve owner taşıyor.
• Her attribute için veri tipi, kardinalite ve uygulanabilirlik tanımlandı.
• Sayısal değer ile ölçü birimi ayrı alanlarda tutuluyor.
• Enum alanları kontrollü sözlük kimliği kullanıyor.
• Marka, üretici ve malzeme gibi tekrar eden kavramlar referans varlık olarak değerlendirildi.
• İlişki alanları yön, tür, geçerlilik ve hedef kimliği taşıyor.
• Null, unknown, not-applicable, unverified, false ve zero semantiği sözleşmeye yazıldı.
• Kalıcı ve türetilmiş alanlar veri sözlüğünde işaretlendi.
• Alan mirası ve override izinleri aile düzeyinde tanımlandı.
• Fallback sırası ve döngü engeli belgelenip test edildi.
• Şema sürümü ile geriye uyumluluk politikası onaylandı.
• Alan deprecation süresi ve tüketici bildirim yöntemi belirlendi.
• Model değişikliklerinin etki analizi ve rollback yöntemi prova edildi.

4. Kimlik, varyant ve ilişki

• SKU üretim, benzersizlik ve yeniden kullanım politikası onaylandı.
• GTIN kullanımı güncel GS1 kapsamı ve marka yetkisiyle doğrulandı.
• EAN/UPC ifadelerinin veri taşıyıcı ve GTIN bağlamı sözlükte netleştirildi.
• MPN değerinin üretici ve marka bağlamı korunuyor.
• Parent kaydın satılabilir olup olmadığı her family’de açık.
• Varyant eksenleri yalnız satılabilirliği ayıran iş kurallarıyla seçildi.
• Varyant kombinasyonu uniqueness kuralı çalışıyor.
• Bundle, kit, multipack ve varyant ilişkileri ayrı tiplere sahip.
• Related, accessory, replacement ve supersedes ilişkileri yönlü tanımlandı.
• Google id ve item_group_id iç kimliklerden dönüşümle ayrıldı.
• Birleştirme ve ayırmada survivor ID ile alias geçmişi korunuyor.
• Silinen veya emekli kimliğin yeniden atanması teknik olarak engellendi.

5. Taksonomi ve referans veri

• Kurumsal taksonomi ile kanal kategori ağaçları ayrı sürümleniyor.
• Kategori, family, collection, tag ve facet sorumluları belirlendi.
• Her family için attribute ve requiredness seti onaylandı.
• Kontrollü sözlüklerde eş anlam, preferred term ve locale karşılığı tutuluyor.
• Deprecated değerlerin yerine geçecek değer ve geçiş tarihi tanımlandı.
• Kanal enum eşlemeleri çift yönlü izlenebilir.
• Referans veri değişikliğinin etkilenen ürünleri çıkarılabiliyor.
• Taksonomi taşımasının URL ve kanal mapping etkisi değerlendirilmiş.
• Yeni kategori talebi için owner ve kabul ölçütü var.
• GS1 GDM veya GPC kullanımı sektör ve senaryoya göre uyarlanıp belgelendi.

6. Veri alımı ve tedarikçi

• Her supplier feed için şema fingerprint’i ve sürüm kaydı tutuluyor.
• Dosya checksum, boyut, kodlama ve tamlık manifesti doğrulanıyor.
• Beklenmeyen kolon, eksik kolon ve tip değişikliği karantinaya gidiyor.
• Null oranı ve değer dağılımındaki drift eşikleri alarm üretiyor.
• Kaynak-kanonik mapping owner ve geçerlilik tarihi taşıyor.
• Birim, tarih, dil ve enum normalizasyonu ayrı dönüşüm adımlarında izleniyor.
• HTML kalıntısı, bozuk URL ve yasak karakter kuralları çalışıyor.
• Duplicate adayları güven skoru ve açıklanabilir eşleşme nedeni taşıyor.
• Survivorship kuralı kaynak önceliği, freshness ve kanıtı birlikte kullanıyor.
• Son başarılı snapshot ve freshness alarmı tedarikçi kesintisinde hazır.

7. Veri kalitesi ve doğrulama

• Accuracy, completeness, validity, consistency, freshness ve uniqueness ayrı KPI’dır.
• Completeness paydası family, channel, locale ve not-applicable semantiğine göre hesaplanıyor.
• Blocker, error, warning ve info yayın davranışları test edildi.
• Koşullu zorunluluk kuralları pozitif ve negatif örneklerle doğrulandı.
• Sayısal aralık ve birim dönüşüm kuralları sınır değerlerle test edildi.
• Alanlar arası tutarlılık kuralları ürün ailesine göre sürümlendi.
• Kimlik checksum veya biçim kontrolü sahiplik kanıtının yerine kullanılmıyor.
• Belge, lisans ve güvenlik alanlarında geçerlilik tarihi zorunlu.
• Kaynak kanıtı olmayan kritik değer unverified durumunda kalıyor.
• Quality score’un ağırlık, payda ve kural sürümü raporda görünür.
• Örneklemle doğruluk incelemesi ve hata nedeni kodları tanımlandı.
• Kanal redleri veri kalitesi kuyruğuna sınıflandırılmış biçimde dönüyor.
• Düzeltme sonrası yeniden test ve eski sürüm karşılaştırması otomatik.
• Kalite kuralı istisnası owner, neden, süre ve kapsam taşıyor.

8. Workflow, rol ve yönetişim

• Data owner, steward, editör, onaylayıcı ve entegrasyon sahibi RACI’de tanımlandı.
• Alan, family, channel ve locale bazlı düzenleme yetkileri en az ayrıcalıkla verildi.
• Kritik değişiklikte hazırlayan ve onaylayan teknik olarak ayrıldı.
• Paylaşımlı hesap kullanımını önleyen kimlik politikası uygulandı.
• Görev SLA’sı, eskalasyon ve tatil/yedek rol akışı tanımlandı.
• Workflow sürüm değişikliğinin açık görevlere etkisi test edildi.
• Toplu işlem için ikinci onay ve risk eşiği yapılandırıldı.
• İstisna kuyruğunun sahibi ve çözüm süreleri belirlendi.
• Audit trail önceki/sonraki değer, kaynak, kullanıcı, zaman ve gerekçe içeriyor.
• Lineage ham kaynak, dönüşüm, onay ve yayın kimliğini bağlıyor.
• Emekli ürünün yeniden etkinleştirme yetkisi sınırlı.
• Yönetişim kurulu kural ve sözlük değişikliklerini düzenli gözden geçiriyor.

9. DAM, görsel ve belge

• Asıl dosya, rendition ve ürün ilişkisi ayrı kimliklerle modelleniyor.
• Görsel açı, sıra, varyant ve kanal uygunluğu doğrulanıyor.
• Hak sahibi, lisans, bölge, kanal ve bitiş tarihi varlıkla bağlı.
• Süresi dolan varlık için alarm, alternatif ve unpublish akışı test edildi.
• Alt metin bağlama göre bilgilendirici/dekoratif ayrımıyla yönetiliyor.
• Dosya checksum ve MIME türü teknik kabulde doğrulanıyor.
• Kılavuz ve güvenlik belgesi ürün/model ile doğru eşleşiyor.
• Belge sürümü, dili, veren kurum ve geçerlilik tarihi tutuluyor.
• Erişim kısıtlı belge için rol ve kanal politikası uygulanıyor.
• Asset coverage yalnız dosya varlığı değil hak ve uygunluğu da ölçüyor.

10. Locale, çeviri ve channel override

• Language, locale, market, channel ve scope alanları ayrı tanımlandı.
• Kaynak dil ve her çevirinin onay durumu kaydediliyor.
• Terminoloji sözlüğü preferred term ve yasak terim içeriyor.
• Makine çevirisi insan onayı olmadan kritik alanda yayımlanmıyor.
• Ondalık, tarih, para, ölçü ve beden biçimleri locale bazında test edildi.
• Pazar uyarıları dil çevirisinden ayrı hukuki kapsam taşıyor.
• Fallback zinciri ve yasak dil geçişleri açıkça belgelenmiş.
• Kanal override’ı owner, neden ve son kullanım tarihi taşıyor.
• Override, kanonik kaydın serbest kopyasına dönüşmüyor.
• Eksik locale için publish block veya kontrollü fallback davranışı test edildi.

11. Kanal eşleme ve yayın

• Kanal kategori mapping’i dış sözlük sürümüyle kaydedildi.
• Her kanal attribute’u kaynak alan, dönüşüm ve requiredness taşıyor.
• Enum mapping’lerinde unmapped değer karantinaya alınıyor.
• Karakter limiti ve format dönüşümü veri kaybı uyarısı üretir.
• Full publish için snapshot, kapasite ve mutabakat planı var.
• Delta publish watermark ve kaçan olay replay kontrolü taşıyor.
• Unpublish hedefte geri okuma ile doğrulanıyor.
• Scheduled publish timezone ve embargo negatif testlerini geçti.
• Submitted, accepted, processed, rejected ve published ayrıdır.
• Kanal hata kodları owner, severity ve retryability ile eşlenmiştir.
• Retry kalıcı hataları sonsuz döngüye sokmuyor.
• Read-back alan bazlı karşılaştırma ve tolerans kullanıyor.
• Channel taxonomy değişikliği etkilenen SKU raporu üretiyor.
• Kanal kesintisinde kuyruk, freshness SLO ve manuel runbook hazır.

12. SEO, structured data ve AI friendly veri

• Kanonik ürün gerçekleriyle kanal başlıkları arasındaki lineage korunuyor.
• Product, Offer ve Inventory alanları sayfa verisinde karıştırılmıyor.
• ProductGroup varyant ilişkisi iç modelden kontrollü dönüşümle üretiliyor.
• Merchant, landing page ve structured data tutarlılık testi çalışıyor.
• İçerik kalitesi SEO veya zengin sonuç garantisi olarak sunulmuyor.
• Opsiyonel Google konuşma alanları destek ve kapsam doğrulanınca kullanılıyor.
• AI nitelik çıkarımı kaynak pasaj ve güven skoru taşıyor.
• AI açıklama taslağı iddia, telif ve marka dili kontrolünden geçiyor.
• Anomali modeli yanlış pozitif/negatif örneklerle izleniyor.
• İnsan onayı, model/sürüm ve prompt bağlamı audit’te kayıtlı.

13. Ürün güvenliği, GPSR ve DPP hazırlığı

• Ürün ve pazar bazlı teknik mevzuat kapsamı uzman tarafından belirlendi.
• Türkiye ilan uyarıları ve işaretleri güncel resmî kaynakla doğrulandı.
• Üretici ve iktisadi işletmeci rol/adres alanları geçerlilik taşıyor.
• GPSR kapsamındaki online teklif alanları Madde 19’a göre eşlendi.
• AB dışı üreticide sorumlu kişi bilgisi kapsam dahilinde zorunlu.
• Uyarı, güvenlik ve kullanım bilgileri locale ile sürümleniyor.
• Sertifika ve kanıt dosyası ürün, model, batch ve pazar kapsamını ayırıyor.
• ESPR çerçevesi her üründe bugünkü DPP zorunluluğu sayılmıyor.
• 2026/1736 standart referansları ürün grubu düzenlemesinden ayrı izleniyor.
• Hukuki istisna owner, dayanak, tarih ve yeniden inceleme taşıyor.

14. Entegrasyon ve mutabakat

• OpenAPI/AsyncAPI veya eşdeğer sözleşme sürüm kontrollü tutuluyor.
• Entity ID, version, schema version ve correlation ID zorunlu.
• occurred_at ile received_at ayrı zaman damgalarıdır.
• Idempotency aynı ve farklı payload tekrarlarıyla test edildi.
• Out-of-order update için reddetme, bekletme veya birleştirme kuralı var.
• Retryable ve permanent hata sınıfları makinece ayrılıyor.
• Backoff, jitter ve retry bütçesi bağımlı sistemi koruyor.
• Dead-letter kuyruğu alarm, owner ve replay runbook’una sahip.
• Webhook imzası, replay penceresi ve secret rotasyonu test edildi.
• Batch manifest, checksum, row count ve watermark doğrulanıyor.
• Consumer contract testleri geriye uyumluluğu kontrol ediyor.
• Read-back aynı sürüm ve kapsam üzerinden karşılaştırılıyor.
• Reconciliation farkı owner kuyruğuna ve düzeltme kanıtına bağlanıyor.
• Çift yönlü alan yazımı source-of-truth matrisiyle teknik olarak sınırlandı.

15. Güvenlik, performans ve DR

• SSO ve yüksek riskli roller için MFA uygulanıyor.
• RBAC/ABAC negatif erişim testleri family, channel ve locale kapsamını doğruladı.
• Tedarikçi tenant’ları arasında çapraz veri erişimi engellendi.
• Embargolu ürün görüntüleme, düzenleme ve export yetkileri ayrıldı.
• API anahtarları vault’ta tutuluyor ve düzenli döndürülüyor.
• Secret ve kişisel veri loglarda maskeleniyor.
• Audit logları değiştirilemez saklama ve export politikasına sahip.
• API P50/P95/P99, throughput ve rate limit temsili yükle ölçüldü.
• Import, bulk edit, indeks ve workflow eşzamanlı yükte test edildi.
• Queue age ve publish freshness SLO alarmları çalışıyor.
• Yedek bütünlüğü ve point-in-time restore prova edildi.
• RTO/RPO bileşen bazında ölçülüp sözleşmeyle karşılaştırıldı.
• Bölgesel arıza ve kanal kesintisi runbook’ları tatbik edildi.
• Tam veri export’u başka ortamda okunabilirliğiyle doğrulandı.

16. Maliyet, sözleşme, migration ve SoloCommerce fit

• Lisans metriği ve sayım dışı/içi kayıt türleri teklifte açıklandı.
• Sandbox, DR, API, depolama, AI ve connector ücretleri TCO’ya eklendi.
• İç ekip zamanı, veri temizleme ve taxonomy çalışması maliyetlendirildi.
• Üç yıllık fiyat artışı ve aşım senaryosu aynı para birimiyle hesaplandı.
• Standart özellik, eklenti, partner ve özel geliştirme ayrıldı.
• SLA, destek seviyesi ve service credit kapsamı sözleşmede yazıldı.
• Exit export alanları, formatı, süresi, ücreti ve silme kanıtı belirlendi.
• Demo, PoC, pilot ve UAT amaçları ile kabul ölçütleri ayrıldı.
• Migration profiling, mapping ve cleansing çıktıları iş birimlerince onaylandı.
• Stable ID, kanal ID, URL ve DAM ilişkisi koruma planı test edildi.
• En az iki migration provası ve alan bazlı reconciliation tamamlandı.
• Delta sync, freeze, cutover, rollback ve hypercare runbook’u onaylandı.
• SoloCommerce canlı ürün, kategori, varyant ve set kapsamı doğrulandı.
• SoloCommerce dedicated PIM olarak varsayılmadan gereksinim boşluğu çıkarıldı.
• Enterprise özel entegrasyon ve SLA yalnız teklif/sözleşme kanıtıyla değerlendirildi.
• Paket bedeli ayrı PIM, veri temizleme ve entegrasyon TCO’sundan ayrıldı.

Toplam 190 uygulanabilir kontrol maddesi elde edilmiştir. Maddeler bir kerelik proje kapanışı yerine yönetişim ritmine bağlanmalı; model, kanal, mevzuat veya sözleşme değiştiğinde ilgili kanıt yeniden üretilmelidir.

PoC ve UAT kabul matrisi nasıl hazırlanır?

PoC, gerçek katalogla çözüm ve risk hipotezini sınar; demo veya ücretsiz deneme değildir. UAT ise seçilen çözümün iş kabulünü, entegrasyonunu, güvenliğini ve geri dönüşünü üretime yakın koşulda doğrular. Her testin önkoşulu, girdisi, adımı, beklenen ve negatif sonucu, kanıtı, ölçülebilir kabul eşiği, sahibi ve önceliği bulunmalıdır. Aşağıdaki 108 satır işletmeye göre uyarlanacak başlangıç matrisidir.

Toplam 108 UAT satırı vardır: A 10, B 12, C 14, D 12, E 10, F 14, G 14, H 12 ve I 10. Kritik testte başarısızlık go-live engelidir; yüksek ve orta bulgular ise kabul edilen risk, owner, çözüm tarihi ve yeniden test kanıtı olmadan kapatılmamalıdır.

Sık yapılan PIM hataları ve kırmızı bayraklar nelerdir?

Kırmızı bayraklar genellikle yazılım ekranından değil; kimlik, sahiplik, kanıt, geri dönüş ve sözleşme boşluğundan doğar. Aşağıdaki maddeler tek başına sağlayıcıyı elemek zorunda değildir, ancak her biri risk sahibi, düzeltme planı ve kabul kanıtı gerektirir. Kritik bir boşluğun “sonra bakarız” diye üretime taşınması, katalog hatasını çok sayıda kanal ve locale’a hızla çoğaltabilir.

1. K01: PIM’i veri ve yönetişim dönüşümü yerine yalnız araç satın alma projesi saymak.
2. K02: Data owner atamadan editörlerin ortak karar vermesini beklemek.
3. K03: Her ürünle ilgili alanı PIM’e taşımaya çalışmak.
4. K04: ERP ve PIM’in aynı alana kuralsız çift yönlü yazmasına izin vermek.
5. K05: Çatışmada her zaman son yazanı kazanan kabul etmek.
6. K06: SKU, GTIN, parent SKU ve item_group_id kimliklerini karıştırmak.
7. K07: EAN ifadesini bütün bağlamlarda GTIN’in eş anlamlısı kullanmak.
8. K08: Parent kaydın her platformda satılabilir SKU olduğunu varsaymak.
9. K09: Ürün modeli sayısıyla satılabilir SKU sayısını aynı raporlamak.
10. K10: Family, kategori ve taksonomiyi tek kavram saymak.
11. K11: Koleksiyon, tag ve facet’i ana sınıflandırma ağacına zorla bağlamak.
12. K12: Her attribute değerini serbest metin olarak saklamak.
13. K13: Sayısal değer ile unit bilgisini aynı metne gömmek.
14. K14: Renk ve beden dahil her özelliği otomatik varyant ekseni yapmak.
15. K15: Varyant ile bundle, kit veya multipack’i aynı ilişki türü saymak.
16. K16: Product, Offer ve Inventory alanlarını tek kayıt sahipliğinde toplamak.
17. K17: Null, unknown, not-applicable, unverified, false ve zero ayrımı yapmamak.
18. K18: Completeness skorunu doğruluk veya uyum kanıtı saymak.
19. K19: Kalite skorunun paydasını ve kural sürümünü gizlemek.
20. K20: Geçerli biçimdeki bir değeri gerçek dünyada doğru varsaymak.
21. K21: Tedarikçi XML veya CSV verisini doğrulamadan yetkili kaynak saymak.
22. K22: Import başarılı mesajını ürünün yayına hazır olmasıyla eşitlemek.
23. K23: Şema drift’i için fingerprint ve profil eşiği kullanmamak.
24. K24: Kaynak mapping’ini sürümsüz ve ownersız bırakmak.
25. K25: Duplicate adaylarını otomatik ve geri dönüşsüz birleştirmek.
26. K26: Survivorship kuralında kanıt ve freshness yerine sabit kaynak önceliği kullanmak.
27. K27: Eski kimliği silip migration sırasında yeni SKU üretmek.
28. K28: Referans veri sözlüklerini statik ve sahipsiz liste sanmak.
29. K29: Deprecated değerler için geçiş ve replacement tanımlamamak.
30. K30: Kanal taksonomisi değişince kanonik taxonomy’yi bozmak.
31. K31: Kanal override’larını bağımsız kopya kataloglara dönüştürmek.
32. K32: Override nedeni, sahibi ve son kullanım tarihini tutmamak.
33. K33: Fallback zincirinin döngü ve yanlış dil riskini test etmemek.
34. K34: Makine çevirisini kritik alanlarda insan onaysız yayımlamak.
35. K35: Ondalık, tarih, beden ve ölçü biçimini yalnız metin çevirisi sanmak.
36. K36: DAM dosyası erişilebilir diye kullanım hakkının geçerli olduğunu varsaymak.
37. K37: Görsel dosya adı, açı, alt metin ve lisansı tek alan yapmak.
38. K38: Asset expiry için alarm, alternatif ve unpublish akışı kurmamak.
39. K39: Alt metni anahtar kelime doldurma alanına çevirmek.
40. K40: Belge sürümü, dili, ürün ilişkisi ve geçerliliğini tutmamak.
41. K41: Türkiye ürün güvenliği alanlarını bütün sektörlerde aynı varsaymak.
42. K42: GPSR kapsamını ürün ve teklif bazında doğrulamamak.
43. K43: DPP’yi bugün her ürün için zorunlu kabul etmek.
44. K44: 2026 DPP standart referanslarını ürün grubu düzenlemesi yerine koymak.
45. K45: PIM’in hukuki uygunluğu otomatik garanti ettiğini söylemek.
46. K46: Google id ve item_group_id’yi iç kimliğin birebir kopyası yapmak.
47. K47: 2026 konuşma odaklı Merchant alanlarını zorunlu saymak.
48. K48: Structured data, Merchant girdisi ve landing page’in birbirinin yerine geçtiğini düşünmek.
49. K49: HTTP 200 veya 201 yanıtını uçtan uca yayın başarısı saymak.
50. K50: Accepted durumunu processed veya published durumuyla birleştirmek.
51. K51: Full ve delta publish için ayrı mutabakat tasarlamamak.
52. K52: Unpublish işlemini hedef sistemden geri okumamak.
53. K53: Exactly-once teslimatı tasarım ve kanıt olmadan vaat etmek.
54. K54: Idempotency anahtarı ve payload uyuşmazlığını test etmemek.
55. K55: Retryable ve permanent hataları ayırmadan sonsuz retry yapmak.
56. K56: Backoff ve jitter olmadan bağımlı sisteme yük bindirmek.
57. K57: Out-of-order olaylarda entity version ve sequence kullanmamak.
58. K58: Dead-letter kuyruğunu ownersız arşive dönüştürmek.
59. K59: Webhook imzası ve replay koruması uygulamamak.
60. K60: Reconciliation farkını yalnız loglayıp iş kuyruğuna bağlamamak.
61. K61: Toplu düzenlemede dry-run, örnekleme ve rollback bulundurmamak.
62. K62: Audit trail’de önceki değer veya değişiklik gerekçesini tutmamak.
63. K63: Editörün kendi kritik değişikliğini onaylamasına izin vermek.
64. K64: Shared admin account kullanmak.
65. K65: Embargolu ürünü gereksiz rollere göstermek veya export ettirmek.
66. K66: API secret’larını kodda ya da maskesiz logda saklamak.
67. K67: Tedarikçi portalında tenant izolasyonunu negatif test etmemek.
68. K68: Ürün verisinin tamamını kişisel veri saymak veya içindeki kişisel veriyi hiç görmemek.
69. K69: PIM performansını yalnız toplam SKU sayısıyla değerlendirmek.
70. K70: Locale-channel-variant patlamasını kapasite testine dahil etmemek.
71. K71: Yalnız ortalama latency ölçüp P95 ve P99 kuyruğunu görmemek.
72. K72: API rate limit, pagination ve async job sınırlarını PoC’de test etmemek.
73. K73: Yedek almayı restore tatbikatıyla doğrulamamak.
74. K74: RTO ve RPO’yu bütün bileşenler için tek belirsiz sayı vermek.
75. K75: Demo ekranını PoC veya UAT kanıtı saymak.
76. K76: Migration’ı tek CSV importu olarak planlamak.
77. K77: Tam prova, delta sync, freeze ve rollback çalıştırmamak.
78. K78: Cutover’da tüketici şema ve cache uyumunu kontrol etmemek.
79. K79: Exit ve tam veri export şartını sözleşmeye koymamak.
80. K80: Yalnız lisans fiyatına bakıp temizlik, taxonomy ve entegrasyonu dışlamak.
81. K81: Açık kaynak yazılımı ücretsiz işletim sanmak.
82. K82: Roadmap’teki özelliği bugün çalışan sözleşmeli yetenek saymak.
83. K83: AI açıklaması veya attribute çıkarımını kaynaksız yayımlamak.
84. K84: AI çıktısında sağlık iddiası, telif ve marka dili riskini incelememek.
85. K85: SoloCommerce’i kanıtsız biçimde dedicated kurumsal PIM olarak sunmak.
86. K86: Yerleşik katalog yönetiminin yeterli olabileceği basit senaryoyu yok saymak.
87. K87: “Sınırsız”, “sıfır hata”, “kesin SEO artışı” veya “anlık” gibi kanıtsız vaatler kullanmak.

Toplam 87 farklı hata ve kırmızı bayrak vardır. Değerlendirme sırasında her madde “yok, kontrol altında, kabul edilmiş risk veya bloke edici” olarak sınıflandırılmalı; karar, satış sunumuna değil test ve sözleşme kanıtına bağlanmalıdır.

90 günlük temsili PIM yol haritası nasıl planlanabilir?

Doksan günlük plan evrensel uygulama süresi veya canlıya geçiş garantisi değildir; keşif, karar ve kontrollü ilk kapsam için temsili bir çerçevedir. Karmaşık kataloglarda süre uzayabilir veya yalnız PoC tamamlanabilir. Her aşamada kapsam, owner, kanıt ve çıkış kapısı bulunmalı; veri kalitesi veya entegrasyon riski kabul eşiğini aşarsa sonraki faza otomatik geçilmemelidir.

SoloCommerce ile yerleşik katalog mu, ayrı PIM mi seçilmeli?

SoloCommerce’in canlı ürün, kategori, varyant, set ürün, katalog, blog/SEO ve ilgili paketlerde ürün eşleştirme yetenekleri birçok e-ticaret operasyonunda pratik bir başlangıç olabilir; bu kapsam ayrı kurumsal PIM vaadi değildir. Basit katalogda yerleşik yönetim, karmaşık çok kaynaklı yapıda ayrı PIM, arada ise özel entegrasyon değerlendirilebilir. Karar güncel paket, demo, fit-gap, teklif ve sözleşmeyle verilmelidir.

Güncel özellik ve paket sınırını SoloCommerce paket karşılaştırmasında incelemek ilk adımdır. Çok kanallı operasyon bağlamı için SoloCommerce pazaryeri entegrasyonu sayfası ayrıca kontrol edilebilir; canlı sayfadaki tüm ifadeler sözleşmeli kapasite veya SLA sayılmamalıdır. Fit-gap sonrasında katalog ihtiyacına uygun paket kapsamı ve gerekirse Enterprise özel entegrasyon seçeneği güncel teklif üzerinden doğrulanmalıdır.

Sıkça Sorulan Sorular

Ürün modeli nedir?

Kanonik varlık diyagramı ürün ailesi, model, parent, varyant ve SKU’yu ayırıyor. Product, Offer ve Inventory alanları ayrı şema ve owner taşıyor. Her attribute için veri tipi, kardinalite ve uygulanabilirlik tanımlandı.

Set ürün ile varyant arasındaki fark nedir?

Sağlam bir PIM modeli ürün ailesini ortak nitelik şeması, ürün modelini ticari kavram, varyantı satılabilir seçeneği ve SKU’yu işletme içi stok tutma birimini ayrı tanımlar. Parent kayıt kimi platformda yalnız gruplama düğümüdür ve satılamaz; başka bir platformda ayrı kayıt olabilir.

Kanonik ürün veri modeli nedir?

Kanonik model, her kaynağın veya kanalın alanlarını kopyalayan en büyük tablo değildir; işletmenin kararlı ürün anlamlarını, kimliklerini, veri tiplerini, birimlerini, kapsamlarını ve ilişkilerini tanımlayan ortak sözleşmedir.

Kısa Değerlendirme

PIM, e-ticarette ürün bilgisini güvenilir ve çok kanallı hâle getirebilir; fakat bunu tek başına ekran, import veya konektör değil, kanonik model, alan sahipliği, kalite kapıları, insan onayı, sürüm, audit, lineage, güvenli entegrasyon ve geri okuma birlikte sağlar. Ayrı PIM gerekip gerekmediğini SKU eşiğiyle değil, veri karmaşıklığı ve riskle değerlendirin; her vaadi gerçek katalog, PoC, UAT ve üç yıllık TCO kanıtına bağlayın.

Yerleşik katalog yetenekleri ihtiyacı karşılıyorsa gereksiz mimari yük eklemeyin. Çok kaynaklı, çok dilli ve çok kademeli yapıda ise PIM ile ticaret platformunun yetkili alanlarını açıkça ayırın. SoloCommerce kapsamını değerlendirmek için canlı paket sayfası, gerçek ürün-varyant denemesi ve yazılı teklif üzerinden ilerleyin; performans, doğruluk, SEO, satış veya mevzuat uyumu konusunda kanıtsız garanti kabul etmeyin.