Google Hotel Feeds: Veri Sözleşmeleri ve Hata Yönetimi

Google otel bağlantısı; kimlikleri, güncelleme biçimleri ve hata sonuçları farklı veri sözleşmelerinden oluşur. Bunları tek bir “otel feed'i” olarak ele almak bağımlılıkları gizler: geçerli tesis dosyası, oda envanterinin, konaklama fiyatının veya rezervasyon hedefinin doğru olduğunu kanıtlamaz.

Google Hotels profili, platformu ve operasyon sahipliğini açıklar. Bu sayfa feed sorumluluklarını ve kurtarma kararlarını kapsar. Kimlik doğrulama, request/response örnekleri ve adaptör uygulaması için entegrasyon rehberini kullanın.

Üretim senaryosu: fiyat güncellemesi kabul edildi, teklif hâlâ yanlış

Örnek bir channel manager oda fiyatını değiştirirken yoğun bir gün için girişleri kapatıyor. Exporter başarılı sonuç bildiriyor; ancak örnek bir landing eski konaklamayı sunuyor. Yalnızca fiyat dosyasına bakmak iki soruyu kaçırır: giriş kısıtı doğru sözleşmeye ulaştı mı ve gözlenen teklif aynı oda/fiyat planı ile aynı revizyona mı dayanıyor?

Kaynak değişikliği, normalizasyon, serialization, iletim ve gözlenen sonuç için olay zaman çizelgesi oluşturun. Taşıma katmanındaki alındı yanıtı bu çizelgenin yalnızca bir adımını açıklar. Tesis eşlemesini, fiyat işlemeyi ve rezervasyon motorunun davranışını ayrı gözlemler olarak tutun.

Hangi veri hangi sözleşmeye aittir?

Google belgeleri Hotel List ↗, fiyat iletimi, oda/paket bilgisi ve landing page ↗ katmanlarını ayırır. Her biri için ayrı doğrulama ve sahiplik kullanın. Tablo sorumlulukları gösterir; evrensel iletim sırası veya eksiksiz XML şeması değildir.

Google'ın ARI genel bakışı ↗, ARI fiyatlaması kullanılmadan önce Transaction property data, rate, inventory ve availability mesajlarını gerekli olarak tanımlar. İsteğe bağlı mesaj aileleri ek fiyat davranışlarını destekler. Tek bir rate mesajının başarıyla gönderilmesini tamamlanmış başlangıç yüklemesi saymayın.

Hotel List ve Actions Center POI ayrı entegrasyonlardır

Hotel List, Hotel Prices'a aittir. Actions Center Lodging ise kendi aggregator entegrasyonunu ↗ ve POI sözleşmesini ↗ yayımlar. İkisi de tesis tarif edebilir; ancak birbirinin doğrudan alternatifi değildir. Onaylı entegrasyonunuzla ilişkili sözleşmeyi seçin.

Örneğin POI sözleşmesi, partner tarafından üretilen poi_id alanını tanımlar; zorunlu tesis bilgilerini isteğe bağlı alanlardan ayırır. Tesisin web sitesi URL'si eşleme amacıyla kullanılır. Bu alanı Hotel Prices landing-page dosyasında tanımlanan rezervasyon hedefi olarak varsaymayın.

Yararlıysa ortak bir iç tesis kaydı tutup bağımsız adaptörler üretin. Şema doğrulamasını, kimlikleri, kabul sürecini ve tanılamayı ayrı tutun. Bir exporter başka Google yüzeyine uyarlandığında ortaya çıkabilen “geçerli JSON, yanlış ürün” hatasını bu ayrım önler.

İç yayınlama modeli

Aşağıdaki JSON, örnek bir iç denetim kaydıdır. Google API isteği veya yükleme için kabul edilen şema değildir. Alanların amacı, kaynak durumunu gönderilen içerikle ve sonraki gözlemle ilişkilendirmektir.

{
  "publicationId": "pub-1042",
  "contract": "hotel-prices-ari-availability",
  "partnerPropertyId": "H-104",
  "roomTypeId": "DBL",
  "ratePlanId": "FLEX",
  "sourceRevision": 42,
  "observedAt": "2026-09-21T10:00:00Z",
  "affectedStayDates": ["2026-10-10"],
  "payloadDigest": "sha256:example",
  "state": "awaiting-observation"
}

Revizyon kaynak durumunu, digest ise serialize edilmiş baytları tanımlar. Sözleşme adı; availability güncellemesini rate veya tesis güncellemesinden ayırır. Taşıma yöntemi sağlıyorsa gerçek request ID'sini ve yanıt ayrıntılarını denetim izine ekleyin. Karşılık gelen bir gözlem olmadan alındı yanıtı verilmiş güncellemeyi “görünür” olarak etiketlemeyin.

Çok müşterili bir exporter'da hesap sahipliğini yayınlama anahtarına dahil edin. Tesis ID'si yalnızca bir partner hesabı içinde benzersiz olabilir. Kimliği tesis adından veya dizi sırasından türetmek yerine kararlı eşlemeler kullanın.

Yayınlama akışı ve kurtarma sınırları

Önerilen iç akış; kaynak görüntüsünü alma, normalize etme, hedef sözleşmeyi doğrulama, serialize etme, yayımlama, yanıtı sınıflandırma ve gözlenebilir durumla mutabakat adımlarından oluşur. Bunlar sizin pipeline aşamalarınızdır; Google servisleri arasında işlemsel bütünlük garantisi değildir.

Güncel durum mutabakatı, kayıp olayların bıraktığı boşlukları tespit etmelidir. Çalışma sıklığı sizin operasyon kararınızdır. Replay, sözleşmeyi dikkate almalıdır: önceki sürüm teknik olarak başarılıydı diye eski fiyat payload'ını körlemesine geri göndermeyin. Bu, sonradan kapatılmış envanteri yeniden açabilir.

Hata senaryoları: eski, boş ve reddedilen veriyi ayırın

Eksik veri her sözleşmede silme talimatı değildir. Bir varlığı kaldırmadan veya müsaitliği temizlemeden önce ilgili sözleşmenin silme/güncelleme anlamını izleyin. Adaptör, tesis listeleri, Transaction mesajları ve ARI güncellemeleri için tek bir kural uydurmamalıdır.

Olay sırası bozulduğunda serialization öncesinde kaynak revizyonlarını doğru varlık ve sözleşme kapsamında karşılaştırın. Bu bir iç eski-veri korumasıdır; Google'ın idempotency garantisi olduğu varsayımı değildir. Yinelenen taşıma denemesini, aynı iş değişikliğinin tekrar oluşmasından ayırın.

Hataları önce kimlik doğrulama, bozuk payload, desteklenmeyen değer, geçici taşıma sorunu ve belirsiz sonuç olarak sınıflandırın. Deterministik doğrulama hatasını retry öncesinde düzeltin. Geçici hatalarda tekrarları sınırlayın ve denenen içeriği kaydedin; uzun gecikmeden sonra kaynak görüntüsünün hâlâ güncel olup olmadığını yeniden değerlendirin.

Landing page bağımsız bir yayınlama yüzeyidir

Feed yayını fiyatları doğru bırakıp tıklamaları bozabilir. Landing yapılandırmasını ayrıca sürümleyin; üretilen URL'yi hedef tarih ve misafirlerle temiz oturumda test edin. Varsayılan para birimi, doluluk veya oda seçiminin karşılaştırmayı sessizce değiştirmediğini kontrol edin.

Google'ın landing-page belgesi, her dosyayı tek partner ile sınırlar. Hesap/partner sahipliğini deployment doğrulamasının parçası yapın. Uygulama ayrıntıları ve desteklenen değişkenler için entegrasyon rehberine ve güncel resmi referansa başvurun.

Operasyonel izleme ve test matrisi

İşleme aşamalarını bağımsız ölçün. Nedene göre reddedilen varlıklar, kaynaktan yayına gecikme, eşlenmeyen tesisler, bastırılan eski revizyonlar, çözümlenmemiş iletim sonuçları ve landing uyuşmazlıkları yararlı iç sinyallerdir. Aşaması ve paydası tanımlanmamış bir genel “feed başarı oranı” yayımlamayın.

Üretimde kapsamı genişletmeden önce her hata sınıfının kurtarma sahibini belirleyin ve exporter'ın kaçan güncellemeyi mutabakatla düzeltebildiğini gösterin. Kaynak görüntülerinin ve gözlemlerin kimlik bilgilerini veya misafir verisini açığa çıkarmadan birleştirilebildiğini doğrulayın. Şemalar ve desteklenen davranışlar resmi referanslardan gelir; denetim modeli, kurtarma stratejisi ve test matrisi mühendislik önerileridir.

Olay incelemesinde platform profilini, bu feed referansını ve uygulama rehberini birlikte kullanın: sırasıyla sorunun sahibini, ilgili sözleşmeyi ve sözleşmenin nasıl uygulandığını açıklarlar.