By Sooraj Rajmohan

Some time ago, it wasn’t uncommon for Gojek’s ‘Allocations’ team to find discrepancies in the rides our driver partners completed. Some of them seemed to be achieving their daily targets with unnatural ease, while others accepted rides near a customer’s location, and magically appeared further on the map. We weren’t even aware that some of our partners were capable of teleportation.

Clearly, something was up.

The flip side of being a popular product operating at insane scale, is that at some point you’re bound to find fraudulent elements. People would sign up to Gojek with multiple accounts, book rides with one, accept them with another, select the cash payment option to avoid being tracked, and pocket the ride completion incentives Gojek handed out. In some cases, driver partners would even resort to using techniques like GPS spoofing. They would make themselves appear close to popular landmarks with high booking opportunities, and then make their way over to the pickup.

On the face of it, building a ride-hailing product seems easy. Build the app, link it up to maps services, onboard drivers, and let the magic of GPS and code do the rest.

This is the story about what it’s actually like to build a ride-hailing product in Indonesia, and the kind of problems Gojek solves every day to serve our customers.

Flashback time ⏪

A lot of Gojek’s volumes are achieved in dense, urban markets like Jakarta, where services like GoRide and GoCar (our 2-wheeler and 4-wheeler taxi services) are essential in getting people to places. However, this comes with some unique challenges.

Like the cartography problem.

In most countries, we take our maps for granted, and are perfectly comfortable following them blindly. But in places like Indonesia, even the best mapping solutions are not 100% reliable. Sure, they’re okay for general navigation, but for our products whose operations depends on maps, we require a whole different level of precision.

No ordinary roadmap this ?

While some of the geographies we operate in, such as Singapore, have reliable mapping, Indonesia presents a different challenge. In Singapore, we can rely on ETAs (Estimated Time of Arrival) provided by maps and show it to our customers directly. Indonesian maps on the other hand, can often show inaccurate ETAs, leaving our partners and customers in a bind.

Inaccurate ETAs == cancellations.

We also have situations where driver partners will park on the periphery of popular pickup points, but maps will estimate this as an error and place them back on the road. This means, even if you book from the same building the partner is standing outside of, maps will try and route them to that building, and present an ETA accordingly.

Incorrect location info == cancellations ?

Did you know? Jakarta has zones where four-wheeler traffic is regulated using the odd-even system (on ‘odd’ days, vehicles with even numbers are not allowed to pass through particular roads, and vice versa). Imagine you’re lounging merrily in a GoCar, stars in your eyes, and are suddenly informed your ride cannot proceed because you have to pass through an odd area and your partner’s vehicle has an even plate.

Improper order acceptance == cancellations ?

As you might suspect, we lost a fair few bookings to fraud and cartography/ETA related cancellations. These were problems that affected our Booking Conversion Rate (BCR). Besides, this also meant our own cartography team could not trust the pings coming from our driver partners to build better routing.

Needless to say, this did not reflect well on us as a business.

Desperate times, desperate measures

There was no Occam’s Razor solution here. We’d need to treat the symptoms first.

So, we go to work.

It just so happened, around the time the Allocations team was struggling with this problem, another team within Gojek was looking to solve authentication. This project, called GoID, was meant to be a central authorisation system for all of Gojek. It also happened to be the perfect solution to monitor account misuse.

GoID allowed us to ensure partner accounts were linked to a singular phone number, and multiple sessions by one partner could be monitored and terminated gracefully. GoID eventually grew into a much more ambitious project, by the way. Read about it here.

ETAs were the next problem. We isolated areas where regular ETAs were significantly inaccurate, and began offering ETAs based on a straight line model (calculating the shortest line connecting partners and customers). Our Cartography team also doubled down on data, analysing frequent routes taken by our partners to better understand the quickest routes between points, as well as new traffic restrictions that might apply.

Evening the odds

Thanks to these improved route estimates, we now had better data to assess if a ride would potentially pass through an odd-even sector, and route incoming requests accordingly to driver partners who could pass through such zones.
However, as always when dealing with the kind of scale that Gojek represents, we had to innovate to make this solution scale.

The problem with calculating if a jagged route passes through restricted areas is that it’s a relatively slow and tedious process even for the fastest of computers. The more restrictions it has to check, the slower the calculation gets.

Being slow is not an option when a customer is waiting to book a ride.

To simplify the solution, we combined all restricted areas into a single large ‘restricted zone’ to check against. Furthermore, we made a single polygon box around the irregularly-shaped restriction zone as a first check. With these two optimisations, our solution was ready to scale. When released, the solution brought down mid-ride cancellations drastically.

We saw a reduction of cancellations by ~60% for all rides in the target area.

For a mature product like Gojek, this is a very significant impact. To throw some context: Usually metrics such as booking cancellation rates are altered around 1–5% by new features, so such a large change represents a major pain point being solved, even if for a limited area.

Ever evolving, ever solving

Problems like these make our own teams appreciate the challenges of working on a SuperApp. A solution proven to work in one area may fall apart completely in another. This contrast is apparent even between Indonesia and Singapore, two countries not too far apart geographically, but poles apart culturally — in terms of what they expect from our service.

For example, when we recently launched chained allocations in the two regions, driver partners in Singapore could just move from one booking to the next seamlessly with minimal communication with the customers, but Indonesian customers like confirmation from partners that they are en-route. This makes Driver-Customer Chat a ‘nice to have’ feature in Singapore, but an absolute essential in Indonesia.

Different folks, different strokes, and one SuperApp for them all!

These are the challenges we solve daily to ensure just one of our products performs to the standards we want to deliver to our customers. When it comes to maintaining more than 20, the scope multiplies exponentially.