If you are responsible for ASO and check app rankings from an office in Moscow or Kyiv, the results in the App Store and Google Play for users in the USA, Germany, or Brazil will be different — and often completely different from what you see. We analyze why this happens, what proxies are needed for accurate monitoring, and how to collect data across dozens of countries without risking account blocking or CAPTCHA on every request.
Why Rankings in the App Store and Google Play are Incorrect Without a Local IP
The algorithms for the App Store and Google Play consider not only keywords and app ratings but also the geolocation of the request. Search results are generated separately for each store-region: Apple has 175 separate store fronts, while Google has localized catalogs for each country. If you open the App Store with an IP from Russia and try to check the app's position in the US results, the system will either show you the Russian storefront or return distorted data due to VPN detection.
In practice, this looks like: an ASO specialist sees that the app ranks in the top 3 for a keyword, but in the target country — the USA or Germany — it is actually in 15th place. The difference in ranking is explained by local competition, the device's interface language, installation history in the region, and even the time of day in the country's time zone. Therefore, for accurate tracking of positions, an IP address physically tied to the required country is needed, ideally to a specific city or operator.
This is especially critical for companies that are entering multiple markets simultaneously: for example, launching an app in Tier-1 countries (USA, UK, Canada) while simultaneously testing promotion in Southeast Asia. Without local proxies, you simply won't know the real picture and will make ASO strategy decisions based on distorted data.
Why Apple and Google Block Mass Checks
Manually checking positions across 30-50 countries by changing the region in phone settings takes hours and is not physically scalable. Therefore, ASO teams use automated scripts or services that make dozens and hundreds of requests to the stores. This is where problems begin: Apple and Google detect patterns of frequent requests from one IP, various User-Agents from one address, and atypical behavior (instantaneous "location" changes without actual device movement).
The reaction can vary: from temporary CAPTCHA and rate limiting to complete blocking of the IP address at the CDN level of the stores. If you use the same data center IP to check positions across 20 countries in a row, there is a high likelihood that after just a few dozen requests, the service will start returning empty results or redirecting to a page with a "suspicious activity" check. Unlike social networks, where specific accounts are banned, here IPs or ranges of IP subnets are more often banned — therefore, the problem affects everyone who uses a shared pool of data center addresses.
The second point is geolocation accuracy. Even if the proxy is not blocked, data center IPs are often identified as "server" and results from them may differ from results for real mobile internet users or home Wi-Fi. For ASO tasks, where maximum data reliability is important, this is critical.
What Proxies are Needed for Monitoring ASO Rankings by Country
The choice of proxy type depends on the scale of monitoring and the required data accuracy. For one-time manual analysis, one approach is suitable, while for regular automated tracking across dozens of countries — another. The comparison below will help you decide.
| Proxy Type | Geolocation Accuracy | Risk of Blocking | When to Use |
|---|---|---|---|
| Data Center Proxies | Low-Medium | High | Quick test checks without scale |
| Residential Proxies | High | Low | Regular monitoring across 20-50 countries |
| Mobile Proxies | Maximum | Minimal | Check results as a real app user sees them |
For most ASO teams, the optimal balance of price and quality is provided by residential proxies tied to a city: they appear as regular users with home internet and allow collecting rankings across dozens of geos without the risk of mass blocking. Mobile proxies make sense to connect selectively — for example, when you need to check how the App Store results differ for mobile traffic from an operator in a specific country, which is especially important for geos with a high share of mobile internet (India, Indonesia, Brazil).
Manual Checking via Anti-Detect Browser: Step-by-Step Setup
If you need to quickly check the app's position in 5-10 countries without connecting complex services, it is convenient to use an anti-detect browser like Dolphin Anty, AdsPower, GoLogin, or Octo Browser. Each profile in the browser creates a separate "digital fingerprint" with the required geolocation, system language, and time zone — this provides a more reliable picture of the results than simply changing the VPN.
The setup looks as follows:
- Create a new profile in the anti-detect browser for each target monitoring country.
- In the proxy settings, choose the type of connection — HTTP or SOCKS5, specify the IP, port, username, and password.
- In the profile settings, set the time zone and system language corresponding to the proxy country (for example, for the USA — English language, time zone America/New_York).
- Open the App Store via the web version (apps.apple.com) or install the localized Google Play on an emulated Android profile.
- Enter the target keyword and record the app's position in the results by taking a screenshot for the report.
- Repeat for each country using a separate profile with the corresponding proxy.
This approach is well-suited for one-time audits before launching an advertising campaign or before localizing the app for a new market, but for regular tracking of 50+ countries daily — it is unreasonably time-consuming.
Automation via ASO Services: AppFollow, Sensor Tower, Mobile Action
For systematic position monitoring, most ASO specialists use ready-made services: AppFollow, Sensor Tower, Mobile Action, ASOdesk, App Radar. They perform the results check from servers physically located in the required regions and provide data in the form of a dashboard with a history of position changes by day.
An important nuance: even these services sometimes have delays in updating data for less popular countries or limit the number of keywords on the plan. If you need more flexible and frequent checks — for example, hourly position tracking during an advertising A/B test — you have to collect data yourself through scripts with proxies. In this case, residential proxies with geotargeting at the country or city level become practically an essential element of the infrastructure, as they allow simulating real users without being tied to the limits of a third-party service.
A combined approach — where basic monitoring is done through a ready-made service, and specific checks of particular geos and keywords are done through your own script with proxies — provides maximum flexibility at reasonable costs.
Technical Example: Script for Collecting Rankings with Proxy Rotation
For teams with a developer or data analyst, it is easier to create a custom position checking script through the public search of the App Store and Google Play. Below is a simplified example in Python using the requests library and proxy rotation by country.
import requests
# Dictionary: country -> proxy tied to the region
proxies_by_country = {
"us": {"http": "http://user:[email protected]:9000",
"https": "http://user:[email protected]:9000"},
"de": {"http": "http://user:[email protected]:9000",
"https": "http://user:[email protected]:9000"},
"br": {"http": "http://user:[email protected]:9000",
"https": "http://user:[email protected]:9000"},
}
def check_app_store_position(keyword, country_code, app_id):
url = f"https://itunes.apple.com/search"
params = {
"term": keyword,
"country": country_code,
"entity": "software",
"limit": 50
}
proxies = proxies_by_country.get(country_code)
response = requests.get(url, params=params, proxies=proxies, timeout=15)
results = response.json().get("results", [])
for position, app in enumerate(results, start=1):
if str(app.get("trackId")) == str(app_id):
return position
return None # app not found in top-50
# Example of running checks for three countries
for country, proxy in proxies_by_country.items():
pos = check_app_store_position("fitness tracker", country, app_id="123456789")
print(f"Country: {country.upper()}, position: {pos}")
For Google Play, there is no official public search API, so checking is usually done through parsing the HTML page of results from play.google.com/store/search with correct Accept-Language headers and geotargeted proxies, or through third-party unofficial libraries. In both cases, it is critical to add delays between requests (2-5 seconds) and change the User-Agent along with the IP change, so the request pattern does not look like an automated scanner.
For the production version of such a script, it makes sense to connect proxy rotation with automatic IP changes within one country — this reduces the likelihood of a ban when checking a large number of keywords and allows checking multiple queries in parallel without waiting for limits to cool down.
Common Mistakes and Signs of a Ban
In practice, ASO teams face the same problems when setting up position monitoring. Here are the main mistakes:
- One IP for all countries. Using a single proxy to check 30 countries at once leads to contradictory results — stores see sharp "movements" and start displaying protective pages.
- Too frequent requests without delays. Sending 50+ requests per minute from one IP — is a direct path to temporary blocking at the CDN level.
- Mismatch of language and time zone with the proxy geo. If the IP is American but the system language is Russian, the results may be mixed and unreliable.
- Using shared data center proxies without rotation. Such IPs are often already "exposed" by other users and get blocked before you even start using them.
- Ignoring CAPTCHA signs. If instead of data, an HTML page with a check "Please confirm you are not a robot" starts coming in — this is a signal to reduce the frequency of requests or change the IP, rather than repeating the request immediately.
Signs that the proxy or data collection method has already been "burned": a sharp drop in the number of successful responses, identical empty results for different keywords, redirects to age or region confirmation pages instead of normal search results.
Checklist for Launching Monitoring by Country
Before launching regular position tracking, go through this list:
- A list of priority countries and keywords for monitoring has been compiled.
- For each country, a proxy with accurate geolocation (residential or mobile) has been selected.
- Delays between requests (from 2 to 5 seconds) and User-Agent rotation have been configured.
- The interface language and time zone of the profile/request correspond to the proxy country.
- Error and CAPTCHA logging has been set up for prompt response.
- The frequency of checks has been determined: daily for the top-10 markets, every few days for the others.
- Results are saved in a single table or dashboard to track position dynamics.
Conclusion
Accurate monitoring of positions in the App Store and Google Play by country is impossible without local IP addresses — this is a basic requirement that determines the reliability of all other ASO solutions. A single shared proxy or VPN for all countries gives a distorted picture and quickly leads to blocks when scaling checks. Manual checking via an anti-detect browser is suitable for one-time audits, automated services — for basic regular tracking, and a custom script with proxy rotation — for flexible control over the frequency and depth of checking specific markets.
If you plan to establish regular position monitoring across dozens of countries without the risk of blocks, we recommend starting with residential proxies tied to specific cities — they provide the most accurate geolocation and minimal risk of bans during frequent checks. For scenarios where it is important to see the results exactly as a mobile app user sees them, consider mobile proxies from a specific operator in the target country.