August 12, 20265 min read

Ad verification: check placements from the city you targeted

By The Masklabs team

The insertion order says Phoenix, on mobile, on a real carrier network. What you see when you check the placement from your office wifi is not what that Phoenix subscriber sees. Different location, different network type, often a different ad server decision entirely. If you only ever verify from where you sit, you're verifying the wrong thing.

Office wifi isn't the audience

Ad servers and landing pages make decisions based on signals you don't carry at your desk: IP geolocation, carrier vs datacenter classification, device type, sometimes even carrier name. A campaign that targets mobile users in a specific metro can serve a completely different creative, a different offer, or no ad at all, to a fixed-line IP in another state. Your corporate network is exactly the kind of signal an ad server or a bad actor uses to decide "this isn't a real prospect, show the safe version."

That mismatch is invisible until someone checks from the actual target. And by the time a client or a compliance team notices a wrong creative running in the wrong city, the spend has already happened.

Load the placement from the actual city

Masklabs runs on real mobile carrier IPs: exit addresses from real phones on carrier networks, not a datacenter range. Append _loc_<CITY> to your username and your traffic exits from that metro, on a real carrier, the same combination the insertion order specifies.

mlabs_a1f9c3_loc_phx:<PASSWORD>@proxy.masklabs.io:8080

Swap phx for any of the 46 supported cities to move your vantage point to Chicago, Miami, Denver, wherever the campaign is supposed to be live. Sessions rotate by default, so repeated checks against the same city land on different carrier IPs each time, which is useful for confirming a placement isn't just one lucky match. If you need to hold a single IP for a multi-step check, like clicking through from an ad to a landing page and then to a checkout, add _sticky and the gateway pins that IP for about three minutes.

What to actually compare against the insertion order

An IO usually specifies creative, geo, and destination together. Verify all three match, not just one:

  • Creative. Is the ad unit showing the approved creative for this flight, in the right size and format, or is it serving a fallback because the targeting didn't resolve?
  • Landing page. Does the click-through land on the URL in the IO, with the right offer, pricing, and disclosures, or has it been swapped for something else?
  • Geo. Does the page content itself, city names, local pricing, "near you" copy, actually reflect the city you're loading from, or is it generic regardless of where the request originated?

Any one of these can be wrong while the other two look fine. A creative can be correct while the landing page behind it has been swapped. Checking all three from the real target is the only way to catch that.

Catching cloaking and affiliate fraud

Cloaking is the more deliberate version of a geo-mismatch: an offer shows a compliant, boring landing page to reviewers, bots, and datacenter IPs, then swaps to the real, often noncompliant, offer for actual mobile users on carrier networks. Ad network reviewers checking from a datacenter see the safe page and approve it. The mobile subscriber who clicks the ad sees something else entirely.

The only way to see what the mobile subscriber sees is to look like one. A check from a carrier IP, in the targeted city, on a mobile-classified connection, gets served the same decision tree as the real audience. If the page you land on doesn't match what got approved, or doesn't match what you'd expect from the IO, you've found a cloak, an affiliate running an unapproved offer, or a landing page that's simply broken for anyone who isn't a reviewer.

Spot checks on a schedule, not just at launch

A placement that verified clean on day one of the flight can drift. Creative gets swapped by an ad ops mistake, a landing page redirect gets hijacked, an affiliate rotates in a different offer once the initial review traffic dies down. Set a recurring spot check across the metros in the flight, not a one-time verification at launch:

  • Rotate through the target cities. Pull each metro in the IO on its own schedule so you're not only ever checking the one city you remember.
  • Recheck mid-flight and near the end. Cloaked offers often wait a few days after launch, once the reviewer traffic has moved on, before swapping to the real page.
  • Keep a separate credential per verification job. An ad-check or verify credential draws from the same pool as the rest of your account and gives you a clean usage line for how much checking you're actually doing, separate from any other work.

See the sessions and locations guide for the full list of supported cities and how the location suffix interacts with rotating and sticky sessions.

The bottom line

A placement is only verified once you've seen it the way the targeted audience sees it: from the right city, on a real mobile carrier connection, checking creative, landing page, and geo together against the insertion order. Anything checked from an office network or a datacenter IP is a different signal than the one your campaign is actually paying to reach, and it's exactly the signal a cloaked offer is built to fool. Check pricing for plan sizes if you're setting up a recurring verification schedule across several metros.