---
title: "Pull vs Changed Pricing vs ARI: Google Hotels Fiyat Teslim Modelleri"
description: "Google Hotels Pull, Changed Pricing ve ARI modellerini freshness, infrastructure, change detection ve ölçek kriterleriyle karşılaştırın."
slug: "pull-vs-changed-pricing-vs-ari"
translationKey: "compare-google-pricing-modes"
locale: "tr"
type: "comparison"
category: "comparison"
tags: ["google-hotels","pull","changed-pricing","ari","pricing","integration"]
publishedAt: "2026-09-19"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
sources:
  - title: "Google Hotels — Pricing delivery modes"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/delivery-mode"
  - title: "Google Hotels — ARI overview"
    url: "https://developers.google.com/hotels/hotel-prices/dev-guide/ari-overview"
---
Google Hotels fiyat entegrasyonunda Pull, Changed Pricing ve ARI aynı hedefe farklı yollarla ulaşır: Google'ın kullanıcılara güncel, rezervasyon yapılabilir rate göstermesi.

Doğru seçim “hangisi daha modern?” sorusundan değil, sizin **change detection, latency ve scale** kabiliyetinizden çıkar.

## Karşılaştırma kapsamı

Bu sayfa bir kazanan seçmez. Karşılaştırma, aynı use case içinde **hangi koşulda hangi modelin veya platform özelliğinin ne tür trade-off ürettiğini** açıklar. Consumer UX, partner erişimi, commercial contract ve teknik entegrasyon aynı şey değildir; karar verirken bunları ayrı boyutlar olarak değerlendirmek gerekir.

## Karşılaştırma

| Kriter | Pull | Changed Pricing | ARI |
|---|---|---|---|
| Ana tetik | Google query | Google query + change hints | Partner push |
| Change detection gereksinimi | Düşük | Orta | Yüksek |
| Partner response latency önemi | Yüksek | Yüksek | Farklı |
| Incremental update kontrolü | Query-driven | Hint-assisted | Partner-driven |
| Data model | itinerary pricing | itinerary pricing | rates/inventory model |
| Büyük ölçek optimizasyonu | Query volume'a bağlı | Daha seçici | Değişiklik push'u |

## Pull

Google hangi hotel/itinerary fiyatını istediğini sorar; partner cevap verir.

Avantajı, fiyat değişikliklerini önceden bilmek zorunda olmamanızdır.

Zorlukları:

- request volume,
- latency,
- upstream dependency,
- timeout yönetimi.

## Changed Pricing

Changed Pricing, Google'ın hangi kombinasyonları tekrar sorgulaması gerektiğini daha akıllı belirlemesine yardım eden change/hint yaklaşımı ekler.

Partner price change sinyali üretebiliyorsa gereksiz sorgu azalabilir.

Ancak change detection yanlışsa stale price riski ortaya çıkabilir.

## ARI

ARI partner'ın availability/rate/inventory modelindeki değişiklikleri push etmesine dayanır.

Güçlü change-data pipeline'ı olan connectivity sistemleri için doğal olabilir.

Ancak ARI başarılı olmak için şunları gerektirir:

- doğru inventory state,
- incremental change tracking,
- restrictions,
- taxes/fees consistency,
- reliable delivery/retry.

## Karar matrisi

### Pull'a yakın durum

- source system only-on-demand pricing üretiyor,
- change events yok,
- query latency kabul edilebilir,
- upstream ölçeklenebilir.

### Changed Pricing'e yakın durum

- hangi hotel/date tarafında değişiklik olduğunu biliyorsunuz,
- full ARI domain modeline geçmek istemiyorsunuz,
- query volume azaltmak istiyorsunuz.

### ARI'ye yakın durum

- rate/inventory state sizin kontrolünüzde,
- incremental event üretebiliyorsunuz,
- yüksek hacimde push yaklaşımı tercih ediliyor,
- restrictions/promotions gibi domain alanları güçlü modellenmiş.

## Hibrit düşünmek

Architecture decision tek bir endpoint seçmekten ibaret değildir.

Cache, live query, fallback ve monitoring katmanları pricing delivery modelinizin etrafında birlikte tasarlanmalıdır.

## Ölçmeden karar vermeyin

Pilot sırasında ölçün:

- requests per property,
- p95 pricing latency,
- stale-price rate,
- update volume,
- API cost,
- price accuracy,
- recovery time after failure.

Bu veriler teorik mimari tercihinden daha güvenilir karar sağlar.

## Sonuç

Pull, Changed Pricing ve ARI'nin amacı aynıdır; operational ownership farklıdır.

Kendi sisteminizde fiyatın **ne zaman değiştiğini ne kadar iyi bildiğiniz**, doğru delivery mode seçiminin merkezindedir.


## Seçim kriteri: source-of-truth nerede?

Delivery mode seçiminde en faydalı soru “hangi protokol daha hızlı?” değil, **rate/inventory state'in authoritative source'u nerede ve değişiklik sinyalini kim güvenilir biçimde üretebiliyor?** sorusudur. Bu cevap cache, retry, replay ve observability tasarımını da belirler.