Nuances to Location Services

Sometimes, when entering near the proximity of a store location, users do not get push messages until much later. How do you account for this?

The reason for the difference is because GPS is only as accurate as its surroundings. If the phone does not have data coverage (cellular or wifi), location services will not always work reliably. Past that, GPS for indoor locations is always a challenging experience if the device cannot physically 'see' satellites.

For more specific, indoor-triggered push experiences, Gimbal beacons are a great alternative and do not require GPS. It should be noted, however, that each user on different devices is going to get a slightly different experience, but during large scale repeat testing, it’s usually about 10-15 seconds from when someone is in range of a Gimbal beacon and then receives a notification.

What about battery efficiency? How is the Gimbal SDK different from others?

Gimbal SDK is built to balance accurate arrival at a place within the bounds of what is provided by Apple and Google’s OS level requirements. The Gimbal SDK is designed to monitor for ‘places’ near you. As you enter closer to a place, the SDK starts monitoring for places more rapidly, but in a battery efficient way. This is done if an app is in the foreground, background or hard closed. Most other providers monitor for places 24/7 when attempting to obtain a background location fix, which can lead to battery drain. Gimbal makes sure the application is not constantly monitoring for places. For example, if I am based out of San Diego, my application with the Gimbal SDK will only monitor for places in my area rather than places that may be set up in New York.

Two app users with the Gimbal SDK enter near the proximity of a geofenced location. One user receives the notification a few yards away from when the other user receives a notification. Why?

Accuracy for GPS is never accurate for more than 50m. There will always be 100m of linear accuracy. Even then, you are going to get a 15 second variability for each user. Beacons can solve for this macro-level accuracy.

Why is the Gimbal SDK required for a beacon use case?

It’s not technically required, but there are strong reasons to use Gimbal’s SDK with Gimbal beacons. If you are looking for any degree of scale and want to use other protocols out there, such as ibeacon, you would need to configure each and every beacon individually, whereas Gimbal beacons come pre-configured. Gimbal SDK can then identify them uniquely without reprogramming.

Why should I use Gimbal Beacons?

Most beacon manufacturers don’t design their own beacons, and substitute quality for a cheaper price. Gimbal uses tier 1 contract manufacturing for S21, S22 and S10 beacons.  No other beacon manufacturer uses this as most require large volume orders. Our manufacturing runs have exceed over 1 million beacons per order.

Doing our own designs for beacons is important because it lets us make our own design choices. For example, all the antenna designs were done by the same teams that do the cellular antenna designs for all of the current Android and iOS phones. With a good antenna, you get stability of signal which gives you accuracy of proximity.

Why should I use Gimbal Software?

Gimbal writes all of our software down to the chip. Most manufacturers only use software available from the manufacturer. Gimbal is able to do our own encryption and we encrypt our firmware as well.

How often does Gimbal make a resolve call?

A resolve call occurs when an application sees a beacon, which then sends that information to the server. The server responds to the call only if that application has ‘permission’ to see the beacon. This resolve call is how Gimbal manages which applications can see which beacons. This is generally only required once per day, but there are a lot of situations that can cause it to behave differently. For example, if connectivity is poor, Gimbal will continue to attempt to make a resolve call until it is successful. Note that this is a beacon resolve call, not geofencing.

What is the difference between client-side and server-side geofences?

Server-Side (Not Gimbal) 

• Primarily Foreground: Only getting location read when app is open (insufficient for capturing device journey because location updates are only done periodically in the foreground)
• Power consumption: If done for an app running in the background, it requires using GPS and the data connection to tell the server a phone’s location 24/7, resulting in battery drain.
• Delay/Missed Connection: The latency of sending data could misrepresent a user’s actual location if connection is off

Client-Side (Gimbal)

• Power Consumption: Optimized to minimize power consumption (where geofence is on client-side, it’s optimized based on distance). Unlike other products, Gimbal allows applications to use geofences while in the background, with minimal impact to the battery life of the mobile device.
• Performance Scaling: Automatically adjusts for greater accuracy with lower power consumption. Gimbal users a combination of GPS, Wi-Fi, cellular, along with proprietary algorithms to manage and detect geofences.
• Powerful: Supports an unlimited number geofences of any shape with a radius of 50m+
• Updates: Customers can easily add, edit and delete geofences from Gimbal Manager without requiring the application to be updated in the app store.

*Client-Side is most useful for developers who want to trigger user experiences when the app is not on the screen

How long does it take for a new geofence to sync with the Gimbal SDK?

It can take up to 24 hours for Gimbal's SDK to sync with a new gefoence.

How accurate are geofences?

Gimbal geofences are accurate up to 50+ meters. Gimbal confirms the accuracy of lat/long and scrubs bad location fixes. For example, if Gimbal sees a device moving 150mph it is likely inaccurate. We also clean location data that does not represent human behavior.

If you are interested in location accuracy below 50m, beacons are a great alternative and do not require GPS.