Taxi and delivery prices in the same city can differ by two to three times depending on the district, time of day, and traffic congestion. For logistics companies, aggregators, and retailers, this is critical data — it forms the basis for pricing models, demand forecasts, and decisions about launching services in new locations. However, collecting this data is not easy: taxi and delivery services tightly link prices to the user's geolocation and actively block automated data collection.
Why Businesses Need Price Monitoring by District
Taxi and delivery prices in apps are formed dynamically: the algorithm takes into account demand in a specific district, time of day, weather, and driver and courier availability. The same route in the city center and on the outskirts can cost differently even with the same service. This opens several practical tasks for businesses.
Logistics companies use competitor pricing data to adjust their own rates in real-time. If a competitor lowers the delivery price in a certain district, it makes sense to react before customers start switching to them en masse. Taxi and car-sharing aggregators analyze price dynamics by districts to identify areas of increased demand and redistribute drivers. Retailers and food delivery services (analogous to Yandex.Eda and SberMarket) monitor competitors' delivery costs to properly set their own free delivery zones and minimum order amounts.
A separate category of users includes urban mobility analysts and research companies that build maps of "price inequality" between districts. Such data helps developers assess the transport accessibility of new buildings, and city authorities identify areas with a shortage of transport services. Without systematic data collection by districts, none of these tasks can be solved — one-time manual price checks provide a distorted picture because prices change every few minutes.
Why Services Block Data Collection by Geolocation
Taxi and delivery services protect their pricing data for several reasons. First, dynamic pricing is a trade secret and a competitive advantage that can be easily copied if one knows the current rates across all districts. Second, mass requests from a single IP address create server load and distort the statistics of real demand, so anti-fraud systems aggressively ban such requests.
Technically, protection is built on several levels. Applications determine geolocation not only by GPS but also by IP address — if a request from a Moscow IP comes with coordinates from Novosibirsk, the system marks it as suspicious. There is also a limit on requests from a single IP over a unit of time: exceeding the threshold leads to temporary blocking or the issuance of deliberately incorrect prices. The third level involves device and browser fingerprinting, which distinguishes a real user from a script based on multiple parameters: screen resolution, font list, cursor behavior.
This is why a simple script with one IP address quickly gets banned or returns distorted data. For stable price collection across dozens of districts in one city, and especially across several cities, an infrastructure that simulates requests from real users in different locations is needed — and this requires proxies tied to the necessary geolocation.
What Data to Collect and from Which Platforms
Before setting up data collection, it is important to determine which specific indicators are needed for analytics. For taxis, this usually includes: base fare for a standard route, demand coefficient, car arrival time, and availability of economy/comfort/business class in a specific district. For delivery, it includes the cost of delivering an order of a specified amount, minimum amount for free delivery, courier wait time, and the presence of a coverage area at all.
The main data sources in Russia and the CIS are the apps and websites of large taxi aggregators, food and grocery delivery services, as well as marketplaces with their own logistics. If the task is comparative analysis, it is advisable to collect data simultaneously from several competing services in the same districts and time intervals; otherwise, the comparison will be incorrect: prices from different services fluctuate asynchronously.
It is important to pre-establish a list of control points — specific addresses or coordinates in each district that will be used to build the route. Without fixed points, the data cannot be compared: comparing the price of a trip from the center to a residential area with the price of a trip within the same area is meaningless for analyzing time dynamics.
Collection Methods: Manual, Automation, API
There are three main approaches to collecting price data. Manual monitoring involves an employee opening the app, changing the departure point, and recording the price. This is a workable option for a one-time study, but completely unsuitable for regular analytics: prices change every minute, and manually checking 20 districts across three services will take hours.
The second approach is automation through browser scripts or headless browsers that simulate user actions: opening the site, entering the address, and reading the price from the screen. This method scales better but requires bypassing bot protection and constant adaptation to changes in the website interface.
The third approach involves working through the internal APIs of mobile applications, which are often easier to use than the web interface but require more precise simulation of request headers and are often tied to authorization. Regardless of the chosen method, to obtain realistic prices for a specific district, requests must come from an IP address physically located in that city, ideally in the corresponding district or at least the region.
The Role of Proxies in Geo-Targeted Data Collection
Proxies in the task of monitoring prices by districts solve not the problem of anonymity but the problem of data reliability. Taxi and delivery services show different prices depending on where the request physically comes from. If prices for St. Petersburg are collected from an IP address in Moscow, the system will either return a geolocation error or show incorrect rates that do not correspond to the real market in the required city.
For this task, residential proxies are the best fit — they use real IP addresses from home providers and allow you to choose a specific city or region, which is critical when comparing dozens of districts. Unlike server addresses, residential IPs do not get blacklisted by taxi service anti-fraud systems because they appear as regular users from mobile or home networks.
For monitoring specifically mobile applications (not web versions), mobile proxies become a good option — they use IPs from cellular operators, which are traditionally considered more trusted by anti-bot systems since they often hide thousands of real subscribers (NAT), and blocking such an address affects many ordinary users, which services aim to avoid.
Data center proxies are also applicable — for example, for collecting data from public web pages without strict geolocation ties, where speed is more important than precise compliance with the city network. However, for taxi and delivery prices, where geolocation directly determines the request result, residential and mobile solutions provide significantly more stable and realistic data.
Which Type of Proxy to Choose: Comparison
To make a decision, it is useful to compare proxy types based on key parameters that are particularly important for monitoring prices by districts.
| Proxy Type | Geotargeting Accuracy | Risk of Blocking | Suitable For |
|---|---|---|---|
| Residential Proxies | High, down to city/district | Low | Taxi, delivery websites and apps, detailed analysis by districts |
| Mobile Proxies | High, tied to operator and region | Very low | Monitoring through mobile taxi and delivery apps |
| Data Center Proxies | Low, without precise geolocation | Above average | Collecting general data where geolocation is not critical |
In practice, many analytical teams combine approaches: using residential proxies for initial price collection on the website and mobile proxies for verifying data from the app, as prices there sometimes differ from the web version.
Step-by-Step Data Collection Setup
If the company does not have a dedicated developer, regular monitoring can be set up through a combination of an anti-detect browser and proxies, without writing code. The approach is as follows: open an anti-detect browser (Dolphin Anty, AdsPower, Multilogin, or Octo Browser), create a separate profile for each city or district that needs to be monitored.
In the profile settings, specify the proxy tied to the desired region: insert the IP address, port, username, and password, and choose the SOCKS5 or HTTP type depending on what the selected proxy provider supports. After this, the profile will appear to the site as if the user is physically located in the selected city — the browser will open the taxi or delivery site with "local" prices.
Next, you can either manually or through built-in automation scripts in the anti-detect browser (many services support simple macros without code) visit the site, enter the control points of the route, and record the price, or take a screenshot of the page for later processing. For several districts, it is convenient to maintain separate browser profiles tied to different IPs, switching between them on a schedule.
For more extensive monitoring — when you need to track dozens of districts in several cities several times a day — the manual mode becomes ineffective, and it is worth transitioning to automated collection through scripts, which will be discussed below.
Example Script for Automated Collection
For those with a developer or analyst on the team who is ready to work with code, automated price collection can be built in Python using the requests library and rotating proxies by region. Below is a simplified example of the logic for polling the delivery service's API with the insertion of district coordinates and proxying the request through the required region.
import requests
import time
# List of control points by city districts
districts = [
{"name": "Center", "lat": 55.7558, "lon": 37.6173},
{"name": "Residential Area A", "lat": 55.8300, "lon": 37.4500},
{"name": "Residential Area B", "lat": 55.6200, "lon": 37.7100},
]
# Proxies tied to the required region
proxies = {
"http": "http://login:password@proxy-host:port",
"https": "http://login:password@proxy-host:port",
}
def get_delivery_price(lat, lon):
url = "https://example-delivery-service.com/api/price"
params = {"lat": lat, "lon": lon}
headers = {"User-Agent": "Mozilla/5.0"}
response = requests.get(url, params=params, headers=headers, proxies=proxies, timeout=10)
return response.json().get("price")
results = []
for district in districts:
price = get_delivery_price(district["lat"], district["lon"])
results.append({"district": district["name"], "price": price, "timestamp": time.time()})
time.sleep(5) # pause between requests to avoid exceeding limits
print(results)
In a real task, proxies need to be rotated at the pool level — so that different districts are polled from different IPs, and requests to the same endpoint do not come too frequently from one address. This reduces the risk of getting banned and makes data sampling more stable over time.
Update Frequency and Data Storage
Taxi and delivery prices change throughout the day, so a one-time snapshot of data will tell an analyst little. The optimal polling frequency depends on the task: to analyze peak hours, it is sufficient to poll prices every 15–30 minutes during peak hours and once every one to two hours at other times. To build a map of "base" prices by districts, one or two measurements per day at the same time will suffice to exclude the influence of demand.
It is most convenient to store collected data in a structured format — a table with fields "date and time," "district," "service," "price," "demand coefficient." This format is easy to upload to Google Sheets for small volumes or to a database for building full-fledged dashboards in BI tools. It is important to preserve historical data rather than overwrite it — it is the dynamics over time that provides the greatest analytical value, not point measurements.
With large volumes of collection (multiple cities, dozens of districts, several services), it is advisable to think in advance about how to store and aggregate data by hours and days of the week — this will allow for building predictive models of demand and pricing, rather than just an archive of disparate figures.
Common Mistakes in Price Monitoring
The first and most common mistake is using the same IP address to poll all districts of the city. This not only increases the risk of blocking but can also lead to the service issuing averaged or cached prices instead of current values for a specific location.
The second mistake is making requests too frequently without pauses, which quickly leads to temporary bans of the account or IP. Anti-fraud systems of taxi services track not only the number of requests but also the behavior pattern: a real user does not check the price of a trip 50 times in a row within a minute from the same point.
The third mistake is ignoring the difference between prices in the app and on the website. Many taxi and delivery services show different rates in their mobile app compared to the web version due to different algorithms or promotions visible only in the app. If analytics is built solely on web data, the results may not reflect the real picture for most users who order through the app.
The fourth mistake is the incompatibility of control points between measurements. If today the coordinates of a district are taken from one address, and tomorrow from another in the same district, the price difference may be explained not by market changes but simply by a different starting or ending point of the route.
Conclusion
Systematic monitoring of taxi and delivery prices by city districts provides businesses with specific advantages: the ability to respond quickly to competitors' actions, more accurate demand forecasting, and informed decisions about coverage areas and rates. A key condition for obtaining reliable data is that requests must come from IP addresses physically tied to the required city and district; otherwise, services will issue incorrect or averaged prices.
If you plan to establish regular data collection on taxi or delivery prices in different districts, we recommend starting with residential proxies with precise geolocation tied to the required city — they provide the most realistic data and minimal risk of blocking. For tasks specifically related to mobile taxi and delivery applications, it is also worth considering mobile IPs, which are better perceived by anti-fraud systems as traffic from ordinary users.