Proxies for Ad Verification: Which Type to Use

Which proxy type to check ads with: residential for in-market creative, datacenter for tag and landing-page QA, and how to log a valid check.

To see an ad the way a buyer in Madrid or Ohio sees it, check it through a residential proxy targeted to that country or city. Use datacenter proxies for the checks where the viewer's network does not change the answer: does the tag fire, does the click tracker land on the right URL, does the landing page load in each market. That split is the whole decision. The rest of this guide shows where each type fits and how to tell a valid check from one that measured your proxy instead of the campaign.

Node4 sells every proxy type compared here, so this is a guide to choosing a type, not a ranking of providers.

What the ad stack sees from your proxy

Three properties of the exit address decide what an ad server sends back:

• Location. Campaigns are geotargeted from IP geolocation. An exit that resolves to Barcelona will not show you a Madrid-only line item.
• Network type. An address registered to a hosting company reads differently from one on a consumer ISP. Ad stacks and invalid-traffic filters can treat hosting traffic as non-human and answer with a house ad, an empty slot, or no bid at all.
• Continuity. One impression is a chain: the page, the ad request, the creative, the impression pixel, the click redirect. If the exit changes halfway, the later calls can be judged as a different visitor.

The way to keep these in check is to log them with every check. For example, a record for a Madrid check whose exit landed in the wrong city might look like this:

check_id:        es-madrid-0412
campaign:        spring-launch / line item 4471
requested exit:  country es, city madrid
reported exit:   ES, Barcelona, consumer ISP
creative served: house ad (ID 0)
landing URL:     not reached
verdict:         INVALID CHECK, exit city outside target; rerun

That last line matters. Without the reported exit, a run like this would be filed as "creative missing in Madrid" and sent to the trafficking team as a delivery problem. Fetch an IP lookup through the same session at the start and end of each check, and reject the record if either one falls outside the target.

Proxy types for ad checks, compared

Residential: the check that has to look like a viewer

Residential exits come from a partner network of consumer devices, not from Node4's own blocks, which is why they geolocate and classify like ordinary home users. Targeting rides in the username, so one credential covers every market you verify:

curl -x "http://USERNAME-country-es-city-madrid-session-adchk0412:PASSWORD@gw-residential.node4.io:8082" https://ipinfo.io/json

Add the session segment so the whole impression chain uses one exit. Residential sessions are best effort, with a 30-minute ceiling, and can end sooner if the device behind the exit goes offline, so the end-of-check IP lookup in the record above is what tells you the chain stayed on one exit. The full username grammar, including state and ASN segments, is in country and city targeting.

Because residential is billed per gigabyte, ad weight drives the bill. If a page with a video pre-roll moves about 5 MB per check, 1,000 checks a month is roughly 5 GB before retries. Blocking video files you do not need to inspect, or checking only the ad request and creative URL rather than rendering the whole page, cuts that sharply. Plan sizes are on the residential pricing page.

Datacenter: tag, redirect and landing-page QA

Plenty of verification does not depend on the viewer's network. Does the click tracker redirect to the URL in the insertion order? Does the landing page return a 200 in Spain as well as the US? Does the conversion pixel fire? For those, a datacenter exit is cheaper and steadier.

• Dedicated datacenter gives you one fixed address that is yours alone, which suits a staging server that only admits known addresses: ad ops add the IP once and every QA run comes from it. There is no data cap, so heavy creative does not change the bill. See dedicated plans.
• Rotating Datacenter spreads a large URL list across many exits. A session ID holds one exit for up to 30 minutes, counted from when the exit is first assigned, and it does not extend while you keep using it. A check that starts at minute 25 of a session can roll over mid-chain, so start each check on a fresh session ID. Sticky and rotating sessions covers the details.
• Rotating Unmetered runs on the same exits as Rotating Datacenter and charges by how many connections you hold open at once instead of by data. If your QA crawler runs 40 workers around the clock, size the plan to 40 connections plus headroom and the data volume stops mattering. See connection-based pricing.
• Shared datacenter is the lowest-cost way to run an occasional spot check, but up to five customers can share an address, so its history with an ad platform is not yours alone.

Do not use a datacenter result as evidence about what a consumer saw. If the tag QA passes from a datacenter exit and the in-market check fails from a residential one, the residential result is the one that describes the campaign. The broader trade-off is in datacenter vs residential proxies.

Which type to buy

If the question is "what creative does a viewer in this market get," buy residential and log the reported exit with every record. If the question is "does this tag, redirect or landing page work," buy datacenter: dedicated for a fixed address your ad ops team can admit to staging, Rotating Datacenter for a large URL list, Rotating Unmetered when the crawler runs many connections all day. A common setup is one residential plan for in-market checks and one datacenter plan for QA, because the two answer different questions. To compare residential providers rather than types, see residential proxy providers compared.