London, September 19, 2019
The Truth About Mobile Location Data Accuracy
Is mobile geo-data accurate enough to measure visits to shops and stores?
Much is made of the power of mobile geo-data and its promise to accurately position consumers in space - but is all geo-data equal?
If like many of us you have experienced Google or Apple’s navigation apps, it would be easy to imagine that this is what all mobile geo-data is like - metronomic updates, and precise enough to place you on one side of the street.
It doesn’t take much to imagine the potential of geo-data to measure things like pedestrian traffic patterns and consumer flow dynamics, or the number of customers visiting shops and stores. If only the reality were so simple.
It’s all about power.
As many of us are all too aware, mobile devices have an unfortunate tendency to run down after a day or so - or in some cases just a few hours. Battery life and performance is probably the number one criticism that mobile device and OS vendors face.
Age plays a role; the coding quality and good practices of app software developers also plays a (big) role. King among battery blasters however is location services - particularly of the most accurate and reliable GPS variety.
Have you ever tried running turn by turn directions when you’re phone isn’t plugged in? You’ll be lucky if you can get to the end of the street before your phone runs out of juice.
Location supports important features and aspects of your phone’s utility however and OS vendors want to be able to provide this in a sensible, even-handed way. Ingeniously, a solution to this emerged in the ‘Assisted-GPS’ or ‘A-GPS’ stack.
What is A-GPS?
A-GPS is a hierarchy of tools used to obtain a mobile device location with varying degrees of accuracy, and correspond directly to availability and power consumption. This is very well documented by others, but the principal means incorporates CellID, WiFi and GPS.
Part of iOS’ CoreLocation and Android’s LocationManager frameworks’ job is to balance the needs of location accuracy with power usage and update recency. Often these frameworks will begin with CellID (low power, low accuracy) and traverse through WiFi to GPS (high accuracy, high power) as required.
What determines the accuracy requirement?
Well, if you’re using an app like Google Maps for turn-by-turn navigation, the requirement is clear and importent. Particularly if it’s plugged in, the mobile OS can throw the full might of its resources at the GPS chip and return a good read, ie. sub 5 meters.
But if your interest - as is ours - is to measure consumer behaviour using mobile geo-data, it’s not enough to only access location data for short periods perhaps once a day, or a few times a week. A good dataset will endeavour to provide continuous coverage through time.
This introduces the world of background app activity, and what that means for resource provision - or the lack of it. It stands to reason that if you’re not using a location-enabled app, your use for location at that time is reduced - and the OS relegates the app’s access to device power.
Background location updates are still available in the relevant circumstances, but rather than using full-fat GPS to return location data, it will turn to other - cheaper - means, often served by proximity to cell towers or known WiFi router locations. You can of course request more accurate updates, but no one will thank you for drinking their juice.
So the more daily coverage you seek, the less accurate your location updates will be.
Measuring location accuracy.
Fortunately CoreLocation and LocationManager return a value associated with coordinate pairs that represents the phone’s best estimate of how accurate that location is - in meters. Like all things location it’s not fool-proof, but it provides a pretty good indication.
We took a sample of location points collected in and around Oxford in the UK, rounded their accuracy values to intervals of 10 and counted the number of points submitted across the dataset. The results are contained in the table above.
The largest proportion of points in this sample, 35.8%, were reported by the OS as being accurate to within 70 meters. A whopping 25.3% were accurate to within over a kilometer, and only 23.3% where accurate to within 10 meters. Does that surprise you?
This is why mobile location data alone cannot be used to measure footfall or other store / unit level trends - unless you’re in a superstore larger than a football pitch. The other option is to throw away anything over 10 meters, say, which is nearly 80% of your data.
To highlight this problem, we’ve plotted 100 random points from this sample on the map above using the reported accuracy to define the size of the buffer. In one typical 70m example there are 23 businesses marked in the area, and who knows how many flats, houses or other.
Using mobile geo-data to measure behaviour.
This challenge is based on a set of circumstances that apply to anyone sourcing geo-data from mobile, and so it’s fair to say that problem applies across the geo-data marketplace. It also represents the specific challenge that Huq set out to solve, and it’s that difference that defines our offering.
Interested to learn more? Get in touch with us today.