Google recently unveiled their bluetooth beacon standard called Eddystone (after the lighthouse), that lets users receive URLs broadcast straight to their phone without needing an app.

It has been viewed as a competitor to Apple’s iBeacon, but how different is it? And how does it work in practice today? Finally, what’s the future for this technology?

Eddystone Primer

Back in September 2014, Google announced their Physical Web initiative, at the time a fairly abstract notion that devices could broadcast URLs and you could Walk up and use anything (TM). Notably, it was accompanied by a GitHub repo and clearly something real was being developed.

Then apparently out of the blue, in July 2015, they announced the Eddystone standard. Simultaneously, the big 3 beacon manufacturers (Estimote, Kontakt.io and Radius Networks) announced support (with many others like Gimbal and Bluecats now on board), making the physical web A Real Thing.

We won’t get too technical in this article, the key thing about Eddystone beacons is that they can broadcast a URL, but they actually transmit three types of information continuously:

  • UID – Unique identification of the beacon comprising namespace and identifier
  • URL
  • TLM – Telemetry information about the beacon, such as battery voltage and temperature.

These are known as frames.

What About iBeacon? (Google vs Apple)

Apple’s iBeacon standard has been around since 2013, and both standards are built on Bluetooth Low Energy. So, from a hardware perspective, devices are very similar. However, the structure of the data transmitted is different, meaning that software on any receiving device must be able to recognise and decode the different frame types being broadcast.

Eddystone’s UID frame is analogous to iBeacon’s single frame type, which includes unique identifiers and a value representing the beacon’s transmission power. See our iBeacon primer for more details.

Importantly, iBeacons cannot transmit URLs – typically the unique ID is used to look up associated information, either held offline in the receiving app, or retrieved from the web. A mobile app is therefore absolutely required, since the unique IDs contain no intrinsic information.

Current Support

Google ensured you could buy Eddystone beacons from Day One by partnering with hardware vendors, however software support was conspicuous by its absence. The supporting software is being developed in the open, and is available on GitHub, for Android and iOS. Anyone can develop their own Eddystone app now, but curiously the only app currently offering support for real-world deployments is the latest version of Google’s Chrome browser on iOS.

Yes, you read that right – Eddystone is not yet supported in Android or in the Android version of Chrome! We’ll show how it looks to iOS users below, but first of all – how do you get your URLs onto your beacons?

Configuring Eddystone Beacons

Typically, beacon vendors will offer a management system when you purchase their hardware. This lets you configure basic settings of your beacons, and may offer extended features such as associating content or data with beacons, to be retrieved via an API using the beacon’s unique ID.

The picture shows Kontakt.io’s management interface for Eddystone beacons – you can specify a URL, but it must not exceed 18 bytes once encoded. The Eddystone standard includes a scheme for compressing URLs to make them a bit more compact, but in practice shortened URLs are likely to be used.

The information held by the vendor about the beacon then needs to be synced with the device, for example by using a management app when in the vicinity of the beacon. This will retrieve the URL and other beacon data online from the vendor and write it to the beacon over bluetooth.

The User Experience

Now that you have your URL on an Eddystone beacon, the only way to currently make use of it is with the latest version of Chrome on iOS. Any app can access the Bluetooth system and therefore monitor for in-range beacons, including Eddystone beacons, even in the background. Typically notifications are used to alert users about the presence of beacons. Chrome uses the Today area in iOS – users are not intrusively prompted, but if Eddystone beacons are present when they view the Today area, Chrome will display information about them.

Clicking on the notification opens the URL in Chrome.

What Does This All Mean

Optimistically, this means that Eddystone applications can be deployed now, albeit within limited parameters. Users must have an iOS device with Chrome installed, and be aware of the deployment so that they will check their notifications for contextual information when in range.

As an example, in a retail context, Eddystone beacons could be configured with URLs showing product details, specs, reviews, as well as options that may not be available in-store such as additional colours, sizes and so on. If users were aware that they could do so, they would simply check their mobile device for the availability of this information if they wanted to find out more about a product.

Of course, retailers and other organisations could also build Eddystone into their existing apps and alert users with more intrusive notifications. However, Eddystone provides little benefit here since a connected app could use the unique IDs of an iBeacon in the same way (to direct a user to information online).

It could be that such contextual location-specific information becomes so commonplace that checking your device for it becomes second nature, but that’s going to require more widespread support.

Future Development

We can see that it’s early days for this technology, so how will it develop in future?

The ability to broadcast a URL to a mobile device only really becomes useful when it’s either a) supported by every browser as a standard – but then, which one gives you the notification? or b) Supported in the underlying operating system.

We think that Google must be embedding Eddystone and physical web support in Android, but there’s no sign of it coming soon. The next version of Android (Marshmallow) was announced recently and is released in a few days, but no such support has been mentioned so far.

So why is this? It’s likely due to consumer concerns over privacy, and nervousness over the prospect of mobile users being bombarded with notifications they never asked for (Minority Report style). Android needs a way to surface these types of notifications that consumers feel they have control over – for example location- and/or time-based opt-in. This means you could turn notifications on or off for specific stores or malls, or perhaps turn them on at the weekend but off during work hours. Another possibility could be controlling permissions by domain of the URL being broadcast.

<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/7bXJ_obaiYQ” frameborder=”0″ allowfullscreen></iframe>

This is closely aligned to the concept of Web Notifications. These are not that widely used yet but, for example, eBay and Facebook can alert you in certain browsers about activity of interest, after obtaining your consent. Importantly, notifications can be shown even if you don’t have your browser open.

All of the major desktop browsers (apart from IE) support web notifications, and support was recently added to Chrome on Android (but not iOS), with the stock Android browser offering partial support.

The picture isn’t quite complete, but we can see where this is going – if you’ve consented to receive web notifications from a site, and you are in the vicinity of an Eddystone beacon broadcasting a URL for that site, Chrome could alert you with a notification, even if it wasn’t currently running.

This enables a purely web-based system of location-awareness together with notifications and contextual content delivery on your mobile, with no requirement for an app other than your web browser. We can imagine that on opening one Eddystone-delivered URL, further beacons in the same venue will simply modify the already-open content, providing a potentially app-like experience for indoor navigation (for example).

However, after introducing iBeacon and doing a lot to promote adoption, Apple is notable by its absence in supporting this pure-web future. That’s probably because Apple Hates the Web, a topic that we’ll be writing more on soon 🙂

iBeacon