Browsing Google Chrome and the Physical Web

Google Chrome Physical Web URL

Chrome 57 has launched, and with it in-browser support for the Physical Web. Now, when a user goes to conduct a search or enter a web URL, any nearby Physical Web addresses will appear just below the address bar as seen in the above graphic.

It adds another piece to the proximity puzzle – allowing your browser to show nearby URLs when you go to enter a Web URL or go to conduct a search.

Use Cases for Chrome URLs

Being able to see nearby Physical Web URLs in your browser suggests some interesting use cases/value propositions:

Closing the Gap on Physical Web Objects – in the world of the Physical Web you walk up to a “thing” and use it. In general, their use case is for that “thing” to include a Physical Web icon. You need to know that the object has a URL attached to it. This is usually accomplished through physical-world icons/signage. You then need to know to “pull down” on a notification tray to see it.

By adding Physical Web URLs to your browser search/address bar, there’s another path to making sure users will more easily be able to “see” that URL.

Show-rooming – Retailers still struggle with ‘show-rooming’ – where users will be shopping, say, for a fridge and go online to compare prices when in the store. By attaching a physical web beacon to the fridge, the retailer has a last chance to catch the user’s attention with a link of their own.

In the Home – This is, perhaps, where beacons can truly start to merge over with the connected home. Device makers (say, the Nest thermostat) can embed a Physical Web broadcast. Now, your thermostat, connected TV or other device can offer up a manual, support hotline or other information as an available link in your browser – and possibly bypass the need for a custom app.

Bluetooth in the Browser

Things start to get really interesting when you take into account the fact that Chrome also supports Bluetooth connections.  By allowing Chrome to connect to nearby Bluetooth devices, you can create use cases where a Physical Web signal leads to a web URL. The web URL leads to a page with support for Bluetooth connectivity.

(We should note that Bluetooth proximity and Bluetooth connectivity are two entirely different things!)

Google does a deep dive on this capability and provides libraries for Angular, Node and Polymer.

We can envision use cases where you approach a fitness machine in a local gym, it has a Physical Web logo, a Physical Web URL shows up when you search in Chrome, and the web page it takes you to can connect to the machine and read out heart rate or other information.

Go Chrome, or Go Physical Web?

This addition to the “proximity pathway” is great. But it adds another layer to an already confusing set of instructions for consumers.

One interesting question: when you’re creating an in-location sign/symbol or marker to let consumers know there is a nearby URL, should you flag it as Physical Web, or Chrome?

I’ve been wondering whether the Chrome logo wouldn’t be a better way to go. It bridges Android and iOS, is a recognized symbol, and is WAY easier to explain.

Because when the current instructions look like THIS, wouldn’t THIS be easier to understand?

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.

Have you engaged yet with a Physical Web URL via Chrome? What use cases do you think we’ll see? And do you think the Physical Web icon will be a driver of adoption, or will we see other ways to promote these new features?

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

Content Creator or “Business Builder”? Drop Me a Line

On a side note, we’ve been partnering with content creators, publishers and entrepreneurs of all stripes. We’ve been building out tools to bring proximity channels to new markets. If you’d be interested in learning more, don’t hesitate to drop me a note – doug (at) fidgets.net . Our mission is to help content creators,  publishers, entrepreneurs and companies to build new revenue streams on the Internet of Things.

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.

 

 

 

 

Google Updates Terms of Service for the Physical Web

Google has updated its Terms of Service for Chrome to clarify the use of the browser as part of the “Physical Web“.

The update, which coincides with the release of beacon detection in Chrome browsers for iOS (with Android support expected in the coming days), clarifies that users won’t be sharing personally identifiable data from their device when they connect to a beacon that broadcasts a URL.

Specifically, the update, which went live on July 21st, informs users that:

If you enable the feature in your device’s Today view, you can use Chrome on your iPhone or iPad to discover objects around you that are broadcasting web addresses as part of the Physical Web. When you use this feature, Chrome sends the web addresses broadcast by these objects to a Google server to find the title of the web page and help rank the results. The information sent to Google to provide this feature does not include any personal information from your device.

Now, it’s not to say that Google isn’t using the data about which URLs are being pinged, and you need to consider your use of location services as well:

If you use Chrome’s location feature, which allows you to share your location with a web site, Chrome will send local network information to Google Location Services to get an estimated location. Learn more about Google Location Services and enabling / disabling location features within Google Chrome. The local network information may include (depending on the capabilities of your device) information about the wifi routers closest to you, cell IDs of the cell towers closest to you, the strength of your wifi or cell signal, and the IP address that is currently assigned to your device. We use the information to process the location request and to operate, support, and improve the overall quality of Chrome and Google Location Services. The collected information described above will be anonymized and aggregated before being used by Google to develop new features or products and services, or to improve the overall quality of any of Google’s other products and services.

But the update is welcome news on the privacy front.

It might not solve the problem of beacon spam if we’re suddenly flooded with millions of the little devices as we wander around the neighbourhood, but it’s somewhat assuring to know that Google isn’t sending personal information back to its servers just because your Chrome browser heard an Eddystone beacon as you walked through the mall.

Share Your Thoughts

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