redBus tracking — What’s under the hood?
If you have traveled by bus in the past, you know what it takes to prepare for the journey. Other than packing bags, you have to plan your day in such a way that you reach the right pick up point and you have to reach on-time. The anxiety that exists before boarding the bus surely overshoots the pleasantness of the journey you would have had. “Am I at the correct pick up point?” “Am I boarding the right bus?”; and, if you are already waiting at the pick up point, the most frequently asked question is “Where is my bus?”
Especially in tier 1 cities, with hundreds of pick up points across the city and most of the inter-state buses departing between 6PM-10PM, there are too many variables and missing a bus is not the experience one would want to have. There is just too much at stake! At redBus, we try to solve this problem and ease the entire boarding process for the passengers by providing the right information at the right time and as accurately as possible. While the whole live tracking feature of redBus is a vast subject, I would like to talk about one core aspect of this experience in this post — the location tracking device.
Location tracking devices are a piece of hardware that is installed on the vehicles to get the location of the vehicle in real-time. The technology is so common and easily accessible today that every smartphone that we use has a tracking device/chip which has opened up a plethora of possibilities for tracking the location of an asset in real-time. The asset can be the document that you couriered, food that you are eagerly waiting for or the cab that you booked on a ride hailing app. The underlying technology in all the location tracking devices is the same — The Global Positioning System (GPS). The working of GPS is a topic in itself and will keep that out of the scope of this post. Simply put, GPS is a constellation of satellites which the location tracking device pings periodically to determine its own location expressed in the form of two parameters called latitude and longitude. Latitude and Longitude are basically numbers used in a coordinate system to represent a location on Earth.
At redBus, we paid close attention to these tracking devices which publish the raw data of the bus location and play an important role in the overall live tracking experience of the users. With over 2000+ bus operators, 12000+ buses and 40+ vendors who installed tracking devices on these buses, we had a very diverse set of devices with varying capabilities and accuracy. It became imperative to have a common yardstick to measure them all which gave us a method to quickly decide if a device is good or bad; with key focus on the user experience. The way we approached this problem is by understanding the system from first principles and design the metrics which could give us an overview of the quality of the device.
The data flow from the tracking device to redBus is as shown in the below figure.
Every data packet that is received by redBus from the vendor server will have three main constituent parameters
- Location (latitude and longitude)
- GPS timestamp — The time at which the location was calculated by the device
- Reception timestamp — The time at which the data packet was received by redBus server
From user experience, the key issues one would face during tracking a bus are
The location of the bus is not updating for a long time. This often confuses the user that if the bus is stationary or something wrong with the interface
Ad Hoc and abrupt data updates where the position of the bus jumps from one location to other which is practically impossible and this doesn’t give a seamless user experience
Differences in the data presented on the tracking screen and the real world events. For example, a bus might have already reached a boarding point but the map shows the bus is yet to arrive
These problems create sub-optimal experiences and are a direct result of the quality of the tracking device that is installed on the bus. But how do we quantify the quality? In an ideal world, a good quality tracking device will solve the above user experience problems. So we looked at measurement of some key attributes which are indicative of the problems using the three main constituents parameters mentioned above.
How do we quantify the quality?
Problem 1: Location not updating often
A good quality tracking device would send the data packets (pings) often enough so that the users get near real-time information of the bus. We call this “Ping rate” — an average time difference between two successive data packets sent by the tracking device.
Problem 2: User observes ad hoc and abrupt data updates
A high quality tracking device should send the data packets consistently and continuously. If there are regions where the tracking device was not able to locate itself and the data is lost for more than 2mins, these gaps in the steam of the packets would cause abrupt updates. We call this “Black zones” — distance covered by the bus without the location data. It is expressed as the percentage of the total distance the bus travels boarding the passengers from different pickup locations (boarding distance).
Problem 3: Differences between the real world events and the data from the tracking device
A high quality tracking device with a good communication module should send the data packets instantly to the vendor servers and redBus should receive these data packets with minimal delay so that it accurately represents the real world status of the bus. We call this “Latency” or “Insert delay” — An average time delay between the GPS time and the reception time of the packet.
Based on user expectations, we came up with the following thresholds for each of the above metrics to determine if a device is “Good”, “Average” or “Bad”. We collectively call the metric “3-factor compliance”. As the name indicates, it is the measure of the 3 factors we consider for the quality.
Now that we have the yardstick ready, we evaluated these metrics for all the devices from multiple vendors which are sending data to redBus and put them into the above three buckets. For this classification, we gave 60% weightage to ping rate, 30% to insert delay and 10% to black zones.
But the quality is a dynamic attribute. A device which has bad performance due to hardware issues can be repaired and if it is due to software, it can be upgraded. So, this is not a one-time activity. We update these metrics for all the devices for every 5 journey days and hence have the latest data at any given point in time.
As you can see, the majority of the devices in our inventory are not up to the expectation and that was a big insight for us. This gave us clear direction towards improving user experience and action items for improvement of the device quality.
In addition to the three factors mentioned above, we also monitor two more parameters called “real-time packets” and “duplicate packets” which help us to measure some of the most common issues which may or may not be under the direct control of the device vendor. Let me explain what these are briefly.
Real-time packets
It is a common occurrence in the usage of the tracking device that some of the packets don’t get sent in real-time to the vendor servers by the device due to low network connectivity. The devices are designed to store these packets locally and push them to the vendor servers the next time the device is able to successfully establish a connection to the vendor servers. Since these packets are stale, they are not useful in real-time tracking; but are necessary for any post-facto analysis. We call these packets “Back-up packets” and the ones sent instantaneously are called “Real-time packets”. We calculate the percentage of real-time packets of all the packets received from the device which is a measure of the efficiency of the communication module and the network connectivity of a device. Higher the percentage, the better the quality.
Duplicate packets
Lastly, we measure one of the fundamental attributes of the tracking device which is to send unique data packets every time. It so happens that sometimes, the devices send packets with the same GPS timestamp and the same location (latitude and longitude) which gives the perception of high ping rate but actually these are duplicate packets. A vehicle can send the same location in successive packets but never the same GPS timestamp. Of all the packets received, percentage of duplicate packets is a measure of the basic sanity that is done at the vendor servers or on the device.
What’s next? — Although for our understanding, we evaluated the metrics of tracking devices and simply classified them as Good, Average and Bad, our goal is to improve the overall tracking experience of the users. This is where redBus B2B products and business teams come in. For a bus operator, when he opens the dashboard, he gets a quick summarized view of all the devices which are consistently performing badly and hence need replacement.
At the same time, our business team takes targets and drives initiatives to replace the bad performing devices phase by phase. But this time, they go with actual performance data to convince the bus operators to invest in new devices. Thanks to the metrics! As we continue to install more high quality devices, we will track the progress and the actual impact on the overall user experience.
A huge shout out to all the folks mentioned below who have contributed towards bringing this idea to life.
redBus tracking team who built the tech meticulously and scaled efficiently — Harshkatare Pradhanbv Akshay Anand
redProWin (redBus B2B) product and design team who built this beautiful dashboard — Nihit Jain Deepika Jain arjun
