Ajanın satın alma sürecini devralması ne demek?
Agentic commerce, kullanıcının ürünü kendisi arayıp sepete eklemesi yerine, verdiği hedefi bir yapay zeka ajanının uçtan uca yürütmesidir. Kullanıcı "on iki yaşındaki bir çocuğa uygun, iki bin liranın altında su geçirmez bir spor saat bul ve satın al" der. Ajan bu cümleyi alt kriterlere böler, aday ürünleri toplar, fiyat ve stok durumunu karşılaştırır, birini seçer ve ödeme adımını kullanıcının önceden verdiği yetkiyle tamamlar.
Kırılma noktası kararın nerede verildiğidir. Klasik e-ticarette satıcı, insanın gözüne girmek için çalışır: görsel kalitesi, başlık, sosyal kanıt, kampanya rozeti. Agentic akışta araya bir yazılım katmanı giriyor ve bu katman sayfayı bir insan gibi görmüyor. Ürünü alanlara ayrılmış veri olarak okuyor, kriterlere göre puanlıyor, eşleşmeyeni aday listesinden düşürüyor. Görselin güzelliği bu aşamada bir girdi değil.
Klasik e-ticaret hunisiyle arasındaki gerçek fark
Klasik huni gösterim, tıklama, gezinme, sepet ve ödeme adımlarından oluşur ve her adım insan dikkatine göre optimize edilir. Kategori sayfasında dolaşan bir kullanıcı fikrini değiştirebilir, bir bannerdan etkilenebilir, benzer ürün önerisine kayabilir. Ajan bu adımların ortasını atlıyor. Kategori sayfasında gezinmiyor, kampanya kurgusundan etkilenmiyor, çapraz satış bloğunu görmüyor.
Bunun iki sonucu var. Birincisi, rekabet yüzeyi sunumdan veri bütünlüğüne kayıyor. İkincisi, sonuç kümesi daralıyor. Arama sonuç sayfasında on bağlantı arasından seçim yapan kullanıcının yerine, iki üç adayı karşılaştırıp bir tanesini öneren bir ajan geçiyor. Sayfanın arama motoru optimizasyonu tarafındaki performansı hâlâ önemli, çünkü ajanlar aday havuzunu büyük ölçüde arama altyapılarından ve satıcının kendi verdiği veriden kuruyor. Ama sıralamada üçüncü olmakla aday listesinden düşmek arasındaki fark, tıklama oranı farkından çok daha keskin.
Ajan bir ürünü nasıl buluyor?
Ajanın bir ürünü değerlendirebilmesi için o ürünün üç ayrı yerde tutarlı biçimde tanımlı olması gerekiyor: satıcının gönderdiği ürün feed'inde, ürün sayfasının kendisinde ve satıcının makine tarafından çağrılabilir uçlarında.
Ürün feed'i ajanın gördüğü asıl katalog
Agentic Commerce Protocol tarafında ürün feed'i zorunlu bir bileşen. OpenAI'ın yayımladığı feed şartnamesinde her satır için istenen alanlar arasında ürün kimliği, başlık, açıklama, ürün sayfası adresi, marka, görsel adresi, fiyat ve stok durumu bulunuyor. Buna ek olarak ürünün arama ve ödeme akışlarında kullanılıp kullanılamayacağını belirten iki uygunluk bayrağı isteniyor. Ödemeye açık ürünlerde satıcının gizlilik politikası ve kullanım koşulları da zorunlu alan haline geliyor. Feed satıcı tarafından gönderiliyor, yani ajan siteyi tahmin ederek okumuyor, satıcının beyan ettiği veriyi kullanıyor.
Google tarafında karşılığı Merchant Center. Universal Commerce Protocol'ün ilk referans uygulamasında bir işletmenin ürünlerinin konuşma temelli yüzeylerde görünebilmesi için aktif bir Merchant Center hesabı ve ödemeye uygun ürünler gerekiyor. İki ekosistem de aynı mantıkta çalışıyor: ajan katalogla değil, satıcının teslim ettiği yapılandırılmış katalog kopyasıyla muhatap oluyor.
Sayfa üstündeki yapılandırılmış veri
Feed tek başına yeterli değil, çünkü ajanların bir kısmı ürün sayfasını da doğrudan okuyor ve feed ile sayfa arasındaki tutarlılığı bir güven sinyali gibi kullanıyor. Ürün sayfasındaki JSON-LD işaretlemesinde fiyatın, para biriminin, stok durumunun ve ürün kimliğinin feed'deki değerle aynı olması bu yüzden önemli. Ayrıştırılamayan veya feed ile çelişen bir işaretleme, ürünü aday havuzunda tutmak yerine güvenilirliğini düşürüyor. Sayfalarınızdaki işaretlemenin gerçekten geçerli olup olmadığını yapılandırılmış veri denetim aracı ile kontrol edip düzeltmek, feed çalışmasının önkoşulu.
Yetenek bildirimi ve checkout uçları
Keşif katmanının üstünde bir de "bu satıcı hangi işlemleri destekliyor" sorusu var. Universal Commerce Protocol bunu standart bir bildirim dosyasıyla çözüyor. İşletme /.well-known/ucp adresinde bir JSON manifesti yayımlıyor, ajan bu dosyadan hangi yeteneklerin açık olduğunu, hangi uçların çağrılabileceğini ve hangi ödeme yapılandırmalarının desteklendiğini okuyor. Checkout oturumları ayrı uçlar üzerinden açılıp güncelleniyor, kimlik bağlama ise OAuth 2.0 üzerinden yürüyor, yani kullanıcı şifresini ajana vermiyor. Agentic Commerce Protocol de benzer bir esneklik sunuyor ve hem klasik REST arayüzü hem de Model Context Protocol sunucusu olarak uygulanabiliyor.
Ödeme ve yetkilendirme neden ayrı bir protokol istiyor?
Bugünkü kart altyapısı tek bir varsayım üzerine kurulu: işlemi onaylayan kişi, o anda orada olan insandır. Ajan devreye girdiğinde bu varsayım çöküyor. Üç soru cevapsız kalıyor. Kullanıcı tam olarak neye izin verdi, bu izin hangi tutarla ve hangi ürünle sınırlıydı, itiraz durumunda sorumluluk kimde. Bunlar ürün verisiyle çözülebilecek sorular değil, bu yüzden ayrı bir katman doğdu.
Agent Payments Protocol bu boşluğu kriptografik olarak imzalanmış doğrulanabilir dijital kimlik belgeleriyle dolduruyor. Kullanıcının onayladığı sepet ve koşullar bir belgede, ödemenin tutarı ve kullanılacak ödeme aracı ayrı bir belgede taşınıyor. Satıcıyla paylaşılan bilgi ile ödeme ağının gördüğü bilgi böylece birbirinden ayrılıyor ve geriye denetlenebilir bir iz kalıyor. Protokol Google tarafından başlatıldı, Agent2Agent protokolünün bir uzantısı olarak konumlandırıldı ve standartlaşma süreci FIDO Alliance çalışma gruplarına taşındı.
Agentic Commerce Protocol aynı problemi farklı bir tarafından tutuyor. Orada ödeme bilgisi ajana hiç açılmıyor, yerine yetkilendirilmiş bir ödeme jetonu geçiyor ve satıcı kayıt merci olarak kalmaya devam ediyor. İki yaklaşım da aynı ihtiyacı işaret ediyor: ajanın yaptığı ödemenin, bir insanın yaptığı ödeme kadar ispatlanabilir olması gerekiyor.
Üç protokol üç ayrı katmanda çalışıyor
Bu üç ismin sürekli yan yana anılması yanıltıcı bir izlenim yaratıyor. Hepsi aynı işi yapan alternatifler değil.
| Protokol | Kim geliştiriyor | Hangi işi çözüyor | Bugünkü durum |
|---|---|---|---|
| ACP | OpenAI ve Stripe | Ürün feed'i, sepet, checkout oturumu ve yetkilendirilmiş ödeme | Açık kaynak spesifikasyon, beta olarak işaretli, ChatGPT tarafında canlı entegrasyonlar var |
| AP2 | Google başlattı, FIDO Alliance çalışma gruplarında standartlaşıyor | Ajanın ödeme yetkisini kanıtlaması ve sorumluluğun izlenebilmesi | Açık spesifikasyon, ödeme ağı ve sağlayıcı entegrasyonları sürüyor |
| UCP | Google ve Shopify | Keşiften satın alma sonrasına kadar tüm ticaret akışı | Açık standart, Google yüzeylerinde ABD'de canlı, yeni pazarlara açılıyor |
Katmanlar tam olarak ayrık değil. ACP ile UCP checkout tarafında gerçekten örtüşüyor ve bir satıcının ikisini birden desteklemesi gerekebiliyor. AP2 ise ikisinin de altına giriyor, çünkü ödeme yetkisinin ispatı her iki akışta da aynı problem.
Universal Commerce Protocol bu tabloda nerede duruyor?
UCP üçü içinde en geniş kapsamlı olanı. Ürün keşfi, yetenek pazarlığı, checkout ve satın alma sonrası süreçleri tek bir standart altında topluyor. Google ve Shopify tarafından geliştiriliyor, Apache 2.0 lisansıyla açık kaynak olarak yayımlanıyor ve arkasında yirmiyi aşkın perakendeci, ödeme ağı ve platform var. Ajanla iletişim için tek bir taşıma katmanı dayatmıyor, Agent2Agent, Model Context Protocol veya düz REST arayüzleri üzerinden çalışabiliyor. Ödeme tarafında AP2 ile uyumlu olduğu belirtiliyor, yani ödeme yetkilendirmesini kendi içine gömmek yerine o katmana devrediyor.
Pratik karşılığı Google'ın kendi yüzeylerinde görünüyor. Arama içindeki yapay zeka modu ve Gemini uygulamalarında ABD'deki kullanıcılar katılımcı perakendecilerden alışveriş yapabiliyor, farklı satıcıları tek bir sepette birleştiren evrensel sepet özelliği de aynı altyapının üstüne kuruluyor. UCP tabanlı ödeme akışı önce ABD'de açıldı, ardından Kanada ve Avustralya'ya genişledi, İngiltere planlananlar arasında. UCP'nin konumu ACP'nin yerini almak değil, onunla birlikte var olmak olarak tarif ediliyor.
Sohbet içi ödemenin geri çekilmesi ne gösterdi?
Bu tablonun en öğretici parçası, çalışmayan denemede. ChatGPT içinde satın almanın sohbeti hiç terk etmeden tamamlandığı model denendi ve geri çekildi. Yerine gelen kurguda keşif ChatGPT'de kalıyor, ödeme ise satıcının kendi sitesinde veya satıcının ChatGPT içinde kurduğu kendi uygulamasında tamamlanıyor. Protokolün kendisi ortadan kalkmadı, aksine keşif tarafına doğru genişledi.
Geri çekilmenin gerekçeleri satıcı için tam olarak doğru yere işaret ediyor. Satıcılar checkout'u üçüncü bir tarafa devretmek istemedi, çünkü sadakat programı, ödeme verisi ve satın alma sonrası ilişki o adıma bağlı. İkinci gerekçe daha teknikti: ajan ürün ve stok bilgisini satıcıdan almak yerine türetmek zorunda kaldığında, gerçek zamanlı fiyat ve stok doğruluğu tutmuyordu.
Buradan çıkan sonuç net. Keşif katmanına yapılan yatırım her iki senaryoda da işe yarıyor, ödeme katmanı ise hâlâ yer değiştiriyor. Aynı ayrım üretken arama motorlarında görünürlük tarafında da geçerli. Bir markanın yapay zeka yüzeylerinde temsil edilmesi, o yüzeyde ödeme alabilmesinden bağımsız ve çok daha erken bir kazanç.
Ajanın okuyamadığı ürün verisi satın alınamaz
Klasik SEO'da eksik yapılandırılmış veriyi iyi bir metin kısmen telafi eder. Ajan kanalında böyle bir telafi mekanizması yok. Ajanlar eksik alanı genellikle tahmin etmiyor, alanı boş olan ürünü eleme kriterine takılmış sayıyor. Bu yüzden veri eksikliği burada bir puan kaybı değil, doğrudan aday havuzundan düşme sebebi.
Satıcı tarafında pratik olarak yapılması gerekenler şunlar:
- Her ürün için değişmeyen bir kimlik kullanın ve bu kimliği feed ile sayfa arasında aynı tutun.
- Fiyat, stok ve kargo bilgisinin feed'deki değeri ile sitedeki değerinin ayrışmasına izin vermeyin.
- Varyantları ayrı satır olarak verin ve hepsini ortak bir grup kimliğine bağlayın.
- Marka, GTIN ve MPN gibi eşleştirme alanlarını doldurun, çünkü ajanlar aynı ürünü farklı satıcılarda bu alanlarla eşleştiriyor.
- Ölçü, renk, malzeme, uyumluluk ve kullanım amacı gibi filtrelemeye giren alanları boş bırakmayın.
- İade ve kargo koşullarını makine tarafından okunabilir biçimde yayımlayın.
Tutarsızlığın maliyeti sadece görünmemek değil. Ajanın fiyat veya stok bilgisine güvenip sipariş oluşturduğu, sonra satıcının bunu karşılayamadığı bir akışta iptal ve iade oranı yükseliyor, satıcının güvenilirliği düşüyor. Ürün verisi hijyeni bu yüzden tek seferlik bir proje değil, sürekli yürütülen SEO çalışmasının parçası olarak ele alınması gereken bir bakım işi.
Türkiye için gerçekçi zamanlama
Keşif katmanı Türkiye'de zaten çalışıyor. Kullanıcılar Gemini'de, ChatGPT'de ve aramanın yapay zeka yanıtlarında ürün araştırıyor, marka karşılaştırıyor, fiyat soruyor. Ürün verisinin makine tarafından okunabilir olmasının bugünkü karşılığı bu ve beklemeye gerek yok.
Ödeme katmanı için aynı şeyi söylemek dürüst olmaz. UCP tabanlı ödeme akışı ABD'de başladı ve açıklanan genişleme sırası Kanada, Avustralya ve İngiltere. Türkiye bu sırada geçmiyor. ChatGPT tarafında ise sohbet içinde ödeme modeli ABD'de bile geri çekildi. Buna yerel bir katman daha ekleniyor: kart yetkilendirme akışlarının, ödeme sağlayıcı entegrasyonlarının ve iade süreçlerinin bu protokollere uyarlanması ayrı bir iş ve bu iş Türkiye'de henüz görünür biçimde başlamadı.
Bunun pratik anlamı şu. Henüz size ulaşamayan bir ajan için checkout API'si geliştirmek erken bir yatırım. Ürün verisini düzeltmek ise erken değil, çünkü aynı veri klasik alışveriş yüzeylerinde, karşılaştırma sitelerinde ve pazaryerlerinde de kullanılıyor. Ödeme protokolleri Türkiye'ye geldiğinde hazır olacak taraf, o gün feed yazmaya başlayan değil, kataloğu zaten temiz olan satıcı olacak.
Sıkça Sorulan Sorular
Agentic commerce SEO'nun yerini alıyor mu?
Hayır, ama SEO'nun çıktısını değiştiriyor. Ajanlar aday havuzunu boşluktan kurmuyor, arama altyapılarından ve satıcının verdiği veriden kuruyor. Bu yüzden dizine girme, sayfa erişilebilirliği ve konu otoritesi çalışmaları geçerliliğini koruyor. Değişen şey, bu çalışmanın yanına ürün verisi kalitesinin zorunlu bir bileşen olarak eklenmesi.
Ürün feed'i olmadan ajanlar ürünümü bulabilir mi?
Kısmen bulabilir, çünkü ürün sayfalarındaki yapılandırılmış veri de okunuyor. Ancak ödeme akışına giren protokollerde feed açıkça zorunlu bir bileşen. Feed'siz bir katalog keşif tarafında görünmeye devam edebilir, işlem tarafında ise büyük ölçüde devre dışı kalır.
Küçük bir e-ticaret sitesi hangi protokole öncelik vermeli?
Protokol seçimiyle başlamak yanlış sıra. Üç protokolün de ortak önkoşulu temiz ve tam ürün verisi. Katalog tarafı düzeldikten sonra öncelik, işletmenin müşterisinin hangi yüzeyde olduğuna göre belirlenir. Kullandığınız e-ticaret altyapısı bu entegrasyonları platform seviyesinde sunuyorsa, kendi başınıza uç geliştirmek yerine o yolu izlemek daha az maliyetli.
Ajan üzerinden gelen siparişte müşteri ilişkisi kimde kalıyor
Her iki büyük protokol de satıcının kayıt merci olarak kalmasını ve müşteri ilişkisinin sahipliğini korumasını esas alıyor. Pratikte kritik olan nokta iade, değişim ve destek süreçlerinin ajana da açılıp açılmadığı. Sipariş durumu ve iade koşulları makine tarafından okunabilir değilse, satın alma sonrası her adım tekrar insana düşüyor.
