Is Eddystone The Game-Changer For Beacons In Retail?

December 16, 2015 by guest author, Nir Doron


GUEST POST: Paul Croubalian, The Customer Experience Group

For 132 years, the Eddystone lighthouse has stood on the treacherous Eddystone Rocks in Devon. Its light has shown out over the waters warning mariners and saving them from impending doom. Now, its namesake sets similar sights on saving retailers, restaurants, hotels, et al. Eddystone just might be the game changer we’ve been waiting for.


I’ve been around the block a few times. I’ve seen many saviour-techs come in with a bang and disappear with a whimper. I’ve also seen tech get labelled as “cute but with no market potential” like the GUI, the mouse, and Ethernet. As a community, maybe we aren’t all that great in judging the eventual impact of a new technology.


Eddystone is not a product, it’s an open-source, and multiplatform standard championed by Google and turned over to the world via Github. I’m not sure why Google chose to do this, rather than monetizing it, but I thank them, and won’t complain. Free is usually a good price.


To answer that, we need to check the difference between Eddystone and iBeacons. An iBeacon transmits a 30 byte signal according to a pre-set schedule. Basically, all it says is

So if I was an iBeacon, I might go around saying, “I’m a human. I’m Canadian. I’m a Montrealer. I’m Paul Croubalian. Work out how far away I am from the loudness of my voice.” By itself, that doesn’t do much, but in an app, it can perform wonders. Without an app it does nothing at all.

iBeacons are difficult, or at least annoying, to maintain. Their batteries die out with no warning. They can be moved or stolen and you’ll never know.



The Eddystone standard works with Android and iOS. It can operate in three different modes, Eddystone-UID, Eddystone-URL, and Eddystone-TLM. There is also another one in the pipe called Eddystone-EID although documentation on it is even lighter that the other modes. I’m not sure if it’s a part of the payload, or a different mode altogether, but my bet is that it’s part of payload.


This mode is very much like the beacons of old. (I can’t believe I’m calling Beacon technology old. It seems like it just came out.) It is a scheduled broadcast of name, etc. just like an iBeacon, but with a slightly different format, and with different names for the pieces. Apparently the difference is for difference’s sake because I can’t see any valid advantage to either format.

Eddystone-URL, Game-Changer #1 and potential Technology Killer

In this mode, the Eddystone beacon transmits a web address, and does this without an app being required. The web address can have optional parameters in it to feed a web app which is great news.

I’ve found several different mentions of the URL’s maximum length. Those mentions range from 17 bytes to 20,000, so for now, let’s say 128 bits because we have to start somewhere, and 20,000 just doesn’t make sense to me (isn’t reading and writing about new tech fun?). This size necessitates an URL shortening scheme that is recognized by all browsers. I don’t see that as a big drawback.

For those of you who are screaming, “Invasion of Privacy” at the top of your lungs, rest assured that that will not be the case. Depending on whom you ask, Eddystone either sends an URL silently to the notification panel, just like a weather update does, or waits until the user opens a browser. The user completes the process or can simply swipe it away. Either way, it is even less obtrusive than LinkedIn notifications with their little chime sound. I confess I prefer the LinkedIn method, but I can’t fault Google for erring on the side of caution.

The nicest thing about this function is that it effectively removes WiFi’s single issue: the inability to proactively offer WiFi access. Now, a splash page offering direct WiFi access is well within anyone’s reach.

Eddystone-URL ties nicely into many Google platforms and APIs. It has support with Proximity Beacon, Nearby, The Physical Web, and more on the way. Development should be a breeze.

Google Now will soon be able to apply context. For example, you might be offered a menu while you are in a restaurant. Further, it wouldn’t surprise me if Google combined the detailed location of beacons with the approximate location of GPS to refine their routing algorithm in Maps.

A side note on Eddystone-URL

If you plan to use this function (why wouldn’t you?) remember that you will be asking your customers to go online to see your content. It really isn’t fair to ask them to pay for the privilege of seeing that content. Offer them secure, free WiFi. Don’t forget to add analytics.

Eddystone-TLM, Game-Changer #2

Managing a large fleet of beacons is annoying at best and a royal pain at worst. TLM stands for telemetry. TLM can let you know if a beacon is not where it’s supposed to be. This solves the fallen/stolen Beacon problem.

In this mode, you can get remaining battery life data along with a bunch of other stuff. Frankly, once I read about being able to check battery life, I just skimmed the rest. Just this little thing changes a lot!

Until now, I have always suggested that customers estimate battery life, cut the estimate in half, and use that figure to create their battery replacement schedules. This is wasteful in both labour and batteries, not to mention not very environmentally friendly. In my defence, there wasn’t much in alternatives.

The TLM also allows for remote management. Since that management is at the platform level, I assume it’s manufacturer-agnostic too. YAY!

Eddystone-EID, Game-Changer #3

Before I describe this frame, I must say that it has not yet been implemented, so take what I write here with a grain of salt, a big one. Google says “it may change” which means it most definitely will.

EID stands for Ephemeral Identifier. Think of it as a Beacon Access card allowing only authorized users to access it. How cool is that? At this point, there is not much data available on what it will do, and how you can make it do it, but I can see several uses for it right off the top of my head.


I recently wrote a post entitled “6 Reasons Your Awesome Engagement is Creeping People Out.” Eddystone-URL, with its simplicity may push #1, 4, 5, and 6 to their breaking points. In fairness to Google, there may be something at the OS level that protects against this, but I have seen no mention of it (which falls under # 6, not understanding the technology, but then again, at this point, who does?).

1 & 4: Engaging too often and too soon

Beacons don’t know or care if their message has been heard. They also transmit, if configured as suggested, 3 times a second. Does that mean I’ll get a bunch of notifications just for walking by your store? Will I get 3600 notifications if I stay twenty minutes? If you have 5 beacons, will I get 18,000 notifications?? There must be something that exists to prevent this occurrence, but I can’t say for sure that it does.

Just to say, one manufacturer told me that notifications will be sent to the notification panel on phone screens. Another told me that there are no notifications sent at all and that everything is pulled by the user, which makes sense but tends to reduce effectiveness. Yet another manufacturer posts on their web site, “Eddystone-URL links can appear on a user’s lock screen, but it does not push notifications to users. (Worth mentioning: Google’s “service worker” technology may evolve to allow browsers to send push notifications from a website, but that technology is not available now.)”

Not quite satisfied with those answers I popped over to Github. Digging around in there I found not one, but three wait() functions. The tech is public, and not everyone is a rock star coder. I worry that the technology’s simplicity may lead to poor implementations that drive consumers away. Even if no notifications are pushed now, it’s likely only a matter of time before they are.

5: Ignoring big numbers

Beacon technology is cheap. It’s so cheap that I can see Eddystone-URL beacons added to vending machines, posters, booths in trade shows, real estate signs, as well as silly things like dog collars and key chains. It’s so cheap that Facebook is giving it away (Place Tips). A full-blown implementation is within the reach of the smallest business, and that scares the living daylights out of me.

Someone might say that hitting a consumer with five or six silent notifications is no big deal. It’s not like we are forcing them to do anything. They can get rid of the notification by just swiping it away.

Ok, that true. Have you considered that you are not the only retailer who will use this very cheap and accessible technology? If I get just five notifications from you and five more from each of your mall neighbours, I could easily end up with 1,000 notifications that I have to swipe off my phone!

If this is the case, then the biggest market this technology will create is for geo-fencing apps that cut Bluetooth off while in shopping areas.

A possible solution

Why not auto-delete the notifications after, say 15 seconds? If I’m still in range, they will pop right back on. If I am not, they won’t. Problem solved.


Right now, Eddystone seems to offer many advantages. Documentation is light. I am unsure if its potential for alienating customers is worth the risk. I guess I’ll just have to order a Developers’ Kit and test the heck out of it. That, I think, is its biggest strength. Eddystone is public via Github. New functions and features will shortly start popping up like crazy. Someone will add direct notification because it sounds like a great idea. Hopefully, someone else will address notification-overload. This is a technology that deserves to survive. Let’s not screw it up.


Editor: Paul writes a lot about technology via Linkedin. While this is not expressly about digital signage, Beacons are a big part of the conversation these days and this post does a great job of explaining what Eddystone is all about. So I asked if it could run in Sixteen:Nine, as well.

Leave a comment