Samsung and the Physical Web Get CloseBy

Samsung has announced support for Physical Web URL detection in its Samsung Internet browser – the default for Samsung devices.

Called CloseBy, the support allows users to activate an extension to their browser which will then deliver a notification when they’re “close by” to a Physical Web beacon. Tapping on the notice, the user is taken to a Web page within the Samsung Internet browser.

The Physical Web is an open source standard for broadcasting a URL from a Bluetooth LE beacon, Wi-Fi direct or other hardware.

Challenges Ahead

CloseBy is still in beta and is reporting its share of glitches. These will be worked out.

But for brands, retailers and developers there’s increasingly a larger challenge in how to effectively managing the end user experience.

Fragmentation is a potential problem. When coupled with the fact that Physical Web has been designed primarily with a “lean-forward” consumer in mind, this is creating a challenge in consumer education.

Simply put:

  • If you want to make sure that most of your users (say, visitors to your store) can be made aware of and “see” a Physical Web URL, some sort of visual prompt is required
  • This is caused by an inability to actively notify users that there is a URL nearby. In theory, your Physical Web URL will appear 100% of the time in the notification tray (although there are serious enough issues with this as well). But getting users to check their notification tray requires some sort of physical world prompt (a sign, say).
  • Google Nearby attempts to solve this by “surfacing” notices. How this happens is opaque.
  • To solve for these challenges, a retailer or location should provide signage or prompts. Just like consumers needed to learn the purpose and use of QR Codes, the theory is that they’ll also learn about Physical Web URLs.

But with the Samsung launch, we now have another series of steps a consumer needs to take to “see” a Physical Web URL.

So how do you resolve the different types of education needed for different devices? It seems unbearable to think of a Physical Web sign with different activation instructions for 3-4 different device types!

(We haven’t even discussed iOS where Physical Web is available through notification widgets for Google Chrome!).

Change is Good. Change is Bad.

Further complicating issues is that there are changes happening with little education of the ‘beacon industry’ and developers.

A stellar comment by “mjanke67” on GitHub captures the heart of the issue:

I would suggest that until that level of Physical Web adoption occurs, users simply won’t drop their drawers (ed: notification tray) to check for scanned Nearby objects. Ultimately, the Physical Web adoption may never grow because it has been setup for future and not current levels of adoption. To address this – it is key that users retain their ability to view Nearby Notifications in both the Status Bar and Lock screen. To ensure that users don’t get offended by too many notifications, disable their display within the Lock Screen by default but give them the ability to enable notifications on the Lock Screen if they so desire. This same control (or another) could be used to enable display of an icon within the Status Bar when a notification has been added to the drawer. With this level of control in place, interested users can be shown or taught how to get notified by Physical Web objects. Disinterested users will leave Status Bar and Lock Screen notifications disabled (their default state) and will be unaffected.

Another key point that I would raise is that Nearby Notifications did exist within the original deployment of Nearby within Google Play Services (GPS) and were removed without warning after my company and others built product around the Nearby featureset. Removing original service features without discussion or warning is (choosing my words carefully) – very very uncool.

This last point is worth noting: features may change without warning.

And while many of them might be in the end service of users, or in the end service of providing a balance between users and developers/locations, it can be disconcerting (or a show stopper) to plan an entire roll-out only to have the use case itself change in a significant way before (or during) launch.

So, sure, all of these tweaks and improvement are good – but they often come with a lack of explanation and non-existent access to meaningful interaction data.

Samsung Gets Closer?

So, Samsung now supports Physical Web URL detection. It joins Opera (which I think was first to the party) but clearly represents a far more substantive audience.

But there are a few things left unclear – and maybe anyone testing the beta version can chime in with a comment below.

  • Is CloseBy like Google Nearby in how it “surfaces” notifications? Their post and screen shots seem to show a lock screen notice.
  • If it does display a lock screen notice, is this a 100% reliable notification?

In other words, at what step does the following screen appear in a user’s journey?

 

Second, Samsung mentions a server:

Upon receiving a URL from the Physical Web object, your phone sends that up to our servers in order to find the title of the page and determine whether to show it.

Can we assume that this is simply a way to parse a URLs metadata in order to display a notice? Where does this content come from? How do the fields on a web page match over to the notice that the user sees?

And are these notices consistent with how other Physical Web detection works, or will developers need to create different metatags for different systems?

Beacon Next

It’s an exciting time for the beacon industry. The Physical Web, Samsung CloseBy and Google Nearby are giving options across devices for the delivery of messages to users.

To fully take advantage of beacons, the next step would be to lead a user to download a beacon-capable app. Within an app, a developer can more finely control and measure the impact of proximity on an end user.

So, this part of the “funnel” is important and Samsung’s entry is a welcome development.

But the large beacon ‘ecosystem’ is leading to a fast-changing and fragmented set of user experiences which will create new challenges in how we educate consumers and how we prompt them in physical spaces.

Share Your Thoughts – Have You Tested CloseBy?

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.

Have you tested Samsung Internet? What has your experience been? How well does it handle notifications and consumer on-boarding? And how well do you think we’ll be able to manage consumer interactions and education?

Drop a comment below, or pop me a note on Twitter.

 

Advertisements

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.