Browsing Google Chrome and the Physical Web

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.

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.

 

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.

 

 

 

 

WWDC 2016: iBeacon and Apple’s Last Chance

Google is cleaning Apple’s clock in proximity. Their suite of software development tools leaves Apple in the dust – from tight integration of their Nearby API and their Eddystone beacon protocols, to the monumentally important physical web, Google is making sense of proximity.

It didn’t need to be that way. Apple was first out of the gate with the iBeacon protocol. They had ample opportunity to take it further.

But a few World Wide Developer Conferences later, and iBeacon is the orphan child of Cupertino – filled with vague promises never fulfilled.

The only hint of iBeacon heading in a new direction was the announcement that you would soon be able to deliver “Offers” . But the project was abandoned when Apple killed iAd. (And the link to the Apple announcement has long been dead).

The Mistakes Apple Makes

The launch of iBeacon promised to revolutionize how our phones would react to the world around them. Apple launched it with little fanfare and yet it prompted a wave of hype – the promise that retailers could reach consumers with coupons, that museums could display digital data “next to” a painting or sculpture, or that we could track down friends at a club because their phones would be broadcasting as beacons.

The initial problems were understandable. A new way to “listen” to nearby devices was bound to have a few bumps. And you’d expect over time that Apple would continue to enhance and improve the technology.

But after several years, the changes have been minimal. And in some ways they’ve perhaps even degraded.

The technology itself, however, wasn’t the only problem:

• iBeacon was a trademark for beacons, but Apple offered little value in the iBeacon brand. You could adopt the iBeacon mark – or not. There was little incentive for beacon manufacturers to proudly wave the iBeacon flag, because it offered little assurance to end purchasers. Sure, it said that “this beacon can be heard by iPhones” but this caused more of a limitation than an opportunity – because the obvious next question was “What about Android?”
• Apple lawyers got in the way. The company aggressively protected its ‘iBeacon specification’. But the move was kind of like trying to protect a proprietary version of WiFi – it’s a technology everyone needs to use, and by ‘blocking’ access it created market confusion and all kinds of end-runs around the iBeacon standard.
• iBeacon detection became (even more) unpredictable. With every new OS release, you’d have to test all over again. The dependability of beacon detection kept changing. With one release, you would detect beacons quickly, and with the next O/S it seemed as if Apple was trying to conserve battery and had toggled back beacon monitoring. Without the ability to dependably say how long it would take to detect a beacon, and without being able to see ‘under the hood’ developers were faced with constantly checking their assumptions about beacon detection every time a new version of iOS was launched.
• There was little integration with other parts of the Apple ecosystem. Have you ever tried to register your “place” with Apple? I can barely find the page. Google, on the other hand, offers much deeper integration with other parts of their ecosystem – in part because of how far ahead they are on things like maps, places, nearby and other protocols.

But perhaps more than the above, Apple neglected the one thing that it does best: focusing on the end user.

Instead, it has allowed app developers to make what they will of iBeacon and BLE, while offering little guidance on how to create great consumer experiences. As a result, we’ve seen struggles in develop “hits” – apps where consumers truly get a ‘wow’ factor.

This isn’t solely Apple’s fault, of course. Instead, the company has focused on other broader experiences – and will perhaps one day bring iBeacon back into the fold.

Physical Web is a Game Changer

Google, on the other hand, looked at the experience of proximity and has created beacon-detection tools that make sense – the Eddystone protocols are well considered, have rich documentation, great examples, and tight integration with other services.

But the true game changer is the Physical Web. And while it’s early days, the Physical Web creates opportunities for user experiences that truly make a difference – by hooking proximity into the web itself.

With the shift to browsers that can detect and control all kinds of BLE devices, the Physical Web is one part of a larger shift to a Web which reacts to the physical world – and in this open world Google will always be master.

The tension between open and closed systems will continue to tug and pull, but for right now open is winning and Apple is left behind.

WWDC – What’s Next?

All of which leaves Apple with one last chance – to elevate iBeacon from orphan child to star of the show.

If Apple makes a move, it won’t be to enhance the ability to deliver coupons. It will be part of a larger ‘connected space’ strategy which may incorporate Apple News, Music or other products.

But it’s a last kick at the can for Apple, in my opinion. Because depending what approach they take at their Developer Conference in a few weeks, developers may well migrate to a “Google-only” proximity strategy (including the use of Google tools on Apple devices).

It’s up to Apple, as they have many times before, to take what others have done and make it their own. But in this case, the mistakes they need to learn first are their own.

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.

Do you think Apple can change the game? Or will Google now dominate proximity? What could Apple do next with iBeacon – or is it too late? Drop a comment below, or pop me a note on Twitter.

BeaconControl: Open Source Beacon Management

Launching this week, BeaconControl is an open source platform for managing proximity experiences using Bluetooth LE beacons.

It promises to help extend the stack of tools available to developers, organizations and brands and allow for more seamless integration with existing systems.

“The platform eliminates the need to focus on low level issues such as hardware integration, security and beacon deployment,” Marley Fabisiewicz, Founder of BeaconControl, tells me.

His Warsaw software agency Upnext has developed BeaconControl. The open source platform includes a suite of software tools which includes:

• SDKs for iOS and Android
• An open source Web management tools based on Ruby on Rails (with a RESTful API), and
• A free mobile app for beacon deployment and set up.

The company is partnering with Kontakt.io to provide the first “deep integration” with the physical beacon itself.

This allows developers and organizations to physically configure a Kontakt beacon and have that configuration link to the BeaconControl dashboard.

Why Beacon Management is Needed

When Apple launched support for Bluetooth LE proximity detection through its iBeacon specification (and accompanying iOS developer tools), brands and organizations often struggled to both understand and implement beacons into their mobile experiences:

• You needed beacons. Most of the beacons on the market came with back-end management systems. Some of those systems were required if you wanted to use that vendor’s beacon. Gimbal was an early example of a beacon company whose back-end system (while rich and robust) was what you were really buying when you bought one of their beacons.
• You could use third-party management systems. If you chose beacons that didn’t require that you use their management systems you could turn to one of the dozens of start-ups offering proximity management platforms.
• You could choose to build your own proximity management system. This could be a costly proposition. It came with the added challenge that the technology was relatively new, support for Android was still in its early days, and best practices for user experiences were yet to be established.

With Google announcing more robust support for proximity and beacon detection and putting their weight behind the Physical Web (through the open source Eddystone protocol), the management of beacons has become even more complex.

And while Google itself now offers a degree beacon fleet management services and basic tools for delivering content, a developer or business still needs to think about how their beacon infrastructure will support the end user experience across a myriad of devices – from Android phones to Apple Watch.

Building an Open Source Beacon Management Community

BeaconControl hopes to help accelerate the proximity industry by making its tools available under an open source license, and to encourage developers and engineers to support its development.

Fabisiewicz tells me that developer involvement will help build momentum for BeaconControl:

We have already entered great partnerships with the Silicon Allee campus in Berlin and the NewLab in New York City to develop sustainable, “technology enabled workspaces” based on BeaconControl. We are in talks with various startups and corporations who have expressed interest in BeaconControl. But at the moment we would love to see developers start using the platform and contribute to the movement.

Developers can check out the BeaconControl code on GitHub and contribute to improving the web-side management dashboard.

For the more technically-minded, Fabisiewicz explains the architecture:

The core stack is Ruby on Rails and that’s how it will stay in the future as we deeply believe in Ruby on Rails.

In terms of mobile integration we are already providing iOS SDK and Android SDK is coming soon, so the mobile mobile landscape is currently covered.

Beacon Control is designed with Service Oriented Architecture in mind, so that any technology stack can integrate it and use it through the REST APIs. Depending on community feedback, we will consider developing wrappers in other languages.

What Does It Mean for Businesses?

For organizations looking to deploy beacons, you need more than just a device. You need a way to manage the interactions that go with a beacon.

You can choose a beacon provider who has accompanying dashboard and management tools, but risk vendor lock-in. Or you can work with a “platform” (from Urban Airship to any of the dozens of proximity providers who specialize in the field).

These approaches have pros and cons: from cost efficiency and speed-to-market, to being able to rely on vendors whose sole purpose is often thinking about and developing for proximity.

But if you have the resources, or if you have the need to integrate proximity campaigns into existing systems, developing your own beacon solution has often seemed a viable approach.

Now, you’ll have the option of using an open source library to get your project started.

Developers Unite!

If it can involve a larger group of developers, BeaconControl could potentially become an emerging standard for proximity management.

With a new generation of sensors and beacons on the horizon, this open source approach can give the industry a leg-up on its ability to respond to technical change.

Its founder tells me that:

We are at the very beginning of proximity technology and we think that BeaconControl can evolve into a platform that supports various types of sensors in the future. Currently Mesh beacons are a very interesting technology, they can turn the current generation of location-broadcasting beacons into a two-way, Net-connected network. Generally we think that proximity technology has the potential to change the world, but it will take time and a lot of effort like with mobile payments.

BeaconControl might also be a sign of things to come. As the industry shakes out, more companies may choose to open source parts of their technology in order to focus on other areas: consulting, analytics or infrastructure management.

For Upnext, BeaconControl is the perfect fit for an agency that focuses on innovation and mobile experiences.

As Fabisiewicz tells me, BeaconControl opens up a range of possibilities for his company:

First and foremost, we are aiming to create a community that builds the physical web and the IOT. We are trying to give innovators and technologists a headstart with our platform. We will eventually make money by consulting with companies to integrate BeaconControl into their applications. We are also thinking of marketplace (like an app strore) for BeaconControl where the entire community can distribute their add-ons for BeaconControl and monetize them.

BeaconControl will help to kickstart new forms of innovation in the proximity industry and will attract developers who are inspired by working together to create new standards and best practices. It represents a milestone on the beacon industry and is, perhaps, a sign of things to come.

Share Your Thoughts

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

Is BeaconControl what you were waiting for? How do you think an open source proximity management platform will impact the industry? Will start-ups who sell proprietary solutions need to consider their own open source strategies? Drop a comment below, or pop me a note on Twitter.

Beacons, Apps and Data Ownership

Bob! Get in the sled!

Guest Post: Thomas Walle, CEO and Co-Founder Unacast

During my attendance at several conferences about beacons, proximity and location based marketing the last couple of months, the conversations and discussions with peers have started to heat up. Especially in recent is the Street Fight awards, where Unacast won the best mobile marketing campaign for our work with Coke and Capa Cinema. In my view these heated discussions are needed to ensure we all build our industry together in the right direction.

In my experience the most heavily discussed topic during coffee and lunch breaks at every event, without exception, is data ownership. And when data ownership is brought up, people tend to get their spikes out, instinctively. The reason for this is not clear, but it´s probably linked to the fact that they know, or at least have heard, that data is gold and needs to be protected by all means.

 To app or not to app

Another common topic is how to get started with beacons when the retailer doesn’t have an app. The rise of beacons has encouraged marketing teams all over the world to rebuild and re-launch their existing apps to take advantage of the possibilities beacons open up. Others, without a current app are hard at work developing a new app and a strategy surrounding it. With beacons, there’s finally a good reason to invest in an app strategy.

However, there is still a large number of retailers and brands that decide not to develop their own app, but would still like to take advantage of the beacon technology. There can be many reasons for choosing not to develop – the investment required to build the app, the marketing required to get people to use the app or the fact that they want to reach a large audience immediately without growing their app base organically. For some companies, I agree that such a decision is the right one.

What we see these retailers and brands with no app do, is that they turn around to a 3rd party app with an existing and large user base. The retailer deploys beacons in their store and allows the 3rd party app to listen to the beacons, send push notifications and collect data.

“All in all, this is great news for all of us working in the proximity industry, more deployments, use cases and adoption is what we need”

But, this is also where a big challenge arises. The two topics I introduced in the beginning, data ownership and use of 3rd party apps, intersect. The following example is something we’ve seen being played out several times among our Unacast PROX partners:

The app owner claims ownership of the data as the users are using their app. At the same time, the retailer or brand claims ownership over the data as the beacons are installed at their location and the users are their customers since they entered their store. Then, the discussion goes back and forth a couple of times, but what then sometimes happens always surprises me. The retailer or brand, too eager to start using beacons, accepts the 3rd party app´s demand and gives them the ownership to the data.

“WHAT? Why did you do that? Why do you give away the most valuable asset? Finally, you can leverage and utilize data about your customer’s offline behavior, but you choose to give it away?”

These are exactly the words that run through my head every time I hear this happen.

I can’t be more clear about this – the use of beacons are not only about push notifications and in-store promotion. The most important aspect and where the true value lies is how this data can strengthen your customer knowledge, online marketing and omni-channel strategy.

As always, by cooperation and sharing, we move forward

So, how can this be solved? Luckily, it’s manageable. It´s all about redefining what data ownership means and how it’s governed in the relevant agreements between the involved parties. Instead of talking about data ownership, owned and guarded by (usually the strongest) party, cross-licensing of the data, where both parties have rights and access is the solution. Several of our partners in the PROX network have seen great success with this setup and we advise them closely on how to make this feasible.

What we see is that when cross-licensing is introduced, the 3rd party app becomes more popular with more retailers and brands wanting to connect to it for beacon purposes. And this is why I believe 3rd party apps should also embrace cross-licensing. All apps want more users, that is their currency.

And by allowing cross-licensing they will, 100% guaranteed, attract more retailers and brands, increasing the 3rd party app´s monthly users and consequently their value.

We all agree that proximity is at an early, but promising, stage. However, to really accelerate market growth and adoption, all the involved parties need to play together to make that happen.

It is worth taking this heated discussion upfront now to ensure we all build this industry together, and in the right direction.

And, it goes without saying, all usage of data should always have the consent of the end user and deliver real value back. But you already know that of course.

It takes two to tango. It takes two or four to pilot a Bobsled. Etc.

– Thomas Walle, CEO and Co-Founder Unacast

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.

The Future of Beacon Technology | Guest Post

Guest Post by Jakub Krzych, CEO and Co-Founder of Estimote

Jakub Krzych is CEO and Co-Founder of Estimote, Inc.

In this (epic) guest post, he provides his thoughts and insights into the future of Web and mobile apps, the introduction of Google Eddystone and beacon support, and his vision for what it takes to bring digital context to the real world.

Mobile & web apps and the future of beacon technologies

It’s been almost two years since Apple launched iBeacon, its own beacon format, and kicked off the contextual computing revolution. For the first time in computer history, a massively distributed and popular consumer device such as an iPhone was able to sense micro-location information broadcast by tiny, battery-powered radio devices.

The most important innovation was removing all of the friction in user interactions. Before iBeacon, it was possible to use QR codes and pass contextual information to the phone, but it was inconvenient: pulling out the phone, opening a QR code scanning app, focusing the camera on the code, etc. With beacon technologies, users just need to enter a beaconified location and a pre-programmed action will automatically appear on the screen—frictionless.

Apple made this technology elegant, privacy-oriented and straightforward. They anticipated billions of devices advertising their presence, thus they designed the iBeacon format to consist of 20 bytes containing a static identifier (UUID + Major + Minor)—enough to number all the objects on earth.

When a phone discovers the beacon and picks up the identifier, it triggers an app and the action assigned with that beacon. That is the most beautiful part of this elegant design: an app searching for a specific beacon is required. That means this technology is opt-in only. Apple knew that powerful and frictionless experiences might also put users at risk of being spammed or tracked without their knowledge. That’s why users have to explicitly opt in by simply downloading their favorite store or brand app. By doing that, they allow app creators to push notifications to their phone or to use location services.

When a user feels that the app shouldn’t use her location or that there’s not much value behind the app, she removes it. That is actually why many app developers concentrate on delivering amazing value to users.

If a user boards a train, arrives at the destination, and gets a notification with the ticket automatically charged to her credit card, that would be a magical experience. Or if she arrives at the airport and the app says exactly where to go and she is checked in by walking to the gate, that would be an amazing frictionless passenger experience.

However, it’s one thing to broadcast a static identifier and trigger hard-coded actions and another to engage with users through dynamic app content.

When a user walks into a furniture showroom and approaches the sofa she likes the most, she can see the picture, description, or price on her smartphone. But this data might change over time. In order to maintain it, developers might either hard-code all the new data into the app and push the new version to the App Store, or the app might simply fetch the data from the server by passing beacon identifiers to CMS solutions, where marketers could keep the content up-to-date.

Eddystone by Google and the mobile web

But what if we want to interact with many brands and many airports or retail stores? Do we need to download all these apps? Not really.

Google recently released a different beacon format called “Eddystone.” Unlike iBeacon, it doesn’t broadcast only an identifier, but also a pre-programmed website URL. So instead of having many different apps fetching contextual data, we might have just one, and it can simply be the web browser.

A similar shift happened in the early ‘90s. There were many standalone apps exchanging data with servers using different data formats. There was, for example, the FTP protocol and the FTP client app, IRC and its client, Usenet, Gopher, Mail, etc. Over time, most of these services moved to the web and were consumed by the internet browser, which could run on any computer, any processor architecture, and any screen.

It was faster and cheaper for developers to design, build, distribute, and update web apps. Broadband and modern browsers made it impossible for users to distinguish the so-called Web 2.0 apps such as Gmail, Google Maps, and Google Docs from their standalone competitors like Outlook or Excel.

That trend is not visible in the mobile world yet. Most of the popular services such as Snapchat, Facebook, or games still run as standalone native apps. It’s because of performance: native apps can run much faster, they optimize battery consumption, and they have access to low-level peripherals such as built-in sensors, cameras, memory, etc.

Over time, the defragmentation of mobile devices, platforms, and screen sizes might again result in a shift towards web apps, especially if browsers become faster and gain more access to low-level peripherals. Google, for example, recently released a Chrome browser for iOS that can natively scan for URLs broadcast by beacons. This might become the promise of a single app talking to many beacons.

Web app or native mobile

One app installed on the phone and responding to all beacons might be an elegant solution to the app distribution problem.

Nevertheless, the most progressive brands and retailers, with their innovative mobile teams, will keep investing in their own loyalty or in-store-experience apps. They know that the only way to have  full control over the data, branding, and end-to-end user experience is via standalone apps installed on consumer devices.

They also know that the only way to convince users to download these native apps is to provide them with amazing value. Beacons help with that, by removing the friction and making apps smarter.

UI and UX designers can leverage beacons to understand the microlocation or context of their users. Also, by using additional data from sensors, such as motion or temperature, user interfaces can be simplified or sometimes completely reduced.

Beaconified apps help their users focus on the main goals behind the apps and can impact important metrics such as engagement, usage, or retention.

Scaling beacon deployments

The typical app beaconification process starts with experimentation and prototyping. A proof-of-concept app is created with just a few beacon dev kits. Pitched internally, it can often attract attention from product people and decision-makers. Once an app is budgeted and the mobile team allocated, the proper app development process starts. After few weeks or months of app development, beacons are deployed to the production environment.

For airports, shopping malls, or huge retailers beaconifying enormous spaces and thousands of locations, deployment might be a logistics nightmare. They will most likely optimize for the simplicity of the installation and maintenance as well as the cost of that operation. It’s easy to calculate that a workday of deployment crew to complete the installation, configuration, and testing, multiplied by thousands of stores, can result in multimillion-dollar bill.

That is the main reason it’s unlikely that large beacon deployments will install beacons that require power cords, manual configuration, and floor-plan assignments. Even tiny details such as the lack of a built-in adhesive layer can impact the efficiency of the deployment.

On batteries and hardware upgrades

For the same reasons, it is unlikely that retailers will replace batteries in their beacons. The cost of that operation would be higher than installing new ones.

Once installed, beacons should last long enough that they can be replaced with the new generation: technology cycles in that industry move fast. Last year, Bluetooth SIG released two updates of their BLE standard and one of them requires completely new hardware for both the beacon and the mobile phone. So three-year-old beacons will be obsolete anyway.

However, software or hardware upgrades shouldn’t affect applications running on top of this infrastructure. The most progressive beacon companies will not only optimize the cost of deployment but also the simplicity of the migration.

For all of these reasons, it’s clear that retailers won’t install multiple beacons broadcasting exclusive data formats for different mobile platforms or apps. We shouldn’t expect that there will be beacons only for Microsoft, Google, or Facebook. It just won’t happen.

There’s nothing preventing beacons from broadcasting as many packets as we want. They’re just tiny computers, after all.. These packets can also consist of whatever data we want. That’s why any customer who purchased Estimote Beacons in the past can simply update them over the air and turn on an Eddystone packet or switch to iBeacon at any time. No new hardware is required. At Estimote, we are committed to supporting whatever the popular future beacon format is.

We expect rapid development of beacon technologies, new formats, sensor integrations, and security updates. That is why we advise our customers to choose a beacon partner wisely and to make sure purchased beacons can be frequently and effortlessly updated with new firmware.

Remote fleet management

An elegant and easy fleet management technique including firmware updates isn’t a huge challenge. Each and every beacon is a tiny computer and can connect to phones or other beacons. It can also exchange configuration data, including firmware.

That is why at Estimote we do not have additional devices or hubs to configure or upgrade our beacons. All the beacons can be upgraded over the air, and we use technology already built-in to the phones. When users visit different locations and their apps interact with beacons, they can simply connect and update beacon configuration or firmware in the background: it’s just a few kilobytes, so there is no impact on usage. And it’s 100% secure and respects the user’s privacy—no personal data are collected or transferred.

Because of the operation cost argument mentioned before, there’s no point in installing additional hardware to remotely manage beacons. Whenever beacons are installed, users with compatible apps should be in the proximity. After all, if there are no users around, why are beacons there?

On security and risks

Part of the fleet management routine should also be security updates. Many retailers or airports investing in beacon infrastructures are very sensitive to any potential vulnerabilities of beacon networks.

We can easily imagine airport passengers receiving notifications about cheaper flights to the same destination from a competitor airline exactly when they check in at the gate. Or, consumers visiting retail stores might receive coupons from E-commerce apps detecting their location in specific departments, causing a showrooming effect.

All of this could happen if competing apps sense the presence of beacons and remember their static identifiers. Since beacons are tiny computers, they can dynamically compute these identifiers so that only authenticated apps could decode them. This is exactly how we implemented Secure UUID mode. Our customers who want to protect their networks can simply turn on Secure UUID, and competing apps won’t be able to easily resolve the location.

Of course, every computer technology is hackable. But even if that happened, the risk is still very low, because there’s an additional layer of security: the Apple App Store approval process. Apple would never agree to publish in the App Store software malware that would basically have access to information it shouldn’t. These days, App Stores are the main distribution channels for apps, so respected app creators won’t risk dealing with Apple on that front.

Infrastructure sharing and innovation acceleration

Once the network of beacons is built and secured, there might also be opportunities to share it with other app creators. That is why we built a feature we call “beacon infrastructure sharing” on top of our cloud and beacons. Our customers can allow any app to take an advantage of the infrastructure and the context established in the venue.

We see retailers enabling different brands to use beacon infrastructure so their apps might trigger notifications when customers visit a partner retail environment. The same with airports, which might share different terminals or gates with different airline or duty-free apps.

We should expect that in the future, locations that are attractive and offer value to visiting consumers will sell access to their beacon infrastructures, via exactly the same model we’ve seen on the web with popular websites and ads. If someone creates a website with high traffic, they can make part of that website available for banners, cookies, or widgets as long as those components don’t confuse users. Otherwise, that website would lose them quickly.

With the security component and infrastructure sharing, any beacon network owner can invite third-party apps and offer campaigns for a specific period of time. For exactly the same reason that the visual language of layouts and banners have been used on the web by agencies and web owners, there must be similar visual language to manage campaigns and interactions in physical venues. That language has been already created: it’s called “floor plans and maps” and has been used by retailers, airports, museums, and their suppliers for years.

Indoor location with beacons

Being able to quickly deploy hundreds of beacons and see them immediately on a floor plan has been always a long-term goal for Estimote. Every day we get closer to that vision because of our heavy investment in beacon-based indoor location.

We’ve built an amazing data science team that has created robust indoor location algorithms and SDKs that anyone can build into their apps to achieve an accuracy of locating people and their phones inside a building to within just a few meters.

In order to make this extremely simple, we invented an auto-mapping tool. Even if the deployment crew doesn’t have a floor plan, they can map the space automatically using our Indoor Location App from the App Store. They just need to walk around the room once. The mapped space and beacon locations are automatically saved in the cloud, where they can be edited, managed, or shared with third-party apps.

There is also an analytics component venue owners can use to better understand the behavior of their users in their locations. The RESTful API makes it extremely simple for integrations or deeper insights.

The privacy issue here is solved by the same opt-in mechanism explained before. If users are offered strong value such as wayfinding, asset tracking, etc., they will download an app with a built-in Indoor Location SDK and explicitly agree to be located.

Knowing the exact location of people and being able to resolve their context is one thing, but having more insight into their interaction with the objects around them is another. Both of these components can help to design amazing context-aware mobile apps and experiences. That is why at Estimote we have also invested heavily in sensors built into beacons and invented “nearables.”

Using tiny beacons in the form factor of stickers, users can turn ordinary things into smart, connected objects. These objects can broadcast into the air not only their presence, but additional metadata such as temperature, motion, orientation, and state duration. This is all possible because of our very own connectionless Nearable Packet, which we introduced last year long before Google started to work on Eddystone.

Apps for the physical world

If you combine all of this—beacon infrastructure sharing, easy-to-use, and precise indoor location, plus nearables—you will very quickly understand where this is going. Finally, all these components make it possible to build real apps on top of physical locations that are full of objects. It’s a tremendous shift from apps designed for phones to apps designed for airports, retails stores, or museums.

For example, Estimote apps designed for one museum can be “run” on top of any museum that is “compatible.” A scavenger app built for one retail store can be scaled to thousands of stores. That is the long-term vision behind beacon technologies: to make it extremely simple to develop, configure, deploy, and distribute apps for physical locations.

At Estimote, we have been executing that vision since the day we launched this project. We interact with many pioneers in the community, and we are very proud of their help in making this technology better every day.

We are extremely excited that all the major players, including Apple and Google, are fully on board with beacons, and we look forward to seeing what comes next and how contextual technologies will evolve. The most exciting part is the fact this is still at an early stage, with many innovations and pioneer inventions ahead.

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.

Come on – let’s give a shout-out to Jakub. Epic post – and lots to think about. What do you think he gets right (or wrong) about the future of mobile and web apps in the era of Eddystone and iBeacon?

Kontakt to its Customers: You’re All Doomed

Kontakt, one of the largest manufacturers of beacons, has a message for its customers: you’re all doomed.

In what might rank as one of the more bizarre examples of corporate messaging, the company’s founder has taken to LinkedIn to pronounce that with the arrival of the Eddystone beacon protocol (and related services) by Google, proximity companies are headed for the dust bin if they don’t radically change (and soon).

“Ask not for whom the bell tolls, proximity devs: it tolls for thee,” proclaims Szymon Niemczura.

But extending the logic of Szymon’s article, you can’t help draw the conclusion that it isn’t just the devs who will pay the price for Google’s entry into the market.

If you’re a retailer, a brand, a museum, a car company, a city or a theme park – you too should just throw up your hands and give up now.

Google will own mobile moments, the borg has arrived, and closed off becosystems will look something like AOL in the years to come: a walled garden that no one visits anymore.

And Apple? Naw. Says Szymon:

With a vanishing share of the smartphone market, the last thing the house that Steve built wants to do is give developers even more reason to jump ship.

Ah yeah. Poor Apple. Poor shrinking tiny little Apple. It’s hard to remember that they’re still around! It will be cute to see what little features they try to throw at us to protect their ever-vanishing market share and profits.

What’s Your Secret Sauce?

Now, I like Kontakt. They’re some really really smart people.

(Although, what’s with the videos that look like they were shot at summer camp? And by the way – audio engineering is a thing).

So maybe they have a secret sauce as Szymon claims: “At Kontakt.io, we think we’ve found our special sauce that will keep us growing and thriving as giants of the Internet space like Google, Apple, Facebook, and others compete over who earns what from the IoT.”

In response to which I have a question: China?

Because if Szymon’s observations are true, then the beacon itself has become king. The app layer, the SDKs and the software, the cloud services and back-end analytics will be swallowed up by the Web.

The promise of Eddystone is that you can turn your beacon into a Web endpoint and simply broadcast a URL.

And if that’s true, then it opens up the opportunity to flood the market with cheap beacons from China that do nothing more than broadcast a URL.

Do You Jump Into Bed With Google?

Setting aside the tone of Szymon’s article, it points to a larger question.

Because what’s clear is that Google has hit a home run. Eddystone is everything a beacon should be.

Google took a page from the Apple playbook: wait for the industry to develop, cherry pick the best ideas, and then come out with something that does everyone else one better.

The Eddystone format is brilliant.

But now you need to make a decision: do you go “all in” with Google, do you try to find a middle ground, do you focus on the “app-less” layer or combine different proximity experiences to create a unified customer journey?

Creative Tensions Between Open and Closed Systems

The way you answer the above questions will have a big impact on what kind of beacon you buy and what kind of customer experience you want to create.

In an interview with Kontakt, they clearly think that the “app-less beacon world” is a big deal:

Along with yesterday’s release of new Chrome browser for iOS with support for a Physical Web standard this became clear – proximity devices are able to communicate with our phones without the need for other apps. This means a Physical Web is finally visible and ready for broader adoption.

But here’s the problem: what does “communicate with our phones” mean?

Is that all we really want to do? Is your vision of the mobile world one in which the Web has won?

Szymon is right:

“10 years in Internet is effectively forever, and it’s a rare startup that considers what the landscape will look like as far out as two years, but this matters, so I’ll point it out: native capacity to push alerts and more direct from beacons to devices kills a huge number of app use cases.”

Truly, the traditional definition of an “app” is eroding.

There will be apps that sit on your phone but that you’ll never use on their own. Instead, they’ll be shared as ‘sheets’ inside other apps, provide deep linking capabilities, and sit as a kind of invisible thread across an ecosystem of experiences.

But that doesn’t mean that apps will be replaced by whatever Google has to offer, anymore than it means that HTML will win in the war against native.

Which is why Eddystone does more than just broadcast Web pages (although its ability to do so will open up some pretty great user journeys).

Like many engineers, Kontakt seems to be more interested in the transactional nature of systems than the very real human experience they entail.

(Just look at Kontakt’s Web site or its developer portal and you’ll see what I mean – they feel like were designed in 2002 by a bunch of engineers one weekend).

The implication here is that in the tension which will always exist between open and closed systems, the pendulum has swung: open will win, Google is right, native is disappearing and apps are dead.

If you’re willing to make that bet, great. Go for it. At least you’ve taken a stance! And perhaps in the longer arc of history you’ll be right – but until then we still have to worry about today.

What Kind of Beacon Will You Use?

In response to questions about Eddystone, Kontakt tells me that you’re going to need to make a choice (at least for now) in which of their beacons you choose: Eddystone OR iBeacon.

Why? Because battery.

In an interview, Kontakt tells me:

Our beacons broadcast 4 different frames one after the other: 3 advertising packets (Eddystone-UID, Eddystone-URL, Eddystone-TLM) and a scan response. To the best of our knowledge, Kontakt.io is the only company on the market who has offered that from day one.

We have been investigating the possibility to add also an iBeacon frame to the set, but broadcasting that many different packets is going to cause a pretty heavy battery drain. While we research ways to help keep a useful battery life on our product, we will also be looking at client demand for this feature. We don’t have any timeline on when we may roll this out, as it’s very much just in R&D right now.

Which is odd, considering that if you don’t interleave with iBeacon, then your beacon battery might be fine, but the iOS user’s won’t be. By relying on Core Bluetooth instead of the native framework from Apple, you can expect Apple users to take a hit on battery life if you’re solely relying on the Eddystone format.

These kinks might be worked out, but it’s an obfuscation to say that it’s your beacon’s battery which is the sole limitation.

In fairness, Kontakt isn’t entirely advocating a “throw out your iBeacons” stance. If you’ve got some of those old beacons lying around then sure, why not, you should hang on to them. (But I guess you should know that you’re missing out on some huge potential):

Every discussion regarding iBeacon and Eddystone formats, and which one fits our client needs better, always starts with a question about use case details. Eddystone opens new possibilities, but at the same time requires more complicated coding to integrate as it sends more types of data than iBeacon does. Beacons that use Eddystone-TLM format to send telemetry data (such as temperature data) will have shorter battery life because they are sending more data packets etc. All of that needs to be taken into account before we jump on the Eddystone bandwagon.

In general, I think that “switching” is probably not the correct choice for anyone with a live deployment right now. Anyone with a P.O.C. that’s running, though, or someone who’s in early tests? I would strongly encourage that those people try this out because this whole platform is growing in exciting ways and has huge potential.

For many use cases, an Eddystone URL format beacon might be fine. You might be able to move the needle a bit on customer engagement.

For everyone else, there are larger questions at stake.

Kontakt itself hints at this future. With the coming wave of mesh beacons, the company’s Cloud Beacon takes aim at what will happen when the next Bluetooth specification starts hitting the market. The company tells me they have big plans, and that those plans validate why its Cloud Beacon format isn’t threatened by Google’s Proximity API:

Our Kontakt.io Cloud Beacon remains the only enterprise-level tool for beacon monitoring that we’re aware of: if you need to be able to guarantee that you are scanning and looking at beacons in a given area at regular intervals, a Cloud Beacon is your best bet. On top of that, Cloud Beacons are part of our other real competitive advantages: security and sharing.

In the future we will introduce completely encrypted channels for communication between beacons, cloud beacons, and smart devices. This, combined with powerful features such as our scheduled profile shuffling (driven by our API) and the industry’s only Power Sleep mode designed to extend beacon battery life, means that the Cloud Beacon still has very strong USPs that make it an attractive prospect for any company looking to roll out beacons on the large scale.

An Industry Transformed

The industry has been transformed with the launch of Eddystone.

For beacon manufacturers, a new wave of low-cost alternatives from China will put pressure on them to tighten up the value-added services they provide, the relationships they have with developers, and the level of execution they put into their user documentation, community management and marketing.

For developers, the range of opportunities has expanded rather than contracted.

But while Eddystone might seem to cut through the clutter and remove barriers in app development it also creates a richer, and thus more complex suite of choices for brands, retailers, cities and cultural institutions.

I have deep faith in this industry.

I don’t need to give any of you a wake-up call or tell you that you’re doomed. Because for the 100s of proximity companies I’ve talked to, and for the hundreds of brands and retailers we’ve interacted with (and who are doing their best to make sense of a rapidly changing world), I’ve found that optimism in the face of progress is the best guarantee of innovation.

And this week, we’ve entered a new era in which to thrive.

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.

How will you respond to Eddystone? Is this a new era of doom or one of innovation?

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.

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.