Before you can compare a hotel's price on two OTAs, you have to be sure both rows are the same hotel. Name-and-city matching gets this wrong often enough to matter, and it fails silently: the wrong hotel still returns a perfectly plausible price.
Published 18 September 2026
Every OTA stores its own copy of a property's name, address and coordinates, typed in by a different person under different rules. The strings drift apart in predictable ways:
| Approach | How it works | Where it breaks |
|---|---|---|
| Fuzzy name + city | String similarity on name, sometimes address | Branches of one chain, transliteration, rebrands. Needs a threshold nobody can tune well for every market. |
| Name + coordinates | Similarity plus a distance cutoff | Better, but OTAs disagree on pins, and dense city centres put different hotels within the same radius. |
| Supplier mapping data | Buy a pre-built cross-reference between supplier IDs | Good if you already buy it. It maps supplier codes, not what a scraper sees on a public page. |
| A shared external key | Resolve every property once to one identifier, then key everything on it | You have to resolve and maintain the key. That is the whole job, and it is a small one. |
A Place ID is Google's unique identifier for a place in its Places database and on Google Maps. It is a practical key for hotels because Google Hotels already groups the OTA offers for a property under that property, so resolving a hotel to its Place ID does the cross-OTA matching step for you.
Three details from Google's own documentation decide how you store it:
NOT_FOUND; a truncated or altered one returns INVALID_REQUEST. Google's suggested fallback is to keep the original search that produced each ID and re-run it.place_id, the original search string, and the date you resolved it. The query is your recovery path if the ID ever goes stale.place_id.NOT_FOUND as a review task, never as a silent re-match.Full disclosure: this is our product. The Google Hotels API accepts a Place ID directly. In that mode the lookup is deterministic, so a request cannot return a different hotel than the one you asked for. Each hotel comes back with 12 to 25 OTAs, including Booking.com, Agoda, MakeMyTrip, Expedia, Hotels.com and Goibibo. Place ID jobs typically finish in 3–5 seconds, name-search jobs in 4–8, and you can batch up to 20 hotels that share the same dates in one request. Details are in the FAQ and the API docs.
No. Google states that Place IDs may change as its Maps database is updated, and recommends refreshing stored IDs that are more than 12 months old. The refresh request is free.
Yes. Google's documentation says Place IDs are exempt from the caching restrictions in the Google Maps Platform Terms of Service, so they can be stored for later use.
Treat it as a review task. Re-run the original search that produced the ID, confirm the result is the same property, and only then store the new ID. Never let the pipeline re-match silently.
Mostly. You still need a one-time resolution step for each new property, and ambiguous cases such as two branches of one chain deserve a human check. After that, every join runs on the ID.