How to Choose an iBeacon platform for your Beacon Project
February 16, 2016
2016 began with a whole lot of exciting news from the beacon world. Famous pharmacy chain Rite Aid went on to claim the title of the brand with the largest beacon installation in retail till date, after having deployed beacons in more than 4500 stores across the U.S. NRF 2016 saw Verifone announce to the world that going forward its point-of-sale terminals would come with built-in beacons. Screenvision, a movie theater management company installed beacons in about 300 theatres (which include 2500 screens) as part of their initial beacon rollout.
Thus, with more and more brands announcing beacon projects that are focused around providing value to the end consumer, 2016 is increasingly proving to be the year of the beacon. However, in the midst of all these developments, many businesses still continue to struggle when it comes to kickstarting their beacon project. This is primarily because deployment of beacon infrastructure is quite complex and the decision around what kind of beacons or which beacon platform makes sense to go ahead with, requires a lot of research and testing. Having said that, most businesses even today aren’t very clear about how beacon hardware and software work together. And this lack of knowledge often leads to many misconceptions around beacons and the values assigned to this technology.
In this blog we will take these challenges head-on by discussing in detail about how beacons and APIs work together. And then we will go on to talk about a few things that brands need to keep in mind when choosing a beacon platform.
How do Beacons and Application Programming Interfaces (APIs) work together?
Contrary to popular belief, beacons do not send notifications to a user’s phone; apps do. Therefore, once a user has installed the corresponding app on his/her device and enabled bluetooth and location services, the SDK begins to search for beacons in the surroundings, in the background. Once detected, the beacons simply send a unique identifier to the app (akin to a geographic landmark), to tell the app that it is entering the beacon range. This will then cause the app to make API calls to the server and send information on the location of the user based on the location of the beacon that was detected. And in return, it will ask the server for the information that should be displayed by the app to the user (given the context of the beacon that the user is close to). Accordingly, the user will receive a push notification on his/her device.
On the other side, the console API uses the location information and behaviour of the user to provide insights on analytics metrics such as – number of repeat visitors, mean or average visit duration, zone dwell times, popular customers paths taken in-store etc. These metrics can then be used to uncover behavioral patterns that can be turned into highly segmented marketing campaigns.
Things to keep in mind while choosing a Beacon Platform
1. Take note of the efficiency of the beacon-based APIs in the face of stress and limited power
One of the primary things that brands need to be sure of while choosing a beacon platform is its ability to crunch data sent by millions of phones at the same time. This is highly critical because unless the beacon-based API is able to store all such information, users won’t have access to any necessary information right from the start.
In order keep a check on this, we at Mobstac, highly recommend brands to use a stress simulator test that generates a lot of fake users, all trying to access the server at the same time. This helps brands understand the limits in terms of data that can be handled by the beacon-based API. Once brands get a good idea of these limitations, they need to check if they can process more such information by making it as horizontally scalable as possible – say brands use one server for one million users, then they can use two servers to process two million users, and so on.
2. Check for the impact that the platform has on the battery life of every device it runs on
Another important thing that brands need to ensure is that the app on the user’s device doesn’t use up too much battery, as this could lead the user to uninstall the app eventually. The best way to go about this is to perform efficient scannings when in the range of beacons.While iOS performs this OS scanning (also called beacon region monitoring) once in every 20 seconds, without user intervention, Android devices allow brands total control over their scanning frequencies.
In the case of Android devices, we at MobStac, recommend brands to perform beacon region monitoring once in every 30 seconds or one minute, based on the data that is arrived at during testing, and then tweaking it to optimize the impact.
Another highly recommended way of crunching the same amount of data, while preserving battery life is using geofencing. For example, the Beaconstac platform comes with a feature called ‘Places’ that allows brands to label a store-location and create a geofence with ease. Businesses can simply add a place by choosing ‘Places’ from the navigation, clicking on ‘Add a new place’ and typing in the attributes such as name and address (latitude and longitude values) of the place. Once that is done, they can easily define the range of a geofence (in metres). Here is the video elaborating the same:
This way brands can set rules using the Rule Engine to start beacon region monitoring once the device is inside the geofence and stop scanning once it is outside the defined geofence area. It highly critical for brands to test their beacon projects on multiple devices over multiple periods of time, preferably at multiple locations.
3. Choose a powerful rule engine which allows you to hold interesting beacon projects in a simple manner
When it comes to choosing a beacon platform, it’s important to go ahead with one that has a powerful rule engine that allows to easily set up complex and interesting beacon campaigns without a developer’s help. Some of the features that brands need to particularly look out for, include:
(a) Ability to show messages from relevant beacons with ease – This feature allows beacon platforms to figure out the beacon of interest among multiple visible beacons, based on the proximity of the user and the direction in which the user is moving. For example, this can be easily done on the Beaconstac platform via the ‘Camp On’ feature. Once it identifies the beacon of interest, the app will trigger content based on the rules applicable to that particular beacon.
To elaborate on the advantage offered by this feature, let’s take the example of a retail store with 3 different sections namely – Clothing, Bags and Shoes, with a beacon deployed in each of these sections. In the absence of the ‘Camp On’ feature, a user who walks into the Bags section from the Clothing section will continue to receive messages from the Clothing section (as he will still be in the range of the beacon placed in the clothing section). Chances are that this might just irritate the user and nudge him/her to uninstall the app.
On the other hand, with the ‘Camp On’ feature in place, the SDK camps on to individual beacons as the user moves from one section to the other (i.e in this case he/she is heading towards the Bags section from the Clothing section). This allows the retail store to show the corresponding relevant message to the user, one at a time, thus reducing ambiguity about the beacon of interest.
(b) Can trigger rules based on tags – This allows brands to manage a fleet of beacons spread across multiple physical locations, grouped into different departments, and having different proximity messages attached to each group, with ease.
For example, say Brand V runs a clothing and accessories line in stores across London, Canada and San Francisco. Now the brand plans to run a targeted beacon campaign for shoes across its stores in London only. This can be easily done by adding both the tags – ‘shoes’ and ‘london’ to the ‘Shoe Campaign only for London’ rule in the Beaconstac platform. This way only the beacons with both the tags will be used for triggering the rule.
(c) Has various Action types feature – To make notifications more interesting it is always best to opt for a beacon platform that supports various action types including, cards, webhooks, webpage, text alert etc.
(d) Has the Custom attributes feature – These are user segmentation parameters that allow brands to further segment their users for targeted messaging. Brands can easily define one by adding the name of the parameter and then assigning a value (string/number/time) to it. The app code can then keep updating these parameters by calling the SDK API based on user behaviour. When the condition set on the portal matches the parameters updated in the app, the rule is triggered.
For example, say Brand V is running a targeted campaign for all women under 35 years of age. This can be done by creating a rule and expanding the custom attribute box by clicking on the ‘Create a custom attribute’. Next, define a custom attribute called ‘Gender’ and another one called ‘Age’ and match it to type ‘String’ and ‘Number’ respectively.
Next, return to the ‘Rule’ window and match the ‘Gender’ custom attribute to ‘Female’ and ‘Age’ custom attribute to under ‘35’ as an additional condition to trigger the rule.
When these conditions, that have been set on the portal match the parameters updated in the app, the SDK sends a callback to the app with a reference to the Rule name and other actions as configured by the brand on the Admin Console.