Earlier this week I spent an interesting couple of hours at the C4DI Beta in Hull discussing Bluetooth beacons. We were brainstorming ideas to showcase the City Engine, C4DI’s open data project that we’re running in partnership with Hull City Council. Support for geolocation data is fundamental to the City Engine, so it seemed obvious that Bluetooth beacon technology had the potential to be a killer app to demonstrate the City Engine’s capabilities.
As well as the usual suspects from the City Engine developer team, we were fortunate enough to have along Matt Dass and Nathan Hunt from Eon Visual Media who have been working with Bluetooth beacons for the last year or so. They were kind enough to talk frankly about their experiences with iBeacon technology in the real world. This gave us a valuable insight into the practicalities of their deployment. They also brought along some examples of beacon hardware including the futuristic looking Estimote, the Kontact and the distinctive cat-shaped Bluecats.
I’ve already discussed how Bluetooth beacons, or iBeacons, interact with smartphone in an earlier post on proximity marketing, so I won’t break it down again here.
Although Bluetooth beacon systems are visible to smartphones and other Bluetooth devices, they are not open. And the apps and cloud services that harvest smartphone data in conjunction with beacon activity are proprietary. If this data was exposed through the City Engine API then it could be used to present metrics based on footfall in different areas of the city centre. But the availability of the data would be dependent on its ownership and this kind of stuff is commercially valuable.
Even if there was a single, publicly-owned and open beacon network that provided coverage across Hull city centre, those beacons are only reference points. It is the apps using the network that generate the data and there is no guarantee that developers would release this back to the public domain. And the practicalities of deploying and maintaining such a comprehensive network of devices are daunting to say the least.
And what would be the point? Apps don’t need a Bluetooth beacon to tell them where they are. Smartphones already have GPS functionality built-in and apps have access to this via location services. Developers can use geo-fences in their apps to trigger events based on the device location. There doesn’t appear to be any justification for having a city-wide beacon network.
How can iBeacons add value?
Bluetooth beacon technology comes into its own in locations where GPS coverage is poor or non-existent, which brings us back to indoor positioning systems. But its application needn’t be as prosaic as navigating around a shopping centre. After all, good signage is probably cheaper and more accessible.
Beacons could really come into their own in driving contextual applications in places like the Deep or Hull’s Muesum Quarter. Not only can this enrich the visitor experience, but the metrics provided by visitor interaction with the apps can be invaluable.
Does it fit?
So how does all this fit with the City Engine? Bluetooth beacons are undoubtedly a very cool and interesting technology. But in the context of Hull’s open data and the City Engine there isn’t really a clear use case. The conclusion we came to was that we were looking at a solution without a problem.
In the event, what started out as a City Engine hack day around an exciting, emerging technology became a pragmatic exploration of feasibility. The outcome wasn’t quite what we expected, but worthwhile nevertheless.
And it was great to meet the chaps from Eon too!