GDS, OTA ve Metasearch Arasındaki Fark

GDS, OTA ve metasearch aynı travel ecosystem içinde yer alır ama farklı katmanlarda değer üretir.

Kavramları aynı "travel site" kategorisine koymak mimariyi anlamayı zorlaştırır.

GDS nedir?

GDS, Global Distribution System ifadesinin kısaltmasıdır. Tarihsel olarak airline inventory ve travel agency distribution arasında merkezi bir teknoloji katmanı sağlar. Amadeus, Sabre ve Travelport bu alanın bilinen oyuncularıdır.

GDS bir consumer metasearch sitesi değildir.

OTA nedir?

OTA, Online Travel Agency'dir. OTA, seyahat ürünlerini kullanıcıya sunan ve çoğu durumda rezervasyon işleminin önemli bölümünü kendi deneyimi içinde yöneten online satış ve dağıtım aracısıdır.

Kullanıcıya inventory sunar ve booking transaction'ın önemli bölümünü kendi platformunda yönetebilir.

Booking.com, Expedia veya Agoda örnek verilebilir.

Metasearch nedir?

Metasearch farklı booking source'ları karşılaştırır ve kullanıcıyı seçilen provider'a yönlendirir. Metasearch, birden fazla sağlayıcıdaki teklifleri aynı arama context'i içinde karşılaştıran, normalize eden ve kullanıcıyı seçilen satış kanalına yönlendiren discovery ve traffic-routing katmanıdır.

Google Flights, Skyscanner, KAYAK veya trivago bu modele örnektir.

Basit zincir

Bir flight senaryosunda dağıtım kabaca şu kombinasyonlardan birine benzeyebilir: Airline → GDS/NDC/Aggregator → OTA → Metasearch → User Ancak her booking aynı zinciri kullanmaz. Direct airline API veya NDC ile bazı katmanlar atlanabilir.

Kim transaction'ı sahiplenir?

• GDS: distribution infrastructure,
• OTA: seller/intermediary,
• metasearch: comparison and traffic routing.

Bu ownership farkı integration contract ve revenue modelini belirler.

Neden önemli?

Bir travel-tech sistemi tasarlarken "provider" kavramını tek type olarak tutmak yetersiz olabilir. GDS, OTA ve metasearch aynı rolü üstlenmez; bu ayrım inventory ownership, pricing, booking transaction, attribution ve entegrasyon mimarisinin hangi sistemde yönetileceğini doğrudan etkiler.

Entity role alanı şu değerleri ayırabilir:

• airline,
• hotel,
• wholesaler,
• GDS,
• OTA,
• metasearch,
• booking engine.

Bu ayrım lineage ve economics analizini kolaylaştırır.

Sonuç

GDS inventory distribution altyapısıdır, OTA transaction intermediary'dir, metasearch comparison layer'dır.

Gerçek travel distribution mimarisi bunların farklı kombinasyonlarını kullanabilir.

Aynı zincirdeki veri ownership'i

Gerçek sistem tasarımında en kritik soru “hangi platformdan veri geliyor?” değil, hangi katman hangi state'in sahibi? sorusudur.

Örneğin flight tarafında:

• airline: schedule, seat/inventory ve fare kaynağı,
• GDS/NDC aggregator: distribution contract ve normalized access,
• OTA: shopping, markup/commission, checkout ve booking ownership,
• metasearch: comparison, ranking, provider handoff ve acquisition measurement.

Bu sınırlar net değilse aynı fiyatın birden fazla sistemde farklı business rule ile değiştirilmesi kaçınılmaz olur.

Economics nasıl değişir?

GDS transaction/segment fee gibi dağıtım ekonomilerine; OTA markup/commission ve payment economics'e; metasearch ise CPC/CPA/referral economics'e yakın çalışabilir. Bu nedenle “en ucuz supplier” ile “en kârlı channel” aynı karar değildir.

Bir OTA kendi internal cost modelinde en azından şunları ayırmalıdır:

• supplier/net cost,
• GDS/aggregator cost,
• payment cost,
• acquisition cost,
• cancellation/refund cost,
• gross margin.

PNR/booking ownership neden önemli?

Flight tarafında booking oluşturulduktan sonra ticketing, servicing, exchange/refund ve disruption operasyonu kimin sisteminde kalıyor sorusu consumer UX'i doğrudan etkiler. Metasearch çoğu zaman transaction'ı downstream provider'a bırakır. OTA ise support sorumluluğunu daha fazla üstlenebilir.

Bu fark kullanıcıya “kimden satın alıyorum?” bilgisinin açık gösterilmesini gerektirir.

Architecture açısından anti-pattern

Tek bir provider tablosuna airline, GDS, OTA ve metasearch'i aynı role ile koymak ileride şu sorunları yaratır:

• yanlış revenue attribution,
• lineage kaybı,
• duplicate inventory,
• yanlış support ownership,
• channel-level SLA ölçememe.

Daha sağlıklı modelde entity ile role ayrılır; aynı şirket farklı context'lerde supplier, seller veya traffic source rolü taşıyabilir.

Ölçülmesi gereken KPI'lar

MetaSearch 101 yorumu

GDS, OTA ve metasearch'i ürün isimleriyle değil inventory ownership → transaction ownership → traffic ownership ekseninde ayırmak, travel distribution mimarisini çok daha doğru açıklayan modeldir.

Sistemde source-of-truth sınırlarını ayırın

GDS, OTA ve metasearch aynı funnel'da görünse de aynı sorumluluğu taşımaz.

Supplier / CRS / PMS
        |
        v
GDS / Connectivity / Wholesaler
        |
        v
OTA / Direct Booking / Distribution Channels
        |
        v
Metasearch / Discovery
        |
        v
Traveler

Gerçek topology provider'a göre değişebilir; önemli olan entity, price, availability ve booking state için hangi sistemin authoritative olduğunun bilinmesidir.

Data contract neden katmana göre değişir?

• GDS/distribution: availability, fare/rate, reservation capability.
• OTA: merchandised offer + transaction.
• Metasearch: comparable offer + handoff.
• Booking engine: final booking context + payment/confirmation.

Aynı "price" alanı bu katmanlarda farklı semantics taşıyabilir.

Failure mode'lar

• metasearch OTA'yı supplier sanıp duplicate inventory üretir,
• GDS fare ile NDC offer equivalence yanlış kurulur,
• booking state metasearch'e geç ulaşır,
• hotel content bir channel'da güncel diğerinde stale kalır,
• source ID canonical entity yerine kullanılır.

Mimari karar soruları

• Inventory truth nerede?
• Price kim tarafından hesaplanıyor?
• Booking'i kim owns ediyor?
• Cancellation event'i hangi sistem publish ediyor?
• Canonical identity hangi layer'da yönetiliyor?
• Commercial attribution hangi hop'ta başlıyor?

Rolleri isimlerden değil state ownership üzerinden ayırın.