GeoMinds: Is Google’s Eddystone The Donald Trump Of The Beaconsystem?
No, this isn't about beacons in The White House. Rather, Google's system has proximity observers salivating like late night comics over an over-the-top presidential hopeful.
Before we go there, it’s been two years since Apple launched iBeacon. We are still working with 1.0 of that standard. Beacon vendors have been nervous about slower momentum in the market. Google had been quietly buying Bluetooth beacons for mysterious internal projects, but there wasn’t an official Google beacon offering. Given that Android represents over 80 percent of the global smartphone market, Google’s absence was troubling. Then Google revealed their hand. They “saw” Apple and “raised the stakes” with the announcement of Eddystone.
When Donald Trump announced he was running for president, Jon Stewart of Comedy Central’s The Daily Show was squirming in ecstasy at the prospect of a cornucopia of endless material. As a consultant on the Beacosystem, I felt the same way when I heard about Google jumping in with both feet. The difference is what Google is doing is nothing to joke about. If there were any doubt about the importance of the Bluetooth beacons, Google just ended that.
Google appear to have studied Apple’s approach closely and filled the gaps that iBeacon left open. Whether that’s a good thing depends upon your position in the market. Apple encouraged VC investments in beacon startups by putting iBeacon hooks in their OS and leaving major gaps for entrepreneurs to fill. Google appears to have identified some of the most lucrative opportunities and is tipping its hand to us as to where it sees the value by filling in those gaps themselves.
So what are some of those gaps and what’s the difference in the offerings of the two mobile OS giants? Google has gone beyond the mobile app paradigm of iBeacon and introduced three kinds of payload, one that triggers mobile apps based on proximity, the other that delivers telemetry and the last incorporates the UriBeacon open source project to send URLs to physical web browsers; a model that removes the need for developers to create apps.
Eddystone-UID is similar to iBeacon in that it drives interactions with mobile apps. The UID identifier is designed to coexist with, but not to be compatible with, Apple’s iBeacon UUID, Major and Minor identifiers. iOS’s Proximity API won’t respond to the signal from an Eddystone beacon.
A number of the beacon manufacturers that were part of the first tranche of beacon OEMs to support Eddystone announced backward compatibility. Their older beacons could be updated and configured to broadcast iBeacon or Eddystone, but not all of beacon OEMs will broadcast both. Estimote for example appears to require the beacon to be setup to broadcast one format or the other. Radius Networks on the other hand interleaves both packet types. This second approach has the benefit of only requiring a single beacon to trigger iBeacon and Eddystone apps.
The implementation of Ephemeral UIDs, that are used to authenticate beacons securely, hides the identity of beacons in stores, preventing them from being mapped and used for showrooming. This fills one of the gaps that many beacon OEMs had filled with proprietary extensions.
The Eddystone telemetry frame is another example of Google taking a feature that beacon vendors had supported in their proprietary extensions to iBeacon and standardizing it. Google supports battery life and temperature as two pieces of data in the standard. This data has obvious management applications but can also be leveraged where beacons are being used for asset tracking and monitoring. This use case has driven the sale of millions of beacons for the fortunate OEMs that had honed that feature as a differentiator.
Eddystone-URL eliminates any uncertainty as to the official status of Scott Jensen’s UriBeacon Physical Web project, which has now been absorbed into Eddystone. UriBeacon had been positioned as being resourced by Google but not as an official Google offering. That certainty is to be welcomed. However, the prospect of Apple embracing this open source project in the short term is more distant.
The integration of the Physical Web with Eddystone makes it a Google “thing” rather than an open standard that Apple might more easily adopt. That said this is something that will be hard for Apple to ignore in the longer term. Developing a web page that can be discovered via Eddystone-URL is a couple of orders of magnitude lower in cost, faster to market and lower in risk to developing an app. Roughly 25 percent of the companies in the Proxbook.com directory of Proximity Solution Providers already support the standard.
While opening up access to the Eddystone spec as an open source project, the ecosystem is solidly anchored to a set of proprietary APIs deeply embedded into the Google Cloud. This worked well as an approach for Android, where the velvet lined handcuffs take the form of compliance with terms and conditions to gain access to Google Play app store. With Eddystone, those cloud services are the Nearby API, the Places API and the Proximity API.
Raising A Red Flag
Proximity API is the way to onboard metadata into a proprietary Google registry of beacons. While apparently benign in the sense that it enables useful management functions for the developer, it’s probably one of the biggest red flags for those beacon vendors that have a strategy of building beacon networks. Brokering access to networks of beacons and harvesting the analytics from the access to those beacons is a rich source of value. Google are being quite audacious and mimicking the approach of vendors like Gimbal by allowing the registration of beacons from competing standards (AltBeacon and iBeacon).
One can imagine considerable discomfort coming from retailers and outdoor advertising companies that are asked to submit the details of their beacon’s location and the metadata to the world’s largest online advertising company. We can anticipate that even if the location of the beacons is registered, the metadata that Google kindly offer to host in their cloud for developers will be shared sparingly by such companies. Maybe this enables the startups like Gimbal to carve out value with a network overlaying the Google network, without handing over their most sensitive information.
It’s going to be almost impossible for companies to abstain from registering their beacons because Google has done another thing that Apple has yet to do, use that beacon metadata to enrich the fidelity of Google Maps. For public spaces like shopping centers and airports that have always struggled to get their apps downloaded and used, their customers will demand the support of better indoor mapping, which could be a gold mine for Google in terms of enabling proximity based advertising in an app we all rely on.
Arguably, Google is encroaching on the value of Fleet Management features that a number of the Beacon vendors have developed, but even though Eddystone will provide estimates of the length of battery life in a beacon and a repository of the location and permanence of beacons, there will still be dashboards and additional tools required.
That said, one can imagine given Google’s level of commitment that those areas may be next in terms of gaps to be filled. For the companies providing Fleet Management, this is an opportunity and a threat. If it’s Google “buy” versus “make,” at least one of them will be very happy.
Is Eddystone “Fired?” Or “Hired?”
So, is Eddystone going to be good for Google and good for the beacon market?
I believe the answer is “yes.”
Eddystone is a significant vote of confidence; it eliminates a huge gap and the uncertainty as to what’s happening in the Android space. Certainty can only help to spur further adoption. Google’s chances of winning its quest to create value are probably significantly better than “The Donald’s” chances of hanging a Trump sign on the outside of the White House. Personally, while many questions have been answered, almost as many new questions have been raised. I can’t wait to see what’s going to happen next.
A final postscript and question; Eddystone is named after a British lighthouse, the first offshore lighthouse to be built. Having grown up in the UK, I generally heard Eddystone pronounced as “Edison Lighthouse” (as in the ‘70s group who produced “Love Grows (Where My Rosemary Goes”) not “Eddy stone”. You can listen to the “correct” pronunciation here. So one of the questions about this standard is whether we are going to pronounce it the American or the British way. That’s probably one of the easiest outcomes to predict.
*The former head of Qualcomm Retail Solutions’ Strategy and Solutions Management groups, industry veteran Stephen Statler is principal consultant at Statler Consulting, writing, training and providing advice on the application of Bluetooth beacon technology to entrepreneurs, investors and venue owners. He is an Advisory Board Member of a number of companies pioneering in the application of proximity technology including: Unacast, Rover Labs and PassJoy. Details of his forthcoming book on the “Beacosystem” can be found at www.newlocationessentials.com.
**Editor’s Note: Our “GeoMinds” opinion series features posts written by outside contributors from all parts of the GeoMarketing community who want to share their views of the trends, issues, problems, and solutions changing the online-to-offline advertising and marketing landscape. To become a contributor, contact us at firstname.lastname@example.org.