Developers hold the key to iBeacon

Will McClellan /

I’m not sure anyone knows what the killer app/service/whatever will be for iBeacon, but we can all see the potential – especially developers. It’s not often we get to work with physical objects (beyond hacking on pet projects), but with iBeacon we have hardware based technology that actually has use beyond the bounds of our desk.

Inevitably, iBeacon will go mainstream and marketing teams around the globe will get another outlet for their ideas and campaigns. But for now, developers hold the key to shaping the future of iBeacon and there’s a bit of a scramble to get services/platforms out in the wild.

At Lighthouse, we’ve recently released a private beta of our iBeacon analytics and content delivery platform. We’ve done a lot of work over the past 6 months with Bluetooth LE beacons and the biggest hurdle we’ve come across is testing. How do we test (or simulate) beacon events in a fast and accurate way?

The big problem (and what makes them exciting) is the nature of how beacons work. They’re designed to fit in with our natural environment and so, ideally, we need to test them in a natural way. But exiting and entering a beacon zone by walking to the other side of the room and back is great for exercise, but terrible for productivity.

A lot of the time we’ve resorted to just removing the beacon battery and putting it back in again. On iOS, this triggers (forces) an enter or exit event. That’s fine for one beacon, but at Lighthouse one of our main objectives is analysing ‘groups’ of beacons (in relation to locations), which forms the basis of our analytics offering.

But we can’t efficiently remove and replace batteries for multiple beacons and its not feasible to setup beacons around the office and have to wait a month to analyse 30 days worth of analytics. Couple this with our campaign feature for mobile apps and the issue is multiplied.

We’ve worked around this by hacking together some automated scripts to ‘generate’ beacon events as though they were natural. We don’t exactly know how people will trigger beacons in the real world, but we have a pretty good idea. For example, at a supermarket, we know that a typical person might spend 30 minutes at the location and visit the dairy, meat, bakery and household aisles (which each have a beacon setup) triggering the beacons at certain intervals, which combined makes up a ‘visit’. Great, we can simulate that scenario and make sure everything works as expected.

That’s a very specific scenario that won’t fit all use cases, but the general idea applies to most situations. We want to build on this work and release a similar tool for Lighthouse. With this, a developer could setup their locations, beacons and campaigns in the configuration they want, hit a button, wait a short while, and then have 90 days of simulated analytics to digest.

The data produced would have to be taken with a grain of salt, but it would give some insight into whether everything is working as you expected i.e. our API is accepting events for your beacons and associating with your campaigns and locations correctly.

Our ‘customer focus’ for Lighthouse is targeting organisations and bringing them sophisticated proximity based analytics and campaigns. But to get there we need developers. The average customer will not be implementing our iOS SDK and testing integration, that’s something they’ll task their app developers with and we want to get them up to speed as quickly as possible

What are we doing to help developers?

  • As mentioned in this post, we’re looking at bringing the tools to simulate beacon events in a ‘test mode’ to developers. Both from the web app and the iOS beacon utility app we’re developing.
  • Giving developers the information they need in the format they want it. We knew it was a good idea to list out the most recent beacon data posted to our API for the current application, so we put it in. At first we did some custom HTML with basic styling. Then we scrapped that idea and just dumped the raw JSON to the screen instead. Developers love JSON!
  • Great documentation and best practice. We want to provide the best documentation. Not just specific to Lighthouse but iBeacon in general. There are a lot of quirks and bugs that developers need to know about.
  • We’re doing this! Reaching out to iBeacon developers to share the issues we’ve run into. We’re looking to open dialogue with developers through different channels such as Blogs, Google hangout sessions, Twitter etc.

At Lighthouse we’re purposely not focusing on a narrow target market. A location can be a shop, a festival, a museum or a bus stop. A campaign could be an offer, a tour guide, general information or a ticket. And you can put a beacon wherever you like.

We already have developers testing our beta product and can’t wait to see what they will do with it. If anyone is going to find the best application for iBeacon, it will be developers.

What is Lighthouse?

Lighthouse uses BLE beacons to deliver content and experiences based on proximity to things in the physical world. Think of it as a beacon–powered CMS.

Lighthouse offers:

  • Campaign centre
  • Real world analytics
  • App integration (SDK)
  • App development