Pratiquer le même prix partout ignore à quel point le pouvoir d'achat et la concurrence varient d'un marché à l'autre. Un éditeur de logiciels qui vendait un produit sur abonnement voulait baisser son prix sur certains marchés et le maintenir sur d'autres, une stratégie assez courante, mais pour cela il fallait savoir sur quel marché se trouvait réellement un visiteur avant même que le prix ne s'affiche sur la page.
Demander directement a été la première idée, et la mauvaise. Un sélecteur de pays sur une page de tarifs ressemble à une invitation à chercher l'option la moins chère en mentant sur sa localisation, et il ajoute une décision sur une page dont le seul rôle est d'amener le visiteur jusqu'au bouton de paiement avec le moins de friction possible. L'entreprise voulait que le bon prix apparaisse tout simplement.
La solution s'exécutait côté serveur, avant le renvoi de la page de tarifs. /v1/ip prenait l'adresse IP du visiteur et renvoyait notamment un champ de pays, que la page de tarifs utilisait pour choisir la grille de prix à afficher. Un visiteur d'un marché au prix standard voyait le prix standard. Un visiteur d'un marché pour lequel l'entreprise avait fixé un tarif régional voyait ce tarif à la place, sans sélecteur, sans clic supplémentaire et sans aucun signe visible que quoi que ce soit ait été détecté.
L'entreprise traitait le pays détecté comme un point de départ plutôt que comme un fait établi, car un visiteur sur un VPN d'entreprise ou en voyage à l'étranger pouvait être associé au mauvais marché par rapport à son éligibilité tarifaire réelle. Au lieu de bloquer strictement qui que ce soit, le parcours de paiement permettait une dérogation par le support pour le cas rare où le pays de facturation réel d'un client ne correspondait pas à ce que suggérait l'IP. Ce cas était traité comme une exception plutôt qu'intégré au parcours principal, car introduire un doute permanent sur la page de tarifs pour un cas limite touchant une petite fraction des visiteurs aurait défait la simplicité que tout ce changement devait apporter.
Un détail méritait d'être signalé directement à l'équipe financière : My Geocode facture lui-même en EUR partout où il opère, sans tarification régionale propre au-delà du quota gratuit standard, du crédit prépayé et de la clé Unlimited. C'est une question différente de celle de savoir si une entreprise qui utilise l'API souhaite appliquer une tarification régionale à son propre produit, une décision qui revient entièrement à l'entreprise qui s'appuie dessus. La recherche fournit uniquement le signal de pays. Ce qu'une entreprise fait de ce signal, et la manière dont elle fixe ses prix en conséquence, reste sa propre décision.
Le volume de requêtes suivait les consultations de la page de tarifs, généralement une petite fraction du trafic total du site, puisque la plupart des visiteurs du site d'un éditeur de logiciels ne consultent pas activement les prix lors d'une visite donnée. L'utilisation est ainsi restée bien dans les limites du quota gratuit quotidien pendant la majeure partie de l'année, ne passant au crédit prépayé que lors de périodes de trafic inhabituellement élevé sur la page de tarifs, par exemple autour d'un lancement de produit.
Une tarification régionale bien faite doit être invisible en tant que mécanisme et évidente en tant que résultat : le bon prix, dès le premier affichage, sans étape supplémentaire. La documentation de l'endpoint se trouve sur /docs/ipv4-lookup/ et /docs/ipv6-lookup/, et les détails de la tarification de l'API elle-même sur /pricing/.