Editor’s note: This is the first post in a series looking at beacon technology and the burgeoning beacon ecosystem.
Apple galvanized the whole area of proximity-enabled applications and services when it launched iBeacon at WWDC in June 2013. When iOS7 launched later that year, it was the first time support for a variety of proximity use cases was both designed in — and available at scale in — a mobile platform.
Since then, hundreds of companies have become involved in different ways in the iBeacon ecosystem — what I call the “Beacosystem.” These companies are making beacon hardware, offering proximity/iBeacon software platforms, creating shopper marketing platforms, using beacons to deliver signals for location analytics and mobile marketing solutions, powering indoor location services, and more.
This post introduces proximity and iBeacon, covers some background on how it works, and explains why there is some excitement and hype around the uses of proximity in various verticals, including retail.
Proximity and Bluetooth Low Energy
Proximity is all about nearness: knowing that someone or something is near to something else. In particular, when we focus on mobile devices like phones, there are a number of ways to figure out if a device is near to something else of interest. A key approach is to use a type of short-range beacon as a “proximity signal” — the mobile device detects a beacon of some kind, and then looks up information about that beacon in some local or online store.
The Bluetooth Low Energy (BLE) standard, which was designed from scratch to enable fast, efficient use cases for Bluetooth in the world of sensors and the Internet of Things (IoT), has built-in support for proximity.
Using BLE, manufacturers can make beacons that can run for years on batteries (and so don’t require a fixed power source) and can be detected by most of today’s mobile platforms without requiring the overhead of a real connection to be formed (so they’re fast to connect and, therefore, efficient in conserving time and battery). This, combined with the broad adoption of BLE in all major categories of mobile device (phone, tablet, laptop), paves the way for mass-market use cases of proximity.
Who owns BLE?
There’s a value chain around BLE that includes the Bluetooth Special Interest Group (SIG), BLE Chip manufacturers, beacon providers, and product manufacturers.
Bluetooth SIG publishes and manages the Bluetooth standard, which includes the standard for BLE. Companies can join the SIG and engage in a process that allows them to create chips that implement the Bluetooth Specification in their products, including BLE. Companies that make BLE chips include Cambridge Silicon Radio, Texas Instruments, Broadcom, Nordic, Bluegiga, and Gimbal.
In turn, other companies incorporate these chips in to their products. Most of the major beacon manufacturers use one of the chips from the manufacturers above to power the core of their beacons.
A wide variety of hardware manufacturers are now making standalone beacons, or embedding beacons into other products, such as wearable devices, lightbulbs, cars, and so on.
How do BLE beacons work?
At its simplest, a beacon is set to transmit a tiny parcel of information some number of times per second, so that any suitably equipped device nearby (such as a phone) can detect it. The beacon’s repetitive transmission is referred to as “advertising,” and there is a structure for the data that must be transmitted, which is defined in the BLE standard. An application on a mobile device can then detect this parcel of information, unpack it, and use it in whatever way it likes.
Beacons are used by placing them anywhere where you might wish to either trigger some form of action in a mobile application, or have that application log the fact that it came near to the beacon (analogous to a website “seeing” a cookie on your computer and recording that you visited). The classic example that’s always used is about shopping.
Typical use cases: Beacons to trigger greetings, contextual offers, or rewards. Image courtesy of LocalSocial.
Apple, BLE, and iBeacon
So far, we’ve discussed BLE. So, where do Apple and iBeacon fit in? With iBeacon, Apple built on top of the standard and layered some conventions over BLE.
From a hardware perspective, in order to be an iBeacon, a BLE beacon must advertise at a specific interval (100ms, or 10 times per second) and abide by certain restrictions regarding connections (it advertises only, so it cannot support full connections). It also provides some further structure about the data that is transmitted by the beacon (see below).
Manufacturers are free to build BLE beacons that comply with the Apple iBeacon conventions, subject to agreeing to some specific terms with Apple.
On the software side, Apple extended their location services within iOS, in two ways:
- Alerts: an iOS application can get a notification (from the operating system) when approaching or departing an iBeacon. It can receive this notification when not running.
- Ranging: an application can also be told, roughly, how far away it is from a given iBeacon, its “range.”
The upshot is that applications on iOS can now be made “iBeacon aware” — and Apple lends a helping hand by baking in some OS-level support to make that relatively simple to do. A developer can now think about interesting new options for their application to use beacons, most of which boil down to variants on the following:
If the user is this close to this Beacon, then do this.
Turns out, there’s a lot you can do with that pattern, which we will return to later.
Since Apple launched details around its iBeacon conventions and APIs, there has been a slew of manufacturers who’ve released iBeacon hardware and software. There’s a great report from AisleLabs covering many of the top standalone iBeacon manufacturers.
Image by Aislelabs, used under a Creative Commons Attribution 4.0 International License.
iBeacon in more detail
Apple mandates that the tiny parcel of information transmitted by an iBeacon contains some key things:
- A proximity universally unique identifier (UUID) (16 Bytes)
- A major and minor code (each 2 Bytes)
A proximity UUID is often used to identify a common group of iBeacons. For example, a museum might choose to use a specific UUID on all the beacons it deploys in its exhibition areas.
Major and minor codes are then often used to uniquely associate a beacon with a given location or area within a physical space.
On iOS (we’ll return to Android later), a given application can monitor (scan for) up to 20 proximity UUIDs. This means an application can register to be notified if a Beacon with a given UUID comes within range (or goes out of range) of the device.
The major and minor codes can then be used to uniquely identify a given beacon. For example, a retailer might use the major and minor code to identify, respectively, a given retail store and a specific display stand where a beacon will be placed.
The application can then use this data, often in tandem with a cloud service, to decide what action to take, if any, when the beacon is detected.
iBeacon range
A rule of thumb for beacon range is anywhere up to around 10 meters or 30 feet. However, manufacturers can offer an option to vary this, by varying the transmit power of the beacon, and therefore varying the range of the radio signal. We’ve seen beacons with ranges up to 100 meters, but this is not typical. It’s best to assume that an off-the-shelf beacon has a range of around 30 feet.
In software, Apple helps identify how far you (the device) is from a beacon. When reporting this back to an app, it divides the distances of an iBeacon into four “chunks” of nearness: immediate, near, far and unknown. Note that these distances don’t have a specific meaning in feet or meters. Instead, they are relative — a beacon that is immediate is nearer than one that is near. The exact distance will depend on the signal strength of the radio, and some other calibrations. As a result, it’s best to use these carefully when thinking about how and when to use the range in applications and services. As a rule of thumb, we think about immediate being anything up to 2–3 feet, near being 3–10 feet, and far being around 10–20 feet. Unknown is then just that — something more than roughly 20 feet.
What are beacons used for?
At LocalSocial, we’ve helped customers deploy beacons used in a variety of scenarios, and across many different verticals. Before looking at some specific examples, let’s revisit what I said above about the common pattern for using proximity and beacons:
If the user is this close to this beacon, then do this.
The key to how we think about beacons is to think of them as one contextual signal (among many others) that we can use to help us understand a user’s context.
For example, we can tell that someone has arrived in a specific area, that they have stayed for a particular amount of time in that area, or that they recently left that area. Depending on the scenario, the first signal (arrived) might be a good point to send a greeting or welcome message, the second may be just a piece of data we choose to log to build a picture of dwell times, and the last might be a good time to ask for some feedback.
With our retail customers, we often use the analogy of eCommerce — think of beacons as helping to surface eCommerce-style data for real-world stores. Who visited? How long did they stay? When were they last here? What parts of the store did they visit? Beacons can help answer these questions by surfacing that data for real-world spaces, making it actionable. And there are many industries and verticals where this sort of data is incredibly useful.
iBeacon use cases: the story so far
A number of verticals have been quick out of the blocks to trial or deploy iBeacons in their consumer offerings. Here’s a sample of some real use cases:
- Travel: Virgin, EasyJet and American Airlines have used beacons to remind passengers to open their electronic boarding cards, trigger offers, and present content relevant to where they are in the airport. Indeed, industry body SITA is providing a common registry in order to harmonize beacon-related experiences for airport travelers.
- Conferences: A lot of conferences now come “beaconized” so that a range of value-add services and content can be enabled for delegates. Greetings on arrival, automatic badge printing, providing contextual information about nearby exhibitors and products, and power-networking (“who’s in the room”) are all features that have been either deployed (Fujitsu, World Smart Week) or trialled. This year’s SXSW featured 1,000 beacons working in tandem with the official SXSW Go App to enable some of the above.
- Tourism: Museums, exhibits, and all sorts of tourist destinations are rapidly adopting beacons so they can surface digital information for visitors based on where they’re standing. Philips Museum, Rubens House, and the Brooklyn Museum have very interesting deployments. Even Elvis has gotten in on the act.
- High value items: In real estate, there are beaconized show houses to help real estate agents surface data about dwell times and visit behavior so they can prioritize which of their visitors to attend to post-launch. Beacons have also been added to cars so that “each car can tell you about itself” as visitors wander the car showroom or outside lot. And there is much potential for jewelry and other high-value products. Whenever something is behind glass, there’s a great opportunity to magically pull digital information at a visitor’s fingertips without them having to ask for cabinets to be opened.
- Retail: And of course, the dominant conversation on iBeacons to date has been in retail: a shopper can be greeted on arrival at a store, be alerted to offers relevant to where they are in real time as they move through the aisles (“Pasta offers in the pasta aisle”), and much more. There are a lot of opportunities to either remove friction or enhance the in-store experience. Recent examples include Sephora; ShopKick; and Sponda, with their “physical cookie.”
Savills beaconized show houses to provide a friction-free guide and to get critical dwell data. Image courtesy of LocalSocial.
I’ve omitted high-profile examples in sports (stadiums) and in finance (banking), but you get the idea: anywhere where a contextual signal of “nearness” might be useful, iBeacons have the potential to appear.
In all of the cases above, the beacons provide a way to elicit a tiny nugget of context (this user is currently this close to this thing) in real time, which an app, perhaps with some help from the cloud, can choose to act on in some way.
How are these solutions built?
Most of the above solutions work to a common pattern. In a follow-on post in this series, we’ll talk about some of the other approaches, but most have the following elements in common:
- Place beacons around some physical space — store, museum, conference.
- Set up information online (in some form of content management system, or CMS) about the beacons (what they represent or mean, what areas of your physical space they represent).
- In the same CMS, define the interactions, actions, or engagements that should happen as someone arrives near, dwells in, or departs from a given area (for example, content to be displayed when near, greetings to be triggered, information to be logged, and so on).
- Build one or more mobile applications that will scan for your beacons, and will then pull information from the CMS as they are detected, and then do what they should (display offers, trigger greetings, log a visit, play media, and so on).
Finally, some things to consider
Image courtesy of LocalSocial.
We will return to some of these points in the follow-on posts, but a few things worth highlighting:
- Are you looking for an indoor location solution, or is “proximity” good enough for many of your use case scenarios?
- Will your chosen approach work on all devices for your target audience?
- Is the cost of installing / maintaining infrastructure (like beacons) worth the return?
In the next post in this series, we’ll examine alternatives to iBeacon from Google, Samsung, and others, and map out the plethora of startups in the beacosystem.
This post is part of our investigations into APIs for the Physical World and Interaction Design and Connected Devices.
Cropped image on article and category pages by Stinging Eyes on Flickr, used under a Creative Commons license.