Geo-targeted ad verification looks simple: connect through an IP in the desired city, load the page, and check the creative. In practice, ad platforms combine many signals. IP location matters, but device location, account history, language, browser state, page context, carrier routing, consent status, frequency caps, and campaign pacing can also affect delivery.
A useful verification program therefore needs a matrix, not a screenshot. The matrix must separate routing evidence from audience and application state, while keeping tests lawful, authorized, and reproducible.

Start with the question the test must answer
Choose one question per run:
- Is the campaign eligible to serve in the intended country or region?
- Is an excluded geography receiving the creative?
- Does the correct language, price, disclaimer, or landing page appear?
- Is delivery consistent across desktop and mobile?
- Is a consent or regulatory message shown in the correct jurisdiction?
- Is a competitor or prohibited category appearing on owned inventory?
Do not combine all of these into one pass/fail label. A campaign can be geographically eligible but fail localization, consent, or landing-page checks.
Build the core matrix
Use rows for regions and columns for the variables that can change delivery.
| Dimension | Minimum cells | Why it matters |
|---|---|---|
| Geography | target, adjacent, excluded, neutral control | proves inclusion and exclusion behavior |
| Connection | Wi-Fi-like residential, carrier-like mobile when authorized | carrier routing may provide coarser location evidence |
| Device | desktop, mobile | inventory and creative formats differ |
| Browser | Chrome, Safari or relevant production mix | browser privacy features can affect targeting and state |
| Session | fresh, returning | cookies, consent, frequency caps, and history differ |
| Language | target locale, neutral locale | separates language targeting from physical location |
| Time | campaign active window, boundary, control window | catches scheduling and time-zone errors |
Begin with a small risk-based matrix. Testing four regions × two devices × two sessions × two time windows already creates 32 cells. Add browsers or connection types only when campaign settings or observed failures justify them.
Treat location as evidence, not certainty
Google's public guidance says ad location can be inferred from IP address, device location, Wi-Fi, cellular data, and other signals. It also describes geographic delivery as best effort rather than perfectly accurate. For carrier traffic, Google Ad Manager recommends country-level targeting because finer location accuracy depends on carrier data.
That means a proxy exit in a city does not guarantee the platform will classify the session at city level. Record three distinct values:
- Requested location: the country, region, or city selected for the test.
- Observed exit: the IP, ASN, and geolocation returned by an independent check.
- Platform outcome: the creative, targeting diagnostic, consent state, or report dimension actually observed.
Never overwrite these into a single “location” field. Differences between them are often the finding.
Stabilize the browser state
Create named session profiles instead of clearing everything indiscriminately:
- Fresh: new browser context, no prior site storage, no signed-in account.
- Returning: a controlled, documented cookie state created during the test.
- Consent accepted or rejected: only where the test is authorized and the choice is valid.
- Account state: signed in or signed out, when required by the campaign and permitted.
Keep timezone, locale, geolocation permission, user agent, viewport, and device scale factor explicit. Changing IP while leaving timezone and language inconsistent can create an unrealistic profile and produce results that do not represent real users.
Capture an evidence package
For every matrix cell, store:
- run ID and UTC timestamp;
- requested region and observed exit metadata;
- connection, browser, device, locale, timezone, and session profile;
- page URL and placement identifier;
- creative identifier when visible;
- screenshot with sensitive information removed;
- landing-page final URL and redirect count;
- consent or regulatory message state;
- network status and first-byte time;
- expected result, observed result, and pass/fail reason.
Hash the screenshot and structured record so later reviews can tell whether evidence changed. Do not store credentials, full cookies, tokens, or personal data.
Avoid the most common false conclusions
“The proxy says Paris, so the ad must be Paris-targeted.” The platform may use other location and interest signals, or only classify the connection at country level.
“No ad appeared, so targeting is broken.” Delivery can be affected by budget, pacing, auction eligibility, frequency caps, inventory, creative approval, and time windows.
“One screenshot proves compliance.” A single impression cannot establish a distribution. Repeat bounded samples across independent sessions and report confidence, not certainty.
“More refreshes create better evidence.” Repeated reloads can trigger frequency caps, bot controls, or unusual behavior. Set a maximum attempt count and cool-down period before testing.
Define pass criteria before collection
Example criteria for one regional cell:
- observed exit country equals requested country;
- expected creative appears within five authorized attempts;
- excluded creative appears zero times;
- language and price match the campaign specification;
- landing page remains on the approved domain and locale;
- required consent message appears before ad storage or personalization;
- screenshot, request metadata, and timestamps are complete.
Use separate statuses for pass, fail, inconclusive, and not eligible. “Inconclusive” is essential when the campaign did not enter the auction or location evidence was too coarse.
Operational checklist
- Obtain written authorization for the campaign, properties, regions, and test volume.
- Translate campaign targeting into explicit matrix cells.
- Include target, excluded, adjacent, and neutral-control geographies.
- Verify the observed exit separately from the requested location.
- Control browser, device, locale, timezone, session, and consent state.
- Use bounded attempts and avoid creating artificial delivery signals.
- Redact secrets and personal data from artifacts.
- Review landing-page redirects as well as the visible creative.
- Preserve inconclusive results instead of forcing pass/fail.
- Escalate discrepancies with the complete evidence package.
FAQ
Should every city test use a city-level proxy?
Only when the campaign targets at city level and the platform supports reliable city classification for that connection type. Start with country or region tests, then add city cells where the expected precision and risk justify them.
Can browser geolocation override replace a proxy?
No. It changes the browser-provided location signal, not the network exit. A complete test may need both signals aligned, but only where the user permission and test authorization allow it.
How many impressions prove a result?
There is no universal number. Define bounded attempts based on delivery probability, campaign volume, cost, and risk. Report sample size and uncertainty; never claim perfect coverage from a small sample.
Should the same account be used in every region?
Not automatically. Account history can become a confounding variable. Use signed-out fresh sessions unless an authenticated audience is specifically in scope, then document the account state and obtain authorization.
Compliance note
Perform ad verification only for campaigns, properties, and regions you are authorized to test. Follow advertising-platform policies, privacy and consent rules, applicable law, contracts, publisher terms, and rate limits. Do not generate invalid traffic, click ads, manipulate auctions, or use proxies to evade controls.
For infrastructure validation, combine this matrix with the proxy-versus-target diagnostic plan and the browser proxy capacity guide.
Related Recommendations
- Proxy Error Troubleshooting: 407, 429, Timeouts and Connection Resets
- http global proxy: how to set up a stable connection
- How to Measure Proxy Cost per Successful Request
- SOCKS5 vs socks5h: How Remote DNS Changes Proxy Routing
- How to Design Proxy Timeout Budgets for Reliable Automation
- How to change IP in a virtual machine?
- How to turn off global proxy settings
- How to set up proxy IP in Edge Browser: Detailed Tutorial
- How to Forecast Residential Proxy Bandwidth Before Buying a Plan
- How to Troubleshoot Proxy Authentication and 407 Errors with curl