Grid extraction has one tunable parameter that matters, and most people never think about it: how big each cell is. Get it wrong in one direction and you silently lose the densest parts of the city, which is exactly where the businesses are. Get it wrong in the other and a one-hour sweep takes six.
This is the arithmetic for getting it right.
The constraint you are designing around
A single Google Maps query returns roughly 120 results, and that ceiling is per query, not per city. Grid extraction works because each cell is its own query. Which means each cell inherits its own 120-result ceiling, and the design goal follows directly:
No cell should ever contain more businesses than a single query can return.
A cell that holds 300 dentists returns about 120 of them and gives no error, no warning, nothing. The sweep completes, the export looks healthy, and the missing 180 are simply absent. This is the worst failure mode in extraction precisely because it is invisible: undercoverage in the city centre looks identical to a smaller city.
The tradeoff in both directions
- Cells too large: silent truncation wherever density exceeds the cap. Lost data, no signal that it was lost.
- Cells too small: every cell is a query, and queries cost time. Halving cell width quadruples the cell count. A metro that needed 30 queries at a sensible size needs 480 at an overcautious one, and the sweep that took forty minutes now takes most of a day, mostly asking empty farmland for dentists.
The asymmetry matters: too-small is slow but correct, too-large is fast but wrong. When in doubt, err small. But the point of doing the arithmetic is not being in doubt.
A worked example
Take “restaurant” in a large metro, something like Greater Manchester at roughly 1,300 km².
- Estimate the category total. A large UK metro holds very roughly 6,000-8,000 restaurant-category listings. You do not need precision; you need an order of magnitude, and one probe query in the densest area plus one in a suburb gives you a feel.
- Set a per-cell target well under the cap. Aim for cells that hold at most 60-80 businesses, roughly half the ceiling. The margin covers estimation error and the fact that density inside a cell is not uniform.
- Divide. 7,000 businesses at ~70 per cell wants about 100 cells over the populated area. Over ~1,300 km² that is cells of roughly 13 km², about 3.6 km on a side, and finer than that over the centre.
Now compare a lazy uniform choice: 6 cells across the metro. That is ~1,200 businesses per cell in a 120-cap world. The sweep runs in minutes and quietly discards more than 80% of the category.
Density is not uniform, so the grid should not be either
A uniform grid sized for the city centre wastes most of its queries on low-density periphery; sized for the periphery, it truncates the centre. The resolution is adaptive subdivision:
- Start with a coarse grid over the whole target area.
- Run each cell and look at its result count.
- Any cell returning at or near the cap is flagged and split into four, and the quarters are re-run.
- Repeat until no cell is near the cap.
The near-cap count is the tell. A cell that returns 118 results did not contain 118 businesses; it contained at least 118, and the true number is unknown until it is subdivided. A cell returning 40 is finished, and its count is real.
Lead Finder does this subdivision automatically, which is most of what “grid extraction” means as a product feature rather than a technique. If you are building your own tooling, this loop is the part worth engineering; the rest is bookkeeping.
Category changes everything
The same city needs different grids for different categories, because density varies by an order of magnitude between them:
- Restaurants, salons, cafes: the dense categories. Fine grids in urban cores, and the categories where truncation happens to people who never notice.
- Dentists, gyms, law firms: mid-density. A moderate grid covers them comfortably.
- Car dealers, moving companies, wedding planners: sparse. A handful of large cells covers a metro, and a fine grid mostly queries nothing.
A practical habit: when switching category, re-probe the densest square kilometre before trusting last week’s grid. The per-industry guides carry typical metro counts per category, which is the estimation shortcut.
Overlap and the de-duplication tax
Cells need slight overlap at their boundaries so businesses on an edge are not missed by both neighbours, and overlap means duplicates: expect 15-30% inflation in raw rows on a properly overlapped grid. This is why de-duplication on place ID is not optional hygiene but a structural requirement of the method. A grid extraction that produces zero duplicates is a grid with gaps.
The checklist
- Probe the densest area to gauge category density.
- Size cells for 60-80 results, half the ceiling.
- Let dense cells subdivide, and treat near-cap counts as “unknown, split me”, never as data.
- Expect duplicate inflation and key the merge on place ID.
- Re-probe when the category changes, not just the city.
Get the cell size right and grid extraction is boring, complete and repeatable, which is exactly what a data pipeline should be.