Google UCP ile AI Mode'da satış nasıl yapılır?

Google UCP ile AI Mode'da satış yapmak için ürün, sepet, ödeme ve sipariş sistemlerini protokole uyumlu API'lerle bağlamalısınız. Merchant Center kaydı tek başına doğrudan satın alma sağlamaz.

Universal Commerce Protocol, yapay zekâ aracısının mağazanızla standart biçimde iletişim kurmasını amaçlar. Ancak entegrasyon, AI Mode içinde otomatik görünürlük veya Türkiye'de hemen kullanılabilirlik garantisi vermez.

Google UCP nedir ve AI Mode satış akışında ne yapar?

Google UCP, yapay zekâ aracıları ile satıcı sistemleri arasındaki ticaret işlemlerini standartlaştırır. Ürün keşfinden sipariş durumuna kadar farklı adımlar için ortak bir iletişim yapısı sunar.

Klasik aramada kullanıcı mağazaya yönlendirilir ve işlemi sitede tamamlar. UCP destekli senaryoda yapay zekâ, uygun ürünleri karşılaştırabilir ve desteklenen yüzeyde satın alma akışını yönetebilir.

Bu yapı, ürün veritabanınızın Google'a taşınması anlamına gelmez. Mağazanız fiyat, stok, teslimat ve sipariş bilgileri açısından temel kayıt sistemi olmaya devam eder.

Örneğin kullanıcı, belirli ölçülerde ve ertesi gün teslim edilebilen bir ürün isteyebilir. Yapay zekâ, katalog verisini tarar; fakat son fiyatı canlı sistemden doğrulamalıdır.

Stok bilgisini yalnız günlük ürün dosyasından alan mağazalarda hata riski oluşur. Son ürün satıldıktan sonra eski veriyle sipariş alınması, iptal ve müşteri şikâyeti doğurabilir.

UCP belgelerinde tanımlanan yetenekler, her mağazada aynı anda açılmak zorunda değildir. Satıcı yalnız teknik ve operasyonel olarak karşılayabildiği işlemleri bildirmelidir.

• Ürün keşfi, uygun seçeneklerin bulunmasını sağlar.
• Sepet işlemleri, ürün ve miktar değişikliklerini yönetir.
• Ödeme akışı, toplam tutarın onaylanmasını sağlar.
• Sipariş işlemleri, kayıt ve durum takibini bağlar.

Yanlış: UCP kurulduğunda bütün ürünler AI Mode'da otomatik satılır. Doğru: UCP teknik iletişimi sağlar; uygunluk, ülke, kategori ve Google erişimi ayrıca değerlendirilir.

UCP entegrasyonundan önce hangi sistemler hazırlanmalıdır?

Entegrasyondan önce katalog, stok, fiyat, teslimat, vergi ve sipariş sistemleri tutarlı çalışmalıdır. Aynı ürünün farklı sistemlerde farklı kimliklerle tutulması önce çözülmelidir.

Her satılabilir varyant için değişmeyen bir ürün kimliği kullanın. Renk veya beden satın alma kararını değiştiriyorsa varyantları ayrı stok birimleri olarak kaydedin.

Merchant Center kimliği, mağaza SKU'su ve sipariş sistemindeki satır kimliği eşleştirilebilir olmalıdır. Bu eşleşme olmadan iadeyi doğru ürüne bağlamak zorlaşır.

Yapılandırılmış veri de katalogla çelişmemelidir. Ürün işaretlemesini istemci tarafında üretiyorsanız Google ürün şeması JavaScript ile eklenir mi? rehberindeki tarama ve render risklerini kontrol edin.

Görseller için ana ürün, varyant ve alternatif açı ilişkisini belirleyin. Görsel meta verisi kullanan ekipler, Merchant Center görseline IPTC etiketi ekleme sürecini ayrıca inceleyebilir.

Entegrasyon başlamadan aşağıdaki kontrol listesi tamamlanmalıdır. Her madde için sorumlu ekip ve doğrulama yöntemi proje kaydına yazılmalıdır.

• Ürün ve varyant kimlikleri bütün sistemlerde eşleşiyor.
• Fiyat API'si indirim başlangıç ve bitiş zamanlarını yönetiyor.
• Stok servisi satılabilir miktarı güncel döndürüyor.
• Kargo seçeneği posta koduna veya bölgeye göre hesaplanıyor.
• Vergi ve toplam tutar ödeme öncesinde yeniden hesaplanıyor.
• Sipariş sistemi yinelenen istekleri ayırt edebiliyor.
• İptal, iade ve kısmi iade kuralları tanımlanmış durumda.
• API erişimleri kayıt altına alınıyor ve izlenebiliyor.

Bu hazırlık, yalnız UCP için yapılmaz. Aynı veri disiplini site, uygulama, reklam akışları ve müşteri hizmetleri ekranlarındaki çelişkileri de azaltır.

Ürün, fiyat ve stok verisi UCP için nasıl modellenir?

Ürün verisi, kalıcı katalog bilgileri ile anlık işlem bilgileri ayrılarak modellenmelidir. Başlık ve marka yavaş değişirken fiyat, stok ve teslimat daha sık değişebilir.

Katalog katmanında ürün kimliği, açıklama, marka, görsel ve varyant özellikleri bulunur. İşlem katmanı ise satılabilirlik, güncel tutar, kampanya ve teslimat seçeneğini doğrular.

Merchant Center dosyasını UCP'nin yerine kullanmak doğru değildir. Ürün dosyası keşif için güçlü bir kaynak olabilir; ancak ödeme anındaki toplam tutarı tek başına garanti etmez.

Bir ürün sayfasında 900 TL, ürün dosyasında 850 TL ve ödeme sisteminde 925 TL görünüyorsa entegrasyon hazır değildir. Önce fiyatın hangi sistemde yönetileceği belirlenmelidir.

Kaynak önceliğini yazılı hâle getirin. Örneğin ürün adı PIM sisteminden, satılabilir stok ERP'den, kampanyalı fiyat fiyatlandırma servisinden ve teslimat tahmini lojistik servisinden gelebilir.

Stok yanıtı yalnız “var” veya “yok” biçiminde tutulmamalıdır. Rezerve edilen miktar, mağaza stoğu ve depodan sevk edilebilir miktar ayrıştırılmalıdır.

Veri tazeliği nasıl belirlenir?

Tek bir güncelleme süresi bütün alanlara uygulanmamalıdır. Süreyi, alanın değişim sıklığına ve yanlış bilginin oluşturacağı zarara göre belirleyin.

Stok hızla tükeniyorsa olay tabanlı güncelleme veya canlı sorgu gerekir. Haftada değişen açıklamalar için aynı altyapıyı kurmak gereksiz maliyet oluşturabilir.

Her yanıta kaynak zamanı ve izlenebilir işlem kimliği eklemek hata incelemesini kolaylaştırır. Böylece yapay zekâya hangi anda hangi fiyatın döndürüldüğü bulunabilir.

AB'ye satış yapan mağazalar, ticari verinin yanında erişilebilirlik koşullarını da değerlendirmelidir. AB'ye satış yapan site EAA'ya nasıl hazırlanır? sayfası ödeme akışındaki temel kontrolleri açıklar.

Google UCP entegrasyonu hangi adımlarla yapılır?

UCP entegrasyonu, resmi belgelerdeki güncel şema ve yetenek tanımları temel alınarak yapılır. Alan veya uç nokta adlarını tahmin ederek üretim bağlantısı kurulmaz.

Önce desteklenecek işlemleri sınırlayın. Ürün arama, sepet oluşturma ve sipariş sorgulama çalışmadan iptal veya kısmi iade gibi karmaşık işlemlere geçmeyin.

1. Kapsamı belirleyin: İlk sürümde desteklenecek ülke, para birimi, ürün grubu ve teslimat yöntemlerini yazın.
2. Kaynak sistemleri eşleyin: Her UCP verisinin katalog, ERP, ödeme veya lojistik sistemindeki karşılığını belirtin.
3. Yetenekleri tanımlayın: Mağazanın gerçekten gerçekleştirebildiği işlemleri, güncel resmi şemaya göre bildirin.
4. Kimlik doğrulamayı kurun: Anahtarları kod içine yazmayın. Gizli bilgileri erişimi sınırlı bir kasada saklayın.
5. İstek doğrulaması ekleyin: Ürün, miktar, ülke ve para birimi gibi alanları işlem başlamadan kontrol edin.
6. İşlem tekrarını yönetin: Aynı isteğin iki kez gelmesi durumunda ikinci siparişin oluşmasını engelleyin.
7. Test ortamını bağlayın: Başarılı işlemler kadar stok bitmesi, ödeme reddi ve zaman aşımı durumlarını deneyin.
8. Üretimi kademeli açın: Önce sınırlı ürün grubu kullanın. Kayıtları doğruladıktan sonra kapsamı genişletin.

Her adım için kabul ölçütü bulunmalıdır. “Sepet servisi tamamlandı” ifadesi yerine, toplamın vergi ve kargoyla yeniden hesaplandığını doğrulayan test sonucu kaydedilmelidir.

UCP ile sohbet tabanlı ürün desteği aynı proje içinde değerlendirilebilir. Ancak Google Business Agent Türkiye'de kullanılabilir mi? sorusundaki erişim koşulları ayrıca kontrol edilmelidir.

Resmi belgelerin sürümü değiştiğinde entegrasyon eşlemesi yeniden incelenmelidir. Eski örnek kodun çalışması, yeni zorunlu alanları karşıladığı anlamına gelmez.

Ödeme ve sipariş güvenliği nasıl sağlanır?

Ödeme güvenliği, kart verisini gereksiz yere mağaza sistemine taşımadan sağlanmalıdır. Kullanılan ödeme yönteminin sorumluluk sınırları teknik tasarımda açıkça gösterilmelidir.

Ödeme öncesinde ürün, miktar, fiyat, vergi, kargo ve indirim yeniden doğrulanır. Kullanıcıya gösterilen toplam ile tahsil edilecek toplam farklıysa açık onay alınmadan işlem ilerlememelidir.

Kart numarası gibi hassas ödeme verilerini günlük kayıtlarına yazmayın. Uygulama kayıtlarında yalnız hata incelemesi için gereken, maskelenmiş ve kişisel veri içermeyen alanları tutun.

Her sipariş oluşturma isteğine benzersiz bir tekrar önleme anahtarı bağlayın. Ağ zaman aşımında aynı isteğin yeniden gönderilmesi, ikinci sipariş veya ikinci tahsilat oluşturmamalıdır.

Sipariş kaydı ödeme sonucuyla tutarlı olmalıdır. Ödeme başarılı, sipariş başarısız durumunda otomatik düzeltme veya ücret iadesi süreci devreye girmelidir.

Tersi durumda, başarısız ödeme için sipariş hazırlanmasına başlanmamalıdır. Ödeme durumu belirsizse depo işlemi, ödeme sağlayıcısından kesin sonuç gelene kadar bekletilmelidir.

Hangi hata durumları test edilmelidir?

Stok tükenmesi, fiyat değişmesi, geçersiz adres ve ödeme reddi ayrı senaryolardır. Kullanıcıya aynı genel hata mesajını göstermek sorunun nasıl düzeltileceğini belirsiz bırakır.

Ayrıca servis zaman aşımı, yinelenen istek, kısmi stok ve kargo seçeneğinin kaybolması denenmelidir. Her hata için yeniden deneme ve işlemi durdurma kuralları belirlenmelidir.

İptal ve iade politikaları satın alma öncesinde erişilebilir olmalıdır. Özellikle kişiselleştirilmiş ürünlerde standart iade varsayımı kullanmak operasyonel ve hukuki uyuşmazlık oluşturabilir.

Güvenlik testi yalnız yayına çıkarken yapılmaz. Yetki anahtarları yenilendiğinde, ödeme sağlayıcısı değiştiğinde veya yeni ülke açıldığında ilgili test paketi yeniden çalıştırılmalıdır.

UCP, Merchant Center ve ürün şeması arasındaki fark nedir?

UCP işlem iletişimini, Merchant Center ürün dağıtımını, ürün şeması ise sayfadaki makine okunabilir bilgiyi destekler. Bu üç yapı birbirinin doğrudan alternatifi değildir.

Bu ayrım veri tutarsızlığını teşhis ederken önemlidir. Merchant Center fiyatı doğru olsa bile canlı sepet servisi yanlış vergi ekliyorsa satın alma yine başarısız olur.

Ürün şeması da kaynak sistem yerine geçmez. Sayfadaki işaretleme, kullanıcıya görünen fiyat ve stokla eşleşmelidir; gizli veya eski veri yayımlanmamalıdır.

UCP daha çok işlem anındaki iletişim katmanıdır. Yapay zekâ aracısının niyetini mağaza servislerine, mağaza yanıtını da anlaşılır işlem sonucuna dönüştürür.

Bir katmanın başarılı olması diğerini doğrulamaz. Ekipler katalog doğruluğu, canlı işlem doğruluğu ve satın alma sonrası sipariş durumunu ayrı test gruplarında ölçmelidir.

Entegrasyonun işe yaramadığı durumlar da vardır. Fiyatı teklif sonrasında belirlenen, stok kaydı bulunmayan veya insan onayı gerektiren ürünler doğrudan satın almaya uygun olmayabilir.

UCP entegrasyonu nasıl test edilir ve performansı nasıl ölçülür?

UCP entegrasyonu, teknik başarı ve ticari sonuç ayrı ölçülerek test edilir. Yalnız tamamlanan sipariş sayısına bakmak hata kaynağını göstermeye yetmez.

İlk katmanda API yanıt süresi, hata oranı ve zaman aşımı izlenir. İkinci katmanda sepet oluşturma, ödeme başlatma ve sipariş tamamlama geçişleri ölçülür.

Üçüncü katman operasyon kalitesidir. İptal edilen siparişler, stok nedeniyle reddedilen işlemler, fiyat uyuşmazlıkları ve manuel destek gerektiren kayıtlar ayrı neden kodlarıyla tutulmalıdır.

Ölçüm başlangıcında sabit bir rakam hedefi uydurmayın. Mevcut site veya uygulama verisini referans alın; aynı ürün grubu, ülke ve cihaz bağlamıyla karşılaştırın.

Örneğin UCP siparişlerinde iptal oranı yükseliyorsa önce stok tazeliğini inceleyin. Dönüşüm düşüklüğünü doğrudan ürün talebine bağlamak, teknik hataları görünmez kılabilir.

• Başarılı ve başarısız her işlem için izleme kimliği oluşturun.
• Sepet toplamı ile sipariş toplamını otomatik karşılaştırın.
• Stok reddini ürün ve depo düzeyinde raporlayın.
• Ödeme reddi ile teknik ödeme hatasını ayırın.
• Aynı isteğin oluşturduğu yinelenen kayıtları izleyin.
• İptal ve iade nedenlerini UCP siparişleriyle eşleyin.

Deney tasarımında yalnız kanal adı kullanılmamalıdır. Ürün fiyat aralığı, yeni veya mevcut müşteri, teslimat bölgesi ve kampanya etkisi sonuçları değiştirebilir.

Gelir atfı için sipariş kimliği temel bağlantıdır. Reklam veya analiz etiketi çalışmasa bile sipariş sistemi, işlemin UCP akışından geldiğini raporlayabilmelidir.

Test, gerçek ödeme verileriyle kontrolsüz yapılmamalıdır. Deneme ürünleri, test hesapları ve ödeme sağlayıcısının desteklediği güvenli test yöntemleri kullanılmalıdır.

Türkiye'deki e-ticaret ekipleri UCP için şimdi ne yapmalıdır?

Türkiye'deki ekipler önce teknik hazırlığı tamamlamalı, ardından hesap ve ülke uygunluğunu resmi kanallardan doğrulamalıdır. Belge yayımlanması, özelliğin her mağazada açıldığı anlamına gelmez.

Google'ın güncel geliştirici belgelerini, Merchant Center bildirimlerini ve hesap içi uygunluk ekranlarını birlikte kontrol edin. Blog duyurusunu üretim erişiminin tek kanıtı olarak kabul etmeyin.

İlk çalışma için yüksek stoklu ve sabit fiyatlı bir ürün grubu seçin. Kişiselleştirme, teklif alma veya kurulum keşfi gerektiren ürünleri başlangıç kapsamına eklemeyin.

Dört haftalık bir hazırlık planı kullanılabilir; ancak süre ekip ve sistem durumuna göre değişir. İlk bölüm veri eşleme, ikinci bölüm API, üçüncü bölüm hata testleri, son bölüm pilot doğrulama için ayrılır.

Pilot kapsamını ürün sayısıyla değil riskle belirleyin. Aynı fiyatlandırma ve teslimat kurallarını kullanan sınırlı bir grup, rastgele seçilen geniş katalogdan daha kolay doğrulanır.

Ürün pasaportu veya mevzuat bilgisi gereken ihracat senaryolarında ek veri katmanları oluşabilir. AB'ye satışta DPP bilgisi nasıl sunulur? rehberi bu ayrımı planlamaya yardımcı olur.

UCP uygun değilse mevcut satın alma yolculuğu korunmalıdır. Kullanıcı ürün sayfasına yönlendirilebilir veya insan desteğine aktarılabilir; işlem yarıda ve açıklamasız bırakılmamalıdır.

Son karar üç soruya dayanmalıdır: Canlı fiyat dönebiliyor mu, stok güvenilir mi ve sipariş otomatik yönetilebiliyor mu? Birine “hayır” cevabı veriliyorsa önce temel sistem düzeltilmelidir.

Hazırlığın çıktısı çalışan koddan fazlasıdır. Veri sözlüğü, yetenek listesi, hata matrisi, güvenlik kaydı, test sonuçları ve geri alma planı aynı dosya setinde tutulmalıdır.