Les prix des taxis et des livraisons dans une même ville peuvent varier de deux à trois fois selon le quartier, l'heure de la journée et l'encombrement des routes. Pour les entreprises logistiques, les agrégateurs et les détaillants, ces données sont cruciales — elles servent à établir des modèles de tarification, des prévisions de demande et des décisions concernant le lancement de services dans de nouveaux emplacements. Cependant, collecter ces données n'est pas si simple : les services de taxi et de livraison lient strictement les prix à la géolocalisation de l'utilisateur et bloquent activement la collecte automatique d'informations.
Pourquoi une entreprise a-t-elle besoin de surveiller les prix par quartiers
Les prix des taxis et des livraisons dans les applications sont formés de manière dynamique : l'algorithme prend en compte la demande dans un quartier spécifique, l'heure de la journée, la météo, et la disponibilité des chauffeurs et des livreurs. Un même trajet au centre-ville et en périphérie peut coûter différemment même chez un même service. Pour les entreprises, cela ouvre plusieurs défis pratiques.
Les entreprises logistiques utilisent les données sur les prix des concurrents pour ajuster leurs propres tarifs en temps réel. Si un concurrent réduit le prix de livraison dans un quartier donné, il est judicieux de réagir avant que les clients ne commencent à migrer massivement vers lui. Les agrégateurs de taxis et de covoiturage analysent la dynamique des prix par quartiers pour identifier les zones de forte demande et redistribuer les chauffeurs. Les détaillants et les services de livraison de nourriture (similaires à Yandex.Eda et SberMarket) surveillent le coût de livraison des concurrents pour ajuster correctement leurs propres zones de livraison gratuite et les montants minimums de commande.
Une catégorie distincte d'utilisateurs est constituée par les analystes de la mobilité urbaine et les sociétés de recherche qui établissent des cartes de « l'inégalité des prix » entre les quartiers. Ces données aident les développeurs à évaluer l'accessibilité des transports pour les nouvelles constructions, et les autorités municipales à identifier les zones manquant de services de transport. Sans une collecte systématique de données par quartiers, aucune de ces tâches ne peut être accomplie — des vérifications ponctuelles des prix manuellement donnent une image déformée, car les prix changent toutes les quelques minutes.
Pourquoi les services bloquent-ils la collecte de données par géolocalisation
Les services de taxi et de livraison protègent leurs données de prix pour plusieurs raisons. Tout d'abord, la tarification dynamique est un secret commercial et un avantage concurrentiel qui peut être facilement copié si l'on connaît les tarifs actuels dans tous les quartiers. Deuxièmement, les requêtes massives provenant d'une seule adresse IP créent une charge sur les serveurs et déforment les statistiques de la demande réelle, c'est pourquoi les systèmes anti-fraude bloquent agressivement de telles requêtes.
Techniquement, la protection est construite sur plusieurs niveaux. Les applications déterminent la géolocalisation non seulement par GPS, mais aussi par adresse IP — si une requête provenant d'une IP de Moscou arrive avec des coordonnées de Novossibirsk, le système la marque comme suspecte. Il existe également une limite de requêtes par IP dans un laps de temps donné : dépasser ce seuil entraîne un blocage temporaire ou la fourniture de prix manifestement incorrects. Le troisième niveau est le fingerprinting de l'appareil et du navigateur, qui distingue un utilisateur réel d'un script par de nombreux paramètres : résolution d'écran, liste de polices, comportement du curseur.
C'est pourquoi un simple script avec une seule adresse IP reçoit rapidement un blocage ou des données déformées. Pour une collecte stable des prix dans des dizaines de quartiers d'une même ville, et encore plus dans plusieurs villes, une infrastructure est nécessaire pour imiter les requêtes des utilisateurs réels depuis différents points — et ici, il est indispensable d'avoir des proxies liés à la géolocalisation requise.
Quelles données collecter et sur quelles plateformes
Avant de configurer la collecte de données, il est important de déterminer quels indicateurs sont nécessaires pour l'analyse. Pour les taxis, il s'agit généralement de : le coût de base d'un trajet sur un itinéraire standard, le coefficient de demande accrue, le temps d'attente d'une voiture et la disponibilité des classes économique/confort/business dans un quartier spécifique. Pour la livraison — le coût de livraison d'une commande d'un montant donné, le montant minimum pour la livraison gratuite, le temps d'attente du livreur et la présence d'une zone de couverture.
Les principales sources de données en Russie et dans les pays de la CEI sont les applications et les sites des grands agrégateurs de taxis, des services de livraison de nourriture et de produits, ainsi que des marketplaces avec leur propre logistique. Si l'objectif est une analyse comparative, il est préférable de collecter des données simultanément sur plusieurs services concurrents dans les mêmes quartiers et périodes de temps, sinon la comparaison sera incorrecte : les prix des différents services fluctuent de manière asynchrone.
Il est important de fixer à l'avance une liste de points de contrôle — adresses ou coordonnées spécifiques dans chaque quartier, sur lesquelles le trajet sera construit. Sans points fixes, les données ne sont pas comparables entre elles : comparer le prix d'un trajet du centre à un quartier résidentiel avec le prix d'un trajet à l'intérieur d'un même quartier n'a pas de sens pour analyser la dynamique dans le temps.
Méthodes de collecte : manuelle, automatisation, API
Il existe trois approches principales pour la collecte de données sur les prix. La surveillance manuelle — un employé ouvre l'application, change le point de départ et note le prix. C'est une option fonctionnelle pour une recherche ponctuelle, mais complètement inadaptée pour une analyse régulière : les prix changent chaque minute, et une vérification manuelle de 20 quartiers sur trois services prendra des heures.
La deuxième approche — l'automatisation via des scripts de navigateur ou des navigateurs sans tête, qui imitent les actions de l'utilisateur : ouvrent le site, saisissent l'adresse, lisent le prix à l'écran. Cette méthode se prête mieux à l'échelle, mais nécessite de contourner la protection contre les bots et une adaptation constante aux changements de l'interface du site.
La troisième — travailler via les API internes des applications mobiles, qui sont souvent plus simples à utiliser que l'interface web, mais nécessitent une imitation plus précise des en-têtes de requête et sont souvent liées à l'authentification. Quelle que soit la méthode choisie, pour obtenir des prix réalistes pour un quartier spécifique, les requêtes doivent provenir d'une adresse IP physiquement située dans cette ville, et idéalement — dans le quartier correspondant ou au moins dans la même région.
Rôle des proxies dans la collecte de données géolocalisée
Les proxies dans la tâche de surveillance des prix par quartiers ne résolvent pas le problème de l'anonymat, mais celui de la fiabilité des données. Les services de taxi et de livraison affichent des prix différents selon l'origine physique de la requête. Si l'on collecte des prix pour Saint-Pétersbourg avec une adresse IP de Moscou, le système donnera soit une erreur de géolocalisation, soit affichera des tarifs incorrects qui ne correspondent pas au marché réel dans la ville concernée.
Pour cette tâche, les proxies résidentiels sont les mieux adaptés — ils utilisent de véritables adresses IP de fournisseurs d'accès domestiques et permettent de choisir une ville ou une région spécifique, ce qui est crucial lors de la comparaison de dizaines de quartiers. Contrairement aux adresses de serveurs, les IP résidentielles ne sont pas mises sur liste noire par les systèmes anti-fraude des services de taxi, car elles ressemblent à des utilisateurs ordinaires provenant de réseaux mobiles ou domestiques.
Pour la surveillance des applications mobiles (et non des versions web), les proxies mobiles sont une bonne option — elles utilisent des IP d'opérateurs de téléphonie mobile, qui sont traditionnellement considérées comme plus fiables par les systèmes anti-bots, car elles cachent souvent des milliers de véritables abonnés (NAT), et le blocage d'une telle adresse affecte de nombreux utilisateurs ordinaires, ce que les services cherchent à éviter.
Les proxies de centres de données sont également applicables — par exemple, pour collecter des données à partir de pages web publiques sans lien strict avec la géolocalisation, où la vitesse est plus importante que la correspondance exacte avec le réseau urbain. Mais pour les prix des taxis et des livraisons, où la géolocalisation détermine directement le résultat de la requête, les solutions résidentielles et mobiles fournissent des données nettement plus stables et réalistes.
Quel type de proxy choisir : comparaison
Pour se décider, il est utile de comparer les types de proxies selon des paramètres clés, importants spécifiquement pour la surveillance des prix par quartiers.
| Type de proxy | Précision de la géolocalisation | Risque de blocage | Convient pour |
|---|---|---|---|
| Proxies résidentiels | Élevée, jusqu'à la ville/quartier | Faible | Sites et applications de taxi, livraison, analyse détaillée par quartiers |
| Proxies mobiles | Élevée, liée à l'opérateur et à la région | Très faible | Surveillance via des applications mobiles de taxi et de livraison |
| Proxies de centres de données | Faible, sans géolocalisation précise | Supérieure à la moyenne | Collecte de données générales, où la géolocalisation n'est pas critique |
En pratique, de nombreuses équipes d'analyse combinent les approches : elles utilisent des proxies résidentiels pour la collecte initiale des prix sur le site et des proxies mobiles pour vérifier les données provenant de l'application, car les prix y diffèrent parfois de la version web.
Configuration étape par étape de la collecte de données
Si l'entreprise n'a pas de développeur à plein temps, il est possible de configurer une surveillance régulière via une combinaison de navigateur anti-détection et de proxy, sans écrire de code. L'approche est la suivante : ouvrez un navigateur anti-détection (Dolphin Anty, AdsPower, Multilogin ou Octo Browser), créez un profil distinct pour chaque ville ou quartier à surveiller.
Dans les paramètres du profil, indiquez le proxy lié à la région requise : insérez l'adresse IP, le port, le nom d'utilisateur et le mot de passe, choisissez le type SOCKS5 ou HTTP selon ce que prend en charge le fournisseur de proxy choisi. Après cela, le profil apparaîtra pour le site comme si l'utilisateur se trouvait physiquement dans la ville choisie — le navigateur ouvrira le site de taxi ou de livraison avec des prix « locaux ».
Ensuite, il ne reste plus qu'à accéder manuellement ou via les scénarios d'automatisation intégrés dans le navigateur anti-détection (de nombreux services prennent en charge de simples macros sans code) au site, à entrer les points de contrôle de l'itinéraire et à noter le prix, ou à faire une capture d'écran de la page pour un traitement ultérieur. Pour plusieurs quartiers, il est pratique de maintenir des profils de navigateur distincts liés à différentes IP, en basculant entre eux selon un calendrier.
Pour une surveillance plus vaste — lorsque vous devez suivre des dizaines de quartiers dans plusieurs villes plusieurs fois par jour — le mode manuel cesse d'être efficace, et il vaut mieux passer à la collecte automatisée via des scripts, dont nous parlerons ci-dessous.
Exemple de script pour la collecte automatique
Pour ceux qui ont un développeur ou un analyste dans l'équipe prêt à travailler avec le code, la collecte automatique des prix peut être construite en Python en utilisant la bibliothèque requests et la rotation des proxies par région. Ci-dessous un exemple simplifié de la logique d'interrogation de l'API d'un service de livraison avec substitution des coordonnées du quartier et proxy de la requête via la région requise.
import requests
import time
# Liste des points de contrôle par quartiers de la ville
districts = [
{"name": "Centre", "lat": 55.7558, "lon": 37.6173},
{"name": "Quartier résidentiel A", "lat": 55.8300, "lon": 37.4500},
{"name": "Quartier résidentiel B", "lat": 55.6200, "lon": 37.7100},
]
# Proxies liés à la région requise
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 entre les requêtes pour ne pas dépasser les limites
print(results)
Dans une tâche réelle, il est nécessaire de faire tourner les proxies au niveau du pool — afin que différents quartiers soient interrogés depuis différentes IP, et que les requêtes vers le même point de terminaison ne soient pas trop fréquentes depuis la même adresse. Cela réduit le risque de blocage et rend l'échantillonnage des données plus stable dans le temps.
Fréquence de mise à jour et stockage des données
Les prix des taxis et des livraisons changent au cours de la journée, donc un instantané unique des données ne dira pas grand-chose à l'analyste. La fréquence optimale d'interrogation dépend de la tâche : pour analyser les heures de pointe, il suffit d'interroger les prix toutes les 15 à 30 minutes pendant les heures de pointe et une fois toutes les une à deux heures à d'autres moments. Pour établir une carte des prix « de base » par quartiers, un à deux relevés par jour à la même heure suffisent pour exclure l'influence de la demande.
Il est plus pratique de stocker les données collectées sous une forme structurée — un tableau avec les champs « date et heure », « quartier », « service », « prix », « coefficient de demande ». Ce format est facile à charger dans Google Sheets pour de petits volumes ou dans une base de données pour créer de véritables tableaux de bord dans des outils BI. Il est important de conserver les données historiques et de ne pas les écraser — c'est la dynamique dans le temps qui donne la plus grande valeur analytique, et non les mesures ponctuelles.
Pour de grands volumes de collecte (plusieurs villes, dizaines de quartiers, plusieurs services), il est judicieux de réfléchir à l'avance à la manière de stocker et d'agréger les données par heures et jours de la semaine — cela permettra par la suite de construire des modèles prévisionnels de demande et de tarification, et non simplement d'archiver des chiffres disparates.
Erreurs typiques lors de la surveillance des prix
La première et la plus fréquente des erreurs est l'utilisation de la même adresse IP pour interroger tous les quartiers de la ville. Cela augmente non seulement le risque de blocage, mais peut également entraîner le fait que le service fournira des prix moyennés ou mis en cache au lieu des valeurs actuelles pour un emplacement spécifique.
La deuxième erreur est des requêtes trop fréquentes sans pauses, qui entraînent rapidement des blocages temporaires du compte ou de l'IP. Les systèmes anti-fraude des services de taxi surveillent non seulement le nombre de requêtes, mais aussi le modèle de comportement : un utilisateur réel ne vérifie pas le prix d'un trajet 50 fois de suite en une minute depuis le même point.
La troisième erreur est d'ignorer la différence entre le prix dans l'application et sur le site. De nombreux services de taxi et de livraison affichent des tarifs différents dans l'application mobile par rapport à la version web, en raison de différents algorithmes ou promotions visibles uniquement dans l'application. Si l'analyse est uniquement basée sur les données web, les résultats peuvent ne pas refléter la réalité pour la plupart des utilisateurs qui commandent via l'application.
La quatrième erreur est l'incomparabilité des points de contrôle entre les relevés. Si aujourd'hui les coordonnées d'un quartier sont prises d'une adresse, et demain d'une autre dans le même quartier, la différence de prix peut s'expliquer non par un changement du marché, mais simplement par un point de départ ou d'arrivée différent.
Conclusion
La surveillance systématique des prix des taxis et des livraisons par quartiers de la ville offre à l'entreprise des avantages concrets : la possibilité de réagir rapidement aux actions des concurrents, de prévoir plus précisément la demande et de prendre des décisions éclairées sur les zones de couverture et les tarifs. La condition clé pour obtenir des données fiables est que les requêtes doivent provenir d'adresses IP physiquement liées à la ville et au quartier requis, sinon les services fourniront des prix incorrects ou moyennés.
Si vous envisagez de mettre en place une collecte régulière de données sur les prix des taxis ou des livraisons dans différents quartiers, nous vous recommandons de commencer par des proxies résidentiels avec une géolocalisation précise à la ville requise — ils fournissent des données les plus réalistes et un risque minimal de blocages. Pour les tâches liées spécifiquement aux applications mobiles de taxi et de livraison, il convient également d'envisager des IP mobiles, qui sont mieux perçues par les systèmes anti-fraude comme un trafic d'utilisateurs ordinaires.