Geo Data From QR Scans: What You Can and Can't Infer

Every QR platform that reports a scan's location, MyQRx included, is reporting an inference, not a measurement. Nothing about scanning a printed code transmits GPS coordinates to the platform; what actually happens is that the scanning device's IP address is looked up against a database that maps IP ranges to approximate geographic locations, and that lookup is where every limitation in this post comes from.

How the location behind a scan is actually derived

An IP address belongs to a network, not a device, and the location a geolocation lookup returns is the network's registered or observed location, which is usually close to correct on a fixed broadband connection and considerably less reliable on a mobile one. Independently published geolocation accuracy figures put city-level accuracy for IP-based lookups in a wide range, commonly cited around 20 to 75%, against country-level accuracy above 99%. That gap between country-level and city-level confidence is the single most important number in this entire topic: knowing which country a scan came from is close to reliable; knowing which city, and especially which part of a city, is meaningfully less so.

Mobile networks make this worse for a structural reason, not a sloppy one. Carriers serve large numbers of subscribers through a comparatively small pool of public IP addresses, reassigning a given address between different devices as connections open and close throughout the day. A geolocation database built to track which address maps to which location can lag that reassignment, so a scan attributed to one part of a city might genuinely have come from a device on the other side of it, simply because the address it was using had just been handed to a different subscriber than the database last recorded. This is normal, well-understood behaviour in mobile networks generally, not a flaw specific to any one platform's lookup.

What marketing claims often get wrong about this

It's common for QR and link-tracking marketing pages to describe location reporting in a way that implies far more precision than IP-based geolocation can actually deliver, phrases suggesting pinpoint or exact positioning without qualifying what "location" means underneath. None of that changes the underlying mechanism: if the data comes from an IP address lookup rather than a GPS reading taken with the scanning device's consent, the accuracy ceiling described above applies regardless of how the reporting dashboard visualises it. A map with a precise-looking pin on it is still built from a city-level or worse estimate; the pin's apparent precision is a design choice, not evidence of better underlying data.

Accuracy by connection type

Most QR scans happen on mobile data, which puts the second row of this table in the middle of nearly every real campaign's geography numbers, not as an edge case.

What this means for in-store and aisle-level questions

No amount of refinement to an IP-based lookup will answer "which aisle did this scan happen in" or "was this scanned inside the shop or on the pavement outside it." That level of precision simply isn't in the data an IP address carries, and any tool implying otherwise is overstating what IP geolocation can do. The only dependable way to get placement-level location data is structural, not analytical: put a separate QR code on each physical spot worth distinguishing, a shelf-edge display, a checkout counter, a window display, so that the code itself, not an inferred location, tells you exactly where that scan happened. QR placement across a physical retail floor depends on exactly this discipline, because zone-level attribution only exists when each zone carries its own code.

A per-code view, not a merged map

Geography reporting on a QR platform is naturally a per-code view: each code's own scans, broken down by where they were estimated to originate. It isn't a merged, campaign-wide map layering every code in a promotion onto one visualisation, and that distinction matters for the same reason total and unique scans matter separately for each code rather than blended across a campaign: merging locations across several codes hides exactly the placement-level comparison a marketer usually wants from geography data in the first place. Reading each code's geography individually, then comparing those readings side by side yourself, gives you the placement-level insight a single rolled-up view would actually obscure.

What geography data is genuinely good for

None of this makes location data useless, and dismissing it entirely would be its own kind of overcorrection. City-level, aggregated geography is well suited to a narrower set of questions than street-level precision would answer, and those questions are still valuable ones. A regional campaign can sanity-check whether scan activity is actually concentrated where the campaign ran, or whether an unexpectedly wide geographic spread suggests a print run travelled further than planned, a code was shared online outside its intended audience, or a placement drew attention from a different area than expected. None of that requires precision below the city level to be useful; it requires being read as a directional signal, not a verified fact about any one visitor.

The privacy position underneath the accuracy question

Location data of any granularity carries a privacy dimension worth stating plainly alongside the accuracy one. Reporting stays at the aggregate, city-level view rather than attempting to resolve individual visitors to a precise point, which is both a technical limit of IP-based geolocation and a deliberate posture: the data retained is what a marketer needs to read a regional pattern, not what would be needed to track an individual's movements. Retention is time-bound with automatic purge rather than indefinite, and what's deliberately not collected matters as much as what is: no GPS coordinates are requested from the scanning device, no location permission prompt is shown to the person scanning, and no attempt is made to resolve a scan to more precise than the geolocation lookup naturally supports.

This distinction, between what's technically possible to collect and what's actually collected, is worth being explicit about, because the two aren't the same question. A QR platform could, in principle, request device GPS permission and collect precise coordinates on every scan; that would solve the accuracy problem this whole post describes, and it would also mean collecting a much more sensitive kind of data than city-level geography ever represents. Sticking with IP-derived, aggregate location is a trade-off made in favour of the less invasive option, not a limitation nobody noticed. Our privacy commitments and our broader data retention and trust position set out what is and isn't collected in full, alongside how retention and purge sit against India's DPDP framework specifically.

What this means for your next campaign

Expect city-level accuracy at best from any QR platform's geography report, and expect it to degrade further on mobile-heavy traffic, which is most QR traffic. Use it to catch broad surprises, unexpected regional spread, an anomaly worth a closer look, rather than to answer a question that needs street-level or aisle-level precision. Where that level of precision genuinely matters to a campaign, solve it structurally with a distinct code per physical location rather than expecting a geolocation method to deliver something it was never built to provide. This same honesty about what a number can and can't tell you belongs across every metric in the full analytics picture, not only the location one, since overstating any single metric's precision is what erodes trust in a report faster than an honest limitation ever would.

Read our data retention and privacy position