Live Prices vs Indicative Prices: Fark Nedir?

Travel search ürünleri her ekranda aynı freshness seviyesinde veriye ihtiyaç duymaz.

Bu nedenle live price ve indicative price ayrımı özellikle flight ve car-rental metasearch'te önemlidir.

Live price nedir?

Live price, belirli bir kullanıcı search context'i için mümkün olduğunca güncel ve bookable teklif üretmeye odaklanır. Live price, belirli tarih, occupancy ve ürün koşulları için kullanıcı araması sırasında veya çok yakın zamanda doğrulanan bookable fiyattır. Bu nedenle freshness ve latency doğrudan kullanıcı güvenini etkiler.

Tipik input:

• exact dates,
• route/location,
• passengers/occupancy,
• market,
• currency.

Live search daha pahalı ve daha yavaş olabilir; çünkü upstream supplier sistemlerine gerçek sorgu çalıştırır.

Indicative price nedir?

Indicative price, kesin booking teklifi olma garantisi vermeyen ama kullanıcıya fiyat seviyesi hakkında güçlü sinyal sağlayan veridir. Indicative price, keşif ve yönlendirme için kullanılan yaklaşık veya önceden hesaplanmış fiyat sinyalidir. Kullanıcının gerçek booking koşullarındaki kesin fiyatı temsil etmek zorunda değildir ve final doğrulama gerektirir.

Kullanım alanları:

• cheapest month,
• everywhere discovery,
• destination inspiration,
• route heatmap,
• early-stage filtering,
• market trend.

Neden ikisini ayırmak gerekir?

Bir kullanıcı "İstanbul'dan Ekim'de ucuz nereye gidebilirim?" diye soruyorsa yüzlerce destinasyon için live search yapmak pahalıdır. Önce indicative dataset kullanılabilir. Kullanıcı Antalya'yı seçtiğinde exact dates için live search başlatılır.

Bu iki aşamalı mimari latency ve API cost'u azaltır.

Freshness

Indicative data daha uzun TTL ile tutulabilir. Live data daha kısa yaşam süresine sahiptir. Ancak "live" etiketi de sonsuz garanti değildir; booking provider tarafında inventory click sonrasında değişebilir.

UI'da nasıl anlatılmalı?

Indicative fiyatı "from" veya "estimated" gibi qualifier ile göstermek daha şeffaftır. UI, indicative fiyatı kesin bookable fiyat gibi göstermemelidir. Yaklaşık fiyat, başlangıç fiyatı veya son görülen fiyat gibi açık bir ifade kullanmak kullanıcı beklentisini ve post-click güvenini korur.

Kesin bookable teklif izlenimi yaratmamak gerekir.

Cache stratejisi

Cache policy use case'e göre değişebilir:

Sonuç

Live ve indicative data birbirinin alternatifi değildir. İyi travel-search ürünleri discovery için indicative, yüksek booking intent için live data kullanarak maliyet, hız ve doğruluk arasında denge kurar.

Product boundary nasıl çizilmeli?

Live ve indicative pricing'i yalnız iki API endpoint olarak düşünmek yerine iki farklı SLA sınıfı olarak modellemek daha doğrudur. Indicative dataset geniş coverage, düşük request cost, yüksek cacheability ve daha gevşek freshness hedefler.

Live pricing ise daralmış exact context, yüksek freshness, provider availability doğrulaması ve booking'e uygun handoff bekler.

Repricing trigger'ı

Kullanıcı discovery ekranından booking intent'e geçtiğinde explicit repricing boundary olmalıdır.

Örneğin:

1. month-view indicative fiyat göster,
2. kullanıcı route/date seçsin,
3. live search başlat,
4. mature result bekle,
5. provider offer'larını sırala,
6. click öncesi gerekirse son validation yap.

Bu sınır UI'da da hissedilmelidir; kullanıcı indicative rakamı guaranteed fare sanmamalıdır.

Cache key tasarımı

Price cache key yalnız route/hotel ID'den oluşmamalıdır. Ürüne göre şu boyutlar sonucu değiştirebilir:

• market,
• currency,
• locale,
• passengers/occupancy,
• cabin/room,
• stay length,
• device veya channel eligibility.

Eksik key dimension yanlış fiyat paylaşımına yol açabilir.

Stale data stratejisi

Upstream live source unavailable olduğunda stale result göstermek bazı discovery use case'lerinde kabul edilebilir, booking-intent ekranda ise risklidir. Bu yüzden cache entry yalnız value değil generated_at, source, freshness class, expires_at ve last validation result gibi metadata da taşımalıdır.

Teknik KPI'lar

Live/indicative ayrımını şu metriklerle yönetin:

• time to first result,
• mature result time,
• cache hit ratio,
• live repricing success,
• stale-result rate,
• price mismatch,
• upstream request/search,
• cost per successful live search.

Failure mode

Indicative fiyatın live repricing sonrası ciddi yükselmesi kullanıcı güvenini bozar. Bunu tamamen engellemek mümkün olmayabilir; ancak indicative age, volatility ve historical delta kullanılarak “from” fiyatın ne kadar güvenilir olduğu ölçülebilir.

MetaSearch 101 yorumu

Live ve indicative price arasında seçim teknik optimizasyon değildir; user intent'e göre farklı doğruluk ve maliyet sözleşmeleri tanımlamaktır.

Funnel bazlı price policy tanımlayın

Indicative ve live price'ı content type olarak değil user-intent seviyesine göre seçmek daha sağlıklıdır:

Bu policy product ve engineering arasında ortak contract olmalıdır.

Internal data model

price_mode
observed_at
valid_until
source_provider
query_context
confidence
is_bookable_signal
last_live_check_at

UI yalnız amount göstermemeli; gerektiğinde "estimated/from" gibi semantics'i doğru yansıtmalıdır.

Failure mode'lar

• indicative price'ın bookable gibi etiketlenmesi,
• old minimum fare'ın current offer sanılması,
• live timeout sonrası fallback'in görünmez olması,
• cache'deki currency'nin current request'ten farklı olması,
• ranking'in low indicative price nedeniyle bozulması.

KPI'lar

• indicative→live conversion,
• live validation success,
• reprice delta,
• fallback rate,
• user abandonment after reprice,
• coverage gain from indicative data,
• conversion by price mode.

Doğru soru “live daha iyi mi?” değil; hangi funnel noktasında hangi doğruluk/latency dengesi gerekli? sorusudur.