What is a Google place ID (and CID), and why keep it?
Updated July 22, 2026 · 4 min read
Every business list eventually faces the same problem: is “Joe's Plumbing”, “Joe's Plumbing LLC” and “Joes Plumbing & Heating” one business or three? Names change, addresses get formatted six ways, phone numbers get reassigned. You need a key.
Google provides two, and a lead list that discards them is a lead list you can't reconcile later.
Place ID and CID, briefly
A place ID is the identifier Google uses for a place across its APIs — a longish opaque string. It identifies one listing and is the value you'd use to look that listing up again.
A CID is an older numeric identifier for the same underlying entity, the one that appears in certain Google Maps URL forms. Both point at the same business; they're two representations rather than two different things.
Neither is guaranteed permanent forever. Listings get merged, split, or recreated, and an ID can change when that happens. Treat them as far more stable than a name, not as immortal.
Why they belong in your export
- 1
Deduplication that actually works
Adjacent zip-code searches return overlapping results. Matching on place ID collapses them exactly; matching on name and address collapses them approximately, which means wrongly.
- 2
Merging refreshes without creating duplicates
When you re-scrape a territory in six months, the ID is what tells you “this is the same business, its rating changed” rather than “here is a new business with a suspiciously similar name”. The list-refresh guide leans on this entirely.
- 3
Linking a CRM record back to the live listing
A rep looking at an account should be one click from the current Maps profile, with today's reviews and hours, not last quarter's snapshot.
- 4
Auditing where a row came from
When a client asks where a lead came from, an ID that resolves to a real public listing is a much better answer than “our database”.
Why name-and-address matching fails
Because business names are written inconsistently by the businesses themselves, suffixes come and go, addresses vary in abbreviation and unit-number placement, and multi-location businesses legitimately share names. Fuzzy matching gets you most of the way and then produces a handful of wrong merges, which are much harder to detect than duplicates.
Phone numbers are a decent secondary key and a poor primary one: a family of businesses can share a line, and numbers get reassigned when a business closes.
Practical handling
Keep both IDs as text columns — a CID read as a number will lose precision and quietly corrupt. Set the column type on import; the CSV-versus-XLSX guide covers how. Then make the place ID the primary key of your account records, and never let a downstream tool drop it because “nobody looks at that column”.
Hubertino's export includes both place ID and CID among its 38 columns for exactly this reason, and the same values come back through the REST API.
Common questions
Can a business have more than one place ID?
It can end up with more than one listing — duplicates happen, especially after rebrands or moves — and each listing has its own ID. Genuine duplicates on Google's side are rarer than name-matching errors on yours.
Do I need an API key to use a place ID?
To query Google's Places API, yes. To use it as a join key in your own data, no — it's just a string, and that's the main reason to keep it.