Metasearch vs Booking Engine: Fark Nedir?

Metasearch ve booking engine aynı booking funnel içinde yan yana çalışabildiği için sık karıştırılır. Oysa biri discovery/comparison, diğeri transaction katmanıdır.

Örnek akış:

Google Hotels → Hotel Booking Engine → Payment / Confirmation

Burada Google Hotels metasearch, otelin kendi rezervasyon ekranı ise booking engine'dir.

Booking engine ne yapar?

Bir hotel booking engine genellikle şu işleri yapar:

• tarih ve occupancy seçimi,
• room/rate listeleme,
• package/promotions,
• guest information,
• payment,
• booking confirmation,
• cancellation/modification.

Yani rezervasyonun gerçek transaction state'i booking engine üzerinde oluşur.

Metasearch ne yapar?

Metasearch kullanıcının birden fazla booking source üzerindeki teklifleri karşılaştırmasına yardımcı olur. Kullanıcı otelin official site teklifini seçerse metasearch, onu booking engine'e gönderebilir. Bu geçiş deeplink ile yapılır.

İki sistem hangi veriyi paylaşır?

İyi bir handoff için en azından şu context önemli olabilir:

• hotel ID,
• check-in,
• check-out,
• adults/children,
• rooms,
• currency,
• locale,
• campaign/click ID.

Metasearch'te gösterilen rate ile booking engine üzerinde açılan rate arasındaki tutarlılık conversion açısından kritiktir.

Booking engine ana sayfasına link vermek neden zayıf?

Kullanıcı metasearch üzerinde belirli tarihler ve occupancy için fiyat gördüyse tıklama sonrasında aynı bilgileri yeniden girmek istemez. Generic homepage yönlendirmesi sürtünmeyi artırabilir, conversion düşürebilir, attribution kaybettirebilir ve price mismatch algısı yaratabilir.

Bu yüzden parametreli deep link önemli bir entegrasyon bileşenidir.

Direct booking stratejisindeki rol

Metasearch otelin direct rate'ini OTA teklifleri yanında görünür hale getirebilir. Booking engine ise bu trafiği rezervasyona dönüştüren katmandır. Dolayısıyla direct-booking performansı için iki ayrı conversion ölçülmelidir:

1. metasearch impression → click,
2. booking engine landing → booking.

Tek toplam conversion rate, sorunun hangi katmanda olduğunu anlamayı zorlaştırabilir.

Teknik sorumluluk ayrımı

Metasearch

• discovery,
• comparison,
• ranking,
• click/handoff,
• traffic attribution.

Booking engine

• real availability,
• final price,
• guest details,
• payment,
• booking state.

Sistem tasarımında bu boundary açık tutulursa hata analizi ve ownership çok daha kolay olur.

Özet

Metasearch rezervasyon motoru değildir. Booking engine de fiyat karşılaştırma motoru değildir. En güçlü direct-booking deneyimi, metasearch'in doğru kullanıcıyı doğru context ile booking engine'e taşıdığı durumda oluşur.

State ownership farkı

Metasearch search state ile booking engine transaction state'i aynı değildir. Metasearch; compare edilecek offer set'i, ranking, provider options ve click attribution ile ilgilenir.

Booking engine ise availability lock/validation, guest details, payment, confirmation ve modification/cancellation state'inin sahibidir.

Bu ayrım integration boundary'yi belirler.

Revalidation neden gerekir?

Metasearch'te görülen offer click anına kadar değişebilir. Booking engine'e geçişte inventory ve price yeniden doğrulanmalıdır. Revalidation sonucunda aynı offer, yeni price, sold out veya alternative room/fare state'lerinden biri oluşabilir.

UI bu değişimi açık anlatmalıdır.

Booking engine conversion metasearch KPI'ıdır

Transaction downstream'da gerçekleşse bile metasearch provider quality değerlendirmesinde booking-engine performance'ı hesaba katmalıdır.

Örnek sinyaller:

• landing speed,
• checkout completion,
• price mismatch,
• mobile conversion,
• payment error,
• cancellation clarity.

Yüksek click alan ama kötü booking engine'e sahip provider toplam kullanıcı değerini düşürebilir.

Direct hotel use case

Hotel direct booking engine metasearch'te provider'lardan biri olabilir. Bu durumda direct channel için room/rate mapping, deeplink parametreleri, attribution ve booking callback aynı disiplinle tasarlanmalıdır.

Meta Search 101 yorumu

Metasearch ve booking engine rakip sistemler değildir. Biri shopping/comparison state, diğeri transaction state sahibidir; ürün kalitesi iki state arasındaki handoff kadar güçlüdür.

Handoff boundary'yi teknik contract olarak tanımlayın

Metasearch ile booking engine arasındaki boundary şu context'i korumalıdır:

property/product
dates
occupancy
rate plan
currency
locale
price expectation
click/campaign identity

Booking engine bu context'i yeniden yorumladığında user başka product'a düşmemelidir.

Booking ownership neyi değiştirir?

Metasearch booking'i own etmiyorsa:

• payment state downstream'dedir,
• booking confirmation provider'dadır,
• cancellation event geri beslenmelidir,
• price validation provider'a bağlıdır.

Booking engine'i siz de işletiyorsanız PCI/PII, idempotency, payment retry ve reservation state gibi ek sorumluluklar oluşur.

Failure mode'lar

• generic property page'e düşen handoff,
• selected rate kaybolur,
• currency değişir,
• booking engine occupancy'yi yeniden default eder,
• metasearch price ile checkout total farklı semantics kullanır,
• conversion callback gelmez.

KPI'lar

• handoff context preservation,
• landing-to-booking conversion,
• price-check delta,
• booking confirmation lag,
• unmatched booking,
• booking-engine error rate.

Metasearch ve booking engine'i UI farkı üzerinden değil transaction ownership sınırı üzerinden ayırın.