Measurement
Part of When to rebuild your local SEO measurement and reporting stack
When to build a local SEO reporting dashboard instead of a report pack
How to scope and build a local SEO reporting dashboard, from metric selection and source discipline to a before-and-after table and a fixed review cadence.
What to take away
- Inflation and demand shifts have changed the questions clients ask, so a dashboard now has to answer spend decisions.
- Build one when reporting effort outgrows the decisions it supports, not on a fixed anniversary.
- Pick the smallest metric set that answers client questions, then let the Local SEO: measurement and reporting guide 2027 govern definitions and review dates.
- Treat your dashboard as a reporting layer over source systems. It never becomes the source of truth itself.
- A before-and-after table makes the rebuild case in one page.
Why dashboard timing matters now
The Bank of England sets monetary policy to meet a 2% inflation target, and its outlook shapes how small firms plan marketing spend. Tight budgets make clients ask sharper questions about what local SEO returns. A dashboard built for vanity charts will not answer them.
Rebuild triggers are practical. A client asks for a metric your current reports cannot show. Three months of manual exports take longer than the meeting they support. A source system changes how it counts something, and stale definitions quietly mislead.
Take an illustrative example: an agency billing £400 a month for a reporting retainer, where 24 tiles are built by hand each cycle. Moving to six sourced tiles returns those hours to analysis without changing the fee.
Start by listing every question a client asked in the last quarter. Group them into demand, visibility, conversion and cost. Questions that repeat become dashboard tiles.
Pick the smallest metric set that works
Choose metrics against the decisions they inform, not against what a tool offers by default. The Local SEO key metrics: selection guide for England walks through selection tests to apply before adding a tile. A dashboard with six well-defined metrics beats one with thirty loose ones.
For each metric, write four things: the question it answers, the source system, the counting rule, and the review date. If you cannot name the source system, the metric is not ready. The same discipline applies to supplier claims, including research on advertising effectiveness published by the ASA and CAP.
Where a metric depends on search data, state whether it covers England, the wider UK, or a single town. Mixing geographies in one tile is the most common reporting error.
Label every tile with its unit and its comparison window. A month-on-month figure and a year-on-year figure answer different questions, and a tile that hides which one it uses turns debates into arguments about arithmetic rather than decisions.
Before and after a rebuild
| Element | Before | After |
|---|---|---|
| Metrics shown | 24, tool defaults | 6, mapped to client questions |
| Source systems | Unnamed exports | Each tile names its system |
| Update cadence | Ad hoc | Monthly, with a fixed refresh date |
| Geography | Unlabelled | England, UK or town stated per tile |
| Review owner | Shared, unclear | One named owner |
| Client decisions | Anecdotal | Logged against each metric |
Use the table as your build checklist. A tile that cannot fill every cell stays out of the first release.
Set sources and review dates
Every figure needs a named source and a date. Where a client operates in a regulated market, note the regulator and check whether a market problem needs reporting to the CMA. Record the date you checked.
Define what a change means before you see it. Agree that a fall in one metric triggers a source system check first, then a conversation. Otherwise small fluctuations become emergencies.
Set a quarterly review to confirm definitions still match the source systems. Demand shifts change client questions, and the dashboard should follow the questions rather than the calendar.
Keep a change log beside the dashboard. When a source system alters how it counts something, record the date and the size of the step, so nobody later reads a definition change as a performance change.
Roll it out without breaking trust
Pilot with one client for a month. Compare its numbers against the old reports line by line, and investigate every difference before you migrate anyone else.
Publish a short change note with each release, stating what moved, which source changed, and what the client should do differently.
Train the person who presents the dashboard. A clear walkthrough of six tiles beats an apologetic tour of twenty-four.
Common questions
How often should the dashboard refresh?
Monthly suits most England clients. Refresh on a fixed date so comparisons stay honest, and note it on every export.
Can a dashboard replace written commentary?
No. Numbers show what moved; commentary explains why it matters and what happens next.
What if a client wants more metrics?
Add them only when a named decision needs them. Otherwise park the request in a backlog with a review date.
Who owns the definitions?
One named owner. Shared ownership is how definitions drift and how disputes start.
