Getting started guide

Reach out to physical-web-discuss@googlegroups.com with any questions.

Who this applies to

This guide is meant to be a tutorial for developers who are interested in the Physical Web and would like to deploy it to their users.

Introduction

To distribute your web page over the Physical Web, you need two things: (1) a bluetooth low energy beacon (the backbone of the Physical Web) and (2) a URL. Depending on how beacons are configured and how many are used, various deployment options are possible. This guide will walk through these different options -- starting from a basic single beacon deployment and transitioning into a more complex multi-beacon, multi-URL deployment.

Bluetooth Low Energy (BLE) Beacons

BLE beacons are low powered devices that unidirectionally broadcast data for applications and devices to use. The Physical Web is built on top of beacons that broadcast over the Eddystone protocol. You can find a list of Eddystone-supported beacons here for your deployment.

When you purchase your beacons, the manufacturer will recommend an application that can connect to the beacons and configure them. Below are the major configuration parameters that you can change for each beacon.

URL

This is the link to your webpage. The Physical Web on Chrome and Nearby Notifications only supports HTTPS URLs. We recommend the URLs to have the following attributes to provide the best possible user experience:

Mobile-optimized, both for the user interface and navigation.
Single-purpose. Each should should cater to a single action (e.g. consume a piece of content, perform an action). Remember that users won’t be browsing to this page but instead will be arriving directly to it if they are nearby your beacon.

The Eddystone protocol provides 17 bytes for the URL packet, so you will likely need a URL shortener to compress the byte size of your URL if the beacon configuration application doesn’t automatically have one. If you anticipate needing to change your broadcast URLs frequently over time, consider using a URL shortener that allows you to update the end URLs later.

Transmission Power

Beacons can vary their transmission power, typically from -40dbm to +4dbm. Note that power is a rough proxy for the transmission distance, which is ultimately a function of beacon antenna, phone antenna, beacon placement, and more. Our suggestions below are therefore rough guidelines.

In general, we recommend setting the transmission power to be low, typically between -30dbm and -35dbm.

This has 2 advantages:

It prolongs the beacon’s battery life.
It ensures that users see your broadcast URL only when they are close to your device (thereby making your content more contextual).

However, there are certain situations where a higher transmission power may be desired such as covering a large space with a single URL.

Advertising Frequency

As a general rule, we recommend an advertising frequency of 700ms.

Most beacons can advertise in a range from as fast as every 100ms to as slow as every 10 seconds. Going slower can save battery life but scanning applications such as Chrome and Nearby Notifications may not reliably surface URLs to users if the frequency is much slower than 1 second. Going faster than 700ms is possible too, although this will reduce the beacon's battery life.

Deploying beacons

The complexity of your deployment will depend on how many beacons you’ll deploy and how many distinct URLs you plan to broadcast. Below, we summarize the different deployment options and which use cases they typically pertain to.

1 Beacon, 1 Url

This is the simplest deployment option to broadcast a single web page associated with a particular location or object. For example, a beacon could be placed on a movie poster and configured to broadcast the movie trailer.

For best performance, we recommend the following best practices:

Place the beacon at high altitude. There will be less interference, and it will be less likely to be tampered with.
Avoid placing the beacon inside or behind metal. Bluetooth signals do not travel well through metal.

Many beacons, 1 URL

If you have a large space in which you’d like to broadcast a single URL, you might consider using multiple beacons. For example, multiple beacons could be used at a conference to broadcast a link to the schedule.

A few things to note for this type of deployment:

Consider increasing the transmit power on each beacon to cover a broader area. This enables you to use fewer beacons to cover the entire space.
For Physical Web scanners such as Chrome, identical URLs will be de-duplicated before being displayed to the user. For example, if five beacons in a conference are all broadcasting the schedule URL, only a single schedule URL will be displayed to users. This enables you to place multiple beacons broadcasting the same URL in an area without overwhelming users with multiple results.

Many beacons, many URLs

You might want to associate unique URLs with different locations in your space. For example, each exhibit at a museum could have a different URL associated with it. In this scenario, you would deploy multiple beacons that broadcast distinct URLs.

You’d likely want to restrict the range in which users can discover each URL -- in the museum example above, users would likely want to discover exhibit URLs when they are within close vicinity of the exhibit. To do this, consider using a lower transmission power for each beacon you deploy in this environment.

Managing content

For certain deployments, you might want to change the broadcast URLs after initial configuration. One example is a large retailer that has deployed beacons across a variety of stores and wants to continually update the broadcast URLs regularly to reflect new content. While it is possible for you to continually re-configure the beacons with a new URL, it requires you to be within bluetooth broadcast range.

For larger beacon deployments, we recommend using a URL shortener that enables you to later edit the destination URL. Many Eddystone certified beacon manufacturers include their own URL management solutions. In addition, we’ve included below a few well known URL shorteners that offer editing of the destination URL -- note that it is not meant to be an exhaustive list:

Alternately, you can choose to build your own updatable URL shortener. Below are a few example github repositories with basic URL shortener implementations that can be further customized. As before, this is not meant to be an exhaustive list. They can be used as building blocks:

Finally, you may wish to disable your URL broadcast in certain scenarios (e.g. turning off exhibit information for a temporary exhibit at a museum). To do so, you can update your shortened URL to redirect to a 404 page. Physical Web on Chrome and Nearby Notifications will not display these URLs.