Our role as developers routinely extends beyond the editor and prompt to include technology consulting. We help our businesses and clients navigate complex topics, analyzing options and making recommendations.
This guidance is even more important when exploring new technologies: do you risk over-committing to a passing fad, or miss out on a competitive advantage by not investing soon enough? This question has most recently been applied to the adoption of iBeacons and beacon technology. Beyond the basics, here are four tech-related considerations for deciding when and how to build that first beacon app.
Just because you can, should you?
As businesses begin brainstorming how location-based awareness could be used within new or existing apps, user experience should still be our first priority. Flashy use of beacons can be appealing, but we need to review how the beacon app adds value to the customer’s experience. For example, it may not make sense to build an app for a small boutique store, as the customer will likely speak to an employee before engaging an app.
TIP: Keep the beacon “ideal use case” in mind throughout planning: any space where people are 1) interacting with a brand 2) via an app 3) where location-based data would enhance the experience.
As much as we’d hope all customers would begin using an app on day one, beacon-enabled apps face some hurdles to widespread adoption. There are several steps a user has to take before an app can interact with beacons. To understand rollout and user adoption, it’s helpful to view the process as a funnel for beacon engagement:
- App install rate
- App open/use rate
- App grants permission to use location data
- User visits beacon-equipped space
- Ad/message impression
- Correlation to sale
While customers can complete steps 1-3 in moments by downloading and running the app, the process highlights the promotional effort and analytic review necessary to nurture use or sales with beacon technology.
Hard-code the experience?
As app planning transitions to architecture, it’s important to consider the product lifespan as it relates to the physical experience. Some beacon experiences have a fairly static lifespan with changes managed through new version releases. For example, an app to enhance a museum exhibition may only need to be updated once or twice a year. Some retail messaging changes frequently though and may not be able to coded directly into the app version. In these instances, an additional web service may need to be developed to provide dynamic updates to the app’s content. As frequency of message updates increases, the architectural requirements also grow in complexity.
Beacon hardware supports cross-platform use, but development remains a separate effort for native mobile platforms. Many beacon hardware manufacturers provider wrapper SDKs to native mobile libraries (we’re a fan of Estimote’s SDKs), but the second half of 2014 saw Apple protecting the iBeacon brand for exclusively Apple devices. Especially with experimental app deployments, now may be the time to explore cross-platform like Cordova/PhoneGap and Xamarin.