A multi-location ad budget can be perfectly on pace and completely off the rails at the same time. Network pacing reads 97 percent and finance is calm. Split the same month by location and the calm falls apart: a few clinics burned their budget early, a few barely delivered half, and the failures cancel into one healthy number. Nothing alerts, because the alert lives at the level where nothing is wrong. The fix is structural: compute pacing per location against a per-location plan, run alerts per location, and keep the network view for finance. This guide gives you the full working system: the pacing formula and bands, the location taxonomy it depends on, the alert set we run in production, and a first-week rollout plan.
This article expands on issue 2 of my multi-location clinic analytics series on LinkedIn, and it includes everything from the Location Analytics Starter I previously shared only by DM. No gate here: the taxonomy, the thresholds, and the alert set are all below, free to use.
Key Takeaways
- Pacing is computed where budget is planned, the network, but spent at the location. Every roll-up between the two averages away the signal you need: which location is over and which is under.
- An average is not a diagnosis, and averages do not page anyone. A 97 percent network number can hide locations at 143 percent and locations at 49 percent that cancel each other out.
- The working formula: pacing_ratio = spend_to_date / (budget × elapsed_share_of_period), computed per location. Bands: 0.90 to 1.10 on track, 1.10 to 1.25 watch, above 1.25 alert now.
- Pacing per location only works on top of a location taxonomy: a minted location_id, one mapping table covering every ad account and analytics property, and campaign names generated from that table.
- Four standing alerts cover the failure modes nobody watches for: zero conversions, CPC spikes, pacing breaches, and silent locations. Every alert routes to a named owner by location_id.
The Pacing Paradox: One Healthy Number, Many Broken Locations
Here is the arithmetic that fools everyone. Say a seven-location network reads 97 percent pacing for the month. Perfectly healthy. Now split it by location (numbers illustrative):
| Location | Pacing vs local plan | State |
|---|---|---|
| Location 1 | 143% | Overspending, budget will run out early |
| Location 2 | 63% | Underdelivering |
| Location 3 | 128% | Overspending |
| Location 4 | 49% | Barely delivering half |
| Location 5 | 98% | On track |
| Location 6 | 141% | Overspending |
| Location 7 | 57% | Underdelivering |
The average of those seven numbers is exactly 97. Three locations are burning budget they will not have at month end, two are starving campaigns that were supposed to fill their calendars, and the network dashboard reports all of it as one green number. Nothing alerts, because the alert is configured at the level where nothing is wrong.
I read pacing that way for years: one healthy number, next slide. We see this constantly in multi-location accounts. The roll-up is green; the portfolio is not.
Why Roll-Ups Average Away the Signal
The root cause is a mismatch of levels. Budget is planned at the network, so pacing gets computed at the network. But budget is spent at the location, campaign by campaign. Every aggregation step between where the money is spent and where the number is reported cancels an overspend against an underspend somewhere else, and the deviations, the only part you can act on, disappear before anyone sees them.
This is the pacing-specific version of the argument from issue 1 of this series: the location must be the core entity of the data model, not a filter applied afterward. A network-level pacing number answers finance's question, is the total on plan, and it should keep doing that. It cannot answer marketing's question, which location needs an intervention this week, because that information was averaged out of it.
For the general mechanics of pacing math and cadences, our marketing budget pacing guide covers the fundamentals. What follows is the multi-location layer on top.
The Fix: Per-Location Pacing Rules
Pacing is only comparable when it is computed one way, per location, from one mapping table. The formula:
pacing_ratio = spend_to_date / (budget × elapsed_share_of_period)
A location that has spent $6,000 by day 15 of a 30-day month against a $10,000 local plan has a pacing ratio of 6,000 / (10,000 × 0.5) = 1.20. Band the ratio and attach a behavior to each band:
| Band | Meaning | Action |
|---|---|---|
| 0.90 – 1.10 | On track | No action |
| 1.10 – 1.25 | Watch | Goes to the weekly digest |
| Above 1.25 | Breach | Alert now. Our production default fires past 125% of lifetime budget |
One guard rule completes the setup: an active campaign with a zero or missing budget makes the pacing math meaningless, so that state is itself an immediate alert, not a blank cell in a report. Thresholds are defaults, tune them to your own baselines.
Talk to an Improvado expert about running per-location pacing on your network.
The Prerequisite: One Location Taxonomy
Per-location pacing presumes you can attribute every dollar of spend to a location, and that is where most networks fail first. Four rules fix it.
Mint a location_id. Never derive identity from names. Names drift with every acquisition and every intern: "BrightSmile Dental - Lakeview", "Brightsmile-Lakeview", and "BSD Lakeview (new)" are one clinic and three report rows. An id is forever; names are labels attached to it.
Build one mapping table, and make it the source of truth. Every ad account, GA4 property, call-tracking number, and CRM office code maps to exactly one location_id (rows illustrative):
| location_id | display name | brand | ads accounts | ga4 property | crm code |
|---|---|---|---|---|---|
| loc_007 | BrightSmile Lakeview | BrightSmile | gads 812-xxx, meta act_49xx | prop 3521xx | LKV |
| loc_014 | BrightSmile Northgate | BrightSmile | gads 812-xxx | prop 3522xx | NGT |
| loc_022 | Harbor Pediatric Dental | Harbor | gads 640-xxx, meta act_77xx | prop 4108xx | HPD |
Name campaigns from the table, not from habit. Template: location_id, platform, objective, and period, joined by one delimiter: loc014_gads_leads_202607. Location tokens come only from the mapping table, brand is a column rather than part of the location, and nonconforming new campaigns get renamed the week they appear.
Define every metric once. One central sheet records what counts as a lead, where the conversion fires, and which spend is included. Every location inherits the definition; no dashboard redefines it. If you run a smaller group, the same sequence applies at lower stakes; see our multi-location medical practice guide.
The Per-Location Alert Set
Nobody watches forty screens. These conditions surface only the exceptions. The first three are production defaults from the governance rule library we run for multi-location clients; the fourth is a recommended add-on.
| Alert | Trigger | First check |
|---|---|---|
| Zero conversions | More than 50 clicks and 0 conversions in the last 7 days | Tracking tag first, then the landing page |
| CPC spike | CPC up more than 30% week over week | Auction mix and search-term drift |
| Pacing breach | Pacing ratio above 1.25, or budget missing on an active campaign | Flight dates and budget allocation |
| Silent location (add-on) | Active budget, near-zero spend for several days running | Account access, disapprovals, paused campaigns |
Routing matters as much as the rules. Every alert carries a location_id and goes to that location's named owner. Watch items batch into the weekly digest; breaches go out immediately. An alert nobody owns is a dashboard with extra steps.
Your First Week
The whole setup fits in one working week if you resist perfectionism:
| Day | Step |
|---|---|
| Mon – Tue | Build the mapping table for your top 20 locations by spend. Resist modeling all of them; twenty proves the pattern. |
| Wed | Rename the active campaigns in those locations to the template. Old names live on as labels in the table. |
| Thu | Turn on the three default alerts against the mapping table. |
| Fri | Schedule one weekly report: the share of spend that maps cleanly to a location_id. When it stops climbing, your taxonomy is done. |
The AI Layer: Rules in Plain English
Everything above runs fine as SQL and scheduled queries. The current generation of AI agents removes the last excuse for not doing it.
Rules are written in plain English. "Alert me when CPC jumps 30 percent week over week" goes to an AI agent that drafts the SQL, previews what it would flag today, and activates after human approval. The rule then runs as a live view against your data.
Alerts find what people miss. A healthcare marketing agency we work with got the email about a search-spend discrepancy from the agent that detected it, not from support, and not from an analyst who happened to open the right tab.
Location models become agent-queryable. MCP-capable agents can pull spend by location from Improvado, inheriting your taxonomy and metric definitions. That inheritance cuts both ways: agents inherit your definitions, chaos included. Taxonomy first, agents second.
The division of labor lands where today's post started: the network view stays for finance, and action lives at the location. Improvado implements the full loop as a managed platform, extraction from every ad account and analytics property, the mapping table and metric definitions applied in transformation, and per-location pacing and alert rules running in production against your own warehouse.
Talk to an Improvado expert about turning these defaults into live alerts on your own data.
Frequently Asked Questions
Why is network-level budget pacing misleading for multi-location marketing?
Because pacing is computed where budget is planned, the network, while budget is spent at each location. Aggregation cancels overspending locations against underdelivering ones, so a healthy network number can hide simultaneous failures in both directions. The deviations you need to act on are averaged out before anyone sees them.
What is the budget pacing formula and what bands should trigger action?
pacing_ratio = spend_to_date / (budget × elapsed_share_of_period), computed per location against its local plan. Useful default bands: 0.90 to 1.10 is on track, 1.10 to 1.25 goes to a weekly watch digest, and above 1.25 alerts immediately. An active campaign with a missing or zero budget should alert on its own, since it makes the math meaningless.
What alerts should a multi-location marketing team run per location?
Four standing rules: zero conversions (over 50 clicks with none in 7 days), CPC spike (over 30 percent week over week), pacing breach (ratio above 1.25 or missing budget), and silent location (active budget with near-zero spend for several days). Each alert carries a location_id and routes to that location's named owner.
How do I set up per-location pacing without boiling the ocean?
Start with your top 20 locations by spend: build the mapping table Monday and Tuesday, rename active campaigns to the id-based template Wednesday, enable the three default alerts Thursday, and schedule a weekly report on the share of spend mapping cleanly to a location_id on Friday. Expand from there as the mapped share climbs.
