Deduplicate Business Lists Without Losing Locations
Distinguish repeated listings from separate branches and reconcile later export batches.
Two rows with the same business name are not automatically duplicates. They might represent separate branches, two practitioners in one office, or a listing whose details changed. Conversely, two rows with different names can refer to the same location after a rebrand. Deduplicating a business list requires deciding what a record represents before choosing a matching rule.
GBP Sweep merges repeated observations of listings while collecting. You may still need review when combining exported files, maintaining a company-level database, or deciding whether separate Google listings refer to the same operation. This guide explains both the extension's behavior and the decisions that remain yours.
Decide whether you count companies or locations
For a delivery route, each physical stop matters. A bakery with three storefronts can legitimately occupy three rows. For a head-office procurement project, you may want one company record linked to those three locations. These are different data structures, not competing definitions of a clean list.
Write your unit of analysis at the top of the working file: one row per listing, operating location, or parent company. If you need both company and location views, keep location records and add a parent-company group. Deleting branches to get a company count removes addresses you may need later.
Also decide how to handle departments and individual practitioners. A shopping center, a shop inside it, and an in-store service desk can share an address while representing different things. Matching only on street address would erase those distinctions.
Know how GBP Sweep identifies a saved record
The collector uses a Place ID when one is available. If it lacks that identifier, it can use a CID. With neither available, it falls back to a normalized combination of name and address. It also checks available identifier aliases when matching observations.
This helps combine a business found in several map tiles or repeated searches. Identifiers are more useful than the spelling of a name alone, but no identifier should be treated as a permanent proof of business identity. Google's Place ID documentation notes that place IDs can become obsolete and a place can have more than one ID.
The name-and-address fallback has limits. Missing address details or meaningful name changes can prevent a match. Normalization removes some formatting differences; it does not establish that two legally or operationally distinct businesses are the same.
Understand what a merge preserves
When GBP Sweep merges an incoming observation into an existing record, fresh non-empty fields can update the saved values. Empty incoming values do not erase populated details. The record retains its original collection timestamp and first source search. The fuller category list is retained when a shorter list arrives.
That behavior is useful for collecting card data first and fuller profile details later. It also means Collected at is not a timestamp for the most recent update to every field. Source search is not a complete list of all searches where the business appeared.
If your work requires an audit of each observation, keep dated raw exports and a separate batch log. The standard collection is a maintained set of business records, not a complete event history. Avoid making update-frequency claims from fields that record first collection.
Use a review order for combined CSV files
When combining exports outside the extension, compare strong identifiers first and review weaker similarities afterward. Preserve text types for Place ID and CID so your spreadsheet does not alter them before the comparison.
| Match found | Suggested treatment | What to verify |
|---|---|---|
| Same Place ID | Treat as a strong repeated-listing candidate | Check any conflicting location details |
| Same CID | Compare as a likely repeated listing | Keep the original identifier text intact |
| Same name and full address | Review as a possible duplicate | Check suite, department, and source links |
| Same domain only | Keep separate pending review | Look for real branch locations |
| Same phone only | Keep separate pending review | Check shared reception or booking numbers |
Do not run a destructive remove-duplicates command across the only copy of the file. Add a Duplicate review column, group likely matches, and retain the raw batches. You can then explain why a row was combined or kept.
Work through common false matches
A fictional company called Orchard Dental has offices on Main Street and River Road. Both use the same website and central booking number. For a location-level list, keep both. Their shared contact fields describe the company's operating setup; they do not erase the two addresses.
Now consider Juniper Bakery and Juniper Street Bakery at the same address with the same listing identifier. That is a stronger candidate for a renamed or differently displayed listing. Compare the source profile and collected fields before choosing the display name for your working record.
Finally, two practitioners may share a building, website, and reception number while maintaining separate listings. Your research question determines whether to preserve both practitioner records or group them under a practice. Document the grouping rather than presenting it as an automatic correction to the source data.
Resolve conflicting details without guessing
When two batches disagree, open the source links and check the fields that matter to the project. A more recent export is not always more complete. A missing phone in one file should not automatically replace a populated phone from another; an older populated phone should not be assumed current either.
Keep the observed values in the raw files. In the working table, record your chosen value, verification date, and reason where the difference affects a decision. For a changed address, check whether the business moved or opened an additional branch. Those cases produce different location records.
If you cannot resolve the conflict, mark it for review. An unresolved address is more honest and easier to fix than a confidently selected value with no evidence. Prioritize conflicts that could cause a wrong visit, misdirected contact, or incorrect company count.
Keep manual notes attached to the right record
Row numbers are poor identifiers because sorting and filtering move businesses around. Use a listing identifier when available, plus readable name and address fields for a human check. If identifiers change, keep a cross-reference rather than silently discarding the old notes.
Separate observed fields from your own company grouping and review status. A parent-company label is a useful addition, but it should not replace the source Name field in the raw data. A note that someone checked a phone belongs with the relevant location or shared contact record, not every row with a similar name.
The Excel guide describes a raw, review, and summary workbook structure that supports this separation without a database.
Check the result against your original purpose
After review, count what remains using the same unit you chose at the start. Report locations as locations and companies as companies. If records were excluded because identity was uncertain, keep that count visible rather than treating those businesses as confirmed duplicates.
For area sweeps, expect many repeated listing appearances across neighboring tiles. Judge the result by distinct useful businesses, not the largest counter during collection. The area sweep guide explains how to review coverage alongside duplicate counts. A clean list preserves real differences while removing repeated observations of the same record.