Multi-location ad automation: one account vs. many

Single account with location targeting versus one account per location

The conventional debate: should ten locations share one Google Ads account with geo-targeting campaigns, or each have their own account? There is no universal answer, but the decision has automation implications.

A single MCC account with sub-accounts per location gives you clean separation of budgets, reporting, and access — each location's data is isolated, blame is unambiguous, and you can draft changes to location 7 without touching location 3. One consolidated account with location-based ad groups is simpler to set up but creates entanglement: a budget change affects the whole account, not just one city.

• One account per location — clean isolation, independent budgets, harder initial setup, best for 5+ locations with meaningfully different markets.
• Shared account with location ad groups — lower overhead, suitable for small networks with uniform products and similar CPCs across locations.
• Hybrid — one MCC account, sub-accounts per region or franchise group, individual campaigns per location within each sub-account.

What the AI operator sees across all of this

SpendSignoff connects to multiple accounts under a single org. The list_ad_accounts tool returns all connected accounts. When you describe a multi-location performance problem to your AI client — "which locations are burning budget without converting?" — the model queries each account, aggregates the results, and stages drafts for the accounts that need changes.

The key difference from a human doing this: the model checks all ten accounts in one pass. A human checking ten accounts manually skips the ones that look okay at a glance. The model does not have that fatigue bias.

Autonomous loop behavior at multi-location scale

The always-on autonomy loop runs on a per-account cadence. For a ten-location setup, that means ten independent check cycles. Each cycle reads current pacing, compares CPA against the account-level target, and drafts adjustments if pacing is off or CPA has drifted.

In V1, these drafts are proposals — they queue in the approval UI and a human confirms before anything goes live. The practical result is that instead of checking ten accounts and deciding what to change, you check the approval queue and decide what to approve. The queue is the interface.

What breaks at scale

The main failure mode is approval queue overload. If the autonomy loop drafts fifteen changes across ten accounts overnight, and the account manager reviews them all manually, the time savings are smaller than expected. The solution is raising approval thresholds: small budget adjustments (under 10% from baseline) can be pre-approved by rule; larger changes still need eyes.

The second failure mode is inconsistent tagging. If half your accounts are tagged with location metadata and half are not, multi-account queries return mixed results that are hard to act on. Tag discipline at setup time pays dividends for the life of the account structure.