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 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.
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 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.
We have had several people asking what happens to Eddystone Notifications if they aren’t actioned in any way by the user. The answer is that they disappear automatically once the beacon goes out of range.
Hence, you can’t rely on the user seeing the notification later in time. This sort of makes sense because it’s a Google Nearby notification. It’s showing what’s nearby at that particular time, not what’s nearby in the future.
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.
Important: This web page is provided for historical purposes.
On 25 October 2018, Google announced they are discontinuing Nearby Notifications on Android. This mechanism should no longer be used.
Read about using Beacons for Marketing
This post assumes you already know about managing Physical Web URLs and the use of SSL.
What do you do if you have set everything up and aren’t getting any notifications? Here are some things to try and do:
- Internet connectivity? Android connects to a Google proxy and then to your site to get information, for example the web site title, to show to the user. If there’s no or poor (slow) Internet connectivity, the beacon will appear not to be detected. To test connectivity, enter your URL into Chrome on Android and see how long it takes. Anything more than a few seconds will cause the Google proxy to give up.
- Is it the URL? Try a URL that you do know works for someone else, for example one generated by phy.net or our test URL http://bzone.click/bz
If you think it’s a problem with the URL, you might like to try using Google’s Physical Web URL validator. However, be aware that the validator itself has faults and we have seen URLs which work that fail with the validator.
- Is it your URL content? Any URL content, for example images, must also be accessed via SSL (https://) links.
- Is it your URL shortener? Some public URL shorteners can get overloaded and when they take too long to respond, the Google Physical Web Proxy gives up. The total time for the shortener and your web site to respond needs to be less than 3 seconds. Test the shortener speed and your web site speed in a normal web browser. Try a different URL shortener.
- Is it your web server? If you have control of the web server and it uses a Cache-Control header, make sure you set it to at least 24 hours so that it gives the Google Physical Web Proxy time to update it while using the old cached version.
- Are you linking to the Play App store? Links to the Play store are not supported.
- Have you waited long enough? While notifications usually arrive in the order of seconds, on some phones this can be minutes. Wait at least 10 minutes before concluding it isn’t working. Turning the screen off and on can sometimes cause Android to re-scan for beacons.
- Is it Android? Try the Physical Web app. Note that notifications are not guaranteed. If Nearby has already sent you notifications recently then it may back off to make sure it is not annoying you.
- Are you running Android 8.0 (Oreo)? There are problems with Android 8.0. We have submitted an issue with Google.
- Is it your phone? Really. Some phone have problems with Bluetooth. Try a different Android phone.
- Is it the beacon? Use the ‘nRF Connect’ app to determine if it sees the beacon and the correct URL.
- Is the beacon being detected? You can test if the beacon has been set up correctly by going to Settings … Google … Nearby and your beacon will be shown (you might need to use the refresh button at the top).
- Have you previously dismissed the notification? If the notification has been dismissed on a device recently, that device may not show another notification a period of time. You can reset the backoff policy by opening Settings … Google … Nearby.
- Is your notification blocked? If notifications have suddenly stopped working, Google might now be blocking your URL. The Google proxy has a scoring algorithm such that a notification won’t show if it has not been well received by users. Try a new URL.
- Is it the Google Proxy? We had a customer say that trying to use the Beacon Tools app, allowed their beacon to be seen even though registering via this app (as expected) failed because it wasn’t a Eddystone GATT beacon. [Only Eddystone GATT beacons can be registered using the Beacon Tools App.] We are not sure if this really caused the beacon to be registered or if it was just a case of ‘Have you waited long enough?’ (above).
- What’s going on in the Android OS? There’s a great post on StackOverflow that shows how to use ADB (needs Android Studio installed) to enable logging. There’s also another post from the Nearby team on how to get the Nearby logging.
Getting Further Help
Log a Physical Web Issue or communicate with the Physical Web team via the Physical Web discussion forum. You can also create a bug report and send it directly to the Nearby Team.
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.
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.
Last month we mentioned how the Physical Web was being temporarily removed from Google Nearby. Since then there have been some posts from Google that have provided further clarification and complications.
As Chrome is rolled out, out of sync with, Google Play Services, it’s possible that some devices have a new version of Play Services (without Physical Web) and an old version of Chrome (pre Chrome 54 without the Physical Web added back). In such cases, the Physical Web won’t work at all.
There’s also insight into why the Physical Web was previously moved from Chrome to Play Services:
“The big restriction with Chrome is that it has to be launched once after boot in order for notifications to show up. Once that’s done though, notifications should show up. This is one of the reasons we moved to Android OS as it got rid of this restriction.”
This means, under the temporary arrangement, you need to run Chrome at least once for Physical Web beacons to be detected. Also see our previous tips on getting this to work.
As we previously said, if you have an important Physical Web rollout then it might be best to delay until late November.