Hotel Metasearch için Room ve Rate Normalization
Room type, rate plan, occupancy, meal, cancellation ve package metadata'yı normalize ederek hotel offer'larını anlamlı farkları kaybetmeden nasıl karşılaştıracağınızı öğrenin.
Room-rate normalization, iki hotel offer'ının gerçekten karşılaştırılabilir olup olmadığını belirler. Sadece property ID ve numeric price eşleştirmek yeterli değildir; room category, occupancy, cancellation, meal, package benefit ve pricing basis offer değerini değiştirir.
Price'tan önce product identity'yi normalize edin
Metasearch önce offer'ın neyi temsil ettiğini anlamalı, sonra fiyatı karşılaştırmalıdır. “Deluxe Sea View + Breakfast” ile “Standard Room Only” hiçbir ayrım olmadan aynı listede yalnız fiyatla sıralanırsa en ucuz sonuç equivalent offer olmayabilir.
Comparison key hotel ID dışında anlamlı product attribute'larını içermelidir.
Room name güvenilir identifier değildir
Aynı oda supplier'larda “Deluxe Double”, “Deluxe King”, “Sea View Deluxe” veya lokalize başka isimle gelebilir. Exact-string matching bu nedenle hızla bozulur.
Katmanlı yaklaşım kullanın:
- supplier room ID,
- normalized room class,
- bed configuration,
- view/features,
- capacity,
- structured amenities,
- yardımcı sinyal olarak textual similarity.
Free text tek identity sinyali olmamalıdır.
Rate plan ayrı normalize edilmeli
Aynı room farklı rate plan'larla satılabilir. Önemli normalized dimension'lar:
- refundable/non-refundable,
- cancellation deadline,
- breakfast/meal inclusion,
- pay-now/pay-later,
- member/mobile rate,
- package benefits,
- occupancy,
- stay restrictions.
Materially farklı koşulları olan iki offer “equivalent” olarak işaretlenmemelidir.
Supplier ID'lerini koruyun
Normalization internal canonical ID üretirken original supplier hotel, room ve rate-plan identifier'larını da tutmalıdır. Source ID'ler debugging, deeplink creation ve booking handoff için gereklidir.
Canonicalization destructive replacement değil overlay olmalıdır.
Confidence score kullanın
Room mapping çoğu zaman probabilistic'tir. Her match exact'miş gibi davranmak yerine mapping confidence ve evidence saklayın.
Pratik sınıflar:
- exact/verified,
- high-confidence automatic,
- ambiguous/manual review,
- rejected.
Bu yapı belirsiz mapping'in price comparison'a sessizce zarar vermesini önler.
Content değişince mapping'i yeniden değerlendirin
Renovation, rebrand veya commercial restructuring sonrası room configuration değişebilir. Google room ve package metadata'nın farklı sıklıklarda değiştiğini belirtir; mapping süreci de revalidation desteklemelidir.
Source update timestamp tutup kritik özellik değişikliklerinde mapping'i tekrar çalıştırın.
Meta Search yorumu
Room-rate normalization raw supplier data ile güvenilir comparison arasındaki köprüdür. Canonical ID, structured attribute, rate semantics ve confidence score; kullanıcı için önemli ticari farkları silmeden equivalent offer'ları karşılaştırmayı sağlar.
Comparable offer contract'ını açık tanımlayın
Room-rate normalization sonunda sistem şu soruyu cevaplayabilmelidir:
Bu iki offer kullanıcı açısından gerçekten aynı product mı?
Örnek normalized key:
property
+ canonical_room_class
+ bed_configuration
+ occupancy
+ meal
+ refundable_bucket
+ cancellation_deadline
+ pay_timing
+ eligibilityPrice ancak bu key yeterince eşleştiğinde karşılaştırılmalıdır.
Room mapping ile rate normalization'ı ayırın
Room identity fiziksel/commercial room'u, rate plan ise satış koşulunu temsil eder. Aynı room için onlarca rate olabilir.
Provider Room -> Canonical Room
Provider Rate -> Normalized Commercial Conditions
|
-> Offer FingerprintFailure mode'lar
- breakfast rate room-only ile eşleştirilir,
- free cancellation deadline farklıdır,
- mobile/member rate public sanılır,
- child occupancy farklıdır,
- suite ve standard room text similarity yüzünden map edilir,
- supplier room rename mapping'i bozar.
KPI'lar
- exact comparable offer rate,
- ambiguous room-map rate,
- rate-semantic mismatch,
- manual review volume,
- price anomalies by mapping confidence,
- mapping change rate.
Normalization'ın amacı supplier farklarını silmek değil, hangi farkların kullanıcı açısından anlamlı olduğunu koruyarak comparison üretmektir.
Benzer bir entegrasyon mu planlıyorsunuz?
Gereksinim, feed/API tasarımı ve production yaklaşımını birlikte değerlendirebiliriz.