Google Places as Supplemental Hotel Context

Google Places can enrich a hotel entity with address, location, business status, ratings/reviews and nearby context. It should not become the source of truth for hotel inventory, room/rate identity or bookable offers.

Canonical mapping

CanonicalProperty
  -> internal property ID
  -> supplier/OTA IDs
  -> Google Place ID (supplemental)

Place ID is a useful external identity, but it should remain one mapping dimension.

Good use cases

• address/location validation,
• map display,
• nearby POI context,
• business-status signal,
• supplemental ratings/reviews,
• moved-place detection.

Bad use cases

Do not infer:

• current room inventory,
• current hotel price,
• rate-plan identity,
• cancellation policy,
• booking availability

from Places data.

Cost and field masks

Places API requires explicit field masks. Request only fields needed by the product so billing and payload size remain controlled.

Freshness

Location/name/business-status changes are slower than rates. Model separate refresh schedules from hotel price crawlers or supplier APIs.

Mapping failure modes

• two properties sharing similar names,
• moved/renamed properties,
• hotel vs restaurant/spa Place confusion,
• duplicate Place IDs attached to one canonical property,
• treating reviews as contractual hotel data.