Route labels get left out of evidence records
The most common QA failure in ad verification is a screenshot with no record of where the page was loaded from. The screenshot proves what appeared on screen. It does not prove which market served the creative, which exit was used, or whether the country target was correct. Without the route label, the evidence is incomplete for any dispute.
Every check should start from a connection labeled to the market being verified. On a Proxynade pool, the gateway is proxynade.net:2555. Country targeting goes in the expanded username: for example, rt97db6958d9-plan-volume-country-de-lifetime-10 routes through Germany residential exits with a 10-minute rotation window. The password travels separately. Nothing about the destination URL or port number controls geography.
Rotating residential is the right starting point for public placement checks — geo QA across markets, creative correctness, consent behavior, and redirect chains. Sticky sessions (a longer lifetime-<minutes> value) only matter when the check includes a login or a private publisher portal that tracks sessions. Static routes are useful for repeat diagnosis of a specific exit, but too narrow for a first-pass sweep.
Bandwidth per check is higher than the browser reports
A rendered ad placement check pulls more than the HTML body: consent scripts, redirect hops, pixel fires, creative assets, and part of the landing page all cross the proxy and all count toward your bill. Browser devtools undercount because they skip failed responses, aborted requests, and pre-render traffic that still transferred bytes.
A realistic per-check estimate is 500 KB to 1.2 MB. At Volume Residential pricing of $0.89/GB, 1,000 checks costs roughly $0.45 to $1.07 in bandwidth — not a large line item, but the dashboard usage logs will show a higher number than your application does. Export the usage CSV after the first real run and use it to calibrate future budgets.
For redirect-chain audits and landing page status checks, a headless browser is not required. Plain HTTP with cookie and header forwarding costs a fraction of the bandwidth and runs faster. Use a browser only when the creative must render — JavaScript-delivered ads, viewability measurement, and consent interaction. When you do route a browser through the proxy, Playwright's HTTP proxy docs cover the configuration options.
Evidence records need the route label
Each check should produce a structured record before the screenshot is taken. The fields that matter for disputes:
| Field | Why it matters |
|---|---|
| Market / country code | Confirms the geo target was correct |
| Proxy route label | Ties the check to a specific exit pool and timestamp |
| Placement URL | Exact URL loaded, not the campaign root |
| Timestamp (UTC) | Flight schedule and dayparting disputes |
| Creative ID | Links to the trafficked line item |
| Final URL | Confirms redirect chain terminated correctly |
| HTTP status code | Distinguishes a 200 serve from a 301/302 or a 403 block |
| Screenshot hash | Proves the file was not altered after capture |
The route label is the field left out most often. Without it, a screenshot cannot be tied to a verified market exit, and the check cannot be reproduced.
Ad verification proxy FAQ
Which proxy type is right for ad verification? Rotating residential for public placement geo checks. Static ISP or sticky residential when the check includes a login or a private publisher portal that tracks sessions.
How much bandwidth does one ad verification check use? 500 KB to 1.2 MB per rendered placement check is a realistic starting estimate. Browser-reported sizes miss failed bodies, redirect chains, consent scripts, and pixel fires that still cross the proxy.
What fields belong in an ad verification evidence record? Market, proxy route label, placement URL, timestamp, creative ID, final URL, HTTP status code, and a screenshot hash. Route label is the field most commonly left out.
Do I need a browser to run ad verification checks? Only when the ad must render — JavaScript-delivered creatives, consent flows, viewability measurement. For redirect chain audits and landing page status checks, plain HTTP works fine and costs less bandwidth.
Check discipline
- Fix market, campaign, and route before capturing evidence.
- Log the proxy route label alongside every screenshot.
- Export the usage CSV after each run to calibrate bandwidth estimates.
- Use plain HTTP for redirect checks; use a browser only when rendering is required.
- Store screenshot hashes so captured files can be verified later.