Casos de uso

Precificar uma assinatura de forma diferente por região

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/.