Google Beacon Platform Shutting Down

Google stopped serving Android Nearby Notifications late in 2018 but kept the Nearby API working for use within apps. Google has now deprecated the Nearby API that allows you to associate beacon ids with arbitrary content such as a link or multimedia data. It will be shut down on April 1, 2021.

No, it’s not an April fool joke but instead another useful thing killed by Google. Apart from Search, Cloud, Gmail and perhaps Android it’s risky to base your business on anything provided by Google. Unless it’s an offering through which Google itself depends for income then you can’t depend on it sticking around. Instead, businesses should look to create their own APIs.

This shows the easy route isn’t always the best route. Think about your project dependencies. It is likely the platform you depend on will exist for the lifetime of your project? How is the platform funded? How is the company that provides the platform funded?

Read about Trigger Data and Beacon Servers

Read about The Advantages of Generic Beacons

EddystoneCMS Retired

Following on from Google to Stop Serving Android Nearby Notifications, today we have retired EddystoneCMS.

If you want to use beacons for marketing you now need to have an app that listens for iBeacon or Eddystone advertising. In some ways this is better than the discontinued Nearby notifications. For marketers it is more:

  • Reliable – Google’s mechanism wasn’t 100% reliable
  • Transparent – you can more easily diagnose problems when it doesn’t work
  • Accountable – you can collect many more metrics
  • Flexible – a beacon can trigger anything the smartphone can do rather than just a web site

However, this is at the cost of requiring the user to install an app. Marketing using beacons is best retro-fitted into existing apps rather than within marketing specific apps for which you will need a large incentive for consumers to install.

Read about Beacons for Marketing

Google to Stop Serving Android Nearby Notifications

Google announced yesterday that they are Discontinuing support for Android Nearby Notifications. This is due to:

“a significant increase in locally irrelevant and spammy notifications that were leading to a poor user experience”

This means that anything mentioning the Physical Web, Eddystone-URL or Nearby notifications will no longer work. While beacons can still send out URLs, you will need an app to see the URL and you might as well use Eddystone-UID or iBeacon instead.

It’s disappointing that this mechanism will be turned off on December 6th, 2018. Unfortunately, it attracted use for more nefarious purposes and also resulted in some subscription schemes of dubious value. It’s especially bad news for those people using Nearby notifications legitimately and those companies that have built up platforms and businesses around Nearby notifications.

The Nearby API still works for apps and Google still supports the Proximity beacon API.  With or without this API, it’s still possible to create beacon triggered notifications in iOS and Android apps using the Bluetooth APIs. What’s no longer possible is unsolicited, app-less notifications.

We will be updating BeaconZone documents, blog posts and articles over the next few days. EddystoneCMS will be retired.

New Eddystone Standard GATT Service Beacons

We now have more beacons that support the Eddystone Standard GATT Service. These have firmware that has been programmed by us using the Nordic Eddystone GATT source code. The beacon hardware is the Radioland nRF52832 that’s more battery friendly than nRF51-based beacons.

Eddystone Standard GATT Service beacons use standard tools rather than manufacturer apps for configuration. They are also compatible with Google Nearby for registering at Google using the Beacon Tools app.

View all our Eddystone GATT Service beacons

Google Nearby Beacon Functionality Severely Cut by Google

Google have quietly cut much of the usefulness of using Nearby with Beacons. The Google Beacon Tools app previously allowed you to register beacons that advertise an id (not URL), even iBeacon, associating the beacon with either a URL or an app so that Android users receive a notification when they come across a beacon.

The Android Google Beacon Tools app that is used to register Nearby beacons has had some updates. Google have removed the capability to register iBeacons and the app now goes into a provisioning state to connect to the beacon being provisioned:

The Android Beacon Tools app can now only connect to and provision Eddystone GATT service Eddystone-UID and Eddystone-EID beacons otherwise it then shows “Eddystone configuration service not supported by this beacon”:

The majority of beacons, not just ours, don’t support Eddystone GATT service. This severely cuts down the types of beacon that can now be registered with the Beacon Tools app (in our case only 7 beacons).

The Nearby programming API, that you can use to register Nearby beacons in your app, still declares it supports iBeacon so it’s still currently possible to register non Eddystone GATT service beacons but not so easily.

This is going to be a problem for organisations who have used Nearby as an alternative to Eddystone-URL. If they have been relying on the Beacon Tools app rather than using their API via their own app, they won’t be able to register more beacons. This puts them into the difficult position of needing to either purchase Eddystone-GATT Service beacons or write an app that uses the API. However, there must have been some reason to restrict Beacon Tools to only Eddystone Standard GATT beacons and this might, one day, also apply to the API.

To be clear, this doesn’t affect Eddystone-URL. Eddystone-URL never, and still doesn’t need, registration at Google.

Together with the recent removal of Eddystone-URL detection from Chrome for iOS, this sees Google distancing Eddystone from iOS and iBeacon from Android OS. Organisations can still write apps that scan for iBeacon or Android and Eddystone on iOS. However, for some unknown reason Google no longer wants to support this in their own apps and tools.

Google Nearby Beacon Code Lab

Google has a useful, not very well publicised, code lab on how to use Google Nearby on Android. Nearby is google’s free API to store and fetch iBeacon and Eddystone beacon attachments (useful) data associated with beacons, in the Google cloud.

One thing that isn’t mentioned and isn’t clear is that you don’t have to register Eddystone-URL beacons with Nearby if you are not using the cloud storage.

Eddystone-URL Doesn’t Need Registration at Google

Google’s evolution of the Phsical Web over time and emphasis on latest features in documentation is still confusing new users. Eddystone-URL and Google’s server based Nearby are two separate things.

For Eddystone-URL you set the URL in the beacon (usually also needs a URL shortener and must have SSL for the final URL) and that’s it. As mentioned in our description of Nearby, beacons advertising Eddystone-URL can’t be and don’t need to be configured at Google. You don’t need to use the Google Beacon Tools App. Nearby in the Android OS (in Google Play Services) will see the URL if the user hasn’t disabled Nearby. Chrome on iOS will fire notifications.

For Google’s server based Nearby services, you register Eddystone-UID, Eddystone-EID or iBeacon at Google at associate it with a URL or app. We have a walkthrough.

Most implementations can use Eddystone-URL and don’t need beacons to be registered at Google. Your beacons will still be shown via notifications created by Android OS. On iOS they will need to be detected via the use of Chrome.

Google Nearby Notifications are Back

In October we reported that Google were temporarily disabling Google Nearby notifications and moving back to using Chrome.

As of yesterday (16th November) Google Nearby Notifications have been reinstated. Google claim:

“We’re currently close to 100% rollout across all Android devices”

However, as Google say there have been a “few tweaks” to the notifications. Web site descriptions are no longer shown. The explanation for this is a confusing:

“We made this decision to reduce the number of factors users need to consider when deciding whether to click on a result”

As to why the number of factors needed to be reduced isn’t explained.

So if, like Timoth J. Salo, you were using the web site description to impart information in a notification, you will have to re-think this strategy.

UPDATE: It appears the removal of the description was a mistake and this will be fixed towards the end of January.

The Physical Web is Getting Personal

There’s an interesting post on Twitter showing how, at the View Source Conf, people are starting to advertise themselves on the Physical Web:

This is similar to the early days of SMS when people (and network operators) really didn’t know how it would be used. New uses will crop up and one of the main uses might even end up being personal advertising.