A few weeks ago we launched live tracking for our guests. Now you can track your Shoffr on the upcoming trips card on the home page of our website.

Why?

One of the biggest anxieties in booking a trip is whether the car will come in time or not. An interesting incident a few months ago was when a guest booked a trip with us several days in advance, then panicked and cancelled because “there was no communication” from our side. That was our first lesson in non-transactional customer communication – we started sending an “You have an upcoming trip with Shoffr” kind of message 1, 2, and 3 days before the trip to tell the guests that we hadn’t forgotten about it.

However, this anxiety is at fever pitch close to the pick up time. We get a lot of calls and whatsapp pings just enquiring where their Shoffr is and when it will reach.

Our problem was keeping customers informed that their vehicles are on time (or a little late on the rare occassion). This makes for a happier customer, and reduced call volumes for us to handle.

How?

The accepted solution to this problem is showing vehicle tracking. And while this is ubiquitous, it is neither easy nor cheap to implement. So while we wanted to implement it, we also wanted to keep our pockets burn-free.

OSS to the recue!

Open Street Map (OSM) is an project which maintains map information via volunteer contributions and makes it publicly available via publicly hosted APIs. Leaflet.js (and its Reactjs wrapper react-leaflet) is a handy map rendering library. With these tools, we went hand-rolling our our little tracker.

We decided to merge the GPS information from our cars with data from OSM to show live tracking to our customers. And while showing a car on a map was the big guest facing feature, there was a bunch of stuff the backend had to do before this became feasible.

Getting the data

While we have used telematics and GPS data for operational monitoring since the beginning of Shoffr, this would be the first use of this data in powering a customer experince feature. This caused a few changes in the way we pulled this information from Intellicar (our telematics provider).

We already had a polling setup which ran every 10 minutes to pull the location of each car into our system. But to show a noticeable tracking experience, this data had to be pulled in much more frequently. We could simply increase polling frequency, but that would put too much pressure on Intellicar API as well as our database. So we worked with Intellicar to implement a push mechanism where they would push GPS info to our system every 10 seconds. This removed the polling pressure.

To reduce the pressure on our database, we implemented a mechanism where the latest pushed location would always be put in a cache to be read, and we pull and store it into our database every 5 minutes. While this means that we do not have the values inside that 5 minute window stored in our transactional database, but that’s fine since we store it all in our data lake anyway.

Rendering the map

Once the data was in place, we went ahead with merging it with map data from a publicly available OSM API and rendering it via react-leaflet. To avoid overloading this free infra (free is great, but we wanted to be responsible about using it), we decided to limit how and when live tracking was shown. We would show it starting 30 mins prior to the trip start time (when the car should really be closeby), and stop showing once the trip starts.

Leaflet.js works directly with the DOM and doesn’t support server side rendering so a few tweaks were needed to make it work with our nextjs setup.

Debugging tip – If you do everything right with the library but do not explicitly specify the size of the MapContainer, the map WILL NOT render. Hope it helps – I lost several hours to this.

Impact

We have been guiding our guests to this feature and the feedback has been great so far. We realized that there’s no such things as “too many ways” when it comes to relieving our guests of the fundamental fear of getting picked up on time.

Additionally, we also learnt that a huge hurdle to adoption of tracking is guests not opening the website repeatedly in the first place. Opening websites just isn’t the default user behaviour anymore. we hope to address this with our upcoming app launch.

Evolving

While the limited tracking we show to our guests today in useful, we want to build a better and more comprehensive tracking experience, not just for the traveller but perhaps also for their parent, friends etc. However, it is clear that it cannot be built at scale on public infrastructure. So we need to evaluate our choices in terms of commercial operators or explore self-hosting OSM data.

We will keep you posted right here on how that is coming along 🙂