Cobrar o mesmo preço em todo lugar ignora o quanto o poder de compra e a concorrência variam de um mercado para outro. Uma empresa de software que vende um produto por assinatura queria cobrar menos em alguns mercados e manter o preço em outros, uma estratégia bastante comum, mas fazer isso exigia saber em qual mercado o visitante realmente estava antes mesmo de o preço aparecer na página.
Perguntar diretamente foi a primeira ideia, e a errada. Um seletor de país em uma página de preços soa como um convite para procurar a opção mais barata mentindo sobre a localização, e acrescenta uma decisão a uma página cuja única função é levar o visitante até o botão de checkout com o mínimo de atrito possível. A empresa queria que o preço certo simplesmente aparecesse.
A solução rodava no servidor, antes de a página de preços ser retornada. /v1/ip recebia o endereço IP do visitante e retornava, entre outros, um campo de país, que a página de preços usava para escolher qual tabela de preços renderizar. Um visitante de um mercado com o preço padrão via o preço padrão. Um visitante de um mercado em que a empresa havia definido uma tarifa regional via essa tarifa, sem seletor, sem clique extra e sem nenhum sinal visível de que algo tivesse sido detectado.
A empresa tratou o país detectado como ponto de partida, e não como um fato definitivo, já que um visitante em uma VPN corporativa ou viajando para o exterior poderia ser identificado como estando no mercado errado para a sua real elegibilidade de preço. Em vez de bloquear alguém de forma rígida, o fluxo de checkout permitia uma exceção feita pelo suporte para o caso raro em que o país de cobrança real do cliente não correspondia ao que o IP sugeria, tratada como exceção e não embutida no fluxo principal, já que colocar dúvida constante na página de preços por causa de um caso extremo que afetava uma pequena fração dos visitantes teria desfeito a simplicidade que a mudança toda pretendia trazer.
Um detalhe era importante o suficiente para ser comunicado diretamente à equipe financeira: o próprio My Geocode cobra em EUR em todos os lugares onde opera, sem preços regionais próprios além da cota gratuita padrão, do crédito pré-pago e da chave Unlimited. Essa é uma questão diferente de saber se uma empresa que usa a API quer aplicar preços regionais ao seu próprio produto, uma decisão que cabe inteiramente ao negócio construído sobre ela. A consulta fornece apenas o sinal de país. O que a empresa faz com esse sinal, e como define os preços com base nele, continua sendo decisão dela.
O volume de requisições acompanhava as visualizações da página de preços, normalmente uma pequena fração do tráfego total do site, já que a maioria dos visitantes do site de uma empresa de software não está ativamente pesquisando o preço do produto em uma determinada visita. Isso manteve o uso bem dentro da cota gratuita diária durante a maior parte do ano, passando para o crédito pré-pago apenas em períodos de tráfego excepcionalmente alto na página de preços, como perto do lançamento de um produto.
Preços regionais bem feitos devem ser invisíveis como mecanismo e óbvios como resultado: o preço certo, na primeira renderização, sem etapa extra. A documentação do endpoint está em /docs/ipv4-lookup/ e /docs/ipv6-lookup/, e os detalhes de preços da própria API estão em /pricing/.
Um código postal e uma cidade que não batem em um formulário de pedido parecem um pequeno erro de digitação até virarem uma entrega enviada para uma região totalmente diferente do país.
Uma empresa de logística queria um alerta simples no momento em que um caminhão de entregas entrasse ou saísse do local de um cliente específico, sem construir ou licenciar uma plataforma completa de rastreamento de frota.
Uma ferramenta de colaboração queria que os colegas de equipe vissem, de relance, onde um colega estava e mais ou menos que horas eram para ele, sem que ninguém precisasse digitar isso no perfil.