Understanding Beacons: Contextualized User Experience

Published Mar 14, 2017Last updated Jun 12, 2017
Understanding Beacons: Contextualized User Experience


Imagine this: you're sitting in front of your TV at home and your phone automatically shows you what’s playing on your favorite channel. Or, as you walk up to your daily bus stop your phone automatically tells you that your bus is delayed by 30 minutes. Or, maybe, you have hearing difficulties and need specific accessibility assistance at a hospital. Instead of spending ten minutes trying to explain your situation to hospital staff, they already know about it.

As software developers, when we're developing apps, we're always interested in finding out more about the context our users might use them in. That way, we can provide more acurate and personalied user experiences. Beacon technology can help us with this goal.


What are Beacons?

A beacon is a small Bluetooth radio transmitter. It's kind of like a lighthouse which repeatedly transmits a single signal that other devices can listen to.

Compared to traditional beacons, which are tall towers that guide ships in the right direction, today’s beacons are quite small (even smaller than a mobile phone) and can do much more than traditional beacons. They have a long battery life as well.

Eddystone Standard

In order to speed up the pace for building apps on beacons Google came up with an open and flexible beacon standard called Eddystone, which is available to everyone. Google also provides its APIs APIs to register, manage and detect beacons via its Proximity Beacon API and Nearby APIs.

Lets try to understand how we as developers can make the most out of these APIs.

Let us think of a scenario in the transportation domain where beacons would be useful, and then try to see how each of these APIs could improve users' experiences. Let’s say our app's purpose is to help improve commuters' experiences with public transit. Its an app that services bus stops and train stations and provides up to date information concerning users' favorite route at those stops.

We would need to deploy several beacons at each station in order to read data from them. Now while checking out which beacon to buy. If you plan to build apps on top of Google APIs, you should buy the beacon that supports Eddystone Standard, which is an open standard for beacons that anyone can use. It offers a common format for building apps and extension for new features and use cases.

Let's look at the steps to build a functional beacon-based system:

1. Provision a beacon:

Once you get your beacon, you need to first provision it, and then, depending on your usecase, register it with a cloud service and attach data. Provisioning basically means specifying the basic beacon settings such as:

  • Eddystone Frame Type
  • Transfer Power
  • Broadcast Rate

The beacon manufacturer should have instructions about this process, and they are likely to have APIs available to help you. Some beacons come preconfigured as well. Once the provision is done properly, a beacon can start broadcasting itself to the world.

If you are using a physical web beacon with the Eddystone Frame Type , you can simply set the URL in the provisioning step and you are done. For all other frame types, you need to register the beacon and attach some data.

2. Registering a beacon:

You can register a beacon with the Proximity Beacon API by providing basic information such as :

  • beaconName
  • placeId
  • latLng
  • expectedStability
  • description
  • properties, etc.

This step also enables various Google integrations, like the Places API and Nearby API.

3. Proximity Beacon API:

Finally, you can use the Proximity Beacon API to add some data. This is where you start to realize how much of an impact beacon technology can have.

The Proximity Beacon API can also be used to manage beacons at scale by detecting lost beacons and low battery and performing activation, deactivation, and decommissioning as well.

4. Beacon broadcast ID:

Now, we have a configured beacon that is broadcasting its ID to anyone who's listening. Actually, beacons are always broadcasting their ID, even if no devices are listening.

5. App listening to beacon:

Next, we need to setup our app to listen for our beacons. There are two approaches to do this:

  • Bluetooth Low Energy (BLE): We can write our own service to scan for beacons using Bluetooth LE and then look them up using Proximity beacon API, or

  • Nearby API : we can let the Nearby messages API do all the extra work for us. This is the most preferred method.


To use the Nearby API method, we need to subscribe to messages from the Nearby API, which includes the same project name space in the subscription that we gave while registering our beacon. We only want to listen to the beacons that were configured with the same project name space. Once this is done, Nearby API will keep an eye on those beacons. When one is sighted, it grabs the beacon's information (including attachments), turns them into messages, and then passes them over to your app. Now, we have working beacons and an app that uses them to make your users' experiences awesome!


Beacons are all about contextualizing and delivering localized information to your users. Whether your users are at a shopping mall, in a bus, or in a car, knowing their context will provide them with a simpler, richer, and more accurate experience.

Discover and read more posts from Ashish
get started