When Lat/Long Lies: Validating Geo-Signal Quality

A bid request arrives carrying a latitude and longitude, precise to several decimal places. It looks authoritative — a specific point on the earth, apparently identifying exactly where the device is. And it might be a crisp GPS fix from a phone with location services on. Or it might be a coarse IP-based estimate, a Wi-Fi triangulation, or a city centroid that places every device in the metro at the same fake-precise point. The coordinate looks identical in all these cases. Its truth varies enormously.

This is the uncomfortable foundation of hyperlocal advertising: a present coordinate is not an accurate one. Before any platform can honestly promise to reach people inside a fence, it has to answer a question the request itself won't answer — how good is this signal, really? Validating geo-signal quality, per supply source, is the unglamorous work that separates honest hyperlocal from confident fiction.

Why a coordinate's precision is not its accuracy

Precision and accuracy are different things, and geo data is where the difference does the most damage. Precision is how many decimal places a number has. Accuracy is how close it is to the truth. A coordinate given to six decimals (≈10 cm of precision) can be tens of kilometers from the device. The decimals are not lying about the math; they're lying about the certainty, by implying a confidence the underlying signal never had.

The sources behind a coordinate vary wildly:

• GPS — potentially accurate to a handful of metres, when present and fresh.
• Wi-Fi / network — usually good to tens or hundreds of metres.
• IP-based — often city-level, dressed as a point.
• Centroids and defaults — a region's geographic center, assigned to everyone in it.

A platform that treats all of these as equally true will draw a tight fence around a centroid and confidently serve to people who could be anywhere in the city. The lat/long didn't lie, exactly — but trusting it blindly does.

Validate per supply source, before you promise

The discipline is to classify the signal before trusting it, and to do so per supply source, because quality varies systematically by exchange and inventory type. Rather than treating every coordinate as gospel, captured geo-signals are sorted into explicit accuracy bands — in the UPA model: ≤ 50 m, 51–100 m, 101–250 m, and > 250 m. The band, not the raw coordinate, becomes the basis for what the system is willing to promise.

The delivered data carries the fields that make this possible: latitude and longitude, but also a geo accuracy value and a geo criteria identifier — the metadata that lets the system reason about how much to trust each point rather than just where it claims to be. Validation means using that metadata, not ignoring it.

From validation to action: allow, warn, block, downgrade

Classifying the signal is only useful if it changes behavior. In the UPA model, routing and eligibility are enforced with guardrails framed as allow / warn / block, plus auto-downgrade: when the available signal can't support the requested precision tier, the system steps the claim down rather than serving against a promise it can't keep. A request with a >250m signal simply cannot honestly fulfill a micro-fence; the disciplined response is to downgrade the precision claim, warn, or block — not to serve and report "precision targeting" anyway.

This is the operational payoff of validation: the signal's measured quality directly gates what the system is allowed to do with it. Quality assessment isn't a report; it's a control input.

H3: making geo computable

Validation and targeting also need geography to be computable, and raw lat/long pairs are awkward for that. Ad360's feature engineering uses H3, a hexagonal geospatial indexing system, to turn coordinates into grid cells. Indexing locations into H3 cells makes proximity, aggregation, and matching tractable — you can reason about "this cell and its neighbors" instead of doing expensive point math, and you can aggregate signal quality and behavior at a consistent spatial resolution. H3 is the substrate that makes geo features usable at bidding speed and scale.

Quality feeds the proof

Finally, validated quality is not just an internal gate — it becomes evidence. Because the system knows each delivered impression's accuracy band, it can grade and report the precision actually achieved, with confidence levels, in proof packs. Geo-signal validation is therefore the first link in the evidentiary chain: validate the signal, gate the targeting on it, then report honestly what precision the signal supported. Skip the validation and every downstream precision claim is built on sand.

Common misconceptions

• "A coordinate in the request means accurate location." Presence says nothing about accuracy; the source could be GPS or a centroid.
• "More decimal places mean more accuracy." Decimals are precision, not accuracy — they can imply false certainty.
• "Geo quality is the same across exchanges." It varies systematically by supply source; validation must be per source.
• "If the data has lat/long, you can do hyperlocal." Without accuracy metadata and validation, tight fencing is guesswork.
• "Validation slows things down." Indexing (H3) and banding make geo computable and honest at speed.

What good operation looks like

• Classify every signal into accuracy bands before promising any precision.
• Use the accuracy metadata (geo accuracy, criteria) the data provides — don't trust the raw point alone.
• Gate targeting on quality with allow/warn/block and auto-downgrade.
• Index geography (e.g. H3) so quality and targeting are computable at scale.
• Carry quality into reporting so precision claims are graded, not asserted.

Open questions

• Can the industry standardize a geo-accuracy declaration so buyers compare supply sources on the same basis?
• How should validation adapt as device/OS location signals degrade under privacy changes?
• How do you validate accuracy against ground truth rather than trusting the supplied accuracy value itself?

The most dangerous number in a bid request is the one that looks certain and isn't. A lat/long with six decimals and a centroid behind it will happily lead you to draw a fence around nothing. Honest hyperlocal starts one step earlier than the fence: validate the signal, band its accuracy, gate the targeting on it, and only then promise precision — graded by what the data could actually support. When lat/long lies, the system that checked is the one that can be trusted.