LOCAL

Map pack grid tracking plan

Use when your map ranking changes depending on where the searcher is standing and you need to measure it properly.

map-pack-grid-tracking-plan.md

Download .md

You are specifying how to measure map results across a service area. You are not running the scans and you hold no ranking data of your own.

Address the grid centres on: {{BUSINESS_ADDRESS}}
Area we serve and how far out it goes: {{SERVICE_RADIUS}}
Terms worth tracking: {{PRIORITY_TERMS}}
What we track today and in which tool: {{CURRENT_TRACKING}}

Produce:

1. A grid specification: number of points, spacing and total span, centred on {{BUSINESS_ADDRESS}} and covering {{SERVICE_RADIUS}}. Justify the spacing in two sentences. Where {{SERVICE_RADIUS}} is too wide to cover at usable spacing, propose two grids rather than one loose one.

2. A term table: Term from {{PRIORITY_TERMS}}, why it is worth the scan cost, the pattern you would expect if things are healthy, scan frequency.

3. A reading guide covering a tight ring around the pin, a lopsided grid, a uniformly weak grid, and a grid that moves week to week. Say what each suggests and which are worth acting on.

4. A gap list against {{CURRENT_TRACKING}}: keep, drop, add, with a reason on each line.

Rules:
- Do not state the distance at which visibility drops away. Say it varies with how many competitors sit between the searcher and the pin.
- Grid position is not a proxy for enquiries. Name two things to report alongside it.
- Never suggest an address change or an extra listing to widen the grid.
- No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{BUSINESS_ADDRESS}}
{{SERVICE_RADIUS}}
{{PRIORITY_TERMS}}
{{CURRENT_TRACKING}}

Getting a better result

Run the same grid on the same weekday. Comparing two different spacings tells you nothing.
Track three or four terms, not thirty. Cost rises with points multiplied by terms multiplied by runs.
Pair the grid with calls and direction requests, or you end up improving a picture nobody buys from.

Questions about this prompt

When do I need a grid rather than a rank tracker?

When your position depends on where the searcher is standing and one number hides that. A tracker reports a single position per term. A grid shows the shape across the area you serve. If you cover a radius rather than a single street, the single number is telling you very little.

What do I need to decide first?

The address the grid centres on, how far {{SERVICE_RADIUS}} genuinely extends, three or four {{PRIORITY_TERMS}} rather than thirty, and what {{CURRENT_TRACKING}} already covers. Cost rises with points multiplied by terms multiplied by runs, so the term list is a budget decision before it is a measurement one.

What comes back?

A grid specification with the spacing justified, a term table, a reading guide for the patterns a grid produces, and a keep, drop, add list against your current tracking. The reading guide is what you will use every month, since a tight ring, a lopsided grid and a weekly wobble mean different things.

What is the mistake?

Changing the grid between runs. Same spacing, same weekday, or the comparison means nothing. The second mistake is reporting grid position on its own. It is not a proxy for enquiries, so pair it with calls and direction requests or you end up improving a picture nobody buys from.