As sticky as many apps may be - most phones spend a lot of time in pockets. This is very true in some of the sectors we work in - venues, visitor attractions and music and sporting events.
There are some cases where location data may only be required when an app is in use. For example:
However many uses of customer location data are different. Two very common examples are geo-fencing, and business analytics. Almost all location and indoor positioning services will claim to support them.
Background location, or 'always on location' is much more challenging than the foreground only case. Mobile operating systems allow us to do less in background - mostly in order to preserve battery life. Many techniques used for indoor positioning use power hungry sensors. These include accelerometers, gyros and magnetometers. Even if these can be used in background, the battery drain may make it unwise.
For example indoor wayfinding needs very accurate and frequent location updates. So systems built mainly for this purpose tend to use techniques that don’t work well for background data gathering. And therefore don’t work well for geo-fencing or for footfall analytics.
Some techniques just don't work at all for background location. New indoor positioning technologies involving modulating light from special LED fixtures have generated a lot of interest. This may work well for wayfinding, navigation, and contextual search. But it's a non-starter for proximity notifications or footfall analytics.
Some techniques are designed to deliver background location, but for a very patricular use case only. Beacon proximity platforms can easily trigger messages while apps are not in use. But they don’t always provide the data needed for complex context or footfall analytics. We've heard our customers say 'you can't generate heatmaps from beacon data'.
Mobile analytics platforms often collect location data. But frequently this is limited to the location of users during the sessions that are being monitored.
So look carefully at any location solution you might want to use for footfall analytics or for contextual marketing. Does it use techniques that don't work well in background (like light signals, or inertial sensors). Is it designed primarily for foreground use cases like indoor navigation. Is it designed for a very specific function, like gathering app session data, or using beacons to trigger messages. These are signs that the solution might not be optimised for contextual marketing and footfall analytics.
And you need to look carefully. Here’s a real example.
We looked at the website for a well known indoor positioning company. They sell ‘indoor analytics’ to help you ‘understand your customers’. Buried in the documentation they say this. ‘Calculating a position while your app is not visible to the user is currently not possible. Please refer to the standard iBeacon API provided by iOS for such use cases.’.