A equipe traduz a interface para uma dezena de idiomas, o desenvolvedor abre o site pelo IP do trabalho, vê o idioma certo e conclui que está tudo funcionando. Na prática, só uma de cinco camadas foi verificada. Moeda, imposto no preço, disponibilidade de entrega e até a composição do catálogo não dependem do idioma do navegador, e sim de onde o site vê o visitante. Sem sair de um endereço real do país em questão, a localização é testada às cegas.

O que muda para o visitante local

A moeda nem sempre é convertida automaticamente pelo idioma: muitas vezes o gatilho é a geolocalização do IP, e um erro na detecção do país mostra dólares onde deveriam aparecer euros ou rublos. O imposto no preço é uma variável à parte: algumas plataformas exibem o valor sem imposto sobre vendas, outras com o imposto incluído, e essa decisão é tomada no backend pelo endereço do visitante, não pelo idioma escolhido na interface.

A disponibilidade de entrega é mais uma camada invisível quando você trabalha a partir do IP de casa. A página do produto pode mostrar "em estoque" para um país e "entrega indisponível" para outro, com um layout absolutamente idêntico. Por fim, a composição do catálogo: parte dos itens é escondida por região por causa de licenças, restrições locais para a categoria do produto ou simplesmente falta de estoque, e isso só aparece quando você acessa a partir de um endereço do país certo.

Por que a tradução da interface só é verificada pela metade

Trocar o idioma no seletor é frontend. Moeda, imposto, entrega e catálogo são lógica de backend ligada à geolocalização do IP e, às vezes, ao ASN: alguns serviços de precificação distinguem um endereço residencial de um de datacenter e mostram ao proxy de datacenter uma versão da página diferente da que o usuário comum vê. A checagem "o texto está traduzido, os botões estão no lugar" responde à pergunta sobre o idioma, mas não à pergunta sobre o que o cliente realmente vai ver no país desejado. A diferença entre um endereço residencial e um móvel nesse tipo de teste também importa. Saiba mais no artigo proxies móveis versus residenciais.

Checklist de verificação da localização

Primeiro, país e cidade pela geolocalização, e não por suposição: o endereço deve resolver exatamente para o lugar onde o usuário-alvo está fisicamente. Segundo, a moeda na página do catálogo e na página de finalização do pedido, que às vezes divergem. Terceiro, a presença e o valor do imposto no preço final. Quarto, a disponibilidade de entrega e de formas de pagamento para a região. Quinto, a composição do catálogo: compare a lista de produtos a partir de um endereço local e do seu IP habitual, e a diferença vai revelar as restrições regionais.

Sexto, o idioma da interface e o formato de datas, números e máscaras de telefone: eles precisam corresponder à localidade, e não apenas ao seletor de idioma. Esses itens devem ser verificados de forma sistemática, e não por amostragem. A metodologia de avaliação da qualidade de proxies descreve em quais métricas se apoiar para que o resultado seja reproduzível.

Bugs típicos de localização que só aparecem com um endereço local

O primeiro é o preço exibido 15–20% abaixo ou acima do real, porque o imposto é aplicado ou não conforme o país do IP, e não o endereço de entrega informado no formulário. O segundo é o botão de finalizar pedido ativo, mas com um erro na última etapa ao tentar entregar na região real: com o IP do trabalho, ninguém percorre esse caminho. O terceiro é o produto visível no catálogo a partir do IP de casa do desenvolvedor, mas que some quando se acessa de um endereço do país-alvo, por causa de um bloqueio regional que ninguém conhecia. O quarto é a moeda trocada pelo idioma, e não pelo país: um usuário francófono do Canadá vê preços em euros em vez de dólares canadenses.

Esses bugs não são pegos nem pelo QA manual feito com o IP do escritório, nem por testes automatizados sem simulação de geolocalização: é preciso uma saída real a partir do país-alvo e, de preferência, com vários tipos de endereço, porque algumas plataformas tratam um IP de datacenter de forma diferente de um residencial. Para entender qual tipo de endereço escolher para a tarefa de verificação, vale ler a análise onde a economia com proxy é só aparente.

Quanto tráfego a verificação de localização consome

Uma página completa de catálogo com imagens pesa de 2 a 5 MB, e uma página de texto sem mídia, de 0,3 a 1 MB. A checagem de cem páginas de produto quanto a preço, imposto e disponibilidade de entrega cabe em cerca de 0,3 a 0,5 GB, e o monitoramento diário de cem páginas em vários países, em 1,5 a 3 GB por mês. A economia vem de desativar o carregamento automático de imagens e fontes na verificação automatizada, e não de escolher o canal mais barato: uma sessão interrompida por um endereço instável custa mais do que os gigabytes economizados.

Perguntas frequentes

Um IP de datacenter basta para testar a localização?

Para verificar o idioma da interface e a disponibilidade básica do site, sim. Para verificar preços, imposto e catálogo, nem sempre: algumas plataformas entregam aos endereços de datacenter uma versão reduzida ou diferente da página, então, para uma checagem de preços precisa, um endereço residencial ou móvel do país desejado é mais confiável.

É preciso um endereço exatamente da cidade onde mora o usuário-alvo?

Para imposto e moeda, em geral basta a precisão no nível do país, às vezes do estado ou da região, se o imposto for regional. Para entrega por CEP e promoções locais, a precisão no nível da cidade pode ser importante, e isso deve ser testado à parte para cada plataforma.

Com que frequência é preciso reverificar a localização se o site já foi testado?

A lógica de preços, impostos e catálogo muda independentemente dos lançamentos da interface: o fornecedor atualizou a tabela de preços, a regra fiscal mudou, surgiu um bloqueio regional. Uma periodicidade razoável é a cada 2–4 semanas ou logo após qualquer alteração na lógica de preços ou de catálogo.

Você pode conferir a localização com os próprios olhos usando um proxy do país desejado: o catálogo de endereços e tipos está disponível na seção de proxies.