How Swiggy catches a map pin that does not match the address

Ordering on Swiggy asks one question twice. The app takes a location from the phone's GPS and asks the customer to place a pin; then the customer "enters the address in textual format". Riders follow the pin "unless the text address contains a well-known landmark". The trouble: "Since GPS signals are susceptible to noise, the captured GPS location may not represent the customer’s actual location." When pin and address disagree, the rider calls around, or "the customer ends up canceling the order". In January 2022, Yaswanth Reddy, with Abhinav Ganesan and Jose Mathew, described on Swiggy's tech blog a model that reads both answers and flags the pin when they do not agree.

The problem: two answers to "where are you?"

Swiggy treats the typed address as the truth: "We assume that customers enter valid and correct text addresses". The question is whether the pin agrees with it. So the team framed it as a "binary classification problem" and used "a deep learning model to flag addresses with incorrectly captured locations."

The hard part is not the model. It is the examples. To learn what a wrong pin looks like, you need many orders where you know the pin was wrong, and nobody labels those.

How they built it

Good examples come from deliveries that worked. The rider's app records where an order was marked delivered, plus a GPS trail. If those pings sit close to the pin, pin and address agree: label 0. Swiggy checked a sample by hand and found "the accuracy of label-0 is approximately 90%".

Wrong examples had to be made. The obvious opposite, pins far from where riders delivered, was "only 31.8% accurate" as a label. One reason shows in the map above: "The DP marks the order as delivered far away from the customer’s location", DP being the delivery partner. So Swiggy chose to "synthesize the label-1 dataset from the label-0 dataset by perturbing the captured location": take a good pin, move it a random distance beyond a minimum (125 metres in one of the post's examples), keep the same address text, and call that wrong.

A pin becomes a word. The model reads text, so the location becomes text too. Swiggy converts the pin to an L8 geohash, a short code for a cell "at most 38.2 m" wide, and feeds "the L8 Geohash of the captured location and the address text separated by a separator token" to RoBERTa, a language model. The team pretrained it from scratch rather than starting from a model trained on Wikipedia and books, because that text "is quite different from the semantics of Indian addresses", and slimmed it from about 126 million parameters to about 83 million.

From flag to fix. In 2022 the flag fed a manual process: "inferencing the (location, address text) tuples through the address flagger model followed by manual correction of the locations flagged as incorrect by the model".

What it delivered

Swiggy reports validation precision and recall by zone, from an 85:15 split: North 87.4% and 89.5%, South 89.6% and 91.3%, Central 89.2% and 91.1%, East 82.5% and 84.7%. Its one real-world figure is "a healthy precision of 84 % in a large Tier-1 Indian city", from "manual validation on a dataset of addresses with cancelled orders". Recall on real data, the post admits, "is hard to estimate".

Read those numbers with care. Validation sits 7 to 15 points below training. The wrong pins in both sets are synthetic, so the scores measure the mistakes Swiggy made up, not the ones customers make. The real-world figure covers one unnamed city and only cancelled orders, and the post reports no effect on cancellations or delivery time.

What has changed since

Swiggy moved from flagging to fixing. A two-part 2024 sequel (part 1, part 2) adds signals from riders' calls and chats with care agents and customers. Swiggy reports the new classifier "improved precision and recall by 23 pp and 32 pp respectively over the baseline model", its earlier work, and notes that the flag "is also useful standalone in nudging the customer to correct the address". Part 2 adds a geocoder that predicts where the customer really is, with "four models deployed one each for South, Central, North, and East India", routing riders to the predicted spot when a pin is flagged. Delivery deviation, the distance between that spot and where the order was delivered, "decreased by an average distance of 143" metres on corrected addresses.

Maps learned to speak in landmarks. Google launched Address Descriptors, landmarks and area names returned with a geocoded point, in "25 Indian metro areas" in 2023 (launch) and expanded them in India in April 2025 (update).

Other Indian platforms published geocoders. Meesho's GeoIndia (EMNLP 2024) reports "outperforming the well-renowned geocoding platform Google Maps", and a Flipkart and IIT Bombay paper (COLING 2025) says its approach "outperforms the current state-of-the-art system by 20% in drift accuracy within 100 meters". Both are the authors' own benchmarks.

India got a digital address code, with the same weak spot. DIGIPIN, launched in 2025, turns a point into a short code. India Post notes that "the accuracy of the DIGIPIN generated for any location largely depends on the precision of the GNSS-enabled device used to capture the coordinates". It encodes the pin; it does not check the pin against the address.

Why it matters for your business

Indonesian addresses make this problem harder. Tokopedia's case study with Google (now only in the Web Archive) describes "villages with no street numbers or names" and says "It's common for homes and businesses in remote areas to use kampung (village) names or local landmarks instead of physical addresses." Its fix was product work, not a model: address autocomplete and "a visual mobile PIN on a Dynamic Map", after which, Tokopedia says, "Successfully completed addresses have gone up by 10%". Shopee's help page asks buyers to "atur titik koordinat (pastikan sudah sesuai dengan alamat Anda)", set the pin and make sure it matches the address, which leaves the check to the buyer. We found no Indonesian platform that publicly describes an automatic pin-versus-address check.

The problem reaches well beyond food delivery: couriers, home services, technicians, property viewings, home test drives, clinics making home visits. Any business that sends a person to an address pays for a wrong pin in wasted trips and lost customers.

One duty of care: a customer's address and location trail are personal data under Indonesia's personal data protection law (UU No. 27 of 2022). If you keep rider pings and traces to train a model, say why you keep them, keep them only as long as you need, and keep them secure.

How we would build it today

1. Measure the gap. For delivered orders, compute the distance between the pin and where the rider marked delivered, and pull the orders that were cancelled or needed a call. That sizes the problem and gives you trustworthy good examples.
2. Fix capture first. When the typed address and the pin look far apart, ask the customer to confirm the pin on a map before checkout. Tokopedia's 10% came from product work like this.
3. Start with a geocoder rule. Geocode the typed address with a maps API and flag pins more than a set distance away. It is cheap and easy to explain.
4. Train a model when volume justifies it. Use Swiggy's recipe: good pairs from successful deliveries, wrong pairs made by moving good pins, and a small text model that reads a geohash token next to the address. Pretrain on your own addresses; text full of RT, RW, gang and kampung names is not what general models learned from.
5. Add rider signals. Calls to the customer and time spent searching near the drop point are strong evidence that a pin was wrong, as Swiggy's 2024 work shows.
6. Close the loop. Every pin corrected by a customer or by operations becomes a new labelled example.

The lasting lesson from Swiggy: when the labels you need are rare and noisy, you can make them from the labels you trust. Just test on real mistakes before you believe the score.