Implementing beacons is a tricky business, but the technology itself is pretty simple:
- A beacon emits a Bluetooth Smart signal including its UUID, Major & Minor properties
- Bluetooth enabled devices listen for these signals via a native application and then detect nearby beacons whose UUIDs have been pre-programmed to listen out for.
- Once a pre-programmed UUID is detected you can record an analytic event as well as trigger a response within an enabled mobile application
So on a one-to-one basis you’re not going to run into too many issues. At Lighthouse, we’ve always been more interested in the potential of multiple beacons, which can bring you more in depth analytics and engagement opportunities from within your mobile application. But with multiple beacons comes a more challenging implementation process.
Many of our customers are interested in beacon analytics to start with (e.g. identifying top locations and popular zones within those locations) which is a sensible first step as you can start collecting location data without sending any content to the user. Once you have some data you can use it to start planning beacon campaigns and content.
So taking a large store example, they might put a beacon in the following spots:
- The Entrance
- Women’s Section
- Men’s Section
- Homeware Section
Most beacon manufactures supply beacons with the same UUID values. Apple describes a UUID as a region which is an nice metaphor so we’ll use that from now on.
So the behaviour is as follows; when your app is in the background (e.g. screen off in the customers pocket), then iOS will detect when the customers device enters that ‘region’. And therein lies the problem of using the same region for beacons in close proximity. Background monitoring does not detect movement between beacons that share the same UUID.
When you think of the UUID as a region, moving between beacons with the same region should not trigger an enter/exit on beacons because they share the same region.
For example, if you enter the Entrance zone of the store the device registers an enter event. If you then move into the Men’s section the phone will not register an exit for Entrance zone and a new enter for the Men’s zone. They are treated as the same region.
Note: It’s important to note that we are talking about background monitoring here. When the device is ranging, beacons are treated as unique based on their UUID, major, minor and enters/exits occur when moving between them.
But for our requirements that’s not good enough. We want enter/exit triggers to occur when the device moves between any beacon, even when the phone is switched off. This is especially important in close proximity as it opens the door for targeted analytics/notifications. You can’t rely on a user to interact with their phone and trigger ranging to enable the scenario we want. So what’s the solution? Well it’s actually quite simple:
For background monitoring of beacons in close proximity, you must use separate UUIDs
So if the Entrance beacon uses one UUID, and the Men’s Section beacon another UUID, then an exit/enter will be triggered when the device moves between them. Even in the background.
Let’s get the obvious implication out the way first: Yes, this means you have to manage multiple UUIDs for your beacons. But it’s not that bad. In our testing the easiest way to manage it is to use different colours.
In our large store example, you would need 4 colours that represent 4 UUIDs. Most beacon manufactures supply a companion app that allows you to modify the properties of the beacons, such as power and the UUID. So after defining your 4 UUID colours you would then apply them to your beacons.
Tip: Use sticky colour dots to easily identify which colour you have applied to which beacon.
Then when you deploy your beacons in store just make sure not to place the same colour beacons in close proximity to each other.
In our testing this has worked really well to trigger enter events (which in turn trigger Lighthouse notifications) between beacons in close proximity. It also ensures you get those valuable enter/exit events per beacon for in-depth analytics.
There are a few things you should keep in mind:
- This is only applicable for beacons whose ranges overlap. We find reducing the beacon power to reduce its range radius (e.g. to 5 meters. Beacons can range up to 70m!) is best for targeting areas. If your beacons are not within the same vicinity then you don’t need to worry about this.
- Background monitoring is not as regular as when the phone is active. Our experience (and it seems other developers agree) of this is inconsistent. We’ve had enter events occur, when the screen is switched off, within 15 seconds, but in some cases it can be up to a few minutes. Our guess is that this is dependant on different factors, mainly battery life, but also when the phone was last active. Once that first event is triggered, subsequent events are triggered more promptly.
- Sometimes using the same UUID might be what you want. If you’re just interested in when customers come into your location and want to use multiple beacons as a way to cover that whole zone, then using the same UUID for all beacons makes sense. When the customer comes in range of one or more of the beacons they will trigger an Enter. When they go out of range of all beacons they will trigger an exit. 1 Enter, 1 Exit. Unless they have the app in the foreground of course.
- iOS apps can only look for a maximum of 20 UUIDs. This gives plenty of room for growth. 20 UUIDs/colours is more than enough for almost all scenarios. Remember, this is all only applicable for beacons with an overlapping range.
And here’s a diagram that illustrates the workaround:
Managing beacons is hard
Managing beacons is hard. That’s why we created Lighthouse in the first place. It’s our job to make beacon management as simple as possible. We’ve even created an app to make beacon management easier for you.
Again, using the example above you would create your four regions and apply them to your beacons using the manufacturers app. You can then use our beacon manager to associate these with your application on Lighthouse:
- Add the 4 UUIDs under your application settings on the Lighthouse dashboard
- Login to your Lighthouse account on the Beacon Manager App
- Hold the beacon close to your device and select it in the app
- Assign that beacon a name and a location.
That’s it. Your beacon is now associated with your application and ready to capture analytics and deliver campaigns.
Demo your beacons
That’s not the only thing we’ve done to make your life easier. We recently released an update to the Beacon Manager App (iOS/Android) which enables you to run demo’s via the Lighthouse application. It’s perfect if you don’t have your own app or development team.
Once you’ve added your beacons to Lighthouse and associated them with a campaign, you can select demo mode on the Lighthouse app which will then trigger notifications and campaigns for your beacons. It’s a fast and convenient way to ensure everything is working as it should before working on integration into your own app. It’s also a great way to show off beacon technology to clients and stakeholders.
As stated in a previous post, we’re making a big push to support developers with their iBeacon integrations and along with the above there’s a lot more to come. If there’s any particular part of beacons that you as a developer think of as a pain point, we’d love to know. Trust us, we probably already know about them all but it’s always great hearing about them from others perspective. Let us know in the comments below and good luck with your beacon implementations.