We are the Dev Teams of
  • brands
  • ebay_main
  • ebay
  • mobile

Geofencing in the mobile.de Android app

by Mario Böhmer
in How We Do It, Tutorials

As Germany’s biggest online vehicle marketplace we were always great when it comes to help potential buyers on our channels during their specification phase. We built great experiences to guide them through their potential purchase of a vehicle. However, we never had insights into what happened next. We didn’t know when and if an actual buyer visits a seller to complete the purchase.

We needed a possibility to guide users through their journey of buying a vehicle even after they contacted the dealer. Wouldn’t it be great to help them while they are actually visiting a car dealership?

That’s where a technology called geofencing comes into play.

A Geofence is a virtual perimeter definition around a geolocation in a defined radius. You can use that perimeter definition to receive signals when someone enters, exits or dwells in that perimeter.

Geofence transitions.
Source: https://developer.android.com/training/location/geofencing.html

We started to experiment with geofencing to learn more about our users and to see where we can provide additional services that are beneficial to the user during the realization phase. Android provides great support for contextual location aware features so we started our experiments on Android by utilising the Android geofencing APIs.

The geofencing APIs are part of Google Play Services Location Services APIs. So in order to use them you have to integrate Google Play Services. A complete integration guide for both Google Play Services and geofencing can be found at: https://developer.android.com/training/location/geofencing.html

So how did we utilize geofencing in the mobile.de Android app?

When a user found a vehicle on our platform and adds it to his favorite list, we check if we have the necessary geolocation data (longitude and latitude) of the seller of that vehicle. This is usually the case for commercial sellers and car dealerships. We register a Geofence on that location with a radius of 250m and a trigger for the enter transition at Google Play Services.

Add vehicle to favorite list and register geofence with latitude, longitude, 250m radius and enter transition at
Google Play Services.

Now when the user is visiting that seller at some point in time, we get the signal from Google Play Services and we can spawn a notification. This notification promotes our checklist feature which guides a user through a quality check while inspecting the vehicle. Upon click of the notification the user enters said checklist and gets an overview of the most important checks to be made when buying a vehicle.


When the user is at the dealership and the geofence is hit, Google Play Services sends the trigger signal to the Android App which spawns a notification that leads to the checklist feature.

There are several question which might come to mind now.

How can you test geofences without walking through the whole city?

Before doing a real field test you can use third party apps to mock your location and its accuracy to make first adjustments to your radius and test your notification flow and see if your geofences were registered correctly. This is especially crucial while debugging your notifications. It’s kind of hard doing that in the field.

In order to do that you need to turn on “Allow mock locations” in your developer settings on your Android device to enable a mock provider for location data. Third party tools like “Fake Location Spoofer” help you to set your current mock location and can even adjust the accuracy of the received location.

How did we come up with this magic number of a 250m radius?

We validate and test everything we develop for our products. For this particular feature we started with an employee field test. We tested with a very small radius of 50m and set artificial geofences around our typical work commute. Surprisingly only half of them triggered and even those only did so sporadically. So for some reason not all geofences triggered.

That comes not as a surprise though if you think about how geofencing is integrated in Android. Being part of Google Play Services, geofencing is dependent of geolocation updates done by Google Play Services doing location updates itself or by feeding passively from other apps requesting location updates. Google Play Services tries to keep its location up to date while trying to consume as little battery power as possible. It does so mainly with triangulation of the cell network and via known WiFi hotspots. Because cell networks have a more coarse location accuracy it may happen more often that you miss a geofence with a smaller radius. This situation improves drastically if geolocation updates are triggered by GPS but Google Play Services will only utilize this if they are triggered by other apps.

How does this translate to our problem? Imagine the diagram below.

Geofence would not trigger.

Although it seems that the user is within the geofence perimeter, his accuracy is not that good. It may very well be that he is still outside the geofence. There is no way for Google Play Services to be sure about that and that’s why it won’t trigger an enter signal in that case.

If the user was located with an accuracy which translates to all possible geolocations within that perimeter then Google Play Services can be sure about hitting the geofence and will trigger the enter transition.

Geofence would trigger.

So in our case it turned out that our geofence radius was just too small to trigger in most cases.

We adjusted our radius more and more and through AB testing in our live application we were able to determine that we get the best results by sticking to a radius of 250m. This doesn’t sound very accurate and it isn’t, but we needed to make sure to reach most users with it while still being as accurate as possible.

In those situations it is important to be pragmatic in your communication to the user but also to your stakeholders. Everybody within the company needed to understand that geofencing is not at all accurate and we still might miss some users. So we should carefully think about every business case we bind to it.

On the other hand the user communication within our spawned notification needed to be careful enough to not annoy or confuse the user. We did it in a way where we asked the users if they are near a car dealership and that we could help them with their task of buying a vehicle.

The geofence notification received when a user enters the geofence of a car dealership.

So what are the results?

For us geofencing really proved that “context is king”. In this particular scenario the context was the location context which provided the users a useful tool in their current intention of looking at or even buying the car they put on their favorite list.

With typical notifications like results for your saved searches you typically get a click through rate of about 30%. This is mainly because you might receive the notification during a time where it is just not convenient for you to open it or you are just not interested in it at that moment.

With our geofence triggered notification the click through rate was amazingly at 60%. That can be explained by the mere contextuality of that feature. The notification hits you when you are actually at the dealership and you probably want to check out one of the cars you added to your favorite list of that particular dealership.

Before we introduced the geofencing feature we already had the mentioned checklist on our detail screen. However users didn’t use that checklist at all. Which comes as no surprise because besides taking notes there was not much of a point of checking the motor when you are sitting on your couch.

In contrast to that, by actually assisting them while they were in the process of checking their desired vehicle at the dealership, this feature was becoming a delight for the people who needed that in the right context.

Tips and pitfalls

  • There is no perfect radius for geofencing, experiment and determine your sweetspot. Take your time to do it right.
  • Use third party mock location providers to help debug your Geofencing logic.
  • Context can be a great driver for features which might otherwise render useless.
  • You can only register 100 geofences per device user, so think of your use cases. We only register the most current 100 vehicles added to the user’s favorite list. We evict older geofences.
  • As hinted by the community, geofences do not persist during a device reboot.
    This however might be subject to change or merely a bug. To circumvent this you can register a BootBroadcastReceiver for the RECEIVE_BOOT_COMPLETED signal from the system and reregister your geofences. If you have a Google Analytics integration and you initialize it during process creation this may cause a sudden rise in sessions so be careful.
  • Always check the received GeofencingEvent for errors before you do any processing.

    GeofencingEvent geofencingEvent = GeofencingEvent.fromIntent(intent);
    if (geofencingEvent.hasError()) {

  • Always check if the received GeofenceEvent really reflects the transition type you are interested in.

    // Get the transition type.
    int geofenceTransition = geofencingEvent.getGeofenceTransition();

    // Test that the reported transition was of interest.
    if (geofenceTransition == Geofence.GEOFENCE_TRANSITION_ENTER) {