Le voyage est le vertical de prix le plus difficile à collecter avec précision, et de loin. Un prix sur une page produit de retail est plus ou moins un fait : il est le même pour tout le monde dans un marché donné, et il change lentement. Un tarif de vol n’est rien de tout cela. Le même siège sur le même vol peut être proposé à des prix différents selon d’où vous achetez, dans quelle devise vous êtes, si vous avez déjà cherché, et ce que le système de revenue de la compagnie a décidé dans les dernières minutes. Les tarifs d’hôtel se comportent de façon similaire.
Pour une équipe d’agrégation de tarifs ou d’intelligence de voyage, c’est tout le problème en une phrase : le tarif qu’un acheteur voit dépend de qui et où le fournisseur pense qu’il est. Collectez ces données depuis l’IP d’un seul bureau et vous n’obtenez pas seulement une image partielle, vous obtenez les mauvais tarifs, proposés pour un marché où vous n’êtes pas. Ceci est un traitement plus approfondi du terrain couvert dans pourquoi l’agrégation de tarifs de voyage a besoin de proxys, centré sur la mécanique qui fait des proxys résidentiels la bonne couche d’accès pour les données de vols et d’hôtels.
Ce que vous collectez
La collecte de données de voyage couvre quelques surfaces liées :
- Tarifs de vol — prix par route, date, cabine, et classe tarifaire, plus disponibilité, règles tarifaires, et ancillaires (bagages, sièges), à travers les compagnies et les OTA et métamoteurs qui les revendent.
- Tarifs d’hôtel — prix par nuit par établissement, date, type de chambre, et occupation, plus disponibilité et conditions d’annulation.
- Location de voitures et forfaits — la même forme, tarifée par lieu et date.
Le fil commun est que chacune de ces surfaces est proposée à un acheteur précis dans un marché précis à un moment précis, ce qui est exactement pourquoi c’est un problème d’accès.
Pourquoi le voyage est de façon unique un problème de proxy
Le scraping de retail a une dimension géo. Le voyage a quatre propriétés qui se composent, et les quatre atterrissent sur la couche proxy.
1. Les tarifs sont fixés par point de vente. C’est le trait déterminant. Les compagnies et les OTA tarifent le même itinéraire différemment selon le point de vente, le marché depuis lequel l’acheteur réserve. Un aller-retour New York-Londres peut porter un tarif différent, dans une devise différente, réservé depuis un point de vente américain face à un britannique ou indien. Ce n’est pas un cas limite ; c’est le cœur du métier, et c’est pourquoi la comparaison de tarifs entre marchés existe tout court. Pour capturer le tarif qu’un acheteur dans un marché donné voit réellement, vous devez sembler être dans ce marché, ce qui signifie une IP résidentielle là-bas (ciblage par pays et ville).
2. Les tarifs sont basés sur la session. Une recherche de tarif n’est pas une requête, c’est un flux : recherche, résultats, sélection d’itinéraire, confirmation du prix. Les fournisseurs proposent et retiennent les prix au sein de cette session, et un changement d’identité en milieu de flux ne ressemble en rien à un vrai acheteur. C’est pourquoi les sessions sticky ne sont pas optionnelles pour le voyage comme elles sont simplement pratiques ailleurs (sticky vs rotatif) : tout le flux de tarif doit venir d’une identité cohérente.
3. Les tarifs sont périssables. Les systèmes de revenue-management retarifent constamment et la disponibilité est en temps réel, donc un tarif que vous avez collecté il y a une heure peut déjà être faux. La fraîcheur est une exigence de première classe, ce qui signifie une collecte continue et à fort volume plutôt qu’un balayage périodique.
4. Le voyage est agressivement défendu. Les compagnies surveillent leur ratio « look-to-book », le nombre de recherches par réservation réelle, et traitent le trafic de recherche à fort volume qui ne convertit pas comme un coût et une menace. Les systèmes GDS, les OTA, et les métamoteurs font tous tourner un anti-bot sérieux. Une IP de datacenter est signalée vite et reçoit un CAPTCHA, un blocage, ou, pire de tout, un tarif différent, donc vous enregistrez un prix qu’aucun voyageur réel ne se verrait proposer (pourquoi les scrapers se font bloquer).
Mis ensemble : pour collecter des données de voyage avec précision, vous devez ressembler à un vrai acheteur, dans le bon marché, tenant une session cohérente, à l’échelle, en continu. C’est un problème en forme de proxy résidentiel.
Où s’inscrivent les proxys résidentiels
Un proxy résidentiel fait passer vos requêtes par de vraies IP grand public, donc les fournisseurs de voyage vous proposent des prix comme ils le feraient à un vrai acheteur local. Concrètement :
Le vrai tarif par point de vente. Avec le geo-targeting sur le pays dont vous avez besoin, vous collectez le tarif en tant qu’acheteur qui réserve vraiment depuis ce point de vente, tarifs américains depuis les États-Unis, tarifs allemands depuis l’Allemagne, chacun étiqueté par marché. Votre comparaison entre marchés repose enfin sur de vrais prix par point de vente au lieu d’un seul emplacement extrapolé.
De vrais tarifs, pas la version bot. Les IP résidentielles portent la confiance d’un vrai utilisateur, donc vous capturez le prix proposé et la disponibilité réels, pas la réponse dégradée, bloquée, ou à CAPTCHA servie au trafic suspect. Pour le voyage, où le « tarif bot » peut être un chiffre véritablement différent, c’est la différence entre des données utilisables et du bruit.
Une collecte cohérente par session. Tenez une session sticky sur la durée d’un flux de tarif pour que recherche, sélection, et prix viennent tous d’une identité, ce qui est à la fois ce que le fournisseur attend et ce qui garde l’offre cohérente. Tournez vers une identité fraîche entre les recherches, pas au sein d’une.
Une couverture complète et fraîche. Un grand pool rotatif vous laisse faire tourner de nombreuses routes, dates, et marchés en continu sans qu’une poignée d’IP déclenche des rate limits, ce qui garde les données de tarifs périssables à jour plutôt que rances (les mêmes principes de qualité de collecte que dans proxys résidentiels pour la collecte de données).
Comment ça marche
Sur le gateway Shifter, vous ciblez un point de vente en encodant le pays dans le nom d’utilisateur du proxy, un point de terminaison, pas de listes d’IP :
# Collecter un tarif en tant qu'acheteur réservant depuis les États-Uniscurl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://fare-source.example
# La même route, tarifée depuis un point de vente britanniquecurl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 https://fare-source.exampleDeux pratiques propres au voyage comptent plus que la mécanique. D’abord, alignez le locale et la devise avec le point de vente, une requête de point de vente britannique qui envoie un locale américain ou demande des USD est une incohérence qui produit des résultats faux ou bloqués ; accordez Accept-Language et la sélection de devise du site au marché. Ensuite, tenez une session sticky à travers le flux de tarif en ajoutant -sid-<id>-ttl-<secondes> au nom d’utilisateur, pour que la recherche à plusieurs étapes reste sur une IP. Des blocages constants (plutôt qu’occasionnels) pointent vers la qualité d’IP ou le comportement des requêtes, couvert dans comment éviter de se faire bloquer, et la qualité du pool façonne ce qui vous est proposé (réputation d’IP).
Envisagez d’abord les sources sanctionnées, et collectez de façon responsable
Deux choses méritent d’être soulignées dans le voyage spécifiquement.
Utilisez les canaux officiels là où ils conviennent. Beaucoup de compagnies, chaînes hôtelières, et OTA offrent des API, des feeds d’affiliation, ou un accès GDS. Là où un feed sanctionné couvre votre besoin, c’est le meilleur premier arrêt, stable, structuré, et permis. Les proxys servent aux données publiques de tarifs hors de ces canaux ou à l’ampleur sur des marchés et fournisseurs qu’un seul feed ne donnera pas. Commencer par l’API là où elle convient est simplement une meilleure pratique.
Ayez à l’esprit le look-to-book. Les fournisseurs de voyage sont inhabituellement sensibles au volume de recherche qui ne convertit pas parce que chaque recherche a un coût réel pour eux. Collectez à un rythme raisonnable, ne martelez pas un fournisseur, respectez les conditions et rate limits, et collectez des données publiques de tarifs plutôt que quoi que ce soit derrière une authentification. C’est à la fois du bon civisme et de l’autoprotection : la collecte agressive est exactement ce qui pousse une source à renforcer ses défenses. Tenez-vous entièrement à l’écart des données personnelles, et obtenez un conseil juridique pour tout ce qui est incertain (le web scraping est-il légal). Un proxy change l’IP d’où part une requête, pas le fait que vous deviez la faire ; notre politique d’usage acceptable est la source de vérité pour ce qui est permis sur Shifter.
FAQ
Pourquoi ai-je besoin de proxys pour les données de vols et d’hôtels ? Parce que les tarifs sont fixés par point de vente, le même itinéraire coûte des montants différents selon le marché depuis lequel vous réservez, et les fournisseurs se défendent durement contre l’accès automatisé. Depuis un seul endroit vous voyez les tarifs d’un marché, souvent la version bot. Les proxys résidentiels vous laissent collecter le vrai tarif qu’un acheteur dans chaque marché se voit réellement proposer.
Qu’est-ce que la tarification par point de vente ? Les compagnies et les OTA tarifent le même vol différemment selon le marché depuis lequel l’acheteur réserve, le point de vente. C’est pourquoi le même siège peut coûter des montants différents (et dans des devises différentes) depuis les États-Unis face au Royaume-Uni, et pourquoi les données de tarifs précises doivent être collectées par marché.
Ai-je besoin de sessions sticky pour les données de voyage ? Généralement oui. Une recherche de tarif est un flux à plusieurs étapes (recherche, sélection, prix) et les fournisseurs proposent au sein d’une session, donc le flux devrait venir d’une IP cohérente. Utilisez une session sticky pour le flux et tournez entre les recherches, pas au sein d’une.
Devrais-je utiliser une API de compagnie ou d’OTA à la place ? Là où une API sanctionnée, un feed d’affiliation, ou un accès GDS couvre votre besoin, oui, c’est stable et permis. Les proxys servent aux données publiques de tarifs hors de ces canaux ou à l’ampleur entre marchés qu’un seul feed ne fournira pas. Commencez par l’API là où elle convient.
Proxys résidentiels ou datacenter pour les tarifs de voyage ? Résidentiels. Les fournisseurs de voyage détectent et bloquent les IP de datacenter agressivement et peuvent leur servir un tarif différent, donc le datacenter vous donne un résultat faux ou bloqué. Les IP résidentielles voient le vrai tarif, précis par point de vente, qu’un vrai acheteur verrait.
En résumé
Les données de tarifs de voyage sont de façon unique difficiles parce qu’elles sont fixées par point de vente, basées sur la session, périssables, et fortement défendues, tout à la fois. La précision d’un produit d’agrégation de tarifs dépend entièrement de la collecte des tarifs de chaque marché en tant que vrai acheteur réservant depuis ce marché, tenant une session cohérente, à une fraîcheur que les données exigent. Utilisez les feeds sanctionnés là où ils conviennent, et routez le reste via des IP résidentielles accordées au point de vente, avec locale et devise alignés et une session sticky à travers chaque flux de tarif.
Faites cela et vous obtenez les tarifs que les voyageurs se voient réellement proposer, par marché, au lieu d’un chiffre mélangé qui ne décrit aucune réservation réelle. Un réseau de proxys résidentiels de qualité est ce qui rend cette collecte précise par point de vente et complète, et la page tarifs propose les forfaits au Go pour l’essayer contre les routes, établissements, et marchés dont dépend votre produit.