Hotel Price Accuracy Nedir? Metasearch'te Fiyat Tutarlılığı

Price accuracy, metasearch'te kullanıcıya gösterilen hotel offer'ı ile click sonrasında provider üzerinde gerçekten bulunan ve book edilebilen offer'ın ticari olarak ne kadar tutarlı olduğunu ölçer. Sadece “aynı numeric price mı?” sorusu değildir; doğru room, occupancy, itinerary, taxes/fees, discount ve availability context'inin korunup korunmadığını da kapsar.

Örneğin search result'ta 4.800 TL görünen refundable breakfast rate, landing page'de 5.350 TL room-only non-refundable rate'e dönüşüyorsa yalnız fiyat değil product identity de bozulmuştur. Bu yüzden price accuracy bir backend data-quality metriği değil; user trust, conversion ve partner economics metriğidir.

Price accuracy problemi nasıl tanımlanmalı?

Production ölçümünde en az üç observation gerekir:

Displayed Offer
  price = 4,800 TRY
  room = Deluxe
  meal = Breakfast
  cancellation = Free until T-2
  observed_at = 10:01

Click Context
  click_id = abc123
  clicked_at = 10:06

Landing / Validation
  price = 5,350 TRY
  room = Deluxe
  meal = Room Only
  cancellation = Non-refundable
  checked_at = 10:06

Bu durumda “price delta = +550 TL” tek başına root cause değildir. Meal ve cancellation semantics de değişmiştir.

Google Price Accuracy modeli bize ne anlatıyor?

Google Travel Partner API price-accuracy resource'ları cached ve fetched price record'larını, timestamps, hotel/date context'ini, device bilgisini ve mismatch reason'ı birlikte ele alır.

Google'ın enum'larında örnek mismatch reason'lar şunlardır:

• TAX_MISMATCH,
• ROOM_UNAVAILABLE,
• SITE_ERROR,
• PRICE_FEED_DELAYED,
• DISCOUNT_MISSING,
• INCORRECT_DISCOUNT_VALUE,
• WRONG_ITINERARY.

Bu taxonomy önemli bir tasarım prensibi gösterir: mismatch oranı tek başına yetersizdir; neden sınıflandırılmalıdır.

Internal mismatch taxonomy nasıl kurulmalı?

Provider-independent taxonomy daha geniş olabilir:

PRICE_CHANGED
TAX_MISMATCH
MANDATORY_FEE_MISMATCH
CURRENCY_MISMATCH
ROUNDING_ONLY
ROOM_MISMATCH
RATE_PLAN_MISMATCH
MEAL_MISMATCH
CANCELLATION_MISMATCH
OCCUPANCY_MISMATCH
WRONG_ITINERARY
CONDITIONAL_RATE_INELIGIBLE
ROOM_UNAVAILABLE
LANDING_ERROR
DEEPLINK_CONTEXT_LOST
UNKNOWN

Bir event birden fazla reason taşıyabilir. Örneğin room unavailable sonrası fallback room açılır ve farklı price oluşur.

Hangi fiyatlar karşılaştırılmalı?

Search-time price

Search response render edilirken kullanılan observation.

Click-time price

User click anında sistemde bilinen son price.

Landing-time price

Provider landing veya validation mekanizmasında gözlemlenen price.

Checkout/final price

Mandatory tax/fee dahil final payable amount.

Bu checkpoint'ler aynı olmak zorunda değildir; fakat farkın reason'ı açıklanabilir olmalıdır.

Comparable offer fingerprint nasıl oluşturulur?

Price karşılaştırmadan önce product comparability belirlenmelidir.

Örnek fingerprint:

property
+ check-in
+ nights
+ adults/children
+ room canonical class
+ rate-plan semantics
+ meal
+ cancellation bucket
+ eligibility
+ currency

Numeric amount yalnız bu fingerprint eşleştiğinde anlamlıdır.

Aksi halde sistem “fiyat değişti” sanırken aslında farklı product karşılaştırıyor olabilir.

Taxes ve fees neden en sık hata kaynaklarından biridir?

Provider A:

Base          4,000
Tax             500
Mandatory fee   300
Total         4,800

Provider B yalnız base price döndürürse UI 4,000 TL gösterip daha ucuz görünür. Landing'de total 4,800 TL olur ve kullanıcı bunu mismatch olarak algılar.

Pricing modelinde şunları ayrı tutun:

• base amount,
• tax,
• mandatory fee,
• optional fee,
• resort/destination fee,
• pay-at-property amount,
• display total,
• billable total,
• currency.

“Total” alanının contract'taki tanımı yazılı olmalıdır.

Cache age ile mismatch ilişkisi nasıl ölçülür?

Global accuracy oranı yerine cache-age bucket analizi daha aksiyoneldir:

Bu tablo 10 dakikadan sonra riskin hızla arttığını gösterebilir. Provider ve check-in proximity ile birlikte analiz edilirse adaptive TTL üretilebilir.

Root-cause analizi hangi sırayla yapılmalı?

Bir mismatch event geldiğinde şu sıra hızlıdır:

1. Search context aynı mı?
   |
   +-- hayır -> WRONG_ITINERARY / OCCUPANCY
   |
2. Property/room/rate aynı mı?
   |
   +-- hayır -> MAPPING
   |
3. Currency aynı mı?
   |
   +-- hayır -> CURRENCY
   |
4. Tax/fee inclusion aynı mı?
   |
   +-- hayır -> TAX/FEE
   |
5. Conditional eligibility aynı mı?
   |
   +-- hayır -> RATE_RULE
   |
6. Offer age yüksek mi?
   |
   +-- evet -> STALE / FEED_DELAY
   |
7. Room hala available mı?
   |
   +-- hayır -> ROOM_UNAVAILABLE
   |
8. Deeplink context korunmuş mu?
   |
   +-- hayır -> DEEPLINK_CONTEXT_LOST

Bu akış support ticket'tan engineering RCA'ya geçişi hızlandırır.

Price accuracy event modelinde ne tutulmalı?

interface PriceAccuracyEvent {
  clickId: string;
  providerId: string;
  propertyId: string;

  checkIn: string;
  nights: number;
  occupancyKey: string;

  displayed: PriceRecord;
  landed?: PriceRecord;

  roomFingerprint: string;
  rateFingerprint: string;

  cacheAgeSeconds: number;
  mismatchReasons: string[];

  checkedAt: string;
  source: "fetch" | "pixel" | "provider-api" | "manual";
}

Raw evidence veya payload reference saklamak RCA için değerlidir.

Tolerance policy nasıl tanımlanmalı?

Her numeric fark critical değildir. Currency rounding veya cent-level fee variation business açısından tolerable olabilir.

Örnek:

absolute delta <= 1 unit       -> rounding bucket
relative delta <= 0.5%         -> soft match
relative delta 0.5% - 5%       -> mismatch
relative delta > 5%            -> severe mismatch
room unavailable               -> severe
wrong itinerary                -> severe

Tolerance market/currency bazlı olabilir. Ancak threshold sorunları gizlememelidir; exact raw delta yine saklanmalıdır.

Failure mode'lar nelerdir?

Yanlış mapping

Canonical hotel doğru fakat room/rate mapping yanlış olabilir.

Delayed price feed

Supplier price günceller, sizin refresh pipeline geride kalır.

Cache invalidation kaçırılır

Update event alınır ama ilgili key invalidate edilmez.

Conditional rate leakage

Member/mobile/geo rate herkes için public offer gibi gösterilir.

Wrong landing context

Deeplink date veya occupancy parametresini kaybeder.

Currency timestamp farkı

Search ve landing farklı FX rate ile convert edilir.

Fallback room

Selected room unavailable olunca provider başka room açar; amount değişir.

Site rendering error

Provider landing doğru data içerir ama validator/crawler yanlış element okur.

Hangi KPI'lar dashboard'da olmalı?

Accuracy

• exact match rate,
• soft-match rate,
• mismatch rate,
• severe mismatch rate.

Root cause

• mismatch by reason,
• provider,
• property,
• market,
• device,
• stay-date bucket,
• room/rate type.

Freshness

• mismatch by cache-age bucket,
• live vs cached accuracy,
• delayed-feed rate.

User impact

• click abandonment after mismatch,
• conversion by accuracy bucket,
• support complaints,
• provider switch after reprice.

Economics

• paid-click spend on mismatched offers,
• lost CPA/commission estimate,
• provider contribution after quality adjustment.

Provider health score nasıl kullanılmalı?

Price accuracy, provider quality score'un bir component'i olabilir:

provider_quality =
  accuracy_weight
+ availability_weight
+ latency_weight
+ deeplink_success_weight
+ conversion_weight

Ancak component değerleri görünür kalmalıdır. Tek birleşik score root cause'u saklamamalıdır.

Mismatch bulunduğunda hangi otomatik aksiyonlar alınabilir?

Reason'a göre:

• TTL kısalt,
• refresh priority artır,
• problematic property'yi live-only moda al,
• provider rank penalty uygula,
• conditional rate'i suppress et,
• deeplink template'i quarantine et,
• supplier alert üret,
• severe mismatch'te offer'ı geçici kapat.

Her otomasyon false-positive riskine karşı threshold ve minimum sample ile çalışmalıdır.

Production checklist

• Comparable offer fingerprint tanımlı mı?
• Search/click/landing price ayrı kaydediliyor mu?
• Base/tax/fee component'leri ayrı mı?
• Mismatch reason taxonomy var mı?
• Cache age event'e ekleniyor mu?
• Raw provider evidence saklanıyor mu?
• Conditional rate eligibility doğrulanıyor mu?
• Deeplink date/occupancy testleri var mı?
• Tolerance policy currency/market için tanımlı mı?
• Provider/property bazlı dashboard var mı?
• Mismatch feedback cache/ranking'e dönüyor mu?
• Severe mismatch için automatic suppression var mı?

Neden business metriğidir?

Price accuracy düşük olduğunda yalnız teknik hata oluşmaz. User trust azalır, conversion düşer, paid traffic boşa gidebilir, provider quality score zayıflayabilir ve support maliyeti artabilir.

Bu nedenle doğru hedef “%X accuracy” rakamını izlemek değil; mismatch reason → user impact → corrective action zincirini kurmaktır.