Beacosystem evolution, hurdles, and resources

In this post, the third of our series, I’ll look at some of the issues in using and deploying beacon-based solutions, some of the trends in both hardware and software offerings, and share some resources where you can find more detail on everything I’ve covered so far.

First off, let’s take a look at some of the topics that can cause issues, or trip us up when starting to consider a new iBeacon-based solution. In no particular order, these include:

Notifications, Notifications, Notifications

I have many conversations with potential clients that go something like this (in condensed form):

Client: “We want to do a beacon project”

Me: “Great, what are you thinking of?”

Client: “We want to trigger messages to people as they come past or in to our place on their phones”

Me: “OK, is this iOS only?”

Client: “No – of course not – in fact, most of our users are on Android”

Me: “Ah – ok… well…”

(long conversation follows)

With the initial hype and excitement around iBeacon, it’s understandable that there’s some confusion around what’s possible, and what’s not, across all the mobile handsets available today. For now, I’ll focus on just iOS and Android, though we could usefully expand to include Windows and Blackberry.

As I’ve discussed before, Apple baked in a background notification feature to their support for iBeacon, meaning that a native iOS notification can be triggered on the handset when near a selected iBeacon. This can occur even if the App that registered an interest in that iBeacon is not even running at the time. This is one of the “hot” features that attracts and excites many people new to iBeacon, which is understandable.  After all, when used well, it’s a very cool feature. The issue, of course, is that if it’s not used well — by which I mean if it’s not used in the right place, at the right time, with the right expectations set with the mobile user — then it’s at best an annoyance, and at worst a spammy disaster that will quite effectively destroy your reputation with the user and ensure they delete your app, never to return.

I believe the key with the notification capabilities around iBeacons, and beacons in general, is to take a deep breath, and sit back, and really think through how your target mobile user is going to experience, use, and then feel about every notification you’re considering using.

I mean: really think through it.

While “triggering alerts about pasta offers in the pasta aisle” sounds great (hey, we use that very example in our own marketing material for LocalSocial), it’s not so great if you’re juggling two screaming children and want to get in and out of the store as quickly as possible. Or, while a greeting as you cross the threshold of your favorite restaurant can be mildly delightful the first time you visit, unless the behavior and content then changes on subsequent visits to reflect that the restaurant knows this is your third time here this week, you’ll start to look for the “off” button for that cute engagement.

So, without over-laboring the point: if you really want to use background notifications, think long and hard about what needs to happen to ensure you can create a delightful experience (best) or a net-positive experience (worst case) for your user. This means thinking about each engagement scenario: first visit, second time, multiple visits within the same hour, juggling kids, hands-full, and so on, and really ensuring that when you trigger a notification based on the user being near, it’s going to have high relevance and not put you and your brand in the doghouse.

Of course, the other big issue that comes up when we have the above conversation is that, broadly speaking, the cool background notification feature doesn’t work on Android.

Sorry, WHAT?!

We need to talk about Android

Apple controls the iBeacon ecosystem, and ensures it behaves the way they want to see it work on their platforms. So, if you have an iPhone or other recent iOS device like an iPad, it’ll work just great with any Apple Certified iBeacon hardware (beacons that comply with the Apple iBeacon conventions).

But what if your project will need to support users on both iOS and Android?

Well, there’s good news and bad news. The good news is that many of the key things beacons can be used for can work just fine on Android. So, for example, an Android app can “see” iBeacons nearby, and even get a rough estimate of which ones are nearest to it, so it can rank them and whatever they represent in proximity order.

The bad news comes in a few parts.

First, while most new Android devices have Bluetooth 4.0 on board, and therefore support Bluetooth Low Energy, not all do. So, it’s worthwhile considering your target user base, and thinking through what sort of phones they carry (if you know), and factoring this into your thinking. Typically, in any given country or region, there is some data available about the types of phones the population are carrying, and the split in the types and versions of those phones. This will give you a useful overview for whether your Android users, or enough of them, will be able to “play nice” with your beacons when deployed. Many clients also have great information from Google Analytics or other sources that helps give them a steer around the nature and split of their mobile user base.

Second, right now, Android does not have baked-in support at the OS level for background notifications. As a result, your choice is to either omit this feature from your service or find a way to build it in on Android. This turns out to be tricky enough, because to support background notifications, “something” on the phone must be continually looking out (scanning) for these beacons. On iOS, Apple have built in some pretty efficient code within iOS itself to do just that, and can take advantage of a variety of techniques in order to ensure this happens without sucking the life out of your battery. On Android, you have to write that code yourself.

Some help is at hand however, as a number of the companies in the Beacosystem have packaged up some of that code for you to re-use in your own apps, thereby saving you the trouble of doing it yourself. See for example, how Estimote and Radius deal with this. Even still, you are left with a situation where the experience with regard to notifications on iOS and Android can be made reasonably compatible, but it’s not identical. And you have to do some hard yards to ensure they are as consistent as possible so that your Android and iOS users get an equivalent experience.

Your app has how many active users?

It’s also fundamentally important to remember that all iBeacon interactions and notifications require an app. This has some implications. If you’re aiming to engage with the visitors to a location or venue, you need to work out what proportion of them will have your app installed, or will download the app based on some call to action or provocation when on-premise.

Again, on iOS, Apple provides some interesting angles to help with this, such as the place-based “Suggested App” icon on the bottom left-hand side of your iPhone’s lock screen (pictured left).

Also, depending on your business, it may be better to consider using someone else’s app and buying the engagements or interactions you’re looking for via their ad network. I cover some of the options for this using aggregation networks below.

Privacy and end-user control

While it has not been center stage to date, privacy policy and user controls over the kinds of location data generated by beacon-based solutions is likely to become a hot topic as more users experience these systems. A good analogy is perhaps the way the use of cookies evolved online and the emergence of options for the consumer to manage, block, or issue do-not-track instructions. I expect to see the same types of options emerge for mobile users, especially with regard to location and visit data.

Understand the real TCO

Finally, when thinking through a possible project using beacons, many clients initially focus on the cost of the hardware — the beacons themselves. Beacons are, relatively speaking, cheap ($10 to $50); they’re designed that way. But the total costs in a solution will involve configuring and installing beacons; testing the setup works as planned; managing content online; then, once installed, checking that the system is working correctly and as expected.

Fun issues that need to be considered once a new deployment is up and running include figuring out that all beacons are alive and well (heartbeat), that batteries are at acceptable levels (power management), that beacons are where you expect them to be (location matching), and that firmware on beacons is updated as needed (software updates).

These topics are worthy of a detailed post in themselves, which I plan to cover in the next post in this series. Suffice it to say, when you look at the overall aspects of deploying a solution, the hardware cost itself will be a minor component of the overall spend.

System evolution

As the beacon market evolved, the various players have begun to focus on specific niches within the overall ecosystem and specialize on doing some things well, while partnering for the things that are non-core. This is typical of a maturing area based around some new technology. I’ve picked a few areas worth highlighting in the continuing evolution happening in the Beacosystem.

Shopper marketing platforms and aggregated beacon networks

A number of companies are building out networks of beacons that can be aggregated together to provide reach for engagement and marketing purposes. This is attractive to brands and marketing agencies, who are often focused on reaching as wide and as relevant an audience as possible. So, for example, if you are a leading brand like Coca Cola, you may want to ensure you reach across the U.S. market when considering a new mobile campaign. Companies  such as InMarket, Mobiquity Technologies, and BeaconsinSpace all offer different approaches to using beacons for marketing purposes.

For example, InMarket has engaged with a number of different mobile shopping app vendors to embed beacon capability within their applications. In turn, they have also installed beacons in many different shopping locations nationwide in the U.S. They claim a potential reach of 30M mobile users via their application partners. The combination means there are “win-win” scenarios for brands, stores, and app providers if they engage in the InMarket ecosystem. And each element of the ecosystem helps add value to the overall network.

Mobiquity Technologies has focused on Malls in the U.S., and has built out a network of 240 malls that it has “Beaconized” to some extent. This gives it a platform to attract brands, retailers, and app owners who are looking to either present content or trigger engagements at specific locations, or collect analytic data on customer behavior and use. BeacosinSpace has a similar model, with the twist that they don’t allow any engagement with mobile users using their platform; the network is for data / analytics purposes only.

Lastly, FreckleIoT and BlueBite are doing something similar — creating a beacon network (they claim sixty thousand beacons deployed in North America) that provides reach for marketers and advertising agencies to employ when thinking about using proximity in campaigns.

Offline to online / retargeting

For many businesses, not just retailers, figuring out a way to connect customers that they meet online (at their website) and offline (in store or on premise) is a key strategic imperative. If they can do this, it helps them get a holistic view of customer behavior, efficiently tune how they direct and spend their marketing and service dollars, and helps them measure and analyze what works when they spend those dollars, and why.

Beacons and proximity sensors holds promise in this regard, as they provide a light touch way to surface a signal that a customer is at a specific store, venue, or place. So, for example, if a retailer has both an online eCommerce presence and a mobile app, they can unify the user identity across both app and Web, and use beacons to surface a signal that a customer is in the store. What they then do with that signal can range from just recording it (for analytics purposes) to using purchase history or customer preferences to tune varying forms of engagement as the customer arrives and moves through a store.

Taking this one step further, even if we don’t know the word for it, many of us are familiar with retargeting. This is where we search online for, say, a certain brand of trainers, and then we notice that, for some days afterward, ads for the very trainers we browsed seem to “follow us around” various websites online. Well, now companies are looking to extend this behavior to the real world: imagine instead if you stood in front of those same trainers for some time in a store, and then noticed ads for them turning up as you surfed the Web. Companies such as Unacast and Glimr are creating networks that enable what’s called “offline to online retargeting” — where someone’s real-world presence at a store, event, or venue could later be used, with their permission, to trigger offers or custom promotions online.

Scale hardware

After the initial period of hype around iBeacon that occurred in late 2013 and early 2014, there has been time for businesses and organizations of all kinds to really absorb all the details of what’s involved in using proximity well in order to support their marketing or communication goals. Players at all levels in the Beacosystem have responded to demands from these customers for more scalability in management and control of new beacon-powered deployments. This has been very evident at the hardware layer, where many of the providers have quickly evolved to build new management and deployment features into their offerings.

For example, Estimote, long the bellwether company on the hardware side of the Beacosystem, has rolled out tools to help companies manage large deployments of beacons from a central Content Management System (CMS). They refer to this as “fleet management” (not a term I like, but let’s roll with it). They also added a feature to cycle (rotate) UUIDs to prevent “piggybacking” on on a deployed network of beacons. This means that if you spend precious time and resources deploying a beacon network, you can then control exactly who has access to use that beacon network.

Kontakt.io has also been innovating in this area, and recently launched its Cloud Beacons — Internet-connected beacons that can act as managers for other beacons nearby. They are used to provide an update or reporting conduit between Kontakt’s Cloud CMS and the deployed beacon network, and they are used to enable bulk beacon firmware upgrades, manage configurations, and more.

Vertical solutions

There have also been a number of companies that have picked a vertical slice of the market on which to focus, and use proximity as a key element of the proposition:

• Gelo Spaces: a custom solution for museums using iBeacons from Gelo
• Events and conference analytics: Loopd and DoubleDutch
• Proximity-centric analytics and visualizations from Datasnap
• Office and meeting room booking and presence from Robin

Where to go for more information: A resource list

• Apple: iBeacon for Developers
• Google: Physical Web and Scott Jenson
• Don Dodge: Speaks and blogs about indoor location
• Beekn: Doug Thompson’s blog on all things proximity and beacon related
• StreetFightMag and StreetFightSummit: All things hyperlocal
• Place2015: Indoor location conference from Opus
• BeaconWeek: Local meetups sponsored by Kontakt.io covering all things beacon related
• New Location Essentials: Upcoming book and seminar series from Steve Statler
• Blogs: Radius, Estimote, Kontakt, LocalSocial

Cropped public domain image via Internet Archive on Flickr.