Google, Beacons and the Black Box

When Google launched its response to the Apple iBeacon standard, it established itself as best-in-class for the field. But as it worked to integrate different initiatives within the company, it has left some notable gaps that hinder the development of effective user experiences.

It can be hard enough to understand all of the competing terms and standards. Sorting out whether your beacon should broadcast Eddystone, Physical Web or iBeacon signals is confusing enough.

But ending the process with a “black box” around your analytics makes it difficult to achieve what Google intends: useful end user experiences.

Background to Beacons

Before Google, all the hype was built around Apple’s iBeacon. The media (and developer community) often conflated software and hardware protocols. There was a perception that Apple was delivering ads based on proximity. Overall, there was both confusion over what iBeacon is or isn’t, and where Apple intended to take it.

Bluetooth Beacons First, it’s good to remember that beacons are all built on the same standard: Bluetooth LE. This is a protocol by Bluetooth for a low energy signal. The proximity standard is one of those protocols. This standard can be ‘interpreted’ in a number of different ways. Basically, Bluetooth provides a method for sending a radio signal in which a packet of data is included. How you use that packet is up to you.

iBeacon When Apple first launched its own standard for how the ‘packet’ should be encoded, it created confusion. iBeacon encompassed the standard for broadcasting, but it also came to include (at least in the popular imagination) the software tools for iOS developers, and the beacon itself (by being allowed manufacturers to use the iBeacon symbol).

Since its launch of iBeacon, Apple has done – well, nothing. Ahead of last year’s developer conference, they announced plans to integrate iBeacon with its iAd platform, giving brands the opportunity to deliver content to beacons without the need for an app.

But Apple pulled the plug on its iAd platform, and iBeacon (and the Apple approach to Bluetooth proximity) remained unchanged for yet another year.

Decoding Beacons the Google Way

Along came Google. When it launched its Eddystone standard, the press hailed it as an iBeacon competitor. And narrowly defined, it was. But this masked a much wider ecosystem. Google support for beacons was both more robust and more confusing.

It’s helpful to begin with understanding a few of the terms that apply in the Google ‘universe’ of beacons:

Physical Web This was the first unofficial entry from “Google” into the world of beacons. And I use the term in quotes because Physical Web is an open source standard which at first seemed loosely coupled with the company. Spearheaded by Scott Jenson, it is a standard protocol for broadcasting a URL in a beacon broadcast.

Browsers and operating systems which support “listening” for this URL can then display a web page.

Since its launch, Physical Web has expanded to include a number of methods (such as Wi-Fi Direct and SSDP) that can act as alternatives to physical beacons for broadcasting a URL.

Eddystone This was, perhaps, the true “Google response” to Apple iBeacon – “a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages.” The protocol is for an open format beacon.

It picked up where iBeacon stopped and addressed some of the key concerns with the Apple standard. By offering three different broadcast protocols, it allowed:

• Secure broadcasts through Eddystone-EID (a companion framework) so that only authorized devices can ‘see’ your beacon
• Additional flexibility within the broadcast packet, giving manufacturers some ‘room to maneuver’ compared to the Apple standard
• Better support for beacon monitoring and management through Eddystone-TLM

Google Nearby Finally, Eddystone was launched with support for Google Nearby. This allows you to register your beacons with Google and present a notice to user’s phones, even if they don’t have an app.

And it’s on this last item that things get interesting. Because without the need for an app, you can now engage with users in a new way – by directing them to an app download page, or to an https web page of your choosing.

Google is Not One Thing

So Google launched Eddystone. It launches beacon support through Google Nearby. And it launches a collision of standards.

Let’s say you want to support iBeacon and “Google”. So you put out beacons that broadcast the Physical Web, iBeacon, and maybe AltBeacon because you have an app that uses it.

You register iBeacon with Google Nearby (huh? Yeah. You can even register an iBeacon to Google Nearby).

Now, your end user might be getting multiple notices – one via Google Nearby, one through your app, and one for Physical Web.

This confusion stems, in part, because different units within Google are developing in parallel – whether the Nearby team or Chrome.

Over time, Google started to coordinate all of these efforts, and has done a brilliant job iterating and improving the user experience. Now, your phone will sort out the Physical Web and Nearby signals and start to sift through them to avoid confusion.

Meanwhile, as a developer, brand or retailer, you’ll still need to sort out the differences between the 100s of Android phones – but that’s the pain of entry into the Android world. (With Samsung recently announcing its CloseBy standard, at least we’re seeing a relative match-up to the Nearby approach).

The Silent Notification

OK, so you’re still probably a bit confused. You’re not alone.

So let’s simplify things a bit:

• You can now send a beacon notice even if your end user doesn’t have an app
• This notice can link (via Physical Web, Google Nearby or…soon, Samsung CloseBy) to a web page or app download
• This notice is silent. Which means the user needs to know to take an action (swiping down, for example, for the notification tray) to see your notice.

Users with Bluetooth on and widgets activated will always be able to see a silent notice. The Physical Web will always show in the notice tray if, for example, you’ve activated the Chrome widget on your iPhone.

But the notification is “silent”.

Except when it’s not.

Because with Google Nearby there’s a catch:

Android users near that device or beacon will see the message in the Nearby section of Google Settings, the Nearby Quick Settings tile will light up on supported devices, and messages that perform well will be raised as notifications.

And there’s the rub: “messages that perform well“.

Because – well, there’s no way to know.

The Data Gap

There’s a problem: Google doesn’t want to spam end users with unwanted messages. According to Google, their data clearly shows that inappropriate messages will ‘turn off’ end users. We can imply that this could lead to turning Bluetooth off, or otherwise disabling Physical Web or Google Nearby.

We get it. So, as a developer, you want to do your best – to test, say, multiple messages. To look at the data and tweak your messages so that it gets better. To improve your performance so that Google will ‘un-toggle’ your notices and present more of them to your end users.

But you’re fighting a battle with one hand tied behind your back:

• You don’t know how many total devices were eligible for your message
• You don’t know how many users “pulled down” and therefore don’t know what your hit rate is with a specific message
• You might not have a good handle on how much physical foot traffic you get near your beacon

All you know is that 50 people (say) opened your page. You don’t know how many of those were from a “pull down”, how many were from a “raised notification”, or how many people even saw your message in the first place.

And to make matters even more difficult, there’s no way to test any of this in your development environment. You can’t easily “reset” your test phone so that it acts like a naive user. Google interprets development and production the same way via Nearby.

We’re working in the dark.

And there’s no easy answer.

Is There a Solution?

With Google I/O approaching in May, I half suspect that Google will monetize Nearby – letting you pay to raise your notification in a more consistent way. Maybe they’ll connect up to Google Analytics or Firebase Analytics.

But even if they don’t there’s no easy way for Google to solve this black box issue without raising a host of other issues.

For example, if you were to give a total count of ‘eligible devices’ wouldn’t this open up the chance to snoop on foot traffic and device counts? Couldn’t you then place a beacon inside a competitor store and use this data to snoop on their location foot traffic data?

But to start, developers and Nearby users should at least be provided with some simple tools to help them improve the end user experience. Some baseline data would be a start:

• When you launch a Nearby campaign with beacons, what is the starting percentage of users who will see your “raised” notification?
• What is the maximum value this will go up to?
• Can Nearby provide the capability of A/B testing messages and report back on which message included a “boost” to raised notifications?
• Can we get access to “percentage of raised notifications” even if it doesn’t give us numbers?

Providing a better method for toggling Nearby beacons to “development” along with better instructions on how to treat a development phone as a naive user would also be a big improvement.

Google is doing it right – they’re making sure that users aren’t spammed, that we don’t see a backlash to beacons, and that the different notices are ‘streamed’ effectively from the different protocols.

But to get to the next step, Google should provide developers with some sort of feedback to help them improve the effectiveness of messages. This type of two-way partnership will be key to the continued uptake of beacons.

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

How do you assess the effectiveness of Nearby or Physical Web projects? How do you assess the data? What would you like to see Google provide (data or other tools) to help improve the end user experience? Drop a comment below, or pop me a note on Twitter.