`place_id` is the same identifier the official Places API uses

Two identifier columns, both from Google, doing two different jobs. Getting them the right way round saves a category of problem that is otherwise very hard to notice.

Two identifiers, two jobs

Both were present on 100% of rows in every market measured.

Deduplication across runs

Deduplication on feature_id works within a run and between runs. That is what makes country-scale sweeps practical: batches can overlap at their edges, a batch can be re-run after a timeout, and neither produces duplicate rows or duplicate charges — re-running a finished census cost 8 requests instead of 180.

Joining to Places API data

If you already hold Google data — from the Places API, from a previous product, from a vendor who used it — place_id joins the two sets directly. No name normalisation, no address parsing, no distance threshold.

Why not match on name and address

Because local business records vary in every dimension that a match would rely on: punctuation, accents, suite and floor numbers, abbreviations, transliteration, and the shop that renamed itself last year. Matching on those produces both false merges and false splits, and neither announces itself — you get a business with two records or two businesses with one, and the row count still looks plausible.

Place names here are kept exactly as Google publishes them, accents and alphabet included — Mérida is not Merida — which is another reason not to build a key out of them.