Unified Commerce'ta satış kanalı ile müşteri yolculuğu neden aynı şey değil?

Bir müşteri mağazada bir pantolon deniyor. Satış danışmanıyla beden ve kalıp tercihini konuşuyor, farklı renkleri inceliyor ama o gün satın almıyor. Üç gün sonra Bonobos’un online mağazasına girip sipariş veriyor. Order kaydında satış kanalı Online Store.

Peki bu satışı hangi mağaza yaptı?

Online Store, işlemin gerçekleştiği kanalı açıklar. Mağaza ziyareti ve satış danışmanının yardımı da müşterinin karar sürecine katkı sağlamış olabilir. İkisini tek bir cevaba sıkıştırmak, hem işlemin kaynağını hem de müşteri yolculuğunu yanlış modelleme riski taşır.

Bonobos’un Shopify ile 14 Ekim’de duyurduğu e-commerce yenilemesi bu ayrımı tartışmak için somut bir örnek. Şirket; müşteri beden tercihlerini satış sistemleri ve Bonobos.com arasında eşitleyen My Fit profillerini, mağaza fitting room deneyiminden sonra otomatik takibi, Shopify POS ile web’de incelenen ürünleri mağaza checkout’ına taşıma imkânını ve mağaza check-in’inden sonraki yedi gün içinde online veya mağazada gerçekleşen alışverişleri mağaza lokasyonu ve Guide ile ilişkilendiren bir sistemi açıkladı. Duyuruda 48 Guideshop bilgisi yer alıyor. Bunlar şirketin açıkladığı kapsam; belirli bir artış veya nedensel satış etkisi paylaşılmıyor.

Bu özellikler aynı “omnichannel” başlığı altında toplansa da farklı problemleri çözüyor. My Fit müşteri bağlamının kanallar arasında kullanılmasına, browse-on-web checkout sepetin mağaza işlemine taşınmasına, follow-up ise ziyaret sonrasında iletişimin sürmesine hizmet ediyor. Cross-channel attribution da mağaza ziyareti ile daha sonra gerçekleşen sipariş arasında ilişki kuruyor. Bunları tek bir “ortak commerce deneyimi” etiketi altında eritmek, her birinin veri ve ürün gereksinimini görünmez kılabilir.

Beş kavramı ayırmak

Transaction Channel, siparişin veya ödemenin gerçekleştiği kanaldır. Online Store, POS, marketplace veya başka bir satış yüzeyi olabilir. Raporlamada hangi sistemin siparişi kabul ettiği, ödemenin nerede yapıldığı ve hangi operasyonel akışın çalıştığı bu tanıma bağlı olabilir.

Customer Touchpoint, müşteri ile marka, mağaza veya çalışan arasındaki belirli etkileşimdir: mağaza ziyareti, fitting room kullanımı, danışman görüşmesi, online ürün görüntüleme veya takip mesajı gibi. Touchpoint sipariş değildir ve tek başına bir satış yaratmış olduğunu göstermez.

Customer Journey, bu etkileşimlerin zaman içindeki ilişkili bütünlüğüdür. Yolculuk farklı kanallara, cihazlara ve çalışanlara yayılabilir. Bir müşteri birden fazla mağazaya uğrayabilir, tekrar web’e dönebilir ve daha sonra satın alabilir.

Sales Attribution, siparişi bir touchpoint, mağaza, kampanya veya çalışanla belirli bir kurala göre ilişkilendirme yöntemidir. Bu kural örneğin “check-in’den sonraki yedi gün” olabilir.

Incrementality, touchpoint gerçekleşmeseydi sonucun ne ölçüde farklı olacağını anlamaya çalışan ölçüm problemidir. Doğrudan gözlenemeyen karşı olgusal bir kıyas gerektirir; basit bir ilişkilendirme kuralıyla cevaplanamaz.

Dolayısıyla Transaction Channel ≠ Customer Journey. Online Store’da gerçekleşen order’ın mağaza ziyaretiyle ilişkilendirilmesi, order’ın kanalını değiştirmez. Aynı şekilde satış danışmanına atfedilen bir işlem, müşterinin yolculuğundaki diğer etkileşimleri ortadan kaldırmaz.

Ortak capability’ler yolculuk modelinin yerini tutmuyor

Unified Commerce’ı POS ve storefront’un tek bir uygulama olması şeklinde düşünmek zorunda değiliz. POS ve Online Store ayrı uygulamalar olabilir; ama aynı customer, product, pricing, inventory ve order capability’lerini kullanabilir. Bu ortaklık, kanal deneyimlerinin daha tutarlı işlemesine ve aynı commerce state’e dayanmasına yardım eder.

Yine de ortak commerce state, müşteri yolculuğunun eksiksiz ölçüldüğü anlamına gelmiyor. Order sistemi siparişin durumunu, ürün ve fiyatı tutabilir. Mağaza ziyareti, fitting room denemesi veya danışman konuşması ise farklı bir olay türü. Bunları order tablosuna eklemek, satışla sonuçlanmayan ama değerli olabilecek etkileşimleri sipariş kaydı gibi göstermeye ve aynı order’ı yinelenen temaslarla çoğaltmaya yol açabilir.

Journey event’lerinin ayrı bir modelde tutulması daha açık sınırlar sunar. Her olayın zamanı, mağazası veya kanalı, ilgili müşteriyle eşleşme güveni, kaynağı, amacı ve izin durumu olabilir. Bazı olaylar müşteri tarafından açıkça tanımlanabilir; bazıları check-in veya sistem etkileşiminden türetilebilir. Her eşleşme aynı kesinlikte değildir. Bu nedenle identity resolution sonucu ve kullanılan kural da veriyle birlikte değerlendirilmeli.

Bonobos’un örneğinde mağaza check-in’i, fitting room deneyimi ve daha sonraki online sipariş ayrı kayıtlar olarak düşünülebilir. Attribution kuralı bunları bir raporlama görünümünde bağlar. Böylece siparişin orijinal kanalı korunurken mağaza ve Guide katkısı da işletmenin belirlediği yöntemle ölçülebilir. Kuralın kendisi veri modeline gömülü tek bir gerçek gibi değil, değiştirilebilir ve açıklanabilir bir ölçüm politikası olarak ele alınmalı.

Benim kavramsal modelim şu:

Commerce Transactions + Customer Journey Events → Identity Resolution → Attribution & Measurement → Operational Insights

Bu Bonobos veya Shopify’ın resmî mimarisi değil, commerce platformu ve analitik tasarımı için bir öneri. Transaction kayıtları ticari işlemin state’ini taşırken journey event’leri etkileşimleri taşır. Identity resolution bunları izin verilen kapsamda bağlar. Ölçüm katmanı ise kullanılan atıf kuralını ve belirsizliği korur.

Yedi günlük pencere ne söyler, ne söylemez?

Bonobos duyurusu, check-in’den sonraki yedi gün içinde online veya yüz yüze yapılan alışverişlerin orijinal lokasyon ve Guide’a atfedileceğini söylüyor. Bu pencere operasyonda net bir kuraldır: hangi siparişlerin hangi mağaza ve çalışanın etki raporuna dahil olacağını belirler. Süre kısalır veya uzarsa raporlanan katkı değişebilir; ürün kategorisi ve satın alma döngüsü de uygun pencereyi etkileyebilir.

Ancak Attribution ≠ Incrementality. Siparişi mağaza ziyaretiyle ilişkilendirmek, ziyaret olmasaydı siparişin gerçekleşmeyeceğini kanıtlamaz. Müşteri zaten ürünü online’da bulmuş, satın alma niyetini tamamlamak üzere mağazaya uğramış olabilir. Ya da mağaza deneyimi tereddüdünü giderip siparişi mümkün kılmış olabilir. Gözlenen tek yolculuk bu iki senaryonun hangisinin doğru olduğunu tek başına söylemez.

Çalışan performansı ve mağaza başarısı bu ayrımın gerçek etkisini taşır. Atfedilen online order çalışan primine dahil edilecek mi? Aynı order hem online kanal satışına hem mağaza etkisine raporlanabilir mi? Eğer raporlanabiliyorsa, şirket toplam satışını hesaplarken iki kez saymayı nasıl önleyecek? Mağazalar farklı check-in alışkanlıklarına veya farklı müşteri profillerine sahipse karşılaştırma adil olacak mı?

Bunların evrensel bir cevabı yok. Bir organizasyon mağazaya yardımcı satış kredisi verebilir ama işlemi online channel revenue olarak bırakabilir. Başka bir şirket primi ekip bazında paylaşabilir. Önemli olan kanal gerçeğini değiştirmeden katkı kuralını açıkça tanımlamak, çalışanların anlayabileceği biçimde açıklamak ve finansal toplamların mükerrerleşmesini önlemek. Daha ileri bir incrementality analizi ise karşılaştırılabilir gruplar, deney veya başka uygun ölçüm tasarımı gerektirebilir.

Bu politika mağaza ve online ekipleri arasındaki iş bölümünü de etkiler. Eğer online order hiçbir zaman mağaza çalışanına katkı sayılmıyorsa, danışmanın müşteriyle ilişki kurup doğru fit bilgisini kaydetmek için ayırdığı zaman görünmez kalabilir. Tersine, her siparişi son ziyaret edilen mağazaya yazmak, çalışanlara veya lokasyonlara gerçek dışı kredi verebilir. Mağaza ekibi müşteriyi tanıyor olabilir; fakat siparişin online gerçekleşmesinde arama, kampanya, ürün bulunurluğu veya müşterinin önceki niyeti de rol oynamış olabilir.

Bu yüzden raporlama tek bir “satış sahibi” alanına indirgenmek zorunda değil. Order’ın transaction channel’ı, mağaza touchpoint’i, Guide ilişkisi ve kullanılan attribution kuralı ayrı boyutlar olarak tutulabilir. Prim veya performans hesaplaması bunlardan bir veya birkaçını işletme politikasına göre kullanır. Kural değiştiğinde geçmiş sonuçları yeniden yorumlayabilmek için ölçüm sürümü ve geçerlilik tarihi de kaydedilmelidir. Böyle bir model yöneticilere farklı görünümler sağlar, ancak finansal toplamı yine order’ın tekil kimliğine dayandırır.

Kuralın adil algılanması için çalışanların neyin kayda alındığını bilmesi de önemli. Check-in, müşteriyle etkileşimin gerçekleştiğine dair kanıt olabilir; ancak konuşma içeriğinin veya çalışan davranışının bütün ayrıntılarını toplamak zorunlu değildir. Yalnızca katkı kuralı için gereken event ve ilişkiyi saklamak, hem veri minimizasyonuna hem çalışan güvenine yardımcı olur. Mağazalar arasında check-in uygulaması eşit değilse, raporlanan katkı gerçek hizmet farkından çok kayıt alışkanlığını yansıtabilir; bu nedenle veri kalitesi de değerlendirilmelidir.

Kimliği bağlamak, veriyi serbest bırakmak değildir

Mağaza ziyaretini online siparişle eşleştirmek müşteri kimliği ve veri işleme kararları içerir. Check-in müşterinin açık eylemi mi? Çalışan müşteri adına mı kaydediyor? Bu kayıt ne kadar süre saklanıyor ve hangi amaçla kullanılıyor? Müşteri kimliği bir e-posta, telefon numarası veya hesap üzerinden eşleştiriliyorsa eşleşmenin doğruluğu nasıl ölçülüyor? Hatalı eşleşme başka bir kişinin mağaza davranışını sipariş geçmişine bağlayabilir.

Bu nedenle consent, veri minimizasyonu, saklama süresi ve erişim yetkisi tasarımın parçası olmalı. Mağaza yöneticisinin ihtiyaç duyduğu performans görünümüyle pazarlama ekibinin istediği müşteri yolculuğu analizi aynı erişim düzeyini gerektirmeyebilir. Müşterinin servis için verdiği bilgi, sınırsız davranış profilleme izni olarak yorumlanmamalı. Hangi verinin hangi amaçla kullanıldığı ve müşterinin tercihlerini nasıl yönettiği açık olmalı. Bu yazı hukuki görüş değil; kimlik ve ölçüm modelinin ürün gereksinimleri üzerine bir değerlendirme.

Birleştirme hatalarının nasıl ele alınacağı da deneyimin parçası. İki kişi benzer iletişim bilgileri kullanıyorsa veya müşteri misafir olarak checkout yaptıysa, sistemin güveni düşük eşleşmeyi kesin müşteri geçmişi gibi sunmaması gerekir. Olaylar bir hesaba bağlanmadan saklanabilir ya da çalışan doğrulaması istenebilir. Müşteri hesabını veya iletişim tercihini değiştirdiğinde geçmiş ilişkiler üzerinde ne yapılacağı, saklama ve silme süreçleriyle tutarlı olmalı. Veri erişimi sonradan denetlenebilmeli: hangi role, hangi amaçla, hangi customer context gösterildi?

Attribution için toplanan verinin ikincil kullanımı da ayrıca düşünülmeli. Bir mağaza performans raporu için kaydedilen check-in’in pazarlama hedeflemesinde kullanılması, müşteri açısından beklenen amaç olmayabilir. Ürün ekipleri event şemasına amaç ve izin bağlamı ekleyebilir; analitik katmanı da yalnızca uygun kullanım koşullarını karşılayan verileri değerlendirmeye alır. Bu kontroller ilk sürümde tüm senaryoları çözmese bile, yolculuk olaylarının rastgele loglardan ibaret kalmasını önler.

Bonobos örneğindeki My Fit profili, beden tercihinin farklı satış sistemleri ve web deneyimi arasında taşınabileceğini gösteriyor. Bu, yararlı bir müşteri bağlamı; ama kimlik ve erişim politikası olmadan her yüzeye açılması gereken bir veri değil. Fit bilgisini mağazada servis için kullanmakla, tüm davranış geçmişini tüm çalışanlara sunmak birbirinden farklı kararlardır.

Unified Commerce’ın bir sonraki ölçüm problemi

Ortak customer, product, inventory ve order capability’leri kanalların aynı commerce gerçekliğinde çalışmasını sağlayabilir. Müşteri yolculuğu ise o gerçekliğin çevresinde oluşan etkileşimleri, izinleri ve ölçüm kurallarını da kapsar. Bonobos × Shopify duyurusu, siparişin nerede gerçekleştiği ile müşteriye nerede ve kim tarafından yardım edildiğini aynı deneyim içinde ilişkilendirmeye çalışıyor.

Bu yön, mağazanın yalnızca fiziksel satış noktası değil; keşif, fit danışmanlığı, servis ve dönüşüm yolculuğunun parçası olduğu bir modele işaret ediyor. Bunun çalışması için event’lerin order’dan ayrılması, müşteri kimliğinin kontrollü çözülmesi ve attribution kuralının gerçek işlem kanalını değiştirmeden uygulanması gerekir. Ayrıca atfedilen katkıyı nedensellik iddiasına dönüştürmeden ölçmek gerekir.

Unified Commerce’ın ürün değeri böylece iki tamamlayıcı alanda ortaya çıkabilir: ortak transaction capability’leri ve kanallar arasında anlaşılabilen müşteri yolculuğu. Aralarındaki bağ, tek bir veri tabanına her şeyi koymak değil; farklı kayıtların anlamını koruyarak onları izinli ve açıklanabilir biçimde ilişkilendirmek.

İlgili olarak Salesforce’un POS ve B2C Commerce inventory paylaşımı ortak commerce state’inin altyapı tarafını gösteriyor. AI agent’lar için satış kanalı tartışması ise yeni interface’lerin mevcut transaction capability’lerini nasıl kullanabileceğini ele alıyor. Bu yazıdaki mesele ikisinden farklı: işlemin hangi kanalda oluştuğu belli olsa bile yolculuktaki katkının nasıl temsil edileceği.

Kaynaklar

Bonobos / PR Newswire — Shopify-powered omnichannel shopping experience — Kaynak tarihi: 14 Ekim 2026. Ürün özellikleri ve yedi günlük attribution kuralı şirket duyurusunda aktarıldığı biçimiyle kullanılmıştır.

Shopify — Point of Sale