Eddystone or iBeacon? What is the best for your project?
On 23 March the Google Chrome app support for the Physical Web was officially released on Android, opening up new opportunities for companies and developers interested in beacon technology. Until now, in order for your customers to get relevant context-aware content from you, they needed to have your app installed. With Chrome 49, you can now address Android users who don’t have your app, using an URL to direct them to a webpage with relevant content.
No matter if you want to provide relevant content to a wider audience, encourage non-users to download your app or create a mobile-responsive web experience and have no app at all, the Physical Web is definitely something you should explore.
How does it work exactly? For most Android users, the new version of Chrome came with a pop-up asking them if they want to enable Physical Web content. The rest would need to go to their Chrome Settings and manually enable the feature, making it less accessible, in a manner similar to the previously released Today view Chrome widget for iOS. When users with Physical Web enabled get in the proximity of a beacon, they are able to access a list of all the URLs currently visible to them in Google Now.
With this new option available, it’s probably worth revisiting an old question – should you use iBeacon or Eddystone in you current and upcoming projects?
The answer to this question can be quite different depending on your usecase. Actually from our experience, at this stage most companies look for ways to use both iBeacon and Eddystone and benefit from their relative strengths, rather than choosing one of them.
When should we use iBeacon?
The biggest advantage of iBeacon right now is the full suite of services available on the market that support Apple’s protocol. Since Eddystone was launched 2 years after iBeacon, most beacon vendors on the market have not yet caught up with offering a complete solution based on Eddystone that goes further than managing your beacon’s infrastructure.
For example, if you already have your own app and want to integrate beacon technology in it, you can make use of our complete solution for iBeacon, including full-featured SDK, REST API and CMS with infrastructure management, marketing campaigns and user behavior analytics. The latter two are coming soon for Eddystone, which means that if you are on a tighter schedule with your POC or full-scale deployment, iBeacon can be a safer bet.
Another advantage for iBeacon comes in case the majority of your app’s users have iOS devices. Scanning for iBeacons near you is done on the operating system level on iOS and uses the Core Location framework, which means you can count on Apple’s out-of-the-box optimized device battery consumption and scanning performance. For Eddystone on iOS, the scanning is done using Core Bluetooth, a framework originally designed for other purposes like connecting to your headphones or other wireless devices nearby.
No matter if you are the one solving the optimization challenge or you rely on an SDK for this, you should be aware that ‘with great power comes great responsibility’ for the amount of battery and processing power your Eddystone-powered app will cost to your iOS users. In addition, Google has not yet found a way to allow you to reach a wide iOS audience with the Physical Web like it has done for Android, which means that one of the biggest strengths of Eddystone is currently non-existent for iOS.
Another situation in which it might make sense to stick to iBeacon is if you already have a large beacon fleet that supports only iBeacon on the firmware level. Although most vendors offer a way for you to update the firmware of your beacons to support the Eddystone protocol, the process is time-consuming. At a rate of 3-5 minutes/beacon for the update itself, many companies choose to do the update and test Eddystone for a couple of beacons and then order some extra instead of switching their existing infrastructure over from iBeacon.
When should we use Eddystone?
Currently, the most important advantage of Eddystone from the perspective of a beacon owner is the richness of data that it can get your beacons to broadcast. iBeacon relies on one advertising packet identifying the beacon (composed of UUID, major and minor), which can be detected by your app in order to signal your user’s micro-location and allow them to benefit from the relevant content you have for them. With Eddystone you can achieve the same thing via the so-called UID packet, but you have two extra packets called URL and TLM at your disposal.
With Eddystone-URL you can benefit from the ability to reach hundreds of millions of Google Chrome and Google Now Android users via the Physical Web functionality, described above. With Eddystone-TLM, you can get information about your beacons’ health (battery level, temparature, uptime, packets sent). For example, if you are building a custom solution where you’d like to show your app’s users information about the battery level of their beacon, Eddystone can be a much more effective solution than iBeacon (where you need to ‘connect’ to the beacon and ‘read’/ask for battery levels, which is often not part of the public SDK you have access to).
Eddystone is also an open format, which means you have visibility of how it works and ability to influence upcoming feature releases by becoming part of their development community. Whereas Apple currently relies on the simplicity coming out of single-purpose protocol that’s standard and easy to code, Google is placing its bet on flexibility, giving a lot more control to solution owners and developers. For example, the Eddystone protocol is expected to extend to include more packets other than UID, URL and TLM in the near future, thus making your beacon infrastructure useful for a greater variety of usecases. In essence, if your app is mostly targeted at Android users or you’d like to shape how your solution works in greater depth, Eddystone is probably the way to go.
Last but not least, looking forward one can easily see how Eddystone can integrate with a great variety of Google’s products and services. In this early stage, the Eddystone format works together with two Google APIs (Proximity and Nearby), which are quite basic in scope and lack an interface to make their functionality easy to navigate for non-developers. However, this is just the beginning – the future holds great potential for Eddystone with deeper integration with Google Chrome, as well as other Google services.
One day, you might see your beacons on Google Maps, see historical user behavior beacon-based data in Analytics, and define Adwords campaigns that use beacon infrastructure to better time and target your marketing messages. To be fair, Apple will also have a lot to say about beacon technology’s future – with more than a hundred iBeacon-related patents granted by the US Patent and Trademark office in the last 2 years, Apple is making big moves in areas like beacon-facilitated mobile payments, indoor location mapping and navigation and others.
How do we benefit from both iBeacon and Eddystone?
While it’s clear that Beacon technology will evolve a lot in the next years with moves from both Apple and Google, the market is still in early adoption phase with little visibility of the timing and order with which new exciting functionalities and integrations will be released. In order to make the best of what the future might bring, companies and developers are adopting two major strategies.
Firstly, they look for flexibility by buying beacon infrastructure that supports both Eddystone and iBeacon formats. With Onyx Beacon devices with new firmware versions (above 4.0.5), for example, you can switch between the two protocols in seconds using our Onyx Beacon app for iOS or request this reconfiguration for thousands of devices at once via CMS and have it delivered to your fleet through your user’s devices.
Secondly, they adopt a ‘mix-n-match’ approach to dealing with the two formats. They choose to keep part of their infrastructure broadcasting with iBeacon to take advantage of analytics, campaigns and full SDK, CMS and API support. And dedicate another part of their infrastructure to Eddystone depending on their usecase, in order to take advantage of the great value offered by the Physical Web and sometimes, Eddystone TLM beacon health information.
Want to get your current beacons to support Eddystone or new ones that support both protocols? Get in touch with us – we will be happy to help you get started.