Price Observation
A price observed for a specific query context and timestamp, stored with amount, currency, source, observedAt and freshness metadata.
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?
Price Observation commonly appears across identity layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Price Observation & Event Model
Model travel pricing as timestamped observations and change events instead of only overwriting mutable current-price state.
Explore →How to Debug Hotel Price Mismatches
Diagnose price differences between metasearch, OTA and hotel booking engines with an evidence-driven triage and root-cause workflow.
Explore →Stale Price & Delayed Feed Troubleshooting
Diagnose stale hotel offers and delayed feeds using freshness timestamps, ingestion lag, cache state and invalidation evidence.
Explore →Agentic Travel Reference Architecture
Design AI agent → search → offer → reprice → confirmation → payment → booking → servicing with travel-specific authorization, idempotency and audit boundaries.
Explore →NDC Offer/Order Lifecycle: Search to Servicing
Model NDC Offer/Order lifecycle across search, offer, revalidation, order creation, payment, ticketing, servicing and reconciliation states.
Explore →Stale Availability / Offer Expired Troubleshooting
Diagnose stale availability and expired offers across freshness, cache, token and revalidation layers between search and booking.
Explore →