Google Nearby Beacons

In July 2016, Google rolled out detection and notification of beacons in the Android OS as part of the Physical Web. Google Nearby Beacons are a way of associating either a URL or an app with a beacon so that people receive a notification when they come across a beacon. The notification comes from the Android OS (Play Services to be more precise). When people encounter their very first Nearby beacon they are asked if they want to see future notifications. This can be turned off/on in Settings…Google …Nearby discoveries.

Nearby beacons don’t need an app and don’t need Chrome (previously the way of seeing Eddystone-URL configured beacons). Our tests have shown Nearby beacons to be more reliable than relying on Chrome for Eddystone URL notifications. Nearby beacons don’t need a beacon platform or API. You implicitly use Google’s Cloud platform free of charge.

Nearby beacons don’t need special types of beacon hardware. Any beacon configured as Eddystone-UID, Eddystone-EID or iBeacon ( * see 2017 update note below) can be set up on Google's Cloud platform. Beacons advertising Eddystone-URL can't be and don't need to be configured at Google. They appear in the OS Nearby notification list without any configuration on the Google cloud platform.

Web sites pointed to by Nearby beacons must be secure (use https://). Unlike Eddystone-URL detection by Android OS, it’s not possible to use URL shorteners that use http:// to point to sites that do have https://

This is an Android only solution if you are relying on the OS to show notifications. However, this does cover over 86% of smartphones. If you have an app on iOS or Android, you can use the Nearby APIs on both platforms to fetch information for detected beacons.

Nearby Beacons is in Google Play Services rather than the Android OS which has allowed it to be rolled out to existing users independent of updates to their Android OS. This means it won’t work on ‘forked’ versions of the Android OS that don’t include Google Play Services. Probably the largest and most significant group of forked users is those using Amazon Fire devices.

A notification typically only appears after the screen has been turned on. It usually causes a minimum priority notification that won’t create a status bar icon. For users who have accepted the Nearby Notifications 'welcome experience', some notifications will start as low priority and create a status bar icon. However, after a few minutes as low priority they degrade to min priority and stay there.

The Physical Web (Eddystone-URL and Nearby Beacons) has been devised as pull not push so as to, as Google says, ‘respect the user’s attention’. It’s expected that the Physical Web will see slow but steady uptake in a similar way to WiFi. It’s intended that, much like WiFi, people will see the Physical Web logo and take out their phone. It’s NOT about them getting a notification that causes them to look at their phone.

* 2017 Update: The Google Beacon Tools app used to register Nearby beacons has had some updates. Google have removed the capability to register iBeacons and the app goes into a provisioning state to connect to the beacon being provisioned. The Beacon Tools app can now only provision Eddystone GATT service Eddystone-UID and Eddystone-EID beacons (e.g. i7 and Sensoro with firmware update). The Nearby API, that you can use to register Nearby beacons in your app, still declares it supports iBeacon.

We have a blog post describing how to set up Nearby Beacons.

Tags: ibeacon, eddystone, google, nearby