iBeacons and Liferay for Audience Engagement: Part 2

This blog is part of a series of entries documenting how we are using iBeacons and Liferay to better engage our audiences at events throughout the year. [Part 1] [Part 2] [Part 3]

Update: Check out my new eBook! Finding Your Way Around iBeacons for Event Marketing.

Download the eBook

In Part 1 I introduced the concept of using iBeacons for Audience Engagement and reviewed knowing your audience and the physical space. In this entry, we'll cover more technical details about beacon programming and management, and what we learned in Amsterdam and Paris. First off, let's explore how devices "listen" for beacons.

Beacon Identification

As we discussed previously, each iBeacon you put in a space continuously emits a Bluetooth LE signal, that contains data that uniquely identifies the beacon. Your app must be coded to enable beacon listening, and then provide code (callbacks) that is called when beacons are detected. In addition, devices must have turned on their Bluetooth radio and the user must have explicitly given the app permission to use the incoming data (this varies by device - for example on iOS the user must grant the Location Services permission, and on Android the user must grant the permission during app installation).

Beacons are uniquely identified with 3 pieces of information: UUID, Major, and Minor. Your app must know of these identifiers and be coded to respond in various ways when beacons are detected. These identifiers are part of the Bluetooth LE signal sent by each beacon. It's important to understand this - the beacons themselves aren't sending any "real" content (no web content, no credentials, no Java or HTML or JavaScript or PHP or Assembly code or pictures of your cat). It's up to your app to detect the presence of beacons and respond appropriately.

Beacon Regions and Region Monitoring

Suppose you have 100 beacons placed in various places at a venue (hotel, grocery store, football stadium, etc). In one large room, you might have 5 beacons to cover the entire space. To detect when the user has entered that room, your code would need to scan for all beacons at all times, and then if one of those 5 beacons were detected, your app would know the person has entered the room. When you can no longer detect any of those 5, then the person has exited the room. Your app would have to remember that a person entered a room so that it can also know when they exit (and what happens if one enters your room, and then restarts your app?) In addition, some beacons might be part of multiple and physically overlapping places to which you wish to respond. For example, at the Liferay France Symposium, the Registration Desk beacons were also in the Rotonde room, for which we had separate events. In a football stadium, Section 232 might be part of both the East and North seating area.

Coding for all that detection logic for each of your 100 beacons would quickly get tiresome, so some smart designers introduced an abstraction to help deal with the complexity. In this case, the abstraction is known as a Beacon Region. A Beacon Region is defined in software only - beacons themselves don't "know" they are "part of" a region. Only your app and device "knows" of these regions, and your app can be notified when the device "enters" or "exits" a region without you having to explicitly code for each individual beacon. This is known as Region Monitoring and is what occurs most of the time during your beacon-powered app's lifecycle.

One thing to keep in mind - even though your app will only get notified on entry or exit of a region, additional logic in your app can set you up to respond to things like "person has been in this region for XX minutes" or "person has gone from region A->B->C->A" and that sort of thing. It can be useful for better engagement (more on this later).

Beacon Proximities and Ranging

In addition to monitoring and responding to Region entry/exit events, your app can also be notified of its proximity (how close you are) to each individual beacon. Thanks to real world physics, the proximity isn't all that accurate - you can't know for certain that you are exactly 1.233 meters away from a beacon, due to multiple sources of interference and the frequency of broadcasts. iBeacons designers also knew this, and introduced 4 "zones" in which a beacon might be. The immediate zone is (from our testing) about 1m away or less. The near zone is about 1-5 meters. The far zone is 5m or further, until you reach the unknown zone which is usually a temporary zone just before the beacon becomes undetectable (and this also where you end up if you dig too deeply in Minecraft). This again is a software abstraction to help your code be simpler. Beacons don't "know" which zone they are in, no do they do anything different due to an approaching person or device.

Proximity detection (also known as Ranging) is also much more expensive in terms of energy consumption (i.e. drains your battery faster), because the hardware must scan for beacons frequently to get a somewhat accurate reading on each one. So you don't typically want your app continuously ranging for nearby beacons. In fact, some devices like the iPhone do not let your app do ranging when it is in the background for this reason. In the Liferay Events app, we only turn on ranging when the app is in the foreground and you have positively entered a region.

During ranging, your app will receive reports of each detected beacon, and in some cases reports of "boundary crossings" (e.g. when you go from near to immediate for a given beacon, and you want your app to do something special). Each beacon's hardware broadcast strength can be set by an administrator, and that setting is included in the packets sent over the air in the Bluetooth broadcast, so the beacon software in devices can do fancy math to calculate an approximate distance based on the power setting and the actual strength of the signal received. For example, if you crank the broadcast power to maximum on the beacon itself, but then the actual received signal is fairly weak by a device, then you can kind of know you're pretty far from the beacon.

Foreground vs. Background

From early testing we discovered most people don't run your app and walk around staring at the screen waiting for popups, looking like Dr. McCoy with a tricorder. Should be obvious, but sometimes you get blinded by the awesomeness of new tech and forget about how people really get along with it. So in reality, for your app to be engaging it has to provide value even when the app is in the background, or it is quit entirely.

For example, iOS allows monitoring but does not allow ranging when the app is in the background or quit entirely, so if all your app does is respond to ranging events, it's not going to be very interesting to most people, because it's not going to do anything while backgrounded/locked/quit. You need to combine region events with proximity events, and we did exactly this for the Liferay Events app. Again, people don't attend our events just to play with an app or their phone, they are there to learn about Liferay, attend sessions, and meet people, so most of the time their phone is in their pocket and not top of mind.

iOS 7.1 introduced a new feature that allows your app to receive beacon event messages even if the app is hard-closed. Again, only beacon monitoring works in this case, so your app should use region monitoring to ensure your users can be engaged even if the app is backgrounded or closed.

How we configured our beacons for events

So now that you understand how beacons work at a slightly lower level, let's talk about how we used them at our events. As part of this experiment, we decided to start small and feature the following types of engagements to engage both business and technical attendees:

  • Venue information and workflow - for example, a welcome message on arrival to the venue, with directional maps to the registration desk and WC, and a quick way to check in on social media, or some reminders to pick up name badges, or discounts at the cafe.
  • Sponsor Engagement - Interactive sponsor and partner marketing, including lead generation (e.g. "fill out our form for more info" or QR code scanning)
  • Speaker Engagement - Information about upcoming sessions occurring in the area you are in, or getting feedback from attendees as they leave a session
  • Gamification - Rewarding attendees by making them go to places (like a scavenger hunt) or using the app as a "virtual railpass" to force them to visit with and engage sponsors
  • Analytics - we wanted to (anonymously) see how people moved through the venue, to see if elements of the event (e.g. sponsor booths, hands-on demos, different food areas) were effective or not.

To support all these types, we defined several beacon regions (one for each discrete room that we wanted to act on) and also a venue-wide region encompassing all beacons (so we could show welcome messages even for those who snuck in through the back door.) We also used individual beacon proximities and ranging for certain triggers, such as when you approached a sponsor's booth, you'd get interactive and engaging content, or when you approached a "mystery guest", you got a trigger to engage in a game (more on gamification later).

Beacons are not super-expensive, ranging from USD 5 [reportedly] - USD 30 each. At typical Liferay events we can have up to 5 or 6 different rooms, and we also wanted to support sponsors, so we ended up needing around 20 beacons (a few more than absolutely needed, for backup purposes). You will also lose some, unless you hide them really well or lock them in a box.

Liferay Portal Solutions Forum Benelux 2014 Configuration

This event took place in a somewhat compact venue (Pakhuis De Zwijger), with the registration area, sponsor area, and main speaking room all within about 50m of each other. We configured the following beacon regions and individual beacons:

iBeacon Config for Benelux Symposium

Region Name UUID Major Minor
Venue B9407F30-F5F8-466E-AFF9-25556B57FE6D [Any] [Any]
Grote Zaal B9407F30-F5F8-466E-AFF9-25556B57FE6D 1 [Any]
Registration B9407F30-F5F8-466E-AFF9-25556B57FE6D 0 [Any]
Expo B9407F30-F5F8-466E-AFF9-25556B57FE6D 2 [Any]
Cafe B9407F30-F5F8-466E-AFF9-25556B57FE6D 3 [Any]

So any beacon with the UUID of B9407F30-F5F8-466E-AFF9-25556B57FE6D would be considered in the "Venue" region (and we had entry/exit triggers setup for entering or exiting the Venue, e.g. "Welcome" and "Goodbye" with links for event surveys, social media, etc). Any beacon with a UUID of B9407F30-F5F8-466E-AFF9-25556B57FE6D and a major of 2 would be considered in the Expo region (this is where the sponsor booths were). Further, each sponsor booth had a beacon dedicated for it, using B9407F30-F5F8-466E-AFF9-25556B57FE6D for the UUID, a major value of 2, and a minor value starting at 0 and going up (we had 6 sponsors). If you're wondering, that special UUID is simply the default UUID of Estimote Beacons, the vendor from which we sourced the beacons.

The main hall (Grote Zaal) was a large space, so we used two beacons placed on either side of the room, up high, to cover the entire room, and this worked pretty good (each were configured with a major value of 1). The other areas were served with 1 beacon each.

We also featured a "mystery guest" game. The goal of the game was to engage attendees through a game, while at the same time forcing them to engage with the sponsors at the event. To play the game, attendees had to find a special person who was secretly carrying a beacon. When you got close to this person, the app would respond and ask you a question, to which only the mystery guest had the answer. Upon learning the answer (and typing it in correctly), you could then proceed to each sponsor booth, and on approaching the booth, you would get more notifications with marketing messages from the sponsors and a form to enter your info, along with the answer to another question (the answer would be found by talking to the sponsors, forcing attendees to engage!).

We then configured the app and Liferay to support the following beacon notifications

  • Venue Entry - Welcome message with registration maps and social media checkins
  • Venue Exit - Farewell message, encouraging you to fill out survey or visit liferay.com
  • Registration Entry - Reminder of what to not forget, links to agenda and social media checkin
  • Registration Linger (5 minutes or more) - Detail about venue and what's upcoming and interesting
  • Expo Entry - Detail about sponsors along with sponsor links and content
  • Expo Linger - More sponsor info
  • Grote Zaal Entry - Links for speaker, session topic, session survey, twitter
  • Grote Zaal Exit - Thanks message, links to agenda, and encourages survey feedback
  • Mystery Guest Proximity - encourages you to find them and pops up form to enter the game
  • Sponsor Proximity - Individual sponsor-provided content and forms (one per sponsor)

There are many details about how these worked and were configured in Liferay - more on that in the next post!

What we learned in Amsterdam

  1. Attendees aren't there to play with your app. We didn't get nearly as many people engaged with the mystery guest game as we'd hoped. About 20% of the attendees began the game, but only about 2% actually finished the game (visited all the booths, entered all the answers correctly). It took quite a bit of effort to complete the challenge, and there was limited time (the event was only a 1-day affair). So the lesson here is don't make things too hard to use! Perhaps at DevCon we may do something more technically difficult yet interesting, but for the two events we've had so far, they just weren't that into it :)
  2. There are many Android devices :) We knew this up front, but were unable to purchase and test all 8,432 Android devices the app supports, so we found several glaring bugs on certain devices (which were fixed either during or shortly after the event). Lesson: Test on as many devices as you can. Ask your friends and colleagues to test the app. Use simulators with reduced memory footprints and weird device types.
  3. Beacon ranging is useful, but cannot be relied upon for initial engagement, since it is disabled when the app is backgrounded/locked/quit.

Liferay France Symposium 2014 Configuration

This venue (Shangri-La Hotel) was a little more spread out, offering a bit more breathing room and chances for engagement. The crowd was also more technical (the first day's sessions were entirely technical). The beacon configuration here was similar to Benelux, but we had several more regions to support the additional areas, and we converted the beacon proximity events for sponsors into beacon region events (so that they worked even when phones were backgrounded/locked/quit).

What we learned in Paris

For the France Symposium, we decided to make the game part much easier to "complete" and took out the mystery guest element entirely, which proved to be too much "game for the game". Instead, we did a simple scavenger hunt (We had a Beacon region named Trésors cachés) - we hid 4 beacons in various places, and when you got close to one, you were given a hint as to where it was, and if you found it, you could enter your information for a chance to win a prize. We gave away all 10 prizes that day, and people were generally more engaged (the analytics data also revealed this fact - we had about 30% more attendees using the app and looking for secret beacons than we had at Benelux).

We also finally decided that any engagement actions in the app must begin through region monitoring, because that is what works when the app is closed or the device is locked (which is like 90% of the time for most people). So, for example, the Trésors cachés game began through beacon region monitoring (as opposed to only relying on beacon ranging and proximity to find the beacons, which would not work when the phone was locked/backgrounded/quit). The other events (entering/exiting breakout rooms, getting notified of upcoming sessions, visiting booths) were also triggered by region monitoring vs. ranging. So people are much more likely to engage with your app and your content if they can get notified when they're not explicitly staring at the screen.

And finally, we learned a hard lesson in upgrading - our beacon vendor decided a couple of days before the event to update the app I was using to program the beacons to require login and that each beacon be associated with the account used to order the beacons. This is great because previously, anyone could re-program your beacons and mess with yo stuff. But not so great when the beacons weren't properly linked to my account. So 2 hours before the France Symposium began, as I sat down to program the individual beacon UUIDs/Majors/Minors, I found that I could not! After several frantic emails to their HQ in Poland, their customer service reps were able to fix the issue - so that's +1 for Estimote.

Coming up next...

That's it for this entry. In the next entry I'll discuss:

  • How the Liferay Events app integrates with Liferay Portal
  • What kinds of beacon actions are good for different audience types, and how to not annoy people
  • Dealing with unintended audience behavior - using a Death Row analogy
  • Android vs. iOS considerations
  • Data collection, analytics and Privacy
  • Future Enhancements

Stay tuned!

iBeacons: The Next Liferay Chapter

If you'd like to know more about using iBeacons for engaging audiences and event marketing, check out my new eBook Finding Your Way Around iBeacons for Event Marketing.

Download the eBook

---

[Region image courtesy of TheNewStack. Proximity image courtesy of PassKit.]

Blogs
James, any update on part 3 or do we wait for Devcon?
http://www.liferay.com/web/devcon2014#agenda