In a previous blog, we published the results from our online survey, where respondents explained under what circumstances they would enable location services and why they deny the access in the first place. In part two, we are comparing this with real data, which indicates how many people actually use location services in the real world.
Hardly any enterprises, agencies or location service providers have published reliable and statistically significant data about the actual use of location services and Bluetooth low energy (BLE) for beacons. We decided to have a look ourselves and took a sample of one million devices  with our location management SDK installed. Specifically, we looked at four different apps with our SDK in it as per the table below.
|Industry (UK only)||Location enabled use case|
|Food delivery app||Location triggered offers|
|Luxury car brand app||VIP check-ins at onsite arrival|
|Retailer app||Click & Collect remote check-in|
|Public event app||Reminder to use the app on site|
Overall sample size: one million unique device IDs (app installs)
For the purpose of this paper, we analysed the operating system and the app settings, with a specific focus on location services and Bluetooth activation.
Why did we take a sample size of a million? Well, apart from it being a nice round number, we wanted the sample to be statistically significant. And it is also pretty much the upper limit of what my late 2013 MacBook Pro can cope with using Excel without crashing…
Here is what we found.
Let’s start with the generic stuff. From the one million devices in our sample, 76.6% were running IOS and 23.4% Android. This ratio is reflective of what we see in our total population of SDK installs .
From the total number of devices, 90.1% had location services enabled at the device level. This is Step 2 of the funnel and means that almost ten percent of all devices in our sample either did not have any location capabilities, or location services had been manually disabled by the user.
When we look at IOS and Android numbers individually, we see a fairly large difference:
In other words, IOS users seem to be more inclined to enable location services at the device level than Android users. We believe the reason behind this is the (historically) different way that Android apps ask for permissions – all app permissions are requested as part of one install screen that only provides an ‘Install’ or ‘Cancel’ button. On IOS, access to location services is requested specifically as part of the install and therefore a lot easier to deny for an app. This leaves Android users that want to use an app, but do not want to give it access to location services, no other option than to switch off location services at the device level .
Next, we consider the percentage of device users that have authorised the app for background location services - step 5 of the funnel. The overall percentage is 58.3% and the breakdown per device type is:
The reason for Android numbers being so much higher than IOS ones is likely again the result of the more coarse-grained permission model on Android . Additionally, after a few days, IOS reminds users that an app still has background access to location services. This makes IOS users more likely to disable location services for the app after a few days.
When both settings are combined, that is: location services enabled for the device AND location services authorised for the app, the overall percentage is 51.5%. This means that for more than half of the devices, the app has access to location information and can be triggered in the background – primarily via GPS and geofences.
The breakdown per device type is as follows:
Finally, we will consider BLE usage – the final step 6 of the funnel. The overall percentage of devices that have BLE enabled is 27.8%. The breakdown per device type looks like this:
This percentage of BLE usage is a lot lower than we expected. Especially considering the increase in BLE enabled wearables, such as watches and fitness trackers.
When we combine all steps, the funnel leaves a meagre 15.2% of the total sample population that can be targeted by beacons. Across the two platforms, it looks as follows:
The table below provides an overview of all the numbers we covered in the sections above.
|Percentage of sample||Location enabled||Location authorised||Location enabled & authorised||BLE enabled||All|
So there you have it. The answer to the question: ‘How many people have location services enabled and Bluetooth on?’- about half and fifteen percent respectively.
However, in Part Three, we are going to show you how these numbers can be significantly improved. We are going to share our insight in what apps should include in order to attract users to enable location services and Bluetooth, in particular.
The author of this blog is Martijn Verbree, Director of Europe at Localz.
 The sample consisted of one million app installs (device IDs) that all requested permission for background location services for the app at install. Only device IDs that have shown user activity in the last month have been included in the sample.
 Why IOS is about four times higher than Android is going to be a topic for a future publication
 The app permission model for Android has become much more granular in version 6, which was released in October 2015. When we look at the almost 65 thousand Android 6 devices in our sample, the percentage of devices that have location services enabled at the device level is 77.7%, which is indeed materially higher than the 70.1% for the total Android sample.
 The percentage of Android 6 devices that have location services authorised for the app is indeed lower than for the entire Android population – 85.2% versus 95.9%.
 This is indeed the same percentage that we reported for location services enabled for the device. This is because IOS removes the location services authorisation for the apps when it is disabled at the device level.