Trigger Data and Beacon Servers

The article on iOS and Android Apps explains how beacons transmit unique ids and how, in many scenarios, these ids need to match up with data held elsewhere, not on the beacon, that determines what the app does and what's displayed to the user.

This trigger data can be obtained in many ways (in order of increasing complexity):

  1. Send out a URL via Eddystone URL

    In this case the beacon is configured to contain a URL. You don't need an app because Google Chrome or the Physical Web App detect Eddystone beacons and produce a notification. You will need a secure server (https://) for the destination web addresses. Read more about Eddystone URL and the Physical web.

  2. Use Google Nearby

    This is a free Google service that doesn't need an app because the detection side is included in the Android OS (Google Play services to be more precise). It only works on Android (consider that's up to 80% of smartphones) and can send either a web address or link to an app to be installed. Both iBeacon and Eddystone-UID beacons can be configured to trigger Google Nearby notifications. You will need a secure server (https://) for the destination web addresses.

  3. Include the data in the Android and iOS apps as fixed data

    While simple, this approach isn't flexible as you won't be able to easily change the trigger data. Nevertheless, it might be sufficient for trials or as a proof of concept.

  4. Subscribe to a commercial ready-made server-side solution

    A very large number (160+ at last count) of startup companies provide solutions that tie together beacons, a ready-made server and an SDK to more easily create iOS and Android apps. Sometimes they also provide the apps. These tend to be tightly focussed solutions based on retail scenarios that sometimes tie you into purchasing particular beacons and/or a commitment to a monthly server side licence fee.

    Some of the more mature solutions provide more precise location through use of bespoke algorithms and better security through the use of rolling UUIDs. However, schemes such as this that require connection to beacons will result in shorter beacon and handset battery life. The connection from smartphone to server to resolve the rolling UUIDs also relies on an Internet connection that can be slow or sometimes non-existent.

    You should consider data ownership, data privacy and service level issues when using such complete systems. They also might not be flexible enough or able to be changed for some non-retail scenarios. Probably the largest consideration is whether some of these startups will continue to be around as long as your solution and whether pricing will remain stable. Startups have already started to suddenly impose charges for, what were free, backend services after they have determined they need to make more money. Some service have been discontinued at short notice. Nevertheless, ready-made solutions provide a relatively easy, quick solution. We provide a curated list of ready-made solutions, including stand-alone apps, in our Solutions Directory.

  5. Use or extend an open source server-side solution

    Software such as the open source SBCMS can be hosted on your own server or automatically on a Heroku cloud server instance

  6. Build your own server side-solution that matches beacon ids with trigger data (text, URLs, images)

    If you wish to go it alone or need a non-retail solution that needs a server, take a look at
    Google's free Proximity Beacon API that allows you to associate any data with an iBeacon or Eddystone beacon. Alternatively, with some development effort, you can use any server to host a simple web UI and provide data for apps.

    Building your own solution doesn't always need to be complex or costly. You can
     use Backend As A Service (BaaS) providers such as Firebase to provide a custom server with included app APIs without any server-side development. However, as demonstrated with the demise of parse.com, BaaS providers pose similar risks to commercial ready-made Beacon CMS solutions in that they won't necessarily be around into the future. They are probably more suited to proof of concepts or trials.

    A further, newer, way of providing for an easier server side is to use
    Parse server. The closing of parse.com caused the server side to be open sourced. You get most of the advantages of Parse (no server side development and easy to use app SDKs) without the uncertain longevity risks of using a BaaS provider. Our Beacon Demonstrator app uses Parse server.
Need more help particular to your project? Read about our consultancy and development services.

Further Articles:

Choosing UUID, Major, Minor and Eddystone-UID For Beacons

Choosing an Advertising Interval

Choosing the Transmitted Power

Determining Location Using Bluetooth Beacons


Tags: ibeacon, eddystone