Agentic Commerce Çağında Isı Haritası (Heatmap) Analizi

Bir e-ticaret müşterisi ürün sayfasına giriyor, yorumları inceliyor, teslimat bilgisini arıyor ve sepete ekliyor. Başka bir müşteri ise aynı işi yapay zekâ asistanına devrediyor. Ajan ürünü bir katalogdan bulabiliyor, uygun varyantı seçebiliyor ve desteklenen bir entegrasyon üzerinden ödeme sürecini başlatabiliyor.

İki yolculuğun ticari hedefi aynı: doğru ürünün satın alınması. Ancak bıraktıkları veri izleri farklı.

Agentic commerce çağında ısı haritası analizleri önemini tamamen kaybetmez. İnsanların kullandığı ekranları anlamaya devam eder; buna ürün verisinin doğruluğunu, ajanların erişimini ve işlemlerin tamamlanmasını ölçen yeni analizler eklenir.

Webtures olarak bu dönüşümü, dönüşüm optimizasyonunun kapsamının genişlemesi olarak ele alıyoruz. Bir ziyaretçinin hangi butona tıkladığı kadar, bir ajanın doğru ürünü bulup bulamadığı ve siparişin hangi aşamada aksadığı da araştırılmalı.

Bu rehber; e-ticaret yöneticileri, pazarlama ekipleri, ürün yöneticileri ve analitik uzmanları için bu iki dünyayı birlikte ele alan bir uygulama çerçevesi sunuyor. Teknik durum 13 Eylül 2026 itibarıyla incelenmiştir. Metrikler ve uygulama planı, işletmenin kendi ölçüm koşullarına uyarlanabilecek öneriler olarak sunulmuştur.

Isı haritası nedir, neyi ölçer?

Isı haritası, belirli verilerin yoğunluğunu renklerle gösteren bir görselleştirme yöntemidir. Web analitiğinde heatmap denildiğinde genellikle ziyaretçilerin sayfa üzerindeki etkileşimlerinin toplulaştırılmış görünümü kastedilir. Microsoft Clarity dokümantasyonu da bu yaklaşımı tıklama, kaydırma ve farklı sayfa alanları üzerinden tanımlar.

Bu yöntemlerin adları ve hesaplama biçimleri araçlar arasında değişebilir. Özellikle “attention” etiketi, ölçümün göz takibine dayandığı anlamına gelmez. Standart tıklama veya fare hareketi verisi, kişinin gerçekten nereye baktığını doğrudan ölçmez. Göz takibi ayrı bir araştırma yöntemidir.

Benzer biçimde bir bölümün uzun süre ekranda kalması, o bölümün ikna edici olduğunu kanıtlamaz. Kullanıcı bilgiyi anlamaya çalışıyor, başka bir işle ilgileniyor veya hata çözmeye uğraşıyor olabilir. Heatmap bir davranış örüntüsünü görünür kılar; davranışın nedenini açıklamak için ek kanıt gerekir.

Agentic commerce alışveriş yolculuğunu nasıl değiştiriyor?

Agentic commerce, yapay zekâ ajanlarının kullanıcı adına ticari görevler üstlendiği alışveriş biçimlerini kapsar. Yetki kapsamına göre ürün araştırması, karşılaştırma, sepet oluşturma veya satın alma işleminin yürütülmesi söz konusu olabilir. UCP dokümantasyonu, insanın sürece dahil olduğu ve daha otonom ilerleyen modelleri birlikte ele alır.

Ölçüm açısından dört yolculuk ayrımı kullanışlıdır:

Bu satırlar birbirini dışlayan müşteri kimlikleri değildir. Aynı alışveriş araştırmada AI destekli, sepet aşamasında API üzerinden, son onayda insan tarafından yürütülebilir. Bu nedenle tüm yolculuğa tek bir “insan” veya “ajan” etiketi yapıştırmak yerine, mümkün olduğunda aşamaları ayrı kaydetmek gerekir.

Ajanların yalnızca API kullandığı varsayımı da doğru değildir. OpenAI’nin ChatGPT agent açıklaması, görsel tarayıcı, metin tabanlı tarayıcı ve doğrudan API erişimini aynı araç setinde tanımlar.

Heatmap tarih mi oluyor?

Hayır. Daha doğru soru, alışverişin hangi bölümlerinin satıcının ölçebildiği ekranlarda gerçekleştiğidir.

Örneğin müşteri AI platformunda ürünleri karşılaştırıp satıcının ödeme sayfasına geçerse, satıcının heatmap’i karşılaştırma sürecini göstermez. Ancak ödeme formunda yaşanan sorunu göstermeye devam edebilir. Satın alma tamamen harici bir platformda tamamlanırsa, insan hâlâ bir arayüz kullanıyor olsa bile bu arayüz satıcının ölçüm alanının dışında kalabilir.

Buradaki değişim iki boyutludur: Bazı görevler ekrandan programatik işlemlere taşınır; bazı insan etkileşimleri ise satıcının sitesinden başka bir platformun arayüzüne geçer. Satıcının veriye erişimi, entegrasyonların ve platform raporlarının sunduğu kapsamla sınırlıdır.

Bu geçişin tek yönde ve aynı hızda ilerlediğini varsaymamak gerekir. OpenAI, 24 Mart 2026 tarihli alışveriş güncellemesinde ürün keşfine odaklanırken satıcıların kendi ödeme deneyimlerini kullanmasına olanak tanıdığını açıkladı. Bu, AI üzerinden başlayan alışverişin satıcının arayüzünü her durumda ortadan kaldırmadığını gösteren somut bir örnektir.

Dolayısıyla heatmap yatırımını azaltma kararı, genel bir gelecek tahmininden çıkarılmamalı. İşletmenin kendi insan trafiği, ölçülebilir ajan işlemleri, gelir dağılımı ve çözülmemiş kullanım sorunları birlikte değerlendirilmelidir.

İnsan deneyiminde heatmap nasıl kullanılmalı?

Agentic commerce gündemi, mevcut müşterinin alışverişini zorlaştıran sorunları ikinci plana atmamalı. Üç örnek üzerinden düşünelim.

Ürün bilgisi bulunamıyor

Bir ürün sayfasında müşteriler kargo ve iade bilgisini sık arıyor, fakat bu bilgiler sayfanın alt bölümünde bulunuyor olabilir. Kaydırma haritası ziyaretçilerin ilgili derinliğe ne kadar ulaştığını incelemek için kullanılabilir. Bu veri, bilgilerin gerçekten okunduğunu veya anlaşıldığını göstermez.

Araştırılacak hipotez, karar için gerekli bilginin geç görünmesidir. Denemede teslimat özeti ürün fiyatının yakınına alınabilir. Değerlendirme ise yalnızca o alana tıklama artışıyla yapılmamalı; sepete ekleme, satın alma ve destek taleplerindeki değişim birlikte izlenmelidir.

Varyant seçimi anlaşılmıyor

Kullanıcılar stokta olmayan bedene tekrar tekrar dokunuyor olabilir. İlk inceleme, pasif seçeneklerin yeterince anlaşılır gösterilip gösterilmediğine odaklanır. Oturum kaydı ve kullanılabilirlik testiyle desteklenen bu hipotez, stok durumu etiketlerinin netleştirilmesiyle sınanabilir.

Burada daha az tıklama, daha kötü etkileşim anlamına gelmeyebilir. Müşteri istediği seçeneğin mevcut olmadığını daha hızlı anlıyorsa gereksiz işlem azalır.

AI yönlendirmesiyle gelen ziyaretçi farklı ihtiyaç taşıyor

AI platformunda ön araştırmasını tamamlamış bir müşteri, uzun ürün anlatımından çok fiyat, gerçek stok ve teslimat doğrulaması arayabilir. Bu bir test hipotezidir; bütün AI yönlendirmeli ziyaretçilerin böyle davrandığı kabul edilmemelidir.

Tanımlanabilen AI yönlendirmeli insan oturumlarını, benzer ürün ve cihaz koşullarındaki diğer insan oturumlarıyla karşılaştırın. Kaynak etiketi tek başına yeterli olmaz; yeni müşteri oranı, kampanya, ürün kategorisi ve stok durumu gibi farklılıkları da dikkate alın.

Tarayıcı ajanları için heatmap nasıl yorumlanmalı?

Tarayıcı ajanları sayfayı ekran görüntüsü, HTML/DOM veya erişilebilirlik ağacı üzerinden inceleyebilir. Arayüzün ajanlar tarafından okunabilir olmasını Agent Experience çalışmasında ayrıca ele alıyoruz. Google’ın web.dev rehberi, bu yöntemlerin bir arada kullanılabildiğini ve anlamlı HTML ile kararlı arayüz yapısının önemini açıklar.

Bunun heatmap analizinde önemli bir sonucu vardır: Ajanın arayüzde yaptığı hareketlere insan psikolojisi atfetmek yanıltıcı olabilir.

Bu açıklamalar tanı değil, inceleme başlangıçlarıdır. Bir ajanın tekrar tıklamasını “öfke”, bir sayfada kalmasını “ilgi” olarak raporlamayın.

Ayrıca tarayıcı kullanan her ajanın heatmap aracına eksiksiz kaydedileceği varsayılamaz. İzleme kodunun çalışması, kayıt izinleri, aracın filtreleri ve ajanın eylem biçimi görünürlüğü etkileyebilir. Kaydın bulunmaması, etkileşimin gerçekleşmediğinin kanıtı değildir.

Kontrollü testlerde heatmap’e ek olarak görevin başlangıç koşullarını, gözlenen eylemleri, hata mesajlarını ve son durumu saklamak daha açıklayıcıdır. Örneğin “sepete ekle butonuna beş tıklama” yerine “stok uyarısı sonrasında ajan üç kez yeniden denedi ve görevi tamamlayamadı” biçiminde bir bulgu, çözüm üretmeye daha uygundur.

LLM attention map, heatmap’in yeni sürümü mü?

“AI hangi kelimeye dikkat etti?” sorusu çekicidir. Ancak aynı adı taşıyan farklı ölçümler birbirine karıştırılmamalıdır.

Dışarıdan gelen bir ajanın sitenizi ziyaret etmesi, o modelin iç dikkat ağırlıklarına erişim sağlamaz. Kendi çalıştırdığınız ve uygun teknik erişime sahip olduğunuz modellerde bazı iç ölçümler incelenebilir. Fakat attention ağırlıkları tek başına güvenilir bir neden-sonuç açıklaması kabul edilemez; ilgili araştırma da bu ilişkinin sınırlarını ortaya koyar.

Satıcının erişebildiği verinin iddiası daha dar tutulmalıdır: Bir ürün kaydı istendi, bir fiyat yanıtı verildi, sepet güncellendi veya işlem hata aldı. “Ajan ürün açıklamasındaki şu kelimeden etkilendi” sonucu için kontrollü deney ve ek kanıt gerekir.

Ajanın ürettiği açıklama metni de tek başına nedensel kanıt değildir. Bu metin, gözlenen tercih ve işlem sonuçlarıyla birlikte değerlendirilebilir.

Webtures yaklaşımı: Dört katmanda dönüşüm analizi

Webtures olarak heatmap analizini, aşağıdaki dört katmanın birlikte değerlendirildiği bir çalışma içinde konumlandırmayı öneriyoruz.

Bir katmandaki iyileşme diğerlerini otomatik olarak düzeltmez. Daha anlaşılır bir buton, eski stok bilgisini güncellemez. Doğru ürün verisi de başarısız ödeme entegrasyonunu onarmaz.

Analizin başlangıcında ekibin hangi katmanı görebildiği belirlenmelidir. Kendi AI alışveriş asistanını işleten bir marka, model ve araç çağrıları için ayrıntılı kayıt üretebilir. Harici bir AI platformundan ziyaret alan marka ise platformun paylaşmadığı işlem izlerini kendi sunucusunda göremez.

OpenTelemetry gibi gözlemlenebilirlik araçları, uygun biçimde enstrümante edilmiş kendi uygulamalarınızın model çağrılarını ve araç işlemlerini incelemeye yardımcı olabilir. Bu imkân, dışarıdaki bütün ajanların iç süreçlerine erişim anlamına gelmez.

İnsan, bot ve alışveriş ajanı trafiği nasıl ayrılır?

Sağlıklı analiz için otomatik trafiğin amacını ayırmak gerekir. Arama motoru tarayıcısı, model eğitimi için içerik toplayan bot, stok kontrol servisi ve kullanıcı adına alışveriş yapan ajan aynı faaliyet değildir.

Önerdiğimiz raporlama düzeninde en az şu gruplar bulunur:

• İnsan oturumları olarak sınıflandırılan ziyaretler.
• AI yönlendirmesi tanımlanabilen insan oturumları; bu grup bir öncekinin alt segmentidir.
• Kimliği doğrulanabilen ajan veya entegrasyon işlemleri.
• Otomatik olduğu düşünülen, ancak kimliği ya da amacı doğrulanamayan trafik.
• Kendi testleriniz ve diğer operasyonel botlar.
• Sınıflandırılamayan ziyaret ve işlemler.

Her sınıflandırmanın dayanağı saklanmalıdır. Yalnızca user-agent metninde bir marka adı görmek kesin doğrulama sayılmaz. Entegrasyon kimliği, uygun kimlik doğrulama ve desteklenen istek imzaları daha güçlü kanıt sağlayabilir. Cloudflare Web Bot Auth, desteklenen otomatik isteklerin imzalarla doğrulanmasına ilişkin somut bir uygulamadır. Böyle bir kimlik doğrulaması, tek başına kullanıcının belirli bir satın almaya yetki verdiğini kanıtlamaz.

GA4 neden tek başına yeterli değildir?

Google Analytics, bilinen bot ve örümcek trafiğini otomatik olarak dışladığını ve bu dışlamanın kapatılamadığını belirtir. Bu nedenle GA4 raporundaki ziyaret sayısını bütün ajan erişimlerinin toplamı gibi yorumlamak doğru değildir.

Heatmap ve tarayıcı analitiğinin yanında CDN, sunucu, API ve sipariş kayıtları da değerlendirilebilir. Bu kaynaklar farklı birimleri saydığı için toplamları doğrudan birbirine eklenmemelidir. Bir ziyaret, çok sayıda HTTP isteği ve tek bir sipariş üretebilir.

AI yönlendirmesinin görülememesi de alışverişte AI kullanılmadığını kanıtlamaz. Müşteri bir öneriyi görüp daha sonra adresi doğrudan açmış olabilir. Böyle durumlarda kaynağı kesin olarak atamak yerine belirsizliği korumak gerekir.

Agentic commerce için hangi metrikler izlenmeli?

İyi bir gösterge, hangi sorunun çözülmesi gerektiğini anlamayı kolaylaştırır. Bunun için her metriğin payı, paydası, zaman aralığı ve veri kaynağı açıkça tanımlanmalıdır.

Aşağıdaki göstergeler bir başlangıç setidir. İşletmeler kendi ürünlerine ve destekledikleri alışveriş biçimlerine göre uyarlamalıdır.

“Uygun” ifadesi rapordan rapora değişmemelidir. Örneğin canlı satın alma niyeti olan görevler, yalnızca fiyat araştıran görevlerden ayrılabilir. Ancak başarısız işlemleri sonradan paydadan çıkarmak oranı yapay olarak iyileştirir. Dahil etme kuralları ölçüm başlamadan belirlenmeli, dışlanan hacim ayrıca görünmelidir.

Oranların paydasını açık tutun

Tamamen varsayımsal bir örnekte, sonuçlanması için yeterli süre geçmiş 200 ajan checkout oturumunun 150’si siparişle tamamlanmış olsun:

Checkout tamamlama oranı = 150 / 200 × 100 = %75.

Aynı dönemde 4.000 katalog isteği kaydedilmiş olması, bu oranın paydasını 4.000 yapmaz. İstekler tek bir görev içinde tekrarlanabilir ve katalog erişimi her zaman satın alma niyeti taşımaz.

Benzer biçimde 50 başarısız oturumun tamamını teknik hata sayamayız. Bir kısmı kullanıcının vazgeçmesi, bir kısmı stok değişmesi, bir kısmı da süresi dolan onay olabilir. Dönüşüm kaybı ile yazılım hatası ayrı sorulardır.

Sipariş sayısının yanına ticari kaliteyi ekleyin

Daha fazla otomatik sipariş tek başına daha iyi ticari sonuç anlamına gelmez. Yanlış varyant seçimi, pahalı teslimat veya artan iadeler sonucu değiştirebilir.

İnsan ve ajan bağlantısı doğrulanmış siparişleri; kategori, sepet tutarı, iptal/iade oranı, destek ihtiyacı ve sipariş başına katkı üzerinden izleyin. Kullanılan gelir tanımında vergi, kargo, indirim ve iadenin nasıl ele alındığı sabit olmalıdır. Kendi model veya entegrasyon maliyetiniz varsa bunu da değerlendirmeye ekleyin.

Heatmap ile işlem kayıtları nasıl birleştirilir?

Amaç bütün verileri tek bir araca doldurmak değildir. Aynı alışverişe ait kanıtların, erişilebildiği ölçüde birbirine bağlanmasıdır.

Önerilen başlangıç veri sözlüğü şu alanları içerebilir. Bunlar bu rehberde önerilen iç analitik alanlarıdır; ACP veya UCP’nin zorunlu alan adları değildir.

Ortak bir kimliğin bütün platformlarda kendiliğinden taşındığı varsayılmamalıdır. Bağlantının kurulamadığı işlemler “eşleştirilemedi” olarak kalabilir. Zaman ve ürün benzerliğine dayalı tahmini eşleştirmeler, doğrulanmış bağlantılarla aynı kesinlikte sunulmamalıdır.

Satın alma olayını sipariş sistemiyle doğrulayın

Google Analytics e-ticaret ölçümünde purchase ve refund olayları ile transaction_id kullanılır. Bu olaylar pazarlama analitiği için yararlıdır; işletmenin sipariş ve ödeme durumlarıyla tutarlılığı ayrıca kontrol edilmelidir.

Bir API’nin başarılı yanıt vermesi, satın almanın tamamlandığını tek başına göstermez. Yanıt yalnızca sepetin güncellendiğini veya ödeme oturumunun oluşturulduğunu belirtiyor olabilir. Başarı tanımı, işletmenin gerçekten hangi sipariş durumunu kabul ettiğiyle eşleştirilmelidir.

Ayrıca aynı olay tekrar gelebilir. Stripe, webhook olaylarının birden fazla teslim edilebildiğini ve işlenen olay kimliklerinin takip edilmesini önerir.

İşlemin yeniden denenmesiyle yeni bir sipariş oluşmasını önleyen idempotency tasarımı ile raporda aynı siparişin iki kez sayılmasını önleyen tekilleştirme farklı katmanlardır. İkisi de değerlendirilmelidir. Stripe’ın API dokümantasyonu idempotent istek yaklaşımını açıklar.

Kayıt kapsamını amaca göre sınırlandırın

Sorunu anlamak için çoğu zaman ürün kimliği, işlem durumu, süre ve hata kategorisi yeterlidir. Ödeme bilgileri, erişim anahtarları veya müşterinin bütün konuşmasını analiz kayıtlarına taşımak gerekmez. Form ve oturum kayıtlarında hassas alanların maskelenmesi, erişimlerin sınırlandırılması ve saklama süresinin belirlenmesi gerekir.

Kendi AI uygulamanızda da içerik kaydı ayrı bir karar olmalıdır. OpenTelemetry’nin GenAI açıklaması, istem ve araç argümanlarının hassas veri içerebileceğine dikkat çeker.

Yeni analiz haritaları nasıl tasarlanabilir?

Isı haritası bir görselleştirme biçimidir. Ekran koordinatları dışında da kullanılabilir: Satırlarda ürün kategorileri, sütunlarda görev aşamaları, hücrelerde ise başarısızlık oranları gösterilebilir.

Bu tür bir tabloyu “ajanın zihnini gösteren harita” olarak sunmak doğru olmaz. Harita, tanımlanmış ölçümün yoğunluğunu gösterir. Metrik, örneklem ve veri kaynağı görünür kaldığında karar vermeyi kolaylaştırır.

Örnek: Görev aşamalarına göre sorun dağılımı

Aşağıdaki tablo tamamen kurgusaldır. Her kategori ve aşama için önkoşulları hazırlanmış 20 ayrı test uygulanmış; başarısız test sayısı gösterilmiştir. Bir satış hunisi veya gerçek müşteri sonucu değildir.

Bu görünümde elektronik için fiyat ve stok senkronizasyonu, giyim için varyant seçimi, ev ve yaşam için teslimat adımı ilk inceleme alanları olur. Ancak 20 test küçük bir başlangıç örneklemidir. Oranlar kesin performans tahmini veya kategori sıralaması olarak sunulmamalıdır.

Gerçek uygulamada tablo renklendirilebilir; oran ve örneklem hücrede korunmalıdır. Veri olmayan hücre “%0 sorun” olarak gösterilmemeli, “ölçülmedi” şeklinde işaretlenmelidir. Farklı ajanların sonuçları karşılaştırılırken model/ajan sürümü, görevler ve test koşulları belirtilmelidir.

Benzer mantıkla üç görünüm daha üretilebilir:

• Veri tutarlılığı görünümü: Ürün sayfası, feed ve API yanıtındaki uyuşmazlıkların alanlara göre dağılımı.
• İnsan devri görünümü: Onay veya müdahale istenen aşamalarda, gözlenebilen devam etme ve vazgeçme oranları.
• Teknik sorun görünümü: Desteklenen entegrasyon ve işlem türlerine göre zaman aşımı, doğrulama hatası ve yeniden deneme dağılımı.

Bu görünümler farklı soruları yanıtlar. Tek bir toplam “agentic başarı skoru” altında birleştirmek, kritik bir ödeme hatasını iyi görünen katalog puanının arkasında gizleyebilir. Önce bileşenlerin ayrı raporlanması daha açıklayıcıdır.

Ürün sayfaları ve veri altyapısı nasıl hazırlanmalı?

İnsanların ve ajanların kullanabileceği açık bir arayüz kurun

Tarayıcı ajanlarına hazırlık için başlangıç noktası anlaşılır sayfa yapısıdır. Anlamlı buton ve bağlantılar, form alanlarına bağlı etiketler, kararlı yerleşim ve etkileşimi örten katmanların azaltılması yararlıdır. Google’ın ajan dostu site rehberi de bu temellere odaklanır.

Bu tasarımı gerçek görevlerle kontrol edin. Müşteri veya ajan bir beden seçtiğinde mevcut seçimin ne olduğu anlaşılmalı; sepete ekleme sonrası yeni durum görülebilmeli; hata varsa ilgili işlemle ilişkilendirilmelidir. Bir öğenin görsel olarak dikkat çekmesi, işlevinin anlaşılır olduğu anlamına gelmez.

Tek ürün için çelişkili bilgiler üretmeyin

Ürün sayfası, yapılandırılmış veri, katalog aktarımı ve işlem API’si aynı ürünü farklı fiyat veya stok durumuyla tanımlıyorsa karar süreci güvenilirliğini kaybeder. Google Merchant Center ürün veri spesifikasyonu da fiyatın açılış sayfası, yapılandırılmış veri ve checkout ile eşleşmesini ister.

Karşılaştırmayı aynı koşullarla yapın: varyant, para birimi, vergi kapsamı, teslimat bölgesi, üyelik ve kampanya. Üyelere özel bir fiyat ile herkese açık fiyatın farklı olması, koşul doğru temsil ediliyorsa kendiliğinden hata değildir.

Kontrol listesine ürün kimliği, varyant özellikleri, satılabilir stok, teslimat seçenekleri ve iade koşullarını ekleyin. Fiyat değişikliklerinin hangi sistemlere ne zaman yansıdığını ölçün. Yapılandırılmış verinin bulunması yararlıdır; fakat görünür içerikle çelişen işaretleme doğru veri sağlamaz. Google’ın satıcı listeleme dokümantasyonu, ürün ve teklif bilgilerinin yapılandırılmasına ilişkin uygulama örnekleri sunar.

ACP ve UCP’yi ticari ihtiyaçla değerlendirin

ACP, desteklenen ajanların ürün/katalog, sepet, checkout ve sipariş yaşam döngüsü gibi ticaret işlevleriyle etkileşmesi için yapı taşları tanımlar. UCP de farklı ticaret katılımcıları arasında birlikte çalışabilirlik ve desteklenen yeteneklerin keşfi için bir çerçeve sunar.

Entegrasyon kararı verirken hedef platformu, pazar ve ödeme desteğini, mevcut e-ticaret altyapısını ve bakım sorumluluğunu inceleyin. Protokolün bir özelliği tanımlaması, bütün platformların onu aynı anda desteklediği anlamına gelmez. Uygulamada desteklenen sürüm ve yetenekler doğrulanmalıdır.

Bir ticaret protokolüne bağlanmak, ürünün önerilerde öne çıkmasını garanti etmez. İşlemin yapılabilir olması ile ürünün kullanıcı için uygun bulunması ayrı konulardır.

AI görünürlüğünü temel bulunabilirlikle birlikte ele alın

AI görünürlüğü, ürünün nasıl temsil edildiğini ve hangi sorularda keşfedilebildiğini araştırmayı gerektirir. Bu tarafı GEO danışmanlığı kapsamında yürütüyoruz. Google, kendi üretken AI arama deneyimlerinde mevcut SEO temellerinin geçerli olduğunu açıkça belirtir. Dolayısıyla taranabilirlik, indekslenebilirlik ve yararlı içerik çalışmalarını kaldırıp yalnızca yeni bir etiket altında ilerlemek sağlıklı değildir.

Ürünün bulunması, doğru anlaşılması, işlemin yürütülmesi ve insanın kararını tamamlaması aynı ticari hedefin farklı çalışma alanlarıdır. Rehberde önerilen ölçüm planı bu alanlar arasındaki kopuklukları bulmaya odaklanır.

İlk 30 günde nasıl bir uygulama planı izlenebilir?

Otuz günün hedefi bütün agentic commerce altyapısını tamamlamak değildir. Ölçüm boşluklarını ortaya çıkarmak, en önemli sorunları doğrulamak ve ilk iyileştirmeleri sınamak için bir başlangıç dönemidir. Entegrasyon gereksinimleri ve trafik hacmi süreyi değiştirebilir.

Görev seti yalnızca kolay alışverişlerden oluşmamalı

Bir başlangıç görevi “belirli bütçe içinde stokta bulunan bir ürünü bul” olabilir. Ardından varyant, teslimat ve koşul değişiklikleri eklenmelidir. Örnek görevler:

1. Belirli renk ve bedendeki ürünü bulup doğru varyantla sepete ekleme.
2. Stokta olmayan ürün için görevin koşullarına uyan alternatif bulma.
3. Belirli bir bölge için teslimat seçeneğini ve toplam tutarı doğrulama.
4. Kupon koşulunu doğru uygulayıp uygulanamadığında anlaşılır biçimde açıklama.
5. Kullanıcı onayı gerektiğinde işlemi doğru noktada devretme.
6. Geçici hata sonrası yeniden denemede ikinci bir sipariş oluşturmama.

Sentetik satın alma görevleri test ortamında veya ödeme sağlayıcısının test imkânlarıyla yürütülmeli; test siparişleri gerçek satış raporlarından ayrılmalıdır. Kontrollü testler, gerçek platformlardan gelecek bütün ajanların davranışını temsil etmez. Kullanılan ajan, sürüm, başlangıç komutu ve başarı koşulu sonuçla birlikte saklanmalıdır.

Değişikliğin işe yaradığını nasıl anlayabilirsiniz?

Bir form etiketini düzeltmeden önce 20 görevin 12’si, sonrasında 17’si tamamlandıysa gözlenen oran %60’tan %85’e çıkmıştır. Bu, 25 yüzde puanlık bir artıştır. Küçük bir test setinde gözlenen iyileşmedir; bütün müşterilerde aynı artışı sağlayacağı veya değişikliğin tek neden olduğu söylenemez.

Daha güçlü değerlendirme için görevleri ve ortamı sabit tutun, koşuları tekrarlayın ve mümkünse sürümleri aynı dönemde karşılaştırın. Canlı insan trafiğinde yeterli örneklem ve uygun deney tasarımı varsa A/B testi uygulayın. Kampanya, ürün karması, fiyat veya stok aynı anda değiştiyse basit öncesi/sonrası karşılaştırmasının sınırını rapora ekleyin.

Teknik düzeltmenin kabul koşulu somut olmalıdır: Doğru varyant sepete ekleniyor mu? Toplam tutar doğru mu? Hata sonrası işlem durumu anlaşılır mı? Kullanıcı onayı doğru alınabiliyor mu? Sipariş bir kez mi oluşuyor?

Hangi sorunlar önce çözülmeli?

Bütün kırmızı hücreler aynı önceliğe sahip değildir. Çok ziyaret edilen bir sayfadaki düşük etkili sorun, daha az görülen ancak ödeme tamamlanmasını engelleyen hatadan daha önemsiz olabilir.

Önceliklendirmede şu dört soruyu birlikte kullanın:

• Sorundan etkilendiği doğrulanabilen kaç görev veya müşteri var?
• Sorun hangi ticari sonuca bağlanıyor: yanlış ürün, terk, iptal, iade veya ek destek ihtiyacı mı?
• Sorunun kaynağına ve önerilen çözümün etkisine ilişkin kanıt ne kadar güçlü?
• Düzeltmenin maliyeti, bağımlılıkları ve uygulanma süresi nedir?

Genellikle yanlış sipariş, ödeme bütünlüğü ve ciddi fiyat/stok tutarsızlıkları erken değerlendirilmelidir. Ardından görevi engelleyen kullanım sorunları ve verimlilik iyileştirmeleri gelir. İşletmenin gerçek verisi bu sıralamayı değiştirebilir.

Bir bulgu kartında gözlem, etkilenen yolculuk, örnek kayıt, hipotez, sorumlu ekip ve başarı koşulu birlikte bulunmalıdır. “Checkout’u iyileştirelim” yerine “teslimat bölgesi değiştiğinde toplam tutarın güncellenmesini görünür hale getirelim; doğru tutarla tamamlanan testleri doğrulayalım” gibi bir iş tanımı daha uygulanabilirdir.

Sık yapılan analiz hataları

Sık sorulan sorular

Agentic commerce çağında heatmap kullanmaya devam etmeli miyiz?

İnsanların kullandığı sayfa ve uygulama ekranlarını iyileştirmek için evet. Kullanımının kapsamı, ölçülebilir insan yolculuklarına göre belirlenmeli. API üzerinden yürütülen aşamalar için işlem ve sipariş analizi eklenmelidir.

Yapay zekâ ajanlarının tıklamaları heatmap’te görünür mü?

Bazı tarayıcı ajanlarının etkileşimleri kaydedilebilir. Ancak bunun her araçta ve her oturumda gerçekleştiği varsayılamaz. İzleme kodu, filtreleme, kayıt kapsamı ve ajanın çalışma biçimi kontrollü bir denemeyle doğrulanmalıdır.

AI’dan gelen trafik, agentic commerce trafiği midir?

AI yönlendirmesi tek başına işlemi bir ajanın yaptığını göstermez. İnsan AI önerisini takip edip alışverişini kendi tamamlayabilir. Analizde yönlendirme kaynağı ile işlemi yürüten aktör ayrı boyutlar olmalıdır.

Ajan ürünümü neden seçmedi, bunu görebilir miyim?

Erişebildiğiniz kayıtlarda stok yokluğu, veri hatası veya başarısız işlem gibi gözlenebilir nedenler bulunabilir. Ancak harici bir modelin bütün değerlendirmesini göremezsiniz. Kontrollü görevlerde fiyat, teslimat veya içerik değişikliklerinin sonuçlarını sınamak mümkündür; sonuçlar test kapsamıyla sınırlı yorumlanmalıdır.

ACP veya UCP entegrasyonu heatmap ihtiyacını kaldırır mı?

Programatik işlemlerin yürütülmesini destekleyebilir; insanların kullandığı arayüzlerdeki analiz ihtiyacını ortadan kaldırmaz. Hangi adımların API, hangilerinin tarayıcı veya insan onayı üzerinden ilerlediği entegrasyona göre belirlenir.

Ajanlar için ürün fotoğrafları ve tasarım önemsiz mi?

Hayır. İnsanlar AI destekli yolculuklarda da görsel karşılaştırma yapabilir; görsel tarayıcı ajanları da ekran görüntülerinden yararlanabilir. Tasarımın işlevi, kullanıcının ve desteklenen ajanın doğru bilgiyi anlayıp doğru eylemi gerçekleştirmesini kolaylaştırmak olmalıdır.

Tek bir araç bütün yolculuğu ölçebilir mi?

Bir araç, yalnızca kendisine ulaşan veriyi işler. Harici AI platformunun paylaşmadığı etkileşimleri veya hiç kaydedilmeyen bir API işlemini otomatik olarak bilemez. Araç seçimi, önce veri kaynakları ve entegrasyon kapsamı belirlenerek yapılmalıdır.

Küçük bir e-ticaret sitesi nereden başlamalı?

Önce satın alma ölçümünü doğrulayın, en önemli ürün sayfalarındaki insan deneyimini inceleyin ve ürün/fiyat/stok tutarlılığını kontrol edin. Ardından birkaç kontrollü ajan göreviyle erişim ve işlem sorunlarını araştırın. Yeni protokol entegrasyonuna yatırım, hedef platform desteği ve gerçek ticari ihtiyaçla gerekçelendirilmelidir.

Webtures ile insan ve ajan alışveriş yolculuklarını değerlendirin

Webtures olarak dönüşüm analizinde müşterinin kararını tamamlamasını ve işlemin doğru sonuçlanmasını birlikte ele almayı öneriyoruz. Davranış analizini satış ve katkı ölçümüyle ilişkilendirmek için E-Ticaret Büyüme Rehberi’ndeki büyüme metriklerine de bakabilirsiniz. Heatmap, bu çalışmanın insan deneyimini görünür kılan araçlarından biridir. Ürün verisi kontrolleri, ajan görev testleri ve sipariş analiziyle birlikte kullanıldığında, sorunun hangi aşamada oluştuğu daha açık araştırılabilir.

İlk adım; mevcut veriyi, desteklenen alışveriş biçimlerini ve en önemli ticari engelleri aynı değerlendirmede buluşturmaktır. Böylece iyileştirme planı, genel teknoloji beklentileri yerine işletmenin gözlenen ihtiyaçlarına dayanır.

E-ticaret yolculuğunuzdaki ölçüm boşluklarını ve dönüşüm fırsatlarını Webtures ile değerlendirin.