Google Eddystone Jumps into the Browser on iOS

Your browser will now connect to ‘cookies’ in the physical world – beacons, which can now broadcast a Web URL as part of Google’s new Eddystone protocol.

And Google is planting its flag on iOS devices first.

By launching beacon support within Chrome, Google is effectively bypassing the gatekeepers at Apple and providing support for beacon detection “without an app” – because the app is the browser.

Having said that, Google won’t exactly be spamming you with messages. Instead, if you’re near an Eddystone beacon, you’ll need to be using the Google Today widget in your notification center (or it will need to be refreshing).

And yet, by planting this flag in iOS, Google has a relatively confined audience to test the Physical Web – and bringing that capacity to Android (in, perhaps, a far richer format) isn’t far behind.

While the percentage of users who have installed of Chrome on iOS devices isn’t known, it’s not insignificant, and likely ranges somewhere around 10%+, representing 10s of millions of users.

The larger win will be when Google launches similar support for Android, likely in the coming days.

But beyond the installation numbers is something perhaps even more compelling – because with beacons, Google will have a way to conceivably “ping you” to open a Chrome browser that you rarely use. While not currently how they’ve designed it (they limit the notices to an active Notification Center view) it won’t be long before they take the functionality further.

Google Goes Out for Launch

It took a while, but Google launched a full beacon development framework this past week. The framework included the open source Eddystone specification for beacon broadcasting, along with a host of tools and integrations.

The project was a grand slam, perhaps shockingly so, (depending on your view of how well Google promotes itself and how well it handles documentation and design).

Apple launched its iBeacon framework with barely a whisper at its World Wide Developer Conference in 2013. It then did very little to evangelize or explain the technology and created endless market confusion (perhaps intentionally), both over what an iBeacon actually IS, how it differs from the Apple software SDKs, the difference between an iBeacon and BLE, and how it would integrate across the larger Apple ecosystem.

Since then, Apple did very little to expand the protocol. It added beacon support to Passbook, thus allowing “app-less interactions”, and it recently announced it would further extend engagement through Apple Wallet and its iAd platform.

But Google has taken a page from what you might typically think of as the Apple playbook – creating a tightly integrated system of software and services to allow rapid development and deployment of a new technology.

Additionally, it did pre-launch outreach to a few select companies, who are now beating the drums as if they’ve joined the Google empire, and it managed its press relations, publicity and self-promotion as if Marissa Mayer still worked there.

And now, its followed up the success of the Eddystone launch by planting its flag inside iOS, letting the Chrome browser detect beacons and pushing you messages even in the absence of what you normally think of as an ‘app’.

The Physical Web

What makes this possible is the unique broadcasting packet of the Eddystone beacon protocol, called the Eddystone-URL. It allows you to:

• Broadcast a URL from your beacon instead of an ID number
• By broadcasting a URL, you can bypass the need for an app to “parse” the meaning of a beacon’s unique ID number
• You can thus leverage existing Web resources and simply point the user to a Web URL
• With this capability, the potential to bypass the app layer entirely is made possible, and with Google now launching support via Chrome, you’ll be able to pop a “URL beacon” on your wall and let the Web do the rest

Back to Basics on Beacons

For those who are just joining us, a beacon is a relatively ‘dumb’ device that is based on an open Bluetooth specification. A beacon broadcasts a signal, and when your phone “hears” that signal, it can act on it.

In a traditional beacon, the signal typically consists of a unique identifier and a bunch of extra ‘keys’. When your phone (via an app) hears this identifier, it can make a decision on how to act, usually by referencing a cloud-based service which provides it instructions on what kind of content to display.

Eddystone, however, incorporates the Physical Web as one of its broadcast signals.

The Physical Web was originally one of those “in my spare time” projects at Google (most of which remain experiments and are never brought into its main business). The premise of the Physical Web was simple: rather than build a NEW infrastructure for beacon content, why not just leverage Web development?

By broadcasting a URL, your “app” wouldn’t need to go to a cloud server or otherwise parse the meaning or purpose of the ID number that the beacon broadcasts. Instead, you can just open a browser.

Eddystone lets you broadcast a URL (it also has more “traditional” beacon broadcast formats, which are still needed for richer/native type app experiences) and it’s this capacity which makes Chrome the natural choice for broader “beacon detection” without the need for an app.

The Pros and Cons for Retailers and Brands

As I wrote yesterday, Eddystone is a big win for anyone who wants to create some kind of interaction with consumers based on proximity.

It’s just a beacon, after all, and by producing a robust suite of software tools for Android, we now have an easier and better way to deploy beacon experiences to Android devices.

But beyond the beacon itself, there will be some strategic decisions to make.

Because Google didn’t just launch beacon support. It also launched a suite of accompanying APIs and integrations – and whether you decide to use them will have as much to do with your views on who owns and should monetize the data in your venue and about your customers, and how important it is to achieve new ‘reach’.

Integrate with the Physical Web and your customers are now using a Google product and that product will now have access to data about where your customers are and what kinds of “physical world Web sites” they’re connecting with (although it promises not to share any personally identifiable information from your device).

Integrate with Places, Nearby or its Proximity API and there are other decisions to make.

But this all points to a larger message: that the tools for reaching customers have just become richer, that the era of the app as the primary driver of mobile engagement is coming to an end. You’ll now have more and more tools to reach consumers based on proximity and that’s a very good thing.

And, strangely, and for today anyways, if you want to test out Google’s Physical Web, you’d better get out your iPhone first.

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.

Well….wow huh? What do you think? Call me impressed.