Offer Fingerprint
Bir offer'ın property/itinerary, occupancy, room/fare, meal, cancellation, eligibility ve currency semantics'ini stable biçimde temsil eden karşılaştırma anahtarıdır.
Neden önemli?
Travel verisinde aynı fiziksel entity farklı supplier'larda farklı ID, isim ve metadata ile temsil edilir. Identity katmanı yanlışsa fiyat ve availability doğru olsa bile yanlış property veya product altında gösterilebilir. Canonical ID, source ID ve mapping confidence birlikte düşünülmelidir.
Pratikte nasıl görünür?
Expedia'daki property ID ile Booking.com'daki property ID aynı fiziksel hotel'i temsil edebilir. Internal canonical property bu iki source ID'yi evidence ve confidence ile eşleştirir.
Uygulamada sorulması gerekenler
- Canonical entity nasıl tanımlanıyor?
- Source-specific ID'ler saklanıyor mu?
- Mapping hangi sinyallere dayanıyor?
- Ambiguous match için manual review var mı?
Yaygın hatalar
- Sadece isim benzerliğiyle mapping yapmak
- Manual override'ı batch job ile ezmek
- Rebrand sonrası duplicate entity yaratmak
Travel stack içinde nerede kullanılır?
Offer Fingerprint, çoğunlukla identity katmanlarıyla ilişkilidir. İlgili sistemlerde source-of-truth, identity, freshness ve transaction ownership sınırlarını açık tanımlamak gerekir.
İlgili terimler
İlgili teknik içerikler
Offer Identity ve Offer Fingerprint Tasarımı
Travel offer'larını provider, room/rate, policy, price ve context boyutlarıyla deterministik biçimde tanımlayan offer fingerprint modelini tasarlayın.
İncele →Package Holiday vs Hotel Metasearch: Mimari Farklar
Paket tatil dağıtımı ile hotel metasearch modelini offer identity, pricing, supplier topology, booking ownership ve cancellation açısından karşılaştırın.
İncele →Agentic Travel Reference Architecture
AI agent → search → offer → reprice → confirmation → payment → booking → servicing akışını travel-specific authorization, idempotency ve audit sınırlarıyla tasarlayın.
İncele →Canonical Offer, Order ve Booking State Model
Travel sistemlerinde Offer, Order ve Booking kavramlarını ayıran canonical state modelini ve booking state machine tasarımını kurun.
İncele →NDC Offer/Order Lifecycle: Search'ten Servicing'e
NDC Offer/Order lifecycle'ını search, offer, revalidation, order create, payment, ticketing, servicing ve reconciliation state'leriyle modelleyin.
İncele →Stale Availability / Offer Expired Troubleshooting
Search sonucu ile reprice/booking anı arasında availability veya offer expire olduğunda freshness, cache, token ve revalidation katmanlarını teşhis edin.
İncele →