Back in 2014, a report by Business Insider called beacons the most important retail technology since the mobile credit card reader, and predicted billions in sales to be affected by the technology. Beacons have of course hardly failed as a technology, and are increasingly being used in the commercial world for proximity-based marketing. But the wildly positive predictions about how the technology would take off have not yet been realised, with no killer applications of the technology having emerged.

Both Apple with its ibeacon protocol, and Google, now with its Eddystone protocol, were supposed to help spread beacon usage to the mass market. Yet neither have so far, and we predict that the newer Eddystone protocol will also fail to bring the technology to its potential. To understand why, we need to look at what beacons are, how they work, and exactly what these two protocols do in order to solve the challenges of the technology.

What are beacons?

beacon hardware and ibeacon Beacons are very small, very inexpensive devices, that continuously broadcast out a Low Energy Bluetooth signal. Think of them as tiny little lighthouses, that do nothing more than constantly send out the same tiny data packet again, and again, every few milliseconds. These broadcasts have a range from 0 to 100 meters depending on how you set up your beacon, and can potentially last for years on a simple coin battery.

Beacons were supposed to bring about a proximity-based marketing revolution. Inexpensive, able to broadcast indoors, and communicating in a highly targeted fashion, we were bombarded with examples in the tech press of their possibilities. Imagine walking next to an exhibit in a museum, and getting information about what you are seeing, or walking into a store, and getting a list of all special offers available and the chance to buy right there and then. From football stadiums, to shops and airports, beacons promised a rich world of location sensitive information and possibilities.

The problem is that all of the advantages of beacons come about from the fact that all a beacon broadcasts out is a miniscule data packet, of otherwise meaningless data. If we keep on with the metaphor of the lighthouse, all our lighthouse does is send out a very tiny set of numbers. This on its own is meaningless to a device like a phone or tablet. How do we therefore turn meaningless broadcasts into actual content on a device, and how do we help users know that they are close to a broadcast that interests them?

ibeacon

ibeacon logo

ibeacon is a protocol from Apple developed to make it easier for apps to work alongside beacons. Basically what Apple did was release a set of rules, that said: ‘If you’re going to set up a beacon to broadcast out some data packet, organize this broadcast in the specific way that I’m telling you.’

Apple told us to broadcast data divided into 3 numbers: a ‘UUID’ (a 32 hexadecimal value) and a Major and Minor value (4 bit hexadecimals each). These numbers on their own are still meaningless. But so long as broadcasts sent out were in this structure, Apple would provide app developers with the tools to easily monitor and pick up such broadcasts, and then carry out actions in the apps they developed based on the broadcast received. Not only would developers be able to build applications that responded to beacons, but those same apps could communicate with the operating system itself, allowing a phone or tablet to keep scanning for certain broadcasts, and notifying the user with a custom notification when in range, even when the app was not running.

Manufacturers of beacons quickly adopted the protocol, building beacons designed to broadcast out values structured in the way that Apple suggested. Developers were able to more easily build apps that could respond to these broadcasts. Soon the protocol was supported in Android devices as well. When ibeacon was announced in 2013, we again were bombarded with examples of how a new generation of apps would be feeding us proximity-sensitive information wherever we went.

But ibeacon fails to solve some of the fundamental problems of the technology. A beacon broadcast is still meaningless unless a user has an app on their phone, developed to carry out a specific action when near a specific beacon. If you’re somebody that wants to use beacons, you either have to build your own app, or try to find out some app already out there that uses beacons in the precise way that you want it to act. Here we are, with beacon hardware that is dirt cheap, and in theory could be useful to even the tiniest of corner shops, and yet we have a massive software barrier in order for these beacons to be able to ‘do’ anything useful.

Meanwhile if you are on the receiving end, you have to download tons of individual apps if you want the beacons around you to be meaningful in any way. The problem is even worse if you expect these apps to allow your phone to monitor for beacons in the background – to avoid resource draining, only a small number of broadcasts can be monitored for at any one time. If you have more than a few apps on your phone dealing with beacons, you theoretically need to be disabling and re-enabling each app in turn, depending on what you wanted to scan for at any given time.

What we’ve ended up with is lots of beacon trials and test runs, and lots of different apps using beacons for gimmicky functionality in very specific locations, but no killer application that uses the technology to take the world by storm.

The Physical web and Eddystone

eddystone logo

When Google took a shot at the technology, it came up with a concept known as ‘The Physical Web’. The idea was that devices broadcasting in Low Energy Bluetooth such as beacons would no longer broadcast out a context-less set of numbers, but would instead be broadcasting out a URL that would direct a user to a web location online. These URLs would be visible by a device’s Operating System itself, without the need of an app sitting in between.

Google developed its own protocol called ‘UriBeacon’ that dictated how beacons should send out URLs such that they could be received by Google devices. Imagine we were told, walking next to a vending machine, and being able to click on a link directly on your phone that would take you to the manufacturer’s website. Yet on its own, UriBeacon never took off, nor solved the fundamental problems of beacon technology.

For one thing, you may no longer need to build a mobile app in order to make a beacon useful, but you now need to build a web app or website, that you are able to change whenever you want to broadcast something different, without affecting its URL. For the smallest of locations that might benefit from beacons this is still a problem. If I’m a corner shop and all I want to broadcast is the fact that I’m having a sale on sandwiches for the next couple of hours, having to build a website to do so is a bit over the top. It’s similarly difficult for a department store that wants to deploy a hundreds of  beacons all over its floor-space.

At the same, an advantage of needing to install an app in order to pick up a beacon broadcast, was that my app selection allowed me to determine what I wanted to be monitoring for at any given time. Would making broadcasts discoverable by the operating system itself mean that we would be bombarded by notifications from hundreds of beacons that we don’t care about as we move around our typical day?

Google’s answer is simply that URL broadcasts cannot be monitored for in the background and trigger notifications to a user. The user actively has to take out their phone, go to an area in their notifications list, and there see a list of context-less links to websites that nearby beacons are broadcasting. But this then takes away from one of the biggest advantages that the technology has – the ‘nice surprise’ factor of being notified of something interesting nearby, without having to actively search for it.

To resolve these issues, Google has now come up with a new protocol called ‘Eddystone’. The big difference is that when following the Eddystone protocol, a beacon can broadcast out ‘both’ a URL, ‘and’ a hexadecimal value that an app on the phone can monitor for in the background. Yet it hardly seems to me that this new protocol really solves the riddle of how the potential of beacons can be reached. You still need tons of apps to download, or flexible web sites and web apps for any broadcast you want to send out. The technology is still inaccessible for small locations, and will still lead to a totally segmented ecosystem of gimmicky applications.

Solving the riddle of proximity based communication.

Beacon hardware has become ever cheaper and more accessible. A fact that has missed most people is that most devices nowadays are able both to receive Low Energy Bluetooth broadcasts, but also to send them. We all already have a beacon in our phones without knowing it. The problem still does not remain on the hardware, but on the software that uses the technology. We may all own beacons, but we seem to have found nothing to do with them.

For beacons and proximity-based communication to take off, a solution needs to meet the following criteria:

  • A user should have to download no more than a single app to be able to receive and make sense of the broadcasts of all the potentially millions of beacons around them. Segmenting our world into thousands of tiny beacon networks that are each only useful with its own niche app, is not the way to go if the technology is to be adopted by the masses.
  • At the same time, a user should be able to monitor for background broadcasts and be notified about things that interest them, but be able to have full control over what they’re scanning for. I should be notified about broadcasts regarding things that ‘I’ am interested about, and have everything else ignored.
  • Users should be able to broadcast ‘anything’ from beacons, and be able to change the content broadcast in a matter of seconds. A beacon broadcast should be able to be a simple text message, or a rich message filled with multimedia; it should be able to be a URL, a pointer to a file to download, an opportunity to buy a product… anything at all, and able to be changed at any time required.
  • People cannot be expected to be blind consumers of one-way marketing broadcasts. People are not interested to be spammed with ads as they go about their day. A proximity-based communication solution should allow users to both send, as well as receive broadcasts, and be able to do so in ways that benefit their everyday social life. We can all use our existing phones as broadcasters, and communication at the local level would be useful at the bar, the football stadium, the office, the nightclub, you name it. It is time to take off the blinders that keep us focusing just on the commercial market, and see the bigger picture around this technology.

Meeting these criteria of course does not rely on the broadcasting protocol. They rely on how those protocols are used. That is why ibeacon and Eddystone on their own may not be part of the solution, but they can certainly be the tools that make the solution possible.

photo credit: beacons by jnxyz.education via photopin (license)