How to mitigate the impact of geolocation problems on your business
Tags: Bigquery, Firebase, React Native, Mobile App Development, Firebase Performance

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 Firebase Analytics. However, the Firebase 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 Firebase Analytics shows you in beautiful dashboards is actually the result of queries on BigQuery.

This is what a query on BigQuery looks like

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).

Excerpt from React Native API documentation

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: