How to mitigate the impact of geolocation problems on your business
A brief story of how we achieved this with the support of Firebase products for our React Native app.
One of the most important features in the user journey on the Gympass product is what we call "check-in". It is through this functionality that the user can access any activity (be it on-site or online), and therefore, help us achieve our goals and pursue our mission: to defeat inactivity and make people increasingly healthy and productive.
The functionality is quite simple. After accessing the check-in screen, the user will see a list of fitness facilities nearby. At this point, they can select the facility they’d like to access, the activity they’d like to perform, and enjoy. What we mentioned as "nearby", is the source of - almost - all our problems.
How did we build our solution?
Our application is developed using React Native, having most of our codebase in JavaScript, with only a few implementations on the native side. Therefore, for several infrastructure capabilities, it is common for us to have access only to the exposed JavaScript API, using native resources indirectly. This is also the right context for geolocation features.
The native implementation of the iOS platform behaves in a very stable way, and therefore it never has any geolocation problem that’s worth taking into consideration. However, on the Android platform, problems have popped up since the very beginning and have not ceased to grow.
After so many reports, we decided to measure when and how exactly these errors occurred, so we started sending an event named position_request_error with the error being the parameter representing the cause of the problem according to Google Analytics. However, the Google Analytics Dashboard did not allow us to filter all the parameters we wanted (it has a maximum parameter report allowed, and we had other events using these parameters).
BigQuery
So we needed another way to get the event data sent to Firebase and organize it the way we wanted, thus extracting something more valuable for decision making. That’s when we found a tool that perfectly met those needs: BigQuery!
BigQuery is, put in simple words, the database where all your events are saved. What Google Analytics shows you in beautiful dashboards is actually the result of queries on BigQuery.
After a new release that made it possible to track the events, we found out that:
- 28% were users who denied access to geolocation;
- 26% timed out when requesting the position;
- 23% did not have any position available;
- 23% unknown.
At a first glance, they all looked very similar and it seemed impossible to create a strategy to solve them all. Investigating further, we could spot different natures of the problems in Android, which made us look better into platform issues.
After some research, we found a possible root cause. The React Native documentation itself indicated that the API available by default was based on native implementations that were no longer recommended by Google. Luckily for us (and the community in general) the doc’s authors already indicated how to use the recommended implementation (Google Location Services API — https://developer.android.com/training/location/) via react-native-geolocation-service package. (https://github.com/Agontuk/react-native-geolocation-service).
As we wrote at the beginning of this article, geolocation is crucial for our application. As new devices manufacturers and new device models grow daily, we must keep our dependencies up to date to be ready for the next releases by Apple and Google, and reduce the number of bugs with their features. Obviously, the first thing we did when we discovered this documentation, was to add and test the recommended library (now hosted by the community with lots of improvements since the last version we used).
Surprise, surprise, after releasing with the library updates, this is what we got:
- Unavailable position errors got down to nothing less than ZERO to ZERO;
- Timeout problems reduced by 50%.
Would watching the user’s location more frequently increase our success rate?
Yes, of course, it would (at least that’s what we thought). After all, the UX at Gympass is all based on geolocation, and the product would just cease to exist without it. If you’ve worked with geolocation before, you’ll know that parameters like accuracy, timeout, distance, etc., really make a difference. So we decided to test them and see which one could affect more directly our success rate.
We used the Firebase Remote Config and A/B Test features in order to test different scenarios. There are two remote configs we created for A/B testing:
And this is the A/B testing for one of them:
One of our hypotheses was that some users open their check-in page while still far away from the desired fitness facility, and if we did not constantly refresh parameters like time or distance, they would get the wrong results once at the facility. Considering this, our A/B test aimed at validating if updating the user location more frequently would eventually increase the number of successful check-ins.
The control group had their location updated every 50 meters, and the A and B groups had 40 and 20 meters, respectively. Our success metric is our custom event “checked_in”. As you can see, Firebase provides other success metrics such as 1, [2~3], and [4~7] days retention. What no one in the team expected is that updating a user's location less frequently would be the best scenario for their experience.
The result will vary for each application that uses geolocation, so please don’t take this as the source of truth for your application. What we recommend is that you develop similar tests in order to get the correct results for your application.
Measuring through Firebase Performance the success and failure time from getting user position
From the reviews, we understood many users were receiving timeout errors while we requested their location. But how to differentiate users with a poor network located far away from those in the right place and with a high location accuracy? Users with the best devices and most recent OS versus old devices with 4 years deprecated Android version?
We decided to measure how long each device takes to successfully request a user location. Firebase Performance helped us a lot since most Firebase products use all the device data they can get to filter all the data. The result is that with 2 lines of code we got more than a million samples of usage, organized by device model, OS version, SO, Career, Country, network.
What did we learn from that? Well, now we can differentiate a bug and an old device running an old OS version, in a country/city where the location takes too long to be resolved. Nowadays this is just one more KPI we have, and we can compare different periods to know if some feature we made affected response time for requesting location.
It’s almost over!
After months of working on improvements for the user experience, at such an important point of the user journey, we were able to count on several products in the Firebase suite, making great discoveries about the usage profile of our application. Google Analytics and BigQuery helped us to first identify and then classify our problems, Firebase A/B Testing enabled from Remote Config showed us the best options for requesting user position and Firebase Performance set KPIs for what is the expected response time when requesting user’s position.
As the subtitle of the article suggests and you may have noticed while reading, we do not propose here how you should solve your problems with geolocation, simply because there is no definitive solution. Geolocation is still a challenge in a totally heterogeneous universe of devices, operating systems, and development platforms. We’d just like to share our story of how we managed to override them and improve our user experience, while we present what tools can help you override yours too.
Have you experienced similar situations or used other techniques and products to deal with them in your organization? Share your stories with us.
Hope you have enjoyed reading this article!
=)
And thanks Rafael Rollo for the opportunity to write this post together!
