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.

Global Internet routes connecting regional browser and mobile ad-verification tests

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:

  1. Requested location: the country, region, or city selected for the test.
  2. Observed exit: the IP, ASN, and geolocation returned by an independent check.
  3. 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.