Multi-location account planning starts with a deceptively simple question: which listings belong together? A shared name can join unrelated businesses, while a shared booking platform can join unrelated brands. A useful first pass preserves locations and records a bounded relationship hypothesis that a researcher can verify.
Google Maps Chain Location Grouper reads places from an existing export. It combines an exact eligible hostname with a compatible normalized brand to identify batch-local groups. The output keeps one location assessment per usable place, so grouping does not erase the addresses or identities needed for follow-up research.
Use a source row with an explicit website
This input is a shortened projection from the installed public September snapshot. A single location demonstrates a valid assessment path. A real group requires compatible evidence from multiple distinct locations in the batch; this isolated example makes no claim that the institution belongs to a chain.
{
"items": [
{
"placeId": "ChIJPy8Y5kIFdkgRxGSXw4Xjt3s",
"title": "Natural History Museum",
"website": "https://www.nhm.ac.uk/",
"address": "Cromwell Rd, South Kensington, London SW7 5BD, United Kingdom",
"scrapedAt": "2026-09-22T23:07:38.397Z"
}
],
"maxInputRows": 100,
"maxResults": 10
}
Keep a stable place identifier as well as the website. Two repeated rows for the same place should not count as two branches. The grouping output preserves duplicate-source evidence so a downstream account table can distinguish source repetition from a location relationship.
Match the actual hostname
The transformation uses a normalized hostname and a compatible brand. Brand compatibility can use the disclosed prefix mode or require exact normalized names. Switching that option changes the relationship rule, so store it with the accepted batch.
Normalization removes ordinary naming noise such as punctuation and supported legal suffixes. It does not establish a legal parent. Different businesses can use similar names, and a website can represent a shared service rather than common ownership. Keep the observed hostname and normalized brand beside groupKey so the match remains explainable.
Maintain the shared-platform exclusions
Known social, booking and website-builder hosts are excluded as common ownership signals. The finite built-in list cannot anticipate every shared platform. additionalExcludedHostnames lets the workflow suppress domains its own reviewer has identified as unsuitable.
Treat a new group based on an unfamiliar host as a verification task. Inspect the company's own branch or locations page and retain that source separately if the team needs a stronger ownership claim. A batch-local relationship is useful for reducing duplicate research without becoming a corporate-registry assertion.
Preserve location-level work
groupSize reflects the actual group, while groupMembers is a bounded cross-reference list. A truncated member list should not redefine the true group size. Keep partial flags and member limits visible when the group is exported to a CRM account hierarchy.
Do not replace distinct location records with one merged company row. Each location can have its own address, local contact route and service status. The shared group can be an additional planning dimension, with a separate field recording whether a person has verified the relationship.
When refreshing the export, compare stable place identities and observed hostnames before accepting changed group memberships. Save the prior accepted batch. A source omission or changed capture scope can split a group even when the underlying business relationship has not changed. This workflow gives account planners a reproducible starting point and an explicit evidence gap to resolve before treating a suggested group as a confirmed organization.
Price and verification scope
Listing pricing read on 23 October 2026 is $0.015 per result-found event on the FREE tier. The documented unit is: One useful location assessment delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.
This article uses the installed source contract from build 0.1.4 (2jkDPQDGYEmdNXXbV). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.
Inspect the Actor's current input and pricing.
AI-assisted draft; independent technical and cover review is required before publication.
Top comments (0)