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?

Advertisements

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.

Google Loves Apple (In a World of Beacons)


 

The launch of Eddystone by Google has, at long last, addressed a challenge in creating proximity experiences with beacons. Namely, that the software tools for beacon detection and interaction were less robust for Android development than for Apple devices.

The media narrative, as always, paints the move by Google as a showdown between Eddystone and iBeacon.

Mashable calls Eddystone a rival, Ars Technica announces that iBeacon needs to move over because Eddystone is a fighter, and Tech Republic concludes that it has clear advantages in the showdown with Apple.

Now, you can’t blame the media. It makes good copy.

If Google launched some kind of self-driving toilet paper the media would call it a rival to the iPad, siphoning off valuable screen time from its arch enemy in Cupertino.

And while there’s a broader truth to the Apple v Google narrative (which I’ll get to in a minute), the truth is that the move by Google has made life easier for brands, retailers, developers and device manufacturing companies.

What Your Clients Need to Know

If you work in mobile development you’ll know that the last thing your clients need to hear is that there’s yet more fragmentation – between Android devices, between Apple and Android.

The good news is that, at the simplest level, Google’s announcement of the Eddystone beacon format (and the accompanying development tools) means that we can now create beacon experiences for both Android and Apple devices in a way that assures a higher level of confidences that the experiences will be on par.

Better yet, Eddystone has added a few tricks to how beacons work that will benefit both Apple and Android apps. These tricks include the ability to embed beacon management functions inside your app (instead of needing to rely on some type of admin app or cloud beacon), a promise of increased beacon security, and the ability to link beacons natively to web URLs.

By launching an open specification and leveraging the capacity of beacons to interleave multiple signals, brands, retailers and venues can get the best of both worlds:

  • Android apps that respond as fluidly to beacons as Apple apps
  • Access to new beacon features across both platforms
  • No need to buy new beacons – especially if your hardware provider is one of Google’s preferred manufacturers (and we note that almost all of them are our own!). Just update your firmware and you’re good to go.

There’s No App For That

The second part of the media narrative about Eddystone is its capacity to deliver a URL in place of a unique identifier. The promise is that on Android, you’ll be able to deliver messages without an app.

Part of this promise will be reliant on what Google releases with Android M so it’s too early to judge how deep this promise will go. We’ve long speculated that the secret war horse for Google will be Chrome – a trojan horse on Apple devices that could conceivably contain beacon detection and help Google bypass the gatekeepers in Cupertino.

Regardless, the capability of reaching consumers without an app isn’t confined to Google.

Apple has been using Passbook to trigger beacon interactions and will be extending this through Offers, a new iAd “wrapper” on Apple Wallet. We assume that this will allow brands to target iAds based on location and allow the delivery of Wallet Offers (similar to Apple passes) which embed beacon detection (as previously available).

So while it’s a compelling value proposition – the ability to bypass apps entirely, it’s not confined to Google.

Who Owns The Experience?

It’s when we look beyond the beacon that the Google v Apple narrative starts to make a bit more sense.

Both Apple and Google give you tools to register your “place”. Both want to help you map your indoor location. Both want to provide “contextual experiences” through Siri, Google Now, and search.

And both want to serve ads:

  • Google wants to use all the data it can get to serve better (and more) ads across more platforms (including iOS)
  • Apple wants to generally keep the data anonymous but still wants to make money through its iAd platform.

Apple’s main focus is the user experience, and we can expect to see more and more tools to integrate beacons into payments, Apple Wallet, in-home connectivity, and location-based context. Google’s main focus is giving users better and better free tools and applications but in the larger service of ad revenue.

Neither approach is bad for brands or venues. But each provides strategic pros and cons – from sharing your data about your customers with Google through the lack of access to individual user data on the Apple platform.

But these trade-offs and decisions have nothing to do with the beacon. The choice to integrate that beacon, to make Google aware of its presence, to integrate it with Google Now (with the benefit of “app-less” consumer interactions but with the cost of providing Google data about your customers) are strategic ones.

As a retailer, you’re faced with the same questions you’ve already struggled with: who owns the data about what happens in your store, and are the trade-offs worth it?

But, again, those questions have nothing to do with the base function of the beacon, and are supplemental decisions about how far you want to go with Eddystone.

For now, it’s enough to know that beacons just got better, and users of both Apple and Android devices will benefit from the innovation.

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.

What do you think? Google has clearly done Apple one better with Eddystone. But is it really a “threat”? How will you use Eddystone?

iBeacon and Why Apple Streaming Music Might Be Free

Apple can make its streaming music service free. And it’s because of iBeacon.

The New York Times reports that industry analysts are predicting a tough climb for the company’s new streaming music service. Apple will need to shift from the pay-to-download model of iTunes toward the all-you-can-eat-buffet of streaming music. And in doing so, it will need to get the support of a music industry that can now turn to Pandora, Spotify or other services to push back on pricing and access.

But these reports are looking for the Apple advantage in all the wrong places – focusing on apps and pricing, iTunes and vivid visuals.

And while those things might be important, Apple has advantages that other streaming services don’t.

This includes access to a platform for music which is larger than the Web and bigger than mobile – a platform made possible, in part, by iBeacons.

Apple Is – Gasp! Not The First-Mover

According to Toni Sacconaghi, a financial analyst for Sanford C. Bernstein, Apple is late to the game.

“They’re used to being a shaper rather than a responder,” Mr. Sacconaghi said. “This is one of the few times where Apple is playing catch-up and not necessarily coming from a position of strength.”

Which makes me wonder what universe Sacconaghi is analyzing, exactly.

History has shown the opposite, of course. The entire Apple business model is based on coming late to the game – letting others get there first and arriving later with far superior products, whether music players, tablets, phones or watches.

If there’s a company on the planet who has shown it knows how to excel at coming second it’s Apple.

Regardless, the media seems happy to create a narrative in which there’s a good old-fashioned showdown between entrenched players like Spotify and the “newcomer” which is Apple.

Is The Apple Advantage an Interface?

These reports predict that Apple might have a shot because…well, because it will have a shiny interface:

The new music app, which is a collaborative effort between Mr. Reznor and other Apple and Beats employees, including Jimmy Iovine — who founded Beats with the hip-hop star Dr. Dre — will feature the streaming music service with many of the same characteristics as the Beats Music streaming service, one Apple employee said. Those may include curated playlists and a more vivid visual appeal, while conforming to Apple’s sleek and minimal design aesthetic, one person said. The name Beats Music will most likely be shed.

More vivid visuals. A minimal design aesthetic.

I can hear Jony Ive now, luxuriating over how every single pixel is perfect, hand drawn from molten gold with every musical note optimized down to nanogradients of sound.

The larger Apple advantage isn’t, of course, an interface. (iTunes has survived just fine even in its current incarnation as a benchmark for horrible UX design).

Apple’s advantage is its ecosystem, from the hardware to software, continuity between devices, and connectivity to your iPad, Apple TV or coming Watch.

If nothing else, Apple could drive a user experience which adapts a music stream based on whether you’re running or working out, can shift a stream from your iPhone to your home speakers with the flick of your thumb, and connect the mood of your music to the Philips lighting in your living room.

This ecosystem on its own, in addition to 800 million iTunes users, can give Apple an edge, regardless of the monthly price.

But there’s another frontier worth considering and it has nothing to do with the device in your pocket or the technology in your home. Because elsewhere the physical world is becoming a digital interface.

And streaming music could, one day, be embedded in things, with iBeacon showing us the way.

iBeacon and The Battle for Physical Space

iBeacon is Apple’s trademark term for Bluetooth Low Energy devices. By sending out a small radio signal, beacons allow our phones and other devices to “see” the world around them.

Beacons are being used in museums and public gardens, shopping malls and parking lots. They let the owner of a “place” send out a push message, a coupon, a piece of media or a special offer to a user’s phone via a ‘beacon-enabled’ mobile app.

Unlike NFC or QR codes, the user doesn’t need to do anything. Their app can be closed but their phone will still listen for beacons.

You can trigger a lock screen message or your app can just be a lot smarter when a user opens it up – sensing nearby beacons in order to present contextually relevant content.

Beacons represent one technology amongst many that are enabling digital interactions with physical space. Anything you can do online can now be triggered by people, places and things. You can “Pin” a store display, Tweet a painting in a museum, or browse a catalogue in the hardware store.

Often conflated with the Internet of Things (which generally refers to the ability of sensors and devices to talk to each other) they nonetheless represent a larger trend towards a fully connected physical world in which billboards know who you are (Minority Report style) and products on a shelf can talk.

Unlocking the Value of Proximity

This convergence of the physical world with digital affordances represents what we think is a platform that will be larger than the Web, which will be more disruptive than mobile, and which will enables new forms of value creation that weren’t previously possible.

With beacons we can link media, content, data and social interaction to the “last meter” of human experience. We can create digital engagement at the point of purchase, we can nudge users from one gallery to another in a museum, we can connect how we live, work and play to increasingly smart and data-driven systems.

This opportunity is both massive and massively frightening.

The convergence of the digital and physical worlds leads to self-driving cars and delivery drones, an apocalypse of artificial intelligence and the benefits of medical research conducted at massive scale.

It also unlocks value that was previously either unavailable, obfuscated or difficult: because if I can connect what you do on a phone to your presence in physical space, if I can connect a piece of media to the point of purchase, it means I can create a connection between digital media and physical activity or product purchases.

It’s this convergence which could both lead to a ‘renaissance of retail’ and its (even more) massive disruption.

In a future of beacons, we’ll see the “AirBnB of grocery” and the “Uber of retail”.

And we’ll see how things like music won’t just be portable. Their value will be embedded in everything.

The Next Big Apple Play is Loyalty

OK, I hate the term loyalty. Because most loyalty programs aren’t about loyalty. They’re transaction-based rewards for purchasing stuff.

I hate the idea of a product called called Apple Loyalty – it sounds like an airline rewards card or a bonus system for owning a ton of Apple devices (buy 10 iPhones and get a free Beats headphone!).

But if there was a company that was going to reinvent the concept of “loyalty” who better than the company that knows something about loyalty? And who better than a company leading the charge on mobile payments, with a growing infrastructure of merchants and payment providers, with the ability for stores to register their locations, and with the software tools to make beacon-detection part of the retail landscape?

Think of it this way:

  • You have two coffee shops near each other
  • One accepts Apple Pay, has iBeacon installed, lets you order in advance, makes the experience of buying your cappuccino frictionless
  • It also has a system in place where you show up, buy a coffee, and your Apple streaming music account is topped up or you’re able to pick up a recommendation from the staff or others who have visited the store

Or imagine going to a concert at a local club and there’s a “powered by Apple Music” sign at the front entrance.

You join a pop-up social network, you share some of your favorite Apple Music streams with fans nearby.

And once you leave your Apple Music account has been personalized, you have access to exclusive band interviews or raw clips from their last recording session, and your streaming costs for the month have been reduced by half because the concert promoter kicked back an account top-up with your ticket purchase.

An Apple patent for iBeacon imagines concerts as venues for media delivery:

Apple’s patent FIG. 15C indicates various location-based content that may be provided in connection with a concert or other music venue. A concert or music venue may provide content including, for example, music, setlists, virtual cards, website information, schedule information (e.g., for upcoming shows at the venue), graphics (e.g., album art, pictures of the band members, etc.), ticket sales (e.g., provide user option to purchase tickets in advance), general information relating to the concert, or any other information.

It’s not loyalty in the traditional sense. It isn’t about transactions it’s about experiences.

And it leverages the power of beacons: because for the first time, physical venues have a financial incentive and an ability to measure digital interactions against real-world behaviour.

If I own the coffee shop and I become an Apple Loyalty location I’m doing it because I can drive more foot traffic to my store compared to the one down the street. The fact that you as the customer get rewarded with Apple Music, if you get a bonus song instead of $2 off your next purchase, so much the better. I’d rather reward you with something you LOVE anyways instead of reducing your bill the next time you visit.

The coffee shop wins. Apple Music wins because it gets more “listens”. And the consumer wins because someone else is partly footing my music bill, and their experience of “place” becomes more deeply grounded in their digital and physical life.

iBeacon, Apple Pay and Apple “Loyalty” are simply the facilitating technologies which will help to triangulate our digital lives, our physical visits, and the interests of the places that we go.

Apple Everywhere

Apple isn’t alone in wanting to own the path you take through the world.

While Apple is focused on closed ecosystems and what I think of as “deeply connected” experiences, Google is coming at the same challenge from a different direction – using the “cloud” to provide an always-on, “deeply ambient” suite of technologies to help guide you through space.

Best typified by Google Now and Google Waze, their goal is to quietly collate where you go and how long you visit with its massive data sets in order to predict and present content that will become increasingly smarter and smarter. Google will know where you’re going before you’ve even decided yourself.

For Apple, the future is smart devices connected to relatively dumb “clouds” (an idea reaffirmed by Tim Cook’s focus on privacy).

For Google, the future is a smart cloud connected to relatively dumb devices.

But both are on a path to take your experience of them out of your pocket and into your home, into the stores you visit and into the music you listen to, television you watch, and games you play.

Beacons are part of this larger journey – dumb devices against which value can be assigned, music unlocked, experiences created, with the result being an absolute blurring of the lines between our digital personas and our physical bodies as they move through space.

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.

What do you think? Will Apple Music be more than just another version of ‘streaming beats’? How might it connect to Apple loyalty, Apple Pay and iBeacon? Drop a comment below.

Beacons Meet WiFi: Cisco Meraki Has Its Eye on Connected Spaces

Bluetooth LE beacons have shifted beyond prototypes and pilots into large-scale distribution. But this shift has brought us bumping up against the downside to a beacon’s elegance and simplicity. Because if a beacon is a relatively simple (and dumb) device, how do you intelligently manage them at scale?

One company thinks it has a solution. Meraki, a division of Cisco, launched a WiFi end point which can both act as a beacon and monitor devices in the area, report back to a cloud-based dashboard, and allow you to manage and shape WiFi traffic at the same time.

I spoke recently to the Meraki team. Adam Weis and Simon Tompson gave me an overview of their system and approach. For a company that’s managing massive networks of WiFi end points (70,000 hotel rooms in one case), they know a thing or two about fleet management.

And as beacons shift into distribution at scale, their approach will both help relieve some of the pain of beacon monitoring while offering the possibly larger advantage of being able to shape WiFi traffic and monitor WiFi networks from the same intuitive dashboard.

Beacons Call Home

The beauty of iBeacon (the trademarked term by Apple for its preferred configuration for the open standard of the Bluetooth Smart devices) was its simplicity. Apple did the heavy lifting in thinking about how beacons could be configured, provided easy-to-use software tools to help you create apps, and then stood back while the media branded the beacon industry with the iBeacon brush.

The move by Apple helped to accelerate an industry. By opening up support for beacon detection (and using your phone or tablet to broadcast as a beacon), we finally had a single standard that would work across all the major phone platforms. And by making the tools simple to use, it spurred a wave of innovation and testing which took advantage of the fact that a beacon doesn’t actually do very much.

Like any radio transmitter, a beacon transmits a signal. The signal contains a small packet of data (which also helps protect battery usage on both the beacon and the user’s phone), and that data includes unique ID numbers, some power and battery data, and a signal strength – all of which are used to identify which beacon you’ve detected and how far away you are.

But as the industry rapidly matured, this simplicity also started to show some cracks.

There was a scramble to make developing beacon detection for Android as simple as it was for Apple. And with Apple willing to enforce its trademarks and proprietary specifications, we started seeing separate beacon broadcasting specifications emerge, with a better-known example being the AltBeacon standard.

Beacon manufacturers emerged and took advantage of how relatively simple it was to build a beacon. But their simplicity came at a cost: it’s easy to create a beacon, configure it, put in a coin cell battery, and attach it to your wall.

But the beacons didn’t do much more than their original purpose. They broadcast a signal but they didn’t receive anything. If you wanted to reconfigure them or monitor their battery you needed to use an app while standing next to the beacon.

Your beacons, in other words, had no way to call home.

Managing Beacons at Scale

For a retailer, the idea that you’d deploy thousands of beacons across hundreds of locations and have no simple way to manage or monitor the devices without sending out staff seemed like a non-starter.

In the early days of the industry, more than one beacon company told me that managing your beacons wasn’t necessary: the devices were so cheap you could just throw them out when they died. But try telling that to a national retailer (or even a large museum!). Because the cost of training staff and sending them out to pop a new beacon on the wall was an instant deterrent to large installations.

The solutions included payloads embedded in user apps, extending the battery life through improved beacon performance, embedding beacons in light bulbs, or plugging them in. By making beacons last longer, the need to replace them would decrease.

But it was clear that beacon fleet management would quickly become a differentiator for the companies that could manage it well. Companies like Netclearance Systems launched a cloud management system and Kontakt.io recently launched its Cloud Beacon.

These solutions relied on placing another device in a store or venue: a sort of “hub” which could both call home and send/receive data, and could connect with beacons in the area in order to update their firmware, change their IDs, or monitor their batteries or performance.

In a World of WiFi, We Have An Endpoint

But Meraki thought it had a more elegant solution. Because why add another device to your location when you already need a box for the most pervasive endpoints available: WiFi.

The company has changed the game for how institutions manage WiFi infrastructure – moving us from the dark ages of what often looked like a command line interfaces to an elegant cloud-based solution that had a lot in common with the most intuitive dashboards available.

This was industrial scale WiFi management with a dashboard your mother might even love.

They took the pain out of managing WiFi endpoints. Organizations ranging from universities to hotel chains deploy, manage, monitor, secure and shape traffic for often widely distributed systems – and with Meraki do so in an intuitive way. (They were so successful that Cisco snapped them up).

So Meraki had a simple premise: since you’re already monitoring your WiFi with their endpoints, why not also use that same dashboard to monitor nearby beacons?

And while they were at it, they threw in the capacity of their WiFi box to ACT as a beacon – a boon to a smaller location that might not need a beacon in every aisle but just wants to send a beacon message when you arrive at the front door.

Their solution solved a simple problem: can I easily monitor all the beacons in the area, keep an eye on their batteries and other signals, and do something useful with the data?

Adam Weis, a brilliant guy and someone who helped drive a lot of the thinking behind the Meraki approach, explains:

Is Monitoring and Configuring the Same Thing?

The Meraki system is simple. It has an incredibly elegant and easy-to-use interface. It not only broadcasts as a beacon, but lets you monitor for ALL Bluetooth-enabled devices in its region:

It helps answer one of the more pressing challenges of fleet management: making sure your beacons are still working and that their batteries haven’t run out. By also monitoring other devices in the region, Meraki is providing a richer data set. I can now compare, for example, the number of total devices and then cross-tabulate that data to the number of beacon “app impressions”.

Meraki can’t, however, update a beacon’s firmware or update their UUIDs. To do that, you need to be able to “pair” with the beacon and the pairing is usually handled by tools provided by the beacon manufacturer. In many cases this might not be an issue – but an ideal scenario would be for Meraki to also partner with beacon manufacturers to allow institutions to also PAIR with the beacons via the Meraki dashboard.

In the meantime, it’s where solutions like the Kontakt Cloud Beacon come in – systems to manage your fleet of beacons and their ID numbers, but without the advantage of being a full WiFi endpoint.

WiFi + Beacon Is A Big Win for Many Use Cases

But let’s face it – in many cases, Meraki is enough. A library, for example, probably doesn’t need to swap the UUIDs of its beacons very often and firmware updates aren’t usually deployed, or rarely. And Meraki offers the advantage that it takes care of another key challenge in creating a ‘connected space’ – you need to manage WiFi access as well, shape WiFi traffic, and would prefer to do so in an intuitive way.

If your WiFi network can also ACT as a beacon and monitor the small fleet you have set up in your hotel lobby, say, then you’re getting two for the price of one: an intuitive WiFi management tool, a beacon, and the ability to monitor any additional beacons you place in your space.

Where Technologies Intersect

But there might be something more profound at play.

Because as beacons have shifted into larger deployments, they’ve also shifted into being just one of several technologies being used to ‘digitize physical space’. And it intrigues me to think about a future in which beacon detection can be combined with network monitoring and access management and then be used to shape new kinds of experiences in a location.

Today, you drop by a Starbucks and hop on a WiFi network. But in the future, a combination of beacon interactions and WiFi access might be combined to create new kinds of experiences.

We call beacons the “gateway drug to the Internet of Things”. They’ve been easy to understand. And they open our eyes to a world in which physical space is a new digital touch point. As they start to intersect with other technologies their management will become more complex but the types of interactions we can enable will also become more elegant, more innovative, and hopefully more useful to the end user.

Meraki has shown us one way that beacon technology will start to intersect with others. As we create the digital fabrics of physical space, it’s an early indicator that the beacon era is just getting started.

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.

What other technologies will beacons intersect with? What are the use cases for WiFi and beacon monitoring and where do you see Meraki fitting into your plans? Drop a line below.