How GPS-Verified Ad Delivery Works

How GPS works on a consumer phone

Every modern smartphone runs a multi-constellation GNSS receiver (GPS, GLONASS, Galileo, BeiDou) paired with a sensor fusion stack: accelerometer, gyroscope, magnetometer, barometer. The receiver locks onto satellite signals, computes pseudoranges, and resolves a 3-D position fix.

On its own, raw satellite acquisition is slow — minutes to first fix on a cold start. Smartphones short-circuit this with Assisted GPS (A-GPS): the cellular network downloads ephemeris and almanac data to the phone over the radio link, so the receiver knows where to look in the sky and locks in seconds rather than minutes.

A-GPS plus Wi-Fi BSSID lookup is what gets a phone to its quoted accuracy floor. Apple, Google, and the broader industry converge on the same number for clear-sky consumer accuracy.

Smartphone with assistive services

≤4.9 m

A-GPS + Wi-Fi positioning, clear sky

Wikipedia — Global Positioning System

Open environment, GPS only

3–5 m

Standard consumer smartphone

Mapscaping — How Accurate Is GPS

Urban canyon (peer-reviewed)

7–13 m

iPhone 6 horizontal accuracy in dense city

Smartphone GPS accuracy in urban environment — PLOS One

Time to first fix with A-GPS

Seconds

vs. minutes on a cold satellite-only fix

Wikipedia — Assisted GNSS

Operator-owned mesh vs. bid-stream-inferred location

There are two ways an ad platform can know where a phone is. They produce wildly different accuracy and economics.

Bid-stream-inferred location. The ad platform never touches the device. It listens to OpenRTB bid requests flowing through ad exchanges. Each request may carry a coarse lat/lon attached by the publisher's SDK, plus a mobile advertising ID. The platform decides whether the device is “near” a billboard or geofence and bids accordingly. The whole auction has to clear in roughly 100 milliseconds, with single-digit milliseconds budgeted for the bidder's own decision.

Operator-owned mesh. WilDi Maps runs its own application on driver phones in the cities it serves. The phone reports its GPS position directly to WilDi infrastructure — no exchange, no bidder, no SDK rake. When a driver enters a leased corridor, the operator's server selects the matching ad from the corridor's lease and serves it to the operator-owned device. The location signal originates inside the operator's stack instead of being purchased downstream of three intermediaries.

The verification step: GPS to server-confirmed delivery

“Verified” is a load-bearing word in the model. It means the delivery record on the server is only written when the device's reported GPS coordinates fall inside the leased corridor geometry at the moment the ad is rendered. The sequence is mechanical:

1. Driver phone reports position. The operator's app reads the OS-level location service (Core Location on iOS, FusedLocationProvider on Android) at a configured cadence. The fix is A-GPS-assisted with Wi-Fi BSSID and inertial sensor fusion.
2. Corridor membership test. The server runs a point-in-polygon test against the leased corridor geometry. If the point is inside the active corridor, the ad slot is eligible.
3. Ad selection. The advertiser whose lease covers that corridor at that hour wins the slot. There is no auction — leases are fixed-rate, time-boxed, and exclusive.
4. Render and confirm. The ad is rendered on the driver's screen. The server writes a delivery record stamped with the device ID, the GPS fix that authorized it, the corridor ID, and the timestamp.
5. Bill the advertiser. $0.20 is debited from the advertiser's prepaid balance. Only confirmed deliveries bill. No fix in the polygon, no charge.

Privacy and data handling

The privacy posture is structurally different from consumer SDK location collection because the device is operator-owned. The driver opts in once when joining the network — same as a delivery driver opts into a logistics platform — and the GPS stream is used to fulfill the operator's contract, not sold downstream to data brokers.

On the advertiser side, the only signals leaving WilDi infrastructure are aggregate delivery counts and (if the advertiser opts in) attribution joins via the lead-capture pipeline. Individual driver coordinates do not leave the operator's stack, are not joined to consumer identifiers, and are not exposed in the OpenRTB ecosystem.

On the consumer side: there is no consumer side. Drivers are network participants, not targeted users. The model does not require Apple App Tracking Transparency consent for cross-app tracking, because there is no cross-app tracking — the ad is shown on the operator's own surface to an operator-contracted device. iOS ATT governs IDFA access for cross-property advertising; that question doesn't arise here.

For OS-level context, see Apple's App Tracking Transparency documentation and Android's location permissions developer guide. Both frameworks distinguish between app-owned device usage (what WilDi does) and cross-property tracking for advertising (what bid-stream targeting does).

Limitations: urban canyon, indoors, edge cases

The model inherits the same physics every other GPS system inherits. Pretending otherwise would be dishonest.

• Urban canyon multipath. In dense downtown grids, satellite signals reflect off glass towers before reaching the phone. Horizontal error climbs from single-digit meters to 7–13 meters in peer-reviewed iPhone measurements, and 10–20 meters anecdotally in worse blocks. WilDi corridors are sized to absorb this — a corridor isn't a 5-meter line, it's a street-aligned polygon.
• Indoor delivery. GPS effectively does not work indoors. Drivers parked in covered garages, tunnels, or warehouse loading docks will not produce in-corridor fixes during those windows. The model does not pretend to deliver impressions to phones whose GPS is dead.
• Cold start. First fix after a phone reboot or extended power-off can take seconds; A-GPS shortens this dramatically but does not eliminate it. Deliveries during the cold-start window are not counted.
• Spoofing. A bad actor running a mock-location app could try to fake corridor membership. The operator runs server-side anomaly checks against speed, heading consistency, and inertial sensor data; flagged sessions don't bill.
• Coverage geography. A corridor only delivers when a contracted driver is physically inside it. Off-peak hours and low-density geometries deliver fewer impressions per dollar of lease. Pricing is per delivery, not per lease-hour, so the advertiser is never paying for empty corridors.

The CPVD pricing model

Cost Per Verified Delivery (CPVD) is the unit. One delivery = $0.20. A delivery is one ad rendered on one driver phone with one server-confirmed GPS fix inside the leased corridor at the moment of render.

There is no CPM. There is no bid. There is no exchange fee, SSP fee, DSP fee, ad-server fee, or verification-vendor fee. The advertiser sees the same $0.20 the operator earns, because there is no middleman stack between them.

For the full pillar treatment of how this compares to standard programmatic OOH, see Cost Per Verified Delivery. For why the model matters financially, see What is the Middleman Tax?