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?

Property Mapping commonly appears across identity layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.

Related terms

Related technical guides