Coletando Dados da App Store e do Google Play em Diferentes Países

Dados de aplicativos móveis parecem enganosamente simples. Um app tem uma classificação, uma nota, um preço, uma descrição. Depois você verifica o mesmo app a partir de outro país e cada um desses números é diferente, porque as lojas móveis não são um catálogo único. Elas são um conjunto de vitrines nacionais, cada uma com suas próprias classificações, seu próprio preço, sua própria disponibilidade e suas próprias avaliações em seu próprio idioma. O que você vê a partir do seu próprio escritório é uma vitrine entre bem mais de uma centena, e tratá-la como o panorama global é o erro mais comum em inteligência de mercado móvel.

Isso torna a coleta de dados de app stores um problema de geografia antes de ser um problema de scraping. Aqui está o que as equipes coletam, por que a vitrine em que você cai é decidida por de onde sua requisição parece vir, e como os proxies residenciais permitem ler cada mercado como um usuário local o faria.

O que as equipes móveis coletam

Os dados úteis se dividem em algumas famílias. As classificações vêm primeiro: a posição de um app nos rankings de categoria e geral, e onde ele aparece na busca da loja para uma determinada palavra-chave, ambos calculados por vitrine e que mudam diariamente. Os metadados vêm em seguida, ou seja, o título, o subtítulo, a descrição, as capturas de tela e as notas de versão, que são localizados por mercado e são a matéria-prima para entender como um concorrente se posiciona em cada região. Depois vem o preço, incluindo o preço pago e os níveis de compra dentro do aplicativo, que variam por mercado e moeda em vez de ser um único número convertido pela taxa à vista.

A disponibilidade importa mais do que as pessoas esperam: um app pode simplesmente não estar listado em determinado país, seja por escolha do publicador ou por exigência regulatória, e saber onde um concorrente está e não está presente é um sinal estratégico por si só. As avaliações e resenhas completam o quadro, já que tanto a nota quanto o texto das resenhas são específicos de cada vitrine, e as reclamações em um mercado frequentemente não têm nada a ver com as de outro. Ao redor de tudo isso está o ritmo de lançamentos e o posicionamento editorial, o registro de quem está lançando atualizações e quem está sendo destacado, o que também é por país.

Por que a vitrine que você vê é decidida pelo seu IP

Ambas as lojas encaminham você para uma vitrine nacional, e o encaminhamento é determinado em grande parte por de onde sua conexão parece se originar, reforçado pela localidade do dispositivo e, nos endpoints web, por parâmetros de país explícitos que nem sempre cobrem tudo o que um usuário local real veria. O efeito prático é que uma requisição de um país retorna a resposta desse país para cada pergunta que você fez: suas classificações, seus preços, sua disponibilidade, suas resenhas.

Portanto, coletar a partir de um único local dá a você a visão de uma vitrine, não importa quantos apps você cubra. Você não consegue inferir uma classificação japonesa a partir de uma alemã, e não consegue ver que um app está indisponível em um mercado olhando para um mercado onde ele está disponível. Para ler uma vitrine, a requisição precisa vir de dentro dela.

Um proxy residencial com direcionamento por país faz exatamente isso, colocando cada requisição no mercado cuja vitrine você quer ler, o que é a mesma segmentação geográfica legítima usada para acessar qualquer dado público que varia por região. Vale notar, e diferente dos casos de varejo e viagens: as vitrines de aplicativos são nacionais, então o direcionamento por país é a granularidade correta aqui e o direcionamento em nível de cidade normalmente não acrescenta nada. Combine o idioma e a localidade que você apresenta com o país de onde você sai, para que a vitrine retorne os metadados localizados que um usuário local realmente leria.

Escala: apps vezes países vezes diariamente

O volume nessa carga de trabalho vem da multiplicação, não de qualquer consulta pesada isolada. Algumas centenas de apps monitorados em trinta ou quarenta vitrines, atualizados diariamente, com verificações de classificação por palavra-chave sobrepostas, somam uma quantidade de requisições que atingirá os limites de taxa por IP imediatamente se vier de poucos endereços. Os endpoints das lojas limitam agressivamente, e uma resposta limitada não é apenas um atraso, é um buraco em uma série temporal diária que você não pode preencher depois.

A resposta é a distribuição: espalhar as verificações pelo pool para que cada endereço permaneça dentro dos limites enquanto a taxa de transferência agregada escala, o que é a lógica de balanceamento de carga por trás de qualquer coletor de alto volume e para o que servem as conexões concorrentes ilimitadas. Se você está se perguntando quanta dispersão isso implica na prática, o raciocínio está detalhado em quantos IPs de proxy você realmente precisa, e a versão resumida é que depende da sua taxa por vitrine, não de um número de pool de destaque.

Recuperando uma vitrine real

Os endpoints web das lojas são defendidos, e faixas de endereços de datacenter são tratadas com rigor porque a coleta automatizada contra elas é constante. O que você recebe de volta de um endereço sinalizado frequentemente não é um bloqueio limpo, mas algo pior para a qualidade dos dados: uma resposta limitada, uma página genérica ou um resultado parcial que parece dado e não é. Esse é o modo de falha contra o qual você precisa projetar, porque ele corrompe um conjunto de dados silenciosamente.

Os proxies residenciais roteiam cada requisição por uma conexão real, de classe residencial, então uma verificação parece um usuário comum abrindo uma página da loja a partir de seu próprio país, e um endereço limpo com boa reputação retorna a vitrine genuína, enquanto um sinalizado é desafiado ou despachado com algo falso. O IP é necessário, mas não suficiente, então ajuste o ritmo das suas requisições com bom senso e trate os sinais que disparam bloqueios em vez de martelar um endpoint só porque ele responde.

Sessões fixas para leituras paginadas

A maioria das verificações de vitrine são requisições únicas e devem rotacionar. A exceção é qualquer coisa que pagina, e nessa carga de trabalho isso significa principalmente resenhas. Percorrer várias páginas de resenhas de um app em um país é uma sequência, e se o endereço de saída mudar no meio dela, você pode obter ordenação inconsistente, entradas repetidas ou uma reinicialização de volta à primeira página. Uma sessão fixa mantém um endereço para essa travessia, de modo que a paginação permaneça coerente, e então o próximo app ou país começa uma sessão nova. Rotacione a varredura diária ampla, mantenha-se fixo dentro de uma leitura paginada.

Mantendo a série honesta

As classificações são uma série temporal, e uma série temporal só é tão boa quanto suas lacunas. Um dia ausente em um país é um dia sobre o qual você não pode raciocinar, então trate a confiabilidade da coleta como parte do problema de qualidade dos dados, e não como higiene operacional. Monitore o pipeline por vitrine, porque uma taxa de sucesso que cai silenciosamente em um mercado é uma linha de tendência distorcida antes de ser qualquer outra coisa, e vale a pena validar que o que voltou é de fato uma vitrine, e não uma página genérica ou limitada. Essa é a mesma disciplina que o monitoramento contínuo de preços e o monitoramento de disponibilidade exigem, e o resultado coletado alimenta o mesmo tipo de análise de dados alternativos.

Colete de forma responsável

Os limites honestos, e eles importam aqui. Ambas as plataformas publicam APIs oficiais de relatórios para seus próprios apps, e essas são a fonte correta para os dados de desempenho do seu próprio app: são estruturadas, precisas e dentro dos termos. A coleta pública de vitrines é para inteligência competitiva e de mercado, as coisas que nenhuma API vai lhe entregar sobre o app de outra pessoa, e deve permanecer sobre dados públicos que qualquer visitante naquele país possa ver, dentro dos termos de serviço e das diretivas de robots de cada plataforma, em um ritmo de requisição educado.

Duas linhas valem ser ditas com clareza. Dados de resenhas são conteúdo gerado pelo usuário que pode conter informações pessoais, então trate-os sob as regras de privacidade aplicáveis e não construa perfis de avaliadores individuais. E isso é apenas medição: coletar dados de classificação é pesquisa de mercado, enquanto tentar influenciar classificações, contagens de instalação ou resenhas é manipulação, contra as regras de todas as plataformas, e não é algo para o qual proxies devam ser usados. Ler a vitrine é a tarefa; mexer nela não é.

Uma leitura mínima por país

O direcionamento vive no nome de usuário no gateway, então fixar uma vitrine é um único campo. Combine o cabeçalho de idioma com o mercado que você está lendo:

import requests

MARKETS = ["us", "gb", "de", "jp", "br"]

def storefront(country, lang):
    proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
    r = requests.get(
        "https://apps.example-store.com/app/id123456789",
        proxies={"http": proxy, "https": proxy},
        timeout=20,
        headers={"Accept-Language": lang},
    )
    r.raise_for_status()
    return r.text            # parse rank, price, availability, metadata

for country in MARKETS:
    html = storefront(country, "en-US" if country in ("us", "gb") else None)
    record(country, html)    # one row per storefront per day

Execute a mesma leitura em cada mercado que você monitora para construir o panorama por vitrine, mantenha as leituras paginadas de resenhas em sua própria sessão fixa, e amostre em um cronograma diário fixo para que a série seja comparável entre países. Os padrões gerais de cliente vêm do guia sobre uso de proxies residenciais com Python, e o ângulo específico de resenhas é abordado em monitoramento de avaliações de clientes.

Conclusão

Um app não tem uma classificação, um preço ou uma nota. Ele tem um diferente em cada vitrine nacional, e cada uma delas só é legível de dentro daquele país. Isso torna a cobertura por país o requisito central da inteligência de mercado móvel, e faz da coleta a partir de um único local uma garantia de um panorama parcial e enganoso. Os proxies residenciais resolvem exatamente isso: direcionamento por país para ler cada vitrine como um usuário local o faz, um pool grande para espalhar uma varredura diária por muitos apps e mercados sem disparar limites de taxa, endereços limpos de classe residencial para que o que volta seja uma vitrine genuína e não um placeholder limitado, e sessões fixas para as leituras paginadas. Use as APIs oficiais para seus próprios apps, mantenha a coleta competitiva sobre dados públicos e dentro dos termos de cada plataforma, e nunca passe de medir os rankings para tentar movê-los.

Essa camada de coleta é o que os proxies residenciais oferecem, um grande pool de IPs reais, de classe residencial, com direcionamento por país e sessões fixas onde uma sequência precisar de uma. O preço por GB atende bem a essa carga de trabalho, já que as verificações de vitrine são pequenas e frequentes e o custo acompanha os dados que você realmente extrai, em vez do número de mercados que você observa.