Viagem é a vertical de preços mais difícil de coletar com precisão, e não é nem perto. Um preço em uma página de produto de varejo é mais ou menos um fato: é o mesmo para todos em um determinado mercado, e muda lentamente. Uma tarifa aérea não é nada disso. O mesmo assento no mesmo voo pode ser cotado a preços diferentes dependendo de onde você está pesquisando, em qual moeda você está, se você já pesquisou antes, e o que o sistema de receita da companhia aérea decidiu nos últimos minutos. As tarifas de hotéis se comportam de forma semelhante.
Para uma equipe de agregação de tarifas ou inteligência de viagens, isso é o problema inteiro em uma frase: a tarifa que o comprador vê depende de quem e onde o provedor acha que ele está. Colete esses dados a partir de um único IP de escritório e você não obtém apenas um retrato parcial, você obtém as tarifas erradas, cotadas para um mercado em que você não está. Este é um aprofundamento do que foi abordado em por que a agregação de tarifas de viagem precisa de proxies, com foco na mecânica que faz dos proxies residenciais a camada de acesso certa para dados de voos e hotéis.
O que você está coletando
A coleta de dados de viagem abrange algumas superfícies relacionadas:
- Tarifas de voos — preço por rota, data, cabine e classe tarifária, além de disponibilidade, regras tarifárias e serviços adicionais (bagagens, assentos), em companhias aéreas e nas OTAs e mecanismos de metabusca que as revendem.
- Tarifas de hotéis — tarifa por noite por propriedade, data, tipo de quarto e ocupação, além de disponibilidade e termos de cancelamento.
- Aluguel de carros e pacotes — a mesma estrutura, precificada por local e data.
O elo comum é que cada um desses itens é cotado para um comprador específico, em um mercado específico, em um momento específico, que é exatamente por que isso é um problema de acesso.
Por que viagem é, de forma única, um problema de proxy
A raspagem de varejo tem uma dimensão geográfica. Viagem tem quatro propriedades que se somam, e todas as quatro recaem sobre a camada de proxy.
1. As tarifas são precificadas por ponto de venda. Essa é a característica definidora. Companhias aéreas e OTAs precificam o mesmo itinerário de forma diferente por ponto de venda, o mercado a partir do qual o comprador está reservando. Uma ida e volta de Nova York para Londres pode ter uma tarifa diferente, em uma moeda diferente, reservada a partir de um POS dos EUA versus um do Reino Unido ou da Índia. Isso não é um caso extremo; é o núcleo do negócio, e é por isso que a comparação de tarifas entre mercados existe. Para capturar a tarifa que um comprador em um determinado mercado realmente vê, você precisa parecer estar naquele mercado, o que significa um IP residencial lá (segmentação por país e cidade).
2. As tarifas são baseadas em sessão. Uma busca de tarifa não é uma única requisição, é um fluxo: busca, resultados, seleção de itinerário, confirmação de preço. Os provedores cotam e mantêm preços dentro dessa sessão, e uma mudança de identidade no meio do fluxo não se parece em nada com um comprador real. É por isso que sessões persistentes não são opcionais para viagem da forma que são apenas convenientes em outros lugares (sticky vs rotativo): todo o fluxo de tarifas precisa vir de uma identidade consistente.
3. As tarifas são perecíveis. Sistemas de gestão de receita repreçam constantemente e a disponibilidade é em tempo real, então uma tarifa que você coletou há uma hora já pode estar errada. Atualidade é um requisito de primeira classe, o que significa coleta contínua e em alto volume em vez de uma varredura periódica.
4. Viagem é defendida agressivamente. Companhias aéreas monitoram sua taxa de “look-to-book”, o número de buscas por reserva efetiva, e tratam o tráfego de busca de alto volume que não converte como um custo e uma ameaça. Sistemas GDS, OTAs e mecanismos de metabusca operam anti-bot sério. Um IP de datacenter é sinalizado rapidamente e recebe um CAPTCHA, um bloqueio, ou, o pior de tudo, uma tarifa diferente, então você registra um preço que nenhum viajante real seria cotado (por que scrapers são bloqueados).
Juntando tudo: para coletar dados de viagem com precisão você precisa parecer um comprador real, no mercado certo, mantendo uma sessão consistente, em escala, continuamente. Esse é um problema com o formato de proxy residencial.
Onde os proxies residenciais se encaixam
Um proxy residencial roteia suas requisições através de IPs reais de consumidores, então os provedores de viagem cotam você como fariam com um comprador local genuíno. Especificamente:
A verdadeira tarifa por ponto de venda. Com segmentação geográfica para o país que você precisa, você coleta a tarifa como um comprador realmente reservando a partir daquele POS, tarifas dos EUA a partir dos EUA, tarifas alemãs a partir da Alemanha, cada uma rotulada por mercado. Sua comparação entre mercados finalmente se apoia em preços reais por POS em vez de uma localização extrapolada.
Tarifas reais, não a versão para bots. IPs residenciais carregam confiança de usuário real, então você captura o preço e a disponibilidade realmente cotados, não a resposta degradada, bloqueada, ou com CAPTCHA servida a tráfego suspeito. Para viagem, onde a “tarifa de bot” pode ser um número genuinamente diferente, essa é a diferença entre dados utilizáveis e ruído.
Coleta consistente em sessão. Mantenha uma sessão sticky pela duração de um fluxo de tarifa para que busca, seleção e preço venham todos de uma identidade, o que é tanto o que o provedor espera quanto o que mantém a cotação coerente. Rotacione para uma nova identidade entre buscas, não dentro de uma.
Cobertura completa e atualizada. Um grande pool rotativo permite que você execute muitas rotas, datas e mercados continuamente sem que um punhado de IPs acione limites de taxa, o que é o que mantém os dados perecíveis de tarifas atuais em vez de desatualizados (os mesmos princípios de qualidade de coleta como em proxies residenciais para coleta de dados).
Como funciona
No gateway Shifter, você segmenta um ponto de venda codificando o país no nome de usuário do proxy, um único endpoint, sem listas de IP:
# Coletar uma tarifa como um comprador reservando a partir dos EUAcurl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://fare-source.example
# A mesma rota, precificada a partir de um ponto de venda do Reino Unidocurl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 https://fare-source.exampleDuas práticas específicas de viagem importam mais do que a mecânica. Primeiro, alinhe o idioma local e a moeda com o ponto de venda, uma requisição de POS do Reino Unido que envia um idioma local dos EUA ou solicita USD é uma inconsistência que produz resultados errados ou bloqueados; combine o Accept-Language e a seleção de moeda do site com o mercado. Segundo, mantenha uma sessão sticky ao longo de todo o fluxo de tarifa adicionando -sid-<id>-ttl-<seconds> ao nome de usuário, para que a busca de múltiplas etapas permaneça em um único IP. Bloqueios consistentes (em vez de ocasionais) apontam para qualidade de IP ou comportamento de requisição, abordado em como evitar ser bloqueado, e a qualidade do pool molda o que é cotado a você (reputação de IP).
Considere fontes sancionadas primeiro, e colete de forma responsável
Duas coisas merecem ênfase especificamente em viagem.
Use canais oficiais onde eles se encaixam. Muitas companhias aéreas, redes de hotéis e OTAs oferecem APIs, feeds de afiliados, ou acesso GDS. Onde um feed sancionado cobre sua necessidade, é a melhor primeira parada, estável, estruturado e permitido. Proxies são para dados públicos de tarifas fora desses canais ou para amplitude entre mercados e provedores que um único feed não vai lhe dar. Começar pela API onde ela se encaixa é simplesmente uma prática melhor.
Fique atento ao look-to-book. Provedores de viagem são incomumente sensíveis a volume de busca que não converte porque cada busca tem um custo real para eles. Colete em um ritmo razoável, não sobrecarregue um provedor, respeite termos e limites de taxa, e colete dados públicos de tarifas em vez de qualquer coisa por trás de autenticação. Isso é tanto boa cidadania quanto autopreservação: coleta agressiva é exatamente o que leva uma fonte a escalar suas defesas. Evite dados pessoais por completo, e busque aconselhamento jurídico para qualquer coisa incerta (a raspagem de web é legal). Um proxy muda de qual IP uma requisição vem, não se você deveria estar fazendo essa requisição; nossa política de uso aceitável é a fonte da verdade sobre o que é permitido no Shifter.
Perguntas frequentes
Por que preciso de proxies para dados de voos e hotéis? Porque as tarifas são precificadas por ponto de venda, o mesmo itinerário custa quantias diferentes dependendo do mercado a partir do qual você reserva, e os provedores se defendem fortemente contra acesso automatizado. De uma única localização você vê as tarifas de um mercado, muitas vezes a versão de bot. Proxies residenciais permitem que você colete a tarifa real que um comprador em cada mercado realmente vê cotada.
O que é precificação por ponto de venda? Companhias aéreas e OTAs precificam o mesmo voo de forma diferente com base no mercado a partir do qual o comprador está reservando, o ponto de venda. É por isso que o mesmo assento pode custar quantias diferentes (e em moedas diferentes) a partir dos EUA versus do Reino Unido, e por que dados precisos de tarifas precisam ser coletados por mercado.
Preciso de sessões sticky para dados de viagem? Geralmente sim. Uma busca de tarifa é um fluxo de múltiplas etapas (busca, seleção, preço) e os provedores cotam dentro de uma sessão, então o fluxo deve vir de um IP consistente. Use uma sessão sticky para o fluxo e rotacione entre buscas, não dentro de uma.
Devo usar uma API de companhia aérea ou OTA em vez disso? Onde uma API sancionada, feed de afiliados, ou acesso GDS cobre sua necessidade, sim, é estável e permitido. Proxies são para dados públicos de tarifas fora desses canais ou para amplitude entre mercados que um único feed não vai fornecer. Comece pela API onde ela se encaixa.
Proxies residenciais ou de datacenter para tarifas de viagem? Residenciais. Provedores de viagem detectam e bloqueiam IPs de datacenter agressivamente e podem servir a eles uma tarifa diferente, então datacenter lhe dá um resultado errado ou bloqueado. IPs residenciais veem a tarifa real, precisa por ponto de venda, que um comprador genuíno veria.
Conclusão
Dados de tarifas de viagem são difíceis de forma única porque são precificados por ponto de venda, baseados em sessão, perecíveis e fortemente defendidos, tudo ao mesmo tempo. A precisão de um produto de agregação de tarifas depende inteiramente de coletar as tarifas de cada mercado como um comprador real reservando a partir daquele mercado, mantendo uma sessão coerente, na atualidade que os dados exigem. Use feeds sancionados onde eles se encaixam, e roteie o resto através de IPs residenciais combinados com o ponto de venda, com idioma local e moeda alinhados e uma sessão sticky ao longo de cada fluxo de tarifa.
Acerte isso e você obtém as tarifas que os viajantes realmente veem cotadas, por mercado, em vez de um número combinado que não descreve nenhuma reserva real. Uma rede de proxies residenciais de qualidade é o que torna essa coleta precisa por ponto de venda e completa, e a página de preços tem os planos por GB para testá-la contra as rotas, propriedades e mercados dos quais seu produto depende.