Metasearch Nedir? Travel Metasearch Nasıl Çalışır?

Metasearch, aynı travel product için birden fazla provider'dan gelen offer'ları tek bir search context'i altında toplar, normalize eder, karşılaştırır ve kullanıcıyı booking'in tamamlanacağı kanala yönlendirir. Teknik olarak yalnız “fiyat karşılaştırma sitesi” değildir; identity, search, supply, pricing, ranking, handoff, attribution ve quality katmanlarının birlikte çalıştığı bir dağıtım ürünüdür.

Bir hotel metasearch sistemi tasarladığınızı düşünün. Kullanıcı İstanbul'da 10–13 Ekim için iki yetişkin arıyor. Aynı property; official booking engine, Booking.com, Expedia ve başka provider'larda görünür. Fakat provider'ların her biri farklı room name, rate plan, tax semantics, cancellation policy ve freshness ile data döndürür. Metasearch'in gerçek işi bu heterojen supply'ı kullanıcı açısından anlamlı hale getirmektir.

Metasearch hangi problemi çözer?

Travel supply parçalıdır. Aynı fiziksel hotel, flight itinerary veya rental car farklı ticari kanallarda farklı identifier, fiyat ve koşullarla satılabilir. Kullanıcı açısından problem yalnızca “fiyatları tek ekranda görmek” değildir; hangi offer'ların gerçekten aynı ürünü temsil ettiğini ve final booking context'inin korunup korunmadığını bilmektir.

Metasearch şu sorulara cevap üretmeye çalışır:

• Bu iki provider aynı hotel veya itinerary'yi mi satıyor?
• Fiyatlar aynı occupancy ve stay koşuluna mı ait?
• Taxes/fees karşılaştırmaya aynı şekilde dahil mi?
• Bir offer live mı, cache mi, indicative mi?
• Tıklanan link doğru date, occupancy ve product context'ini taşıyor mu?
• Click sonrası booking gerçekleşirse hangi source'a attribution yapılacak?

Bu nedenle metasearch, search UI'dan önce bir data reconciliation ve distribution problemidir.

Gerçek bir hotel search akışı nasıl görünür?

Tipik production akışı kabaca şöyledir:

Traveler Search
      |
      v
Search Context Normalization
      |
      +--> Property / Destination Resolution
      |
      +--> Cache / Indicative Layer
      |
      +--> Live Supplier Fan-out
                |
                +--> Provider A
                +--> Provider B
                +--> Provider C
      |
      v
Offer Normalization
      |
      +--> room / rate plan
      +--> occupancy
      +--> taxes & fees
      +--> currency
      +--> cancellation
      +--> availability
      |
      v
Deduplication & Ranking
      |
      v
Displayed Offer
      |
      v
Deep Link / Provider Handoff
      |
      v
Click / Booking Attribution

Bu akışta herhangi bir katman yanlış çalışırsa kullanıcıya hâlâ “bir fiyat listesi” gösterebilirsiniz; fakat ürün güvenilir metasearch olmaz.

Metasearch ve OTA arasındaki fark nedir?

OTA çoğu zaman transaction'ın daha büyük bölümünü kendi booking flow'u içinde yönetir. Metasearch ise discovery, comparison ve traffic routing katmanında yoğunlaşır. Kullanıcı offer'ı seçtikten sonra provider veya OTA landing page'ine geçer ve booking downstream sistemde tamamlanır.

Bu fark operasyonel olarak önemlidir. OTA booking state'ini daha doğrudan kontrol ederken metasearch şu alanlarda provider'a bağımlıdır:

• landing page'in çalışması,
• fiyatın click sonrasında korunması,
• availability'nin güncel olması,
• booking event'inin geri bildirimi,
• cancellation veya modification bilgisinin reconciliation'a ulaşması.

Gerçek dünyada sınırlar tamamen keskin değildir. Aynı travel grubu farklı ürünlerde OTA, affiliate ve metasearch modellerini birlikte kullanabilir.

Hotel metasearch'te “aynı ürün” ne demektir?

Hotel tarafında yalnız property eşleşmesi yeterli değildir. Aynı hotel içinde iki offer'ın comparable sayılabilmesi için en azından şu boyutlar anlaşılmalıdır:

• room type,
• occupancy,
• meal plan,
• cancellation policy,
• rate plan,
• check-in/check-out,
• length of stay,
• taxes ve mandatory fees,
• currency,
• conditional/member/mobile rate koşulları.

Örneğin “Standard Double + Breakfast + Free Cancellation” ile “Standard Double + Room Only + Non-refundable” aynı hotel ve aynı tarihte olsa bile aynı ticari ürün değildir.

Bu yüzden production data modelinde price, product identity'den bağımsız düşünülemez.

Flight metasearch neden farklı bir modele ihtiyaç duyar?

Flight tarafında canonical product property değil itinerary'dir. Itinerary bir veya daha fazla leg ve segment içerebilir. Aynı uçuş kombinasyonu farklı agent'lar tarafından farklı fare condition, baggage veya ancillary paketleriyle satılabilir.

Temel entity'ler genellikle:

• itinerary,
• leg,
• segment,
• marketing carrier,
• operating carrier,
• fare brand/class,
• baggage,
• agent/provider,
• total duration,
• stop count,
• price ve currency.

Sadece “TK123 + 5.000 TL” gibi bir model booking ve repricing için yetersizdir.

Car-rental metasearch'te karşılaştırma neye dayanır?

Araç kiralamada headline daily rate çoğu zaman total value'yu açıklamaz. Pickup/drop-off station, vehicle class, transmission, mileage, fuel policy, insurance/waiver, deposit, driver age ve mandatory fee'ler toplam sonucu değiştirir.

Bu nedenle “en ucuz araç” ranking'i, commercial condition normalize edilmeden kullanıcıyı yanıltabilir.

Metasearch data modeli nasıl katmanlanmalı?

Pratik bir model şu ayrımı korur:

Canonical Entity
  hotel / airport / route / vehicle class
        |
Provider Mapping
  provider-specific identifiers
        |
Search Context
  dates / occupancy / market / currency
        |
Offer
  room or itinerary + rate semantics
        |
Price Observation
  amount / taxes / fees / observed_at / source
        |
Handoff
  deeplink / provider / click_id
        |
Conversion Event
  booking / cancel / modify / revenue

Canonical entity ile provider identifier aynı şey değildir. Provider değişse bile internal identity yaşayabilmelidir.

Feed, API ve live query ne zaman kullanılır?

Yavaş değişen content; property master, amenity, image veya destination mapping gibi alanlar bulk feed veya scheduled sync ile taşınabilir. Price ve availability ise daha volatil olduğu için API, push update, live query veya hibrit pattern gerektirebilir.

Aynı sistemde birden fazla pattern'in bulunması normaldir:

• hotel content → günlük feed,
• room/rate definition → event/delta sync,
• price cache → push/pull,
• final click → live recheck,
• booking → webhook/event.

Doğru pattern data'nın volatility'sine ve transaction'a ne kadar yakın olduğuna göre seçilir.

Ranking yalnız fiyata göre yapılırsa ne bozulur?

Lowest-price ranking basittir ama product value'yu küçültür. Gerçek ranking sinyalleri şunları kapsayabilir:

• comparable total price,
• availability confidence,
• freshness,
• cancellation flexibility,
• provider quality,
• deeplink success,
• historical conversion,
• commercial bid,
• user/context relevance.

Commercial ranking ile user-value ranking aynı şey değildir. Sponsored veya bid-driven signal kullanılıyorsa bunun UX ve governance tarafında açık kuralları olmalıdır.

Metasearch'te en sık hangi failure mode'lar görülür?

Yanlış entity mapping

İki farklı property aynı canonical hotel'e bağlanabilir veya aynı property duplicate kalabilir. Sonuç yanlış fiyat karşılaştırmasıdır.

Stale price

Cache'teki price provider tarafında değişmiştir. Kullanıcı click sonrası daha yüksek fiyat görür.

Tax/fee mismatch

Bir provider base, diğeri total price döndürür. UI numeric olarak karşılaştırır ama semantics farklıdır.

Wrong room/rate mapping

Daha ucuz fakat farklı cancellation veya meal condition olan rate eşdeğer sanılır.

Supplier timeout

Fan-out search'te bir provider yavaşlar ve tüm response'u geciktirir.

Broken handoff

Deep link hotel/date/occupancy context'ini kaybeder ve kullanıcı generic landing'e düşer.

Attribution gap

Click var fakat booking event doğru click ID ile eşleşmez; CPA/revenue raporu bozulur.

Metasearch nasıl para kazanır?

Yaygın modeller:

• CPC: provider click için ödeme yapar.
• CPA/CPS: booking veya stayed booking gibi conversion üzerinden ödeme oluşur.
• Referral commission: booking value üzerinden pay alınabilir.
• Sponsored placement: visibility commercial signal içerir.
• Advertising: klasik media inventory kullanılabilir.
• Hybrid: birden fazla model birlikte uygulanabilir.

Commercial model teknik mimariyi değiştirir. CPC'de click integrity kritik hale gelirken CPA modelinde booking lifecycle ve cancellation reconciliation çok daha önemlidir.

Ürünün sağlıklı olduğunu hangi KPI'lar gösterir?

Tek başına traffic veya CTR yeterli değildir. Sağlıklı metasearch scorecard'ı farklı katmanları birlikte izler:

• mapped entity coverage,
• searches with at least one offer,
• live/cached offer ratio,
• price freshness,
• price accuracy,
• p95 supplier latency,
• unavailable-after-click,
• broken-deeplink rate,
• click-to-booking conversion,
• cancellation-adjusted conversion,
• unattributed booking rate,
• provider contribution margin.

Bu KPI'lar “sistem cevap veriyor mu?” sorusundan “kullanıcıya doğru ve ticari olarak sürdürülebilir sonuç üretiyor mu?” sorusuna geçiş sağlar.

Bir metasearch sistemi tasarlarken hangi sırayla ilerlenmeli?

Production'a giden pratik sıra:

1. Canonical entity ve provider mapping modelini kurun.
2. Search context contract'ını netleştirin.
3. Offer ve pricing semantics'i normalize edin.
4. Cache/live sınırlarını tanımlayın.
5. Supplier adapter'larını timeout ve error taxonomy ile izole edin.
6. Ranking için user-value ve commercial signal'ları ayırın.
7. Deep link context preservation testleri yazın.
8. Click ID ve conversion reconciliation tasarlayın.
9. Price accuracy ve supplier health dashboard'larını kurun.
10. Coverage/freshness/latency trade-off'larını gerçek traffic ile optimize edin.

Production checklist

• Canonical entity ve provider ID ayrımı var mı?
• Occupancy/date/currency search contract'ı açık mı?
• Comparable offer tanımı yazılı mı?
• Base/total/tax/fee semantics normalize mi?
• Cache age her offer'da izlenebiliyor mu?
• Provider timeout'ları tüm search'ü bloke ediyor mu?
• Deeplink doğru product context'ini koruyor mu?
• Click → booking attribution durable ID ile kurulmuş mu?
• Cancellation/modification event'leri reconciliation'a giriyor mu?
• Price mismatch için reason taxonomy var mı?
• Provider bazlı quality KPI'ları izleniyor mu?

Özet

Travel metasearch'in özü “çok sayıda fiyatı tek sayfada göstermek” değildir. Esas ürün; parçalı travel supply'ı canonical identity, comparable offer, fresh price ve güvenilir handoff altında birleştirmektir. İyi metasearch mimarisi kullanıcıya seçenek sunarken engineering ekibine de her offer'ın nereden geldiğini, ne kadar güncel olduğunu ve click sonrasında ne olduğunu açıklayabilir.