Google Hotels: Platform, Rezervasyon Akışı ve Operasyon

Google Hotels, otel keşfini katılımcı sağlayıcıların rezervasyon tekliflerine bağlar. Sağlıklı bir bağlantı için fiyat göndermek yeterli değildir: seçilen tesis, konaklama, misafirler, oda koşulları ve ödenecek tutar rezervasyon motoruna geçildiğinde de aynı kalmalıdır.

Bu profil platformun rolünü ve operasyonel kararları açıklar. Google Hotel Feeds referansı veri sorumluluklarını; Google Hotels entegrasyon rehberi uygulama akışlarını ve request/response örneklerini kapsar.

Üretim senaryosu: gösterilen fiyatla rezervasyon yapılamıyor

Örnek bir otel, iki yetişkin için iki gecelik, iade edilebilir konaklama satıyor. Google'da EUR 240 görünen teklifin ödeme adımında EUR 280 olması zorunlu ücret, değişen fiyat, farklı doluluk veya farklı odadan kaynaklanabilir. Reklam teklifini yükseltmek bu nedenleri düzeltmez.

Tekrarlanabilir tek bir teklif karşılaştırmasıyla başlayın. Tesis kimliklerini, giriş ve çıkışı, yetişkin sayısını, çocuk yaşlarını, oda/fiyat planı kimliklerini, para birimini, öğün planını, iptal koşullarını ve zorunlu ücretleri kaydedin. Her fiyatın ne zaman gözlemlendiğini ekleyin. Olayı eski fiyat olarak sınıflandırmadan önce aynı koşullardaki toplam konaklama tutarını karşılaştırın.

Bu bir operasyon örneğidir; Google payload'ı veya yayınlanmış bir doğruluk eşiği değildir.

Google Hotels rezervasyon akışında nerede durur?

Google keşif ve teklif görünürlüğü sağlar; bağlantının yönlendirdiği sağlayıcı rezervasyon yolculuğunu yürütür. Konaklamayı satan otel veya OTA ile veriyi gönderen teknoloji ortağı farklı kuruluşlar olabilir. Veri sorununun bağlantı ekibine, rezervasyon sorununun ise rezervasyon sahibine ulaşması için sorumlulukları açıkça tanımlayın.

Bu, önerilen bir sorumluluk modelidir. Belirli bir sözleşmede birden fazla rol aynı kuruluşta birleşebilir.

Erişim ve ticari sınırlar

Google'ın entegrasyon genel bakışı ↗, ücretsiz rezervasyon bağlantıları ile Hotel Ads'i ayırır. Her ikisi de temel otel veri bağlantısına dayanır; Hotel Ads buna ücretli kampanya kontrollerini ekler. Otel yüklemek veya reklam bütçesi ayırmak belirli bir teklifin gösterileceğini kanıtlamaz.

Mevcut bir bağlantı sağlayıcısını kullanmakla kendi adaptörünüzü işletmeyi karşılaştırın. Hotel Center ilişkisinin, tesis kimliklerinin, tanılama verilerinin, landing yapılandırmasının ve olay müdahalesinin kimde olduğunu doğrulayın. API kimlik doğrulaması bu anlaşmanın yalnızca bir parçasıdır. Yönetim API'sine erişim, fiyat bağlantısının çalıştığını tek başına göstermez.

Ücretsiz görünürlüğün de işletme maliyeti vardır: içerik bakımı, fiyat iletimi, rezervasyon motoru kalitesi ve olay müdahalesi. Ücretli müşteri edinimini bu ortak maliyetlerden ayrı değerlendirin. “Metasearch” etiketinden komisyon yüzdesi veya güncel bir teklif stratejisi çıkarmayın.

Kimlik modeli ve teklif eşdeğerliği

Hotel List sözleşmesi ↗, fiyatlardan ziyade tesisleri tanımlar. İç modelinizde kanonik oteli, partner tesis ID'sini ve gözlemlenen Google eşleme sonucunu ayırın. Tedarikçi bir tesisi yeniden adlandırdığında, birleştirdiğinde veya böldüğünde denetim izini koruyun.

Teklif düzeyinde tesis eşleşmesi yalnızca ilk kontroldür. Bir teklif kahvaltı, iade edilebilir iptal koşulu veya zorunlu ücret içerirken diğeri içermiyorsa iki toplam karşılaştırılabilir değildir. Fiziksel envanteri müsaitlik kısıtlarından ayırın: oda mevcut olsa bile belirli giriş günü, doluluk veya konaklama uzunluğu satılamayabilir.

Normalize edilmiş değerlerle birlikte özgün tedarikçi değerlerini de saklayın. Uyuşmazlıkta teklifin kaynakta mı, dönüşümde mi, landing yolculuğunda mı değiştiği böylece anlaşılabilir.

Entegrasyon yüzeyini seçmek

Google, Pull, Changed Pricing ve ARI ↗ yöntemlerini farklı fiyat iletim yaklaşımları olarak belgeler. Uygulama kararı kaynak sistemin yeteneklerine ve bağlantıyı işletme kapasitenize dayanmalıdır. Aşağıdaki karşılaştırma mühendislik önerisidir; herhangi bir yöntemin sonuç garantisi değildir.

Google'ın ARI genel bakışı ↗, konaklamaya özgü fiyat sorgularını yanıtlamak yerine fiyat modelinin bileşenlerini göndermeyi açıklar. Bu nedenle modelin bütünlüğü önemlidir. ARI, güvenilir envanter ve kısıt verisinin yerini tutmaz.

Travel Partner API ↗, desteklenen Hotel Center yönetimi ve tanılama işleri içindir. Raporlama yüzeyini genel tüketici otel arama veya rezervasyon API'si olarak değerlendirmeyin.

Hata senaryoları ve teşhis

Teklif yokluğunun birden fazla nedeni olabilir. “Müsait değil”, “gönderilmedi”, “eşlenmedi”, “reddedildi” ve “gözlemlenmedi” durumlarını tek bir kesinti bayrağına indirgemeyin. Her durumun farklı bir sahibi ve doğrulama yöntemi vardır.

Operasyonel izleme ve karar metrikleri

Sabit inceleme grupları ve açık paydalar kullanın. Aşağıdakiler önerilen iç metriklerdir; Google'ın skor tanımları veya sözleşmesel hizmet seviyeleri değildir. Karşılaştırmaya alınmayan örneklerin nedenini de saklayın; aksi halde başarısız örnekleri dışarıda bırakan bir oran yanıltıcı olabilir.

• Eşleme kapsamı: inceleme grubundaki doğru eşlenmiş gönderilen tesisler / gönderilen tesisler.
• Teklif karşılaştırma başarısı: eşdeğer ve rezervasyon yapılabilir örnekler / incelemeye uygun örnekler.
• Güncelleme gecikmesi: gözlem mümkünse, kaynak değişikliği ile sonraki sistemde gözlenen durum arasındaki süre.
• Landing başarısı: hedeflenen tesis ve konaklamayı koruyan örnek tıklamalar / test edilen tıklamalar.
• Net rezervasyon sonucu: ölçüm politikanızla ilişkilendirilen, iptal ve iadelerle mutabık hale getirilen rezervasyonlar.

İç gözlemleri mevcut Hotel Center raporlarıyla birlikte değerlendirin. Tanılamayı tedarikçi, tesis ve hata nedeni bazında ayırın. Tek bir genel yüzde, az sayıda oteldeki ağır uyuşmazlıkları gizleyebilir. Örnekleme yalnızca incelenen durumlar için kanıttır; bütün tekliflerin doğruluğunu ispatlamaz.

Üretim kontrol listesi

Bağlantıyı genişletmeden önce iade edilebilir ve iade edilemez konaklamayı, doluluk değişimini, zorunlu ücret içeren teklifi ve müsait olmayan günü yeniden üretin. Entegrasyon ve rezervasyon ekiplerinin her örneği kaynak kaydından landing sonucuna kadar izleyebildiğini doğrulayın.

Eşlemeyi fiyat iletiminden bağımsız kontrol edin. Başarısız güncellemelere sahip ve kurtarma yolu atayın. Eski bir olayı yeniden işlemenin daha yeni satılabilirlik verisini ezmediğini sınayın. İç alarm eşiklerini trafik ve iş etkisinden belirleyin; Google için genel bir timeout veya SLA uydurmayın.

Bu profili sorumlulukları seçmek ve hazırlığı değerlendirmek için kullanın. Yayınlama sınırları için feed referansına, adaptör uygulaması için entegrasyon rehberine geçin. Desteklenen davranışı sağlayıcı belgeleri belirler; olay modelleri, metrikler ve karar tabloları metasearch mühendislik önerileridir.