Offer Fingerprint
A stable comparison identity representing offer semantics such as property/itinerary, occupancy, room/fare, meal, cancellation, eligibility and currency.
Why it matters
The same physical travel entity can appear with different IDs, names and metadata across suppliers. If identity resolution is wrong, correct price and availability data can still be attached to the wrong property or product. Canonical identity, source identifiers and mapping confidence need to be designed together.
What does it look like in practice?
An Expedia property ID and a Booking.com property ID can represent the same physical hotel. Internal canonical identity should connect them using evidence and confidence.
Implementation questions
- How is the canonical entity defined?
- Are source-specific IDs retained?
- Which signals drive matching?
- Is there a manual-review path for ambiguous matches?
Common mistakes
- Mapping from name similarity alone
- Overwriting manual overrides
- Creating duplicates after rebrands
Where does it appear in the travel stack?
Offer Fingerprint commonly appears across identity layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Offer Identity & Offer Fingerprint Design
Design deterministic travel-offer fingerprints across provider, room/rate, policy and search-context dimensions without coupling identity to price.
Explore →Package Holiday vs Hotel Metasearch: Architecture Differences
Compare package-holiday distribution with hotel metasearch by offer identity, pricing, supplier topology, booking ownership and cancellation.
Explore →Tripadvisor Hotels: Content, Offer Identity and Booking Boundaries
Separate Tripadvisor hotel content, Terra access and rate distribution; diagnose property mapping, offer mismatches and booking-handoff failures.
Explore →KAYAK Cars: Rental Offer Equivalence and Booking Operations
Compare KAYAK Cars offers by total cost, station, vehicle policy and seller identity, with practical mismatch diagnosis and operational metrics.
Explore →Agentic Travel Reference Architecture
Design AI agent → search → offer → reprice → confirmation → payment → booking → servicing with travel-specific authorization, idempotency and audit boundaries.
Explore →Canonical Offer, Order and Booking State Model
Design canonical Offer, Order and Booking lifecycle boundaries with an explicit booking state machine for travel integrations.
Explore →