Headless commerce'tan sonra headless customer data mı geliyor?

Headless commerce bize bir ayrımı uzun süredir anlatıyor: ürün, fiyat, stok, sepet ve sipariş capability’leri tek bir storefront’a bağlı olmak zorunda değil. Web mağazası, mobil uygulama, POS veya başka bir kanal aynı iş kurallarını kullanan platform servislerine erişebilir. Yeni olan, farklı kullanıcı arayüzlerinin sayısı değil. Platform capability’lerini bu arayüzlerden bağımsızlaştırma fikri.

AI agent’lar bu ayrımı yeni bir yere taşıyor. Kullanıcı işi yapmak için her seferinde ürünün kendi yönetim ekranına girmek zorunda kalmayabilir; bir asistana amacını söyleyebilir. Fakat agent’ı yalnızca yeni bir ekran gibi görmek eksik kalır. Arayüz bilgiyi gösterir ve kullanıcı eylemini toplar. Agent ise verileri yorumlayabilir, seçenek üretebilir, birden fazla capability’yi sıraya koyabilir ve yetki verildiyse işlem çağrısı yapabilir. Bu nedenle agent’ı platforma bağlamak, yeni bir istemciye API vermekten daha geniş bir ürün ve yönetişim problemidir.

Headless’in bugünkü anlamı

Headless mimarinin yaygınlaşmasında temel motivasyon, iş yeteneklerini tek bir deneyimden ayırmaktı. Aynı fiyat ve ürün kurallarını kullanan online store ile POS, farklı kullanıcı deneyimleri sunabilir. Ekranların her biri kendi commerce gerçeğini yaratmaz; platformdaki ortak capability’lere erişir.

Bu yaklaşımın yönetim tarafındaki olası devamını headless admin yazısında ele almıştım: ürün, fiyat veya sipariş işlemlerine ulaşmak için platformun kendi Admin ekranı tek yol olmak zorunda mı? Buradaki soru farklı. Müşteri verisini yalnızca hangi arayüzden göreceğimiz değil, agent’ın farklı sistemlerden oluşturduğu customer context’i hangi kararla kullanabileceği.

Bir pazarlama yöneticisinin son 90 günde alışveriş yapmamış, belirli kategorilerle ilgilenen ve yüksek müşteri değerine sahip kişileri analiz etmek istediğini düşünelim. Bu segmenti tanımlamak için siparişler Commerce’te, kategori affinity’si CDP veya analitik platformunda, müşteri değeri CRM ya da Loyalty sisteminde olabilir. Agent bir sorgu yazmaktan önce bu bilgilerin hangi anlamda birleştirilebileceğini ve kullanıcının bunları görmeye yetkili olup olmadığını bilmek zorunda.

Cordial örneği neyi gösteriyor?

Cordial, 11 Haziran 2026 tarihli duyurusunda AI headless infrastructure’ını kullanıma açtığını belirtti. Şirket MCP, CLI, API ve geliştirici araçlarını platform capability’lerine erişim yüzeyleri olarak tanımlıyor. Duyuruda audience logic, message generation, brand validation ve send execution gibi servislerin agent’larca kullanılmasından; Context Services ve raporlama yeteneklerinden söz ediliyor. Aynı açıklamada genel kullanım için önceden hazırlanmış agent harness’leri ve native agentic interface’in gelecekte sunulacağı belirtiliyor. Yani duyuru mevcut altyapı ile ilerideki ürün planlarını ayırıyor.

29 Ekim tarihli Headless CDP duyurusu bunun üzerine müşteri verisini AI çalışma ortamlarına taşıyor. Cordial, Claude, ChatGPT, Microsoft Copilot veya özel agent’lar üzerinden gerçek zamanlı müşteri verisini inceleme ve görselleştirme olanağı sunduğunu söylüyor. Şirket, Boot Barn ve Torrid gibi markaların kendi açıklamasına göre CDP üzerinden kitleleri incelediğini, fırsatları ve sonraki aksiyon önerilerini değerlendirdiğini aktarıyor. Ayrıca commerce, analytics ve data warehouse sistemlerinden gelen verilerle birlikte çalışmayı hedef olarak gösteriyor.

Burada şirketin ürün iddiasını, genel bir mimari kanıtla karıştırmamak gerek. Cordial’ın kendi müşterileri ve ürünü için anlattığı kullanım, tüm CDP’lerin müşteri bağlamını aynı gecikme, kimlik eşleştirme kalitesi veya yönetişim düzeyiyle birleştirebildiğini göstermiyor. Duyurudaki “real-time” ifadesi de kaynakların her biri için aynı tazelik garantisini, tutarlılık modelini ya da işlem anındaki güncelliği açıklamıyor. Bunlar uygulama ve sözleşme düzeyinde ayrıca sorulması gereken konular.

Customer Context tek bir müşteri tablosu demek değil

“Müşteri 90 gündür alışveriş yapmadı” tanımı ilk bakışta basit görünüyor. Fakat hangi siparişler sayılıyor? İade edilmiş işlemler düşülüyor mu? Mağaza ve online sipariş aynı kimliğe bağlanmış mı? Misafir checkout’ları eşleştirilmiş mi? Kategori ilgisi son gezintilerden mi, satın almalardan mı, model tahmininden mi geliyor? Müşteri değeri hangi zaman penceresinde ve hangi para biriminde hesaplanıyor?

Birleştirilmiş Customer Context tek bir merkezi veri tabanı gerektirmek zorunda değil. Bazı bilgiler kaynak sistemden gerçek zamanlı okunabilir; bazıları analitik depoda hesaplanabilir; bazıları da işletmenin tanımladığı bir kimlik grafiğinden gelebilir. Önemli olan bütün veriyi tek yerde toplamak değil, belirli karar için hangi kaydın yetkili olduğunu ve güncelliğinin ne anlama geldiğini bilmek.

Kimlik eşleştirmesi de sessizce kesin kabul edilmemeli. E-posta adresi değişmiş, aynı evde iki kişi aynı cihazı kullanmış veya geçmiş kayıtlar farklı müşteri kimlikleriyle tutulmuş olabilir. Agent’ın yanlış kişiye ait alışveriş geçmişini bir profile bağlaması, yalnızca segment sayısını bozan bir analitik hata değildir; müşterinin özel bilgisinin uygunsuz biçimde görünmesine veya yanlış kampanya almasına neden olabilir. Eşleşme güveni düşükse sonuç bunu işaretlemeli, belirsiz kişileri kapsam dışında bırakabilmeli ve düzeltme yolunu kaydetmelidir.

Bu yüzden Customer Context’i “agent’a verilen bütün müşteri alanları” olarak değil, belirli bir amaca yönelik, zaman damgalı ve kaynağı bilinen veriler olarak düşünmek daha sağlıklı. Her değer için kaynak sistem, güncellenme zamanı, hesaplama veya tahmin yöntemi, kimlik eşleşmesinin güveni ve kullanım kısıtı anlamlıdır. Bir segment önerisinin açıklanabilir olması, hem pazarlama kararını hem müşteri itirazını ele almayı kolaylaştırır.

Analiz başka, kampanya göndermek başka

Örnekteki agent yetkisi dahilinde gerekli veriyi okuyup segmenti önerebilir. Bu, kampanyayı gönderebileceği anlamına gelmez. Bir hedef kitleyi analiz etme, yeni segment kaydetme, kampanya içeriği oluşturma, bir kampanyayı onaya sunma ve gönderimi başlatma farklı etkileri olan işlemlerdir. Yetkilendirme de “agent’a Cordial erişimi verdik” gibi tek bir izinle çözülmemeli.

Gönderim anında ilgili kanal için ticari ileti izinleri ve opt-out bilgisi, frekans sınırları, hedef kitle kuralları, kampanya zamanı, marka onayı ve kullanıcının rolü kontrol edilmelidir. Bu kuralların her AI prompt’una kopyalanması ciddi bir tasarım hatası olur. Agent bağlamı kaybedebilir, eski talimatla çalışabilir veya aynı kural başka bir kanalda farklı uygulanabilir. İş kuralları onları yöneten yetkili sistemlerde kalmalı; agent işlem talebi üretse de son doğrulama bu sistemlerde yapılmalı.

Bu akışın benim önerdiğim kavramsal modeli şöyle:

Customer Context → Audience Analysis → Campaign Proposal → Policy Validation → Authorization → Execution → Audit

Bu, Cordial’ın açıklanmış teknik mimarisi değil; müşteri verisi analizinden ticari aksiyona geçişi tasarlamak için kullandığım ürün modeli. Agent önce izinli veriyle analiz yapar ve öneri üretir. Öneri uygulanmadan önce kampanya motoru veya ilgili domain servisleri hedef kitlenin kurallarını, ileti izinlerini ve frekans koşullarını doğrular. Kullanıcı ya da uygun rol gerekli onayı verir. İşlem yürütülür, sonuç ve karar zinciri denetlenebilir bir kayda dönüşür.

Bir segmenti kaydetmek de etkisiz bir okuma değildir. Bu kayıt daha sonra başka kullanıcılarca kampanya hedefi olarak kullanılabilir. Bu nedenle segment oluşturma yetkisi ile salt analiz yetkisini ayırmak gerekir. Kampanya taslağı oluşturma da gönderim iznini içermemeli. Gönderim, ayrı bir yüksek etkili işlem olarak ele alınmalı; kapsam, kanal ve tahmini alıcı sayısı onay ekranında açıkça gösterilmelidir. İşlem çok büyük veya alışılmadık bir kitleyi kapsıyorsa ek onay ya da belirlenmiş sınırların aşılmaması gerekir.

Agent kimliği ile kullanıcı kimliği de birbirine karıştırılmamalı. Kullanıcı adına çalışan bir agent, kullanıcı yetkisini devralmış olabilir ama kendi çalışma bağlamı ve teknik kimliği de izlenebilir olmalı. Denetim kaydı “hangi kullanıcı hangi agent aracılığıyla hangi veri kapsamını kullandı, hangi öneri üretildi, hangi politika kontrol edildi, kim onayladı ve ne çalıştı?” sorularına yanıt vermeli. Hatalı gönderim durumunda kampanyayı durdurma, kalan alıcıları engelleme veya uygun düzeltme iletişimi gibi geri alma ve telafi yolları önceden tasarlanmalı. E-posta gönderildikten sonra her şeyi geri almak mümkün değildir; bu nedenle geri alınabilirlik beklentisi, yürütme öncesi kontrolü ikame etmez.

Türkiye’deki uygulamalar için KVKK ve ticari ileti kuralları da bu tasarımın dışında düşünülemez. Hangi verinin hangi amaçla işlendiği, agent sağlayıcısına hangi alanların gönderildiği, saklama süresi ve kullanıcı erişimleri gözden geçirilmeli. “MCP bağlantısı var” demek, bu işleme amaçlarının veya hukuki dayanağın kendiliğinden uygun olduğu anlamına gelmez. Veri minimizasyonu önemlidir: analiz için gerekiyorsa agent’a tüm profil alanlarını vermek yerine belirli segment koşullarının sonucunu ya da takma adlı kayıtları sunmak mümkün olabilir.

MCP, API ve headless aynı şey değil

MCP, bir AI uygulamasının araç ve bağlam kaynaklarını keşfetmesi ve çağırması için kullanılan bir entegrasyon mekanizmasıdır. API, sistemin işlevlerini çağırmaya yarayan sözleşmeleri ve uç noktaları tarif eder; bu API MCP arkasında sunulabilir veya başka istemcilerce doğrudan kullanılabilir. Headless ise capability’lerin belirli bir kullanıcı arayüzüne sıkı biçimde bağlı olmadan sunulmasına ilişkin daha geniş mimari yaklaşımı anlatır.

Hiçbiri tek başına güvenlik ve iş yönetişimi çözümü değildir. MCP bir işlemin meşru olup olmadığını belirlemez; iyi tanımlanmış bir API de çağıranın müşteri verisini görme veya kampanya gönderme yetkisini otomatik sağlamaz. Her araç için kimlik doğrulama, kapsamlı yetki, amaç sınırlaması, alan düzeyinde veri erişimi, oran sınırı, onay ve denetim tasarlanmalıdır. Bağlantı protokolü capability’ye ulaşma yolunu sağlar; capability’nin hangi koşullarda çalışabileceğini iş kuralları belirler.

Commerce platformları nasıl hazırlanmalı?

Agent kullanımına hazır bir commerce veya marketing platformu yalnızca daha fazla endpoint yayımlamamalı. Müşteri, sipariş, ürün ve kampanya kavramlarının tutarlı tanımları; sorgu ve işlem sözleşmelerinin ayrılması; veri tazeliği ve kaynak sahipliğinin belirtilmesi gerekir. Bir sorgu “90 gün” penceresinin takvim günü mü, UTC mi, yerel saat mi olduğunu ve iade durumunun hesabı nasıl etkilediğini açıklayabilmeli. İşlem API’si ise önkoşulları, yan etkileri, idempotency davranışını, hata kodlarını ve hangi onayın gerektiğini bildirmeli.

İzinler de tek bir rol adına indirgenmemeli. Agent’ın hangi müşteri alanlarını okuyabileceği, hangi audience koşullarını çalıştırabileceği, segment kaydedip kaydedemeyeceği ve kampanyanın hangi aşamasına kadar ilerleyebileceği ayrı capability’ler olarak modellenebilir. Platform, “bu agent kullanabilir” kararı yanında kaynak veriyi güncel tutan sistemin cevabını ve işlem anında yeniden kontrol edilen kuralları da görünür kılmalı.

Operasyonel hata yönetimi de sözleşmenin parçası. Birden fazla sistemden veri okunurken kaynaklardan biri erişilemiyorsa agent eski veriyi güncelmiş gibi sunmamalı. Audience sayısı kampanya onayı ile gönderim arasında değişirse hedef kitle yeniden hesaplanmalı veya kullanıcı bilgilendirilmeli. Yetki geri alındığında devam eden agent oturumları da bu değişikliği takip etmeli. Her çağrı için aynı izin kararının sonsuza kadar geçerli olduğunu varsaymak güvenli değil.

Agent’lar yeni bir arayüz yüzeyi sunuyor; aynı zamanda analizi işlemlere bağlayan yeni bir yürütme aktörü oluyor. Bu yüzden platformların olgunluğu “MCP sunucusu var mı?” sorusuyla ölçülemez. Daha belirleyici olan, müşteri bağlamını doğru ve amaca uygun sunarken analiz ile ticari eylem arasındaki sınırı koruyabilmeleri. Headless customer data’nın değeri, verinin her yere akmasında değil; her agent’ın yalnızca gerekli bağlamı görmesi, önerinin kural sahibince doğrulanması ve gerçek işlemin kimin yetkisiyle yapıldığının kanıtlanabilmesinde yatıyor.

Kaynaklar

Cordial / PR Newswire — Cordial Launches Headless CDP, Bringing Real-Time Customer Data to Where Marketers Work — Kaynak tarihi: 29 Ekim 2026. Ürün ve müşteri kullanım bilgileri Cordial’ın duyurusundaki şirket açıklamaları olarak aktarılmıştır.

Cordial — Headless or walled: Cordial draws the line on how AI agents should work — Kaynak tarihi: 11 Haziran 2026. Haziran duyurusundaki mevcut altyapı ile geleceğe dönük ürün ifadeleri ayrıştırılmıştır.