Clean up stale location targeting
Find every location rule that names a place the geo database no longer knows, see what removing each one would change, and remove or replace them in one pass.
The geo database behind location targeting is updated by its provider, which now and then renames a place or folds it into a neighbour: “Lexington-Fayette” became “Lexington”, Las Vegas suburbs such as “Enterprise” and “Spring Valley” are now reported as Las Vegas. A rule that names such a place matches no visitor. Stale locations lists every one of them across the advertisers, campaigns, banners, sites, zones and placements you manage, says what removing each would change, and removes or replaces them in one pass.
Who this is for
Network managers, and anyone whose role manages targeting: the page opens with Manage Demand Targeting (advertisers, campaigns, banners) or Manage Supply Pre-targeting (sites, zones, placements), together with the right to change those entities. Each rule is listed only when you may change it: your role also needs the targeting permission of its type (Location, or Country for a country rule) on that side, and update rights on the entity.
Prerequisites
- Location or country rules saved on at least one entity. Paused entities and entities whose targeting is switched off are checked too — their rules apply again once they run — deleted ones are left out.
- The geo service answering. While it is down the page says so and lists nothing (see the corner cases below).
Steps
-
Open Account → Advertisers (or Publishers) and click the Stale locations button (a crossed-out map pin) on the action rail left of the tree. A red place on a targeting card links here too: Clean up stale places across the account.
-
Read the header: how many stale rules there are, how many are safe to remove and how many need a decision. Each row names the entity (a link to its edit page, where the targeting card shows the place in red), the place, include or exclude, and If removed:
If removed When What removing it does Safe to remove A stale include while the entity still targets a valid place of the same type, or a stale country exclude Nothing. The ad server already ignores it. Opens to all locations The entity’s only includes of that type are stale Today the entity reaches no visitor. Once every such place is gone, the location limit is lifted and it serves everywhere. Starts delivery A stale location exclude Today it keeps every visitor out. Once it is gone the entity starts serving to everyone else. -
Rules that are safe to remove are already selected. Narrow the list with If removed and Entity type if you want to work through one kind at a time.
-
For a rule that opens or starts delivery, prefer Replace…: pick the place it is called now (country, then optionally region and city, as on the targeting card) and click Replace. The new place gets the same include or exclude on the same entity and the stale rule is removed, so the targeting stays as the advertiser meant it.
-
Click Remove selected (N). The confirmation counts how many of the selected rules are safe and how many change delivery, and names the change. Confirm with Delete.
-
The list refreshes. Rules the server did not remove are named in a message with the reason (for example, someone removed them meanwhile).
Every removal and replacement goes through the same path as an edit on the targeting card: it is written to the action log and reaches the ad servers like any other targeting change.
Corner cases & gotchas
Corner case: a geo service outage is not mistaken for stale places. A place is listed only when the service’s own lists prove it unknown — its country, region or city list was read and the name is not there. When the service does not answer, answers for too few places, or nearly every place fails at once, the page shows Stale places cannot be checked right now with the reason and Try again, and lists nothing. A handful of places the service gave no clear answer for are left out and counted under the list instead. An empty list is an answer, not an outage: a region named in a country the provider lists no regions for is stale, so a single such place no longer keeps a small network on Try again. Names are compared as the geo service compares them — case does not matter, accents and spaces do.
Corner case: “safe” is decided per entity and per targeting type. A stale city next to a valid city on the same campaign is safe; the same stale city on a banner whose only location include it is opens that banner to every location, even if its campaign still targets cities. Location and country rules are separate types, so a valid country include does not make a stale location include safe.
Corner case: a country exclude naming a code nobody has excludes nobody, so it is safe to remove; a stale location exclude keeps every visitor out and is listed as Starts delivery. Country rules cannot be replaced from this page — remove them and add the country again on the targeting card.
Corner case: the list is computed when you open the page; the places it looks up are remembered for about ten minutes, so a refresh after a cleanup is quick. A rule saved on a targeting card is checked against the geo database when you save it — an unknown region or city is refused (Unknown region: …, Unknown city: …) — so new stale rules appear only when the provider renames a place later.
Corner case: a new place is matched the way the geo service matches it: case does not matter, accents and spaces do (Sao Paulo is not São Paulo). A look-up that fails for a moment does not refuse a real place — it is confirmed from the region’s or city’s own list — and while the geo service does not answer at all, Replace says so (The geo service did not answer. Retry later.) instead of calling the place unknown. A rule someone removed after the page was opened answers Not a stale place you can manage, or already removed.
Over the API
GET /rest-api/targeting/stale-locations.do answers the same list (status, counts, rows
with kind per rule). POST /rest-api/targeting/stale-locations/remove.do takes targetIds
and removes only rules of kind SAFE unless confirmChanges=true; the rest come back in
skipped with reason CONFIRM_REQUIRED. POST /rest-api/targeting/stale-locations/replace.do
takes targetId, countryCode, regionName and cityName; it answers 503 while the geo
service does not answer and 404 for a rule removed since the list was read. See
Targeting rules via API. The AI assistant and MCP clients
use the stale_locations and stale_locations_fix tools, which ask before any change that
affects delivery — see MCP.
Per-role notes
- Advertiser or publisher roles: see only the rules of the entities they manage; the button is on the action rail of the side their role manages targeting on.
- Read-only (view) access: the page does not open — there is nothing it could change.
- Super-Admin: account pages are not available to the admin area; use Switch user to a network user to clean up.