Proximity and the Beacosystem pt. 2
In the first of this series, I covered some of the basics behind Proximity, Bluetooth Low Energy and iBeacon, and walked through some use cases where Proximity and iBeacon have started showing up in retail, travel and other industry applications.
While iBeacon has arguably galvanised the whole notion of using Proximity in applications and services, it’s not the only game in town.
In this post, we’ll cover one of the alternatives to Apple’s iBeacon, Physical Web from Google, and then we’ll zoom out to look at the flurry of activity in startups in the evolving “Beacosystem”. Note that, Google’s major update to Physcial Web and all things proximity-related, Eddystone, will be covered in a later post.
Creating an Ecosystem
As I mentioned, Apple’s iBeacon is a layer, or a “convention” that builds on the Bluetooth Low Energy (BLE) Standard. Apple has spurred an ecosystem around iBeacon by doing several things, which all feed in to each other:
- Baked support for iBeacon in to its mobile operating system (iOS) so that APIs are readily available for developers.
- Included support for background notifcations at the OS level, so that push notifications can be triggered in certain situations, but without killing your phone’s battery.
- Provided a certification programme to enable hardware manufacturers to create iBeacon compatible hardware. This allows third party manufacturers to provide iBeacon compatible hardware of all shapes, sizes and form factors, At last count, there were over 50 suppliers of iBeacon hardware that we counted.
- Enabled every iOS device to *be* an iBeacon. This has many potential uses, from iPad based POS systems welcoming you to a store <link>, to the Hailo App letting you know that you can pay by Hailo <link>.
- Ate its own dog food, by using iBeacon with their Apple Store App in all their US based Apple Stores. <link>
Taken together, the Apple hardware and software platform is pretty well set up to drive and support a wide range of proximity experiences. So, where do Google and Android fit in the picture?
iBeacon : not the only game in town
Google has taken a different approach to Proximity, which in its own way, may end up having as great an impact as iBeacon. In October 2014, Google launched a project called Google Physical Web <link: https://google.github.io/physical-web/>, with a simple and short web page that described it, and a link to the technical details on Github. They positioned it as “interaction on demand”. The project has the tagline: “walk up and use anything”.
A few things distinguish Google’s approach from Apple’s, so far:
- It’s a Google Project right now, not a Google product
- It’s an open source project, hosted at GitHub, so “everyone can contribute”
- It aspires to be an open standard, not controlled by a single company
- It’s web-centric — where iBeacon advertises UUIDs and Major/Minor codes to devices nearby, instead Physical Web Beacons send URLs
- It’s not intended to proactively alert or notify the user (so no ad-hoc alerts, and no background scanning when the phone is in your pocket)
What Physical Web has in common with iBeacon is that it too, uses BLE to send (advertise) URLs to “whoever is interested” nearby. The use of the URL ties the approach to Google’s native home turf of “the Web” — and also provides a easy hook for everyone to understand the concept: what if physical things could send out an URL to tell you all about themselves?
In the documents describing the Physical Web <link: https://github.com/google/physical-web>, Google takes aim at some of the potential issues with iBeacon, including the emphasis on being open as opposed to being controlled by one company, and not being “interrupt” driven.
Instead the user “pulls” information only when they go looking for it, and the system reacts by offering information about whatever “things nearby” support physical web.
How Google Physical Web works
As with iBeacon, at the core of Physical Web, is a BLE Beacon that advertises a URL. The URL is encoded in a particular way and is sent in the advertising packet transmitted by the Beacon. Google specifies the formatting (link: https://github.com/google/uribeacon) and they refer to a Beacon that complies with the required formatting as a “UriBeacon” (pronounced YUR-ee-BEE-kun).
Right now, the client that detects the URL advertised by a UriBeacon is an application that runs on one or more devices (there are several clients available, on Android, iOS and other platforms). The client app lists the nearby UriBeacons that it can “see”, and displays associated information (title, description, URL, etc.). The user can tap on the URL to “follow” that URL to its destination. The URL may lead to a simple web page (with some basic information or content), an interactive web site (perhaps with controls for the device in question), or a deep link in to mobile application. The use of the URL gives the system some of its most interesting potential, as it provides a simple but flexible way of “jumping off” to any given endpoint on the web. Simple, but powerful.
A number of companies now sell ready-to-run UriBeacons, that comply to the Physical Web UriBeacon specification. These include Blesh, Accent Systems, KST and others. In addition, those looking for lower level control over their own UriBeacons can flash their own firmware for a variety of popular hardware devices, such as Arduino and Raspberry Pi.
Up next for Physical Web
Google did not rush in to the Proximity party. Physical web first appeared as a public project in September 2014, around 15 months after the first mention of iBeacon appeared from Apple at their WWDC conference, and today it remains a project, as opposed to a product with widespread support across the deployed Google ecosystem. However, it seems likely that this will change, and we may see new developments around Physical Web at their upcoming Google I/O conference in May. Google has the potential to “switch on” support for Physical Web in their mobile products, such as Android and their mobile browser variants. There are many industries and verticals very interested in an “app-free” proximity solution, and with Physical Web, Google has an option to deliver a solution at scale, albeit only on its own mobile platform.
Aside from Apple and Google, the only other significant player to emerge with an offering is Samsung, who launched Samsung Proximity (link: http://developer.samsung.com/samsung-placedge) in November 2014. They wrapped up the proximity services in a branded platform called Placedge, which, like both Apple and Google, used BLE Beacons to enable proximity powered applications and services.
In this case, Samsung was proposing to require no app, and instead would bake support for proximity in to their own suite of mobile hardware and software products. However, after initial launch at the end of 2014, not much has been heard in terms of real product rollout since, and the contact details listed at their website now bounce. There’s also a notice stating that Placedge SDK will not be distributed in public any more. So we’ll assume that’s dead for now.
The Beacosystem: Startups, movers, and shakers
Since 2009, when we first developed our proximity platform LocalSocial, we have been tracking companies of different kinds who were working in the same “space” — either adjacent to us, complementary in terms of offerings (so we could perhaps partner), or directly competitive. Back in the early days, the competitors were thin on the ground. It was us, and perhaps three other companies.
Today, depending on how you define the same “space,” there are around 150 or more companies offering some element of proximity to the market: hardware, SDK, platform, or some combination of all of these, wrapped into a generic or vertical solution. To help make some sense of this explosion in companies, we began to chart them in our own “Lumascape” picture, and share them online for feedback. We called the picture with its accompanying analysis the “Beacosystem”:
We grouped the companies into the following broad categories, some of which overlap in various ways:
- Hardware: this includes any of the companies that manufacture beacon hardware, including Estimote, Kontakt, Radius, Gimbal, and others. Some of the hardware manufacturers focus only on hardware, while others are building out broader offerings that include Developer SDKs, Cloud-based Content Management Systems (CMS), Analytics, and more.
- Indoor location: A number of companies are using BLE and iBeacons primarily as part of an indoor location platform solution: a “GPS for Indoor use.” They use a mix of technology, including beacons, to do this. Indoors, Meridian/Aruba, and ByteLight are examples of companies using beacons as an element of their solution for delivering indoor location solutions to various verticals.
- Shopper/retail-centric: Retail has, to some extent, dominated the initial period of coverage about beacon technology and iBeacon, and that’s reflected in the number of companies positioning themselves specifically as solutions for retail or shopper marketing. ShopKick was a genuine pioneer in this area, and companies such as Aisle411, InMarket, Swirl, and ShopperTrak have all built out offerings tuned to the needs of retailers and brands.
- Mobile marketing: A number of companies are using beacons as signals that can be used within a broader mobile marketing platform. Urban Airship, the “daddy of push notifications” was early to the fray here, but has been joined by Swrve, Localytics, and others in this quickly expanding space.
- Proximity platforms: Some companies (ours included) offer a more general-purpose proximity platform, not tied to a specific vertical, and often open via APIs to work with various other players in the ecosystem. Radius, IOT, MOCA, and others all have offerings that comprise software, APIs, and devkits that let third parties build whatever proximity-enabled application or service that interests them.
I regularly update our picture of the Beacosystem, as the area continues to evolve rapidly. A great resource to track the Beacosystem is the Unacast Prox Network — which aims to collect together a universal directory of all the companies in the space.
In later posts in this series, I’ll look at some of the issues in using and deploying beacon-based solutions, some of the trends in both hardware and software offerings, and share some resources where you can find more detail on everything I’ve covered so far.